[flagged]
Someone that knows basic Go can build a server that would be just as performant as one in Rust with no optimizing, no external dependencies, fewer lines of code, and in minutes not hours or weeks.
Yes, obviously a server in Rust will be faster once you optimize it, but the point is that you don't really have to do optimizations with Go to get fast concurrent code. You pretty much get fast programs by default. This is why it is so popular.
So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would do is pull in Tokio/Tower or similar. At which point you'll already have a better foundation than Go provides out of the box, plus all the other benefits of Rust like a proper type system.
However note that needing to pull in libraries and frameworks, make those choices, etc is explicitly more complex than Go’s approach with a very strong standard library that does most of the things you want. Besides all of the other things that’s complicated about Rust, you also need to learn the ins and outs of the ecosystem, memorize the names of a bunch of packages, remember what fits together with what from Cargo. I guess in Rust the HTTP library of choice today is “tower” and you need “tokio” so it can do IO? Can’t tell from the names, so need to memorize. The choice in Go is simple and understandable in plain English: “net/http” does HTTP things.
This sounds like a common mantra from people who love Rust to the point they'd use it even for basic scripting.
No, Go does not losing any mindshare to Rust whatsoever. Rust is an interesing choice when you need all these memory management tricks but treality is - in most cases you don't really care because Go is just good enough.
Add to this that developing in Go requires much less time and effort (in other words money) and you will see that it won't be replaces by Rust in areas of web dev, systems integration etc.
Rust is good for systems programming, embeded devices and so on.
Show me the empirical evidence otherwise it's just an opinion.
I also have an opinion which is that Go and Rust are about equal in complexity.
I don't think this is really a "citation needed" kind of discussion. This is basically how Rust is advocated--you do work to satisfy the borrow checker, but in return, you get a program which is both high-performance and safe. In Go, the safety cost is paid at runtime.
I also wouldn't ask for evidence that Rust is faster than Go at runtime. This is well known.
If it helps, think of the language ecosystem, including Go and Rust, as Pareto-efficient.
I'd say you pay for the complexity when you learn the language. Once satisfying the borrow checker becomes second nature, it feels just as fast to write as go (in my opinion, after switching from go to rust for most of my scratchpad code)
Really core stuff is nice to write in Rust. Parsers, core algorithms, that kind of thing.
However, I write a lot of code in Go that does stuff like glue together libraries, call APIs, etc. That stuff is really nice to use in Go.
I'd also say that when I need to use a library in Rust, it's a coin-flip whether the library has a straightforward interface, or whether it is some monster with tons of template parameters, or maybe even a bunch of macro rules that you are supposed to use. Go libraries tend to be much simpler to use than Rust libraries.
How about the code written for commercial purposes? As in "you have to write a service that satisfies business requirements and you have to finish by time T"
I will come to you with "the empirical evidence" as soon as I decide to write a paper on the topic.
Needless to say we both are entitled to our respective opinions and will have to live with that.
Keep in mind that the arena thing is not from the Go developers for general purpose usage, I suspect it’s an internal detail that might be useful only for certain very specific use cases (e.g. maybe proto deserialization, where you hang a million tiny objects off a single GC’ed one and can deterministically bound lifetimes).
Now suddenly we have generics, and a bunch of other pretty significant changes, but no clear vision of where Go is going. Will "Go 2.0" with breaking changes happen or not? Will error handling be overhauled or not? Will radical changes proposed by core developers, like arbitrary-precision integers, be implemented? I'm not sure if there's really a lack of vision or just a lack of proper communication, but from the outside it's very confusing.
It has been made clear that this will not happen. The changes of the last years ARE the "Go 2" initiative, but there won't be a major version bump.
I know some people did the knee-jerk attacks like "Go sucks, it should have had generics long ago" or "Go is fine, it doesn't need generics". I don't think we ever needed to take those attitudes seriously.
> Will error handling be overhauled or not?
Error handling is a thorny issue. It's the biggest complaint people have about Go, but I don't think that exceptions are obviously better, and the discriminated unions that power errors in Rust and some other languages are conspicuously absent from Go. So you end up with a bunch of different proposals for Go error handling that are either too radical or little more than syntactic sugar. The syntactic sugar proposals leave much to be desired. It looks like people are slowly grinding through these proposals until one is found with the right balance to it.
I honestly don't know what kind of changes to error handling would appear in Go 2 if/when it lands, and I think the only reasonable answer right now is "wait and find out". You can see a more reasonable proposal here:
https://github.com/golang/proposal/blob/master/design/go2dra...
Characterizing it as a "lack of vision" does not seem fair here--I started using Rust back in the days when boxed pointers had ~ on them, and it seemed like it took Rust a lot of iterations to get to the current design. Which is fine. I am also never quite sure what is going to get added to future versions of C#.
I am also not quite sure why Go gets so much hate on Hacker News--as far as I can tell, people have more or less given up on criticizing Java and C# (it's not like they've ossified), and C++ is enough of a dumpster fire that it seems gauche to point it out.