Hacker News Reader

Comment by konart | Hacker News Reader

>Go from losing more mindshare to Rust

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.

View on HN

> developing in Go requires much less time and effort

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 write both Go and Rust. Rust is definitely more complex. Go, the language, is simpler, which means that Go code is more verbose and explicit. Rust, the language, is more complex. People take advantage of the complexity and implement all sorts of macros and templates. The code is shorter but less explicit.

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.

> Rust, the language, is more complex. People take advantage of the complexity and implement all sorts of macros and templates.

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)

I think it does depend on the kind of code you are writing. I also think it is a bit of a cop-out to say that "once satisfying the borrow checker becomes second nature"... maybe I just write different code from you, but I periodically run into really thorny situations in Rust where figuring out how to satisfy the borrow checker is difficult. This happens most often in application programming, it's not something that I really run into when I'm writing libraries.

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.

> most of my scratchpad code

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"

And you’re going to amortize what you learned over years. A short learning curve is like a toolbox that’s nearly empty.

This is a comment based on an opinion (based on experience of the author and some of this collegues), yes.

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.

Reply on news.ycombinator.com