Hacker News Reader

Comment by gnur | Hacker News Reader

I don’t think this should surprise anyone. Go is an excellent language for quick prototyping and easy distribution.

The investment to become fluent in Go might literally be an order of magnitude less than becoming fluent in rust.

Rust might be the perfect language in terms of capabilities and safety, but it is far from a simple language.

The function signatures from even some simple methods have become ridiculous. I’ve seen enough examples where it was needed to unpack a value two or three times to get the value you want.

The perfect language probably doesn’t exist, but go is one of the easiest compiled and strongly typed languages to learn. And that in itself is quite an achievement.

View on HN

> The investment to become fluent in Go might literally be an order of magnitude less than becoming fluent in rust.

From my own experience with both languages, it's actually closer to two orders of magnitude. One order of magnitude might be correct for the language, but Rust requires you to navigate the ecosystem very early on [1], whereas Go gets you much farther with its stdlib in its common usecases.

[1] For example, you pretty much immediately have to decide "Tokio vs async-std vs std" if you want to do anything with IO, or "Actix vs Rocket vs whatever" for HTTP, at a point where you probably cannot gauge the ramifications of these choices properly.

Anecdotal, but I've found rust much easier to grok and become comfortable to work in than I have with Go - partially due to the docs, but largely because of the perceived complexity in explicitly typing and handling of options and results.

With rust, I very rarely feel like the code I'm writing might not be correct for a technical reason, whereas with Go, I find myself very often having to think too much about how best to actually do something "safely" or "correctly" because it's inherently possible in a way that rust makes either impossible, or at the very least, warns you profusely.

Isn’t having to check for integer overflows in rust an example of the exact opposite of your example, or is this something that requires extra effort in go as well?

You don't have to check for overflows in rust? It does by default in debug and not in release and has five explicit adding methods for any of the ways it could behave

I tried learning go a few times years ago but got stuck with tooling issues and when I made it to work I was put off by the syntax / verbosity, error messages and never managed to learn it.

I started doing a project in rust and things just made a lot of sense (with previous haskell, C/C++, JS experience), fixing compiler errors until green was easy. Eventually I developed an understanding for fixing lifetime related issues, which is the only complicated bit in rust (and hard to fix ones are not even that common).

I'm definitely more confident in the correctness of my programs written in rust than anything else - even than haskell, my previous gold standard experience, given the lack of GC and laziness.

I think different people will grok different languages.

From a maintainability point of view, from what I experienced in a few companies, most developers will not feel comfortable with either go or rust.

Reply on news.ycombinator.com