top | item 41763894

(no title)

monlockandkey | 1 year ago

No harm if all these requirements are met by some framework to cater to the Rust community.

In my opinion you should for 99% of cases use Golang for your web backend. Any other languages there are tradeoffs you are making.

Go:

- very easy to learn and grok Go code

- static typing

- fast compilation

- single binary (easier deployment)

- strong standard library

- large library ecosystem

- go routines for concurrency

- highly performant

Maybe Java,Kotlin and C# but they are still an order of magnitude more complex and resource heavy than Go.

discuss

order

neonsunset|1 year ago

Go is stuck in the eighties and replies like this are a good demonstration why it's very difficult to engage in intelligent discussion with many from Go communities.

As someone who mainly specializes in .NET, I have had incomparably better time participating in Java and C++ ones because people there are usually able to acknowledge pros and cons of various platforms, how they evolved and where are their strengths and weaknesses.

The average level of understanding and ability to consider what is the dev flow and how the language of choice impacts it in Go ones seems to be just so much worse it's not even funny.

That is to say, goroutines are discount futures/tasks which force you into synchronizing the "yielding of result" manually either via a channel or a waitgroup and a collection, or similar. Not to mention they are also much more expensive than .NET Tasks. I have not measured the cost of Java's new green threads yet but assume they are going to be in the same ballpark of memory cost as Goroutines, but with drastically better steady state performance provided by OpenJDK HotSpot when it comes to regular application code.

And lastly - Go requires you writing heaps of boilerplate for simplest things, Go channels come with a lot of footguns and gotchas you have to learn, standard library has weird omissions, type system is static but weak and as the demands put onto Go continue to become more complex, as more and more developers are forced into it, the language becomes the kind of unreadable soup you accuse other languages of. Just look at range over funcs and iterators discussions recently. It's ugly and token-heavy. And you will see a lot of code like this if you browse random libraries on Github - it's unnecessarily bulky, in a way that is excusable for true system programming languages but not in Go which has even higher level of abstraction runtime than .NET.