Hacker News Reader

Comment by klodolph | Hacker News Reader

I’m still learning Rust, but I’m developing a deeper appreciation for Go. I’ve already learned Go. As far as I can tell, I’m a Go expert.

Rust has a pretty large surface area. There’s a ton of places where you can get overwhelmed by choices. For example, when you’re working with slices, you might find yourself thinking about the pros and cons of different approaches using indexes, convenience functions, pattern matching, or iterators.

It’s a big toolbox, and sometimes I wish I had a smaller toolbox, even if it means giving up the choice of which tools to keep.

So, I’ll still be learning Rust for a while, too.

View on HN

Pretty much what I am thinking. When I use Rust, at the end of the day I will have spent more time with the language instead of my actual task, and I don't see this changing given the rate Rust is still changing. It feels like you have to be a "programming language afficionado" to use Rust properly.

Whereas in Go, there is always only one reasonable way to do a specific task. You almost forget about the language and just get stuff done.

Here is a very practical example.

We chose Rust for the current project because our Python program took more than 1TB of RAM. Rust program carefully manually laying out memory takes 75G. Other choices in this case are C/C++, but after you get a hang of Rust, it's actually easier because you don't spend days inspecting core dumps in gdb: once it compiles it actually works.

What kind of program requires that much ram?

> What kind of program requires that much ram?

Elasticsearch is written in Java, and routinely uses 30GB+ of RAM. I suspect if it was written in Python, it would use an order of magnitude more.

I think you are confusing VM with RSS memory metrics. Elasticsearch is not using routinely 30GB+ of RAM, I am using it on machines that have a lot less RAM. You can additionally set how much RAM you want to give to JVM.

It would depend on the data set you want cached in memory I would think? And you set that in a configuration file I suppose. You can probably set it to use 128MB or RAM too.

An in-memory database essentially

That's why I was drawn to Python, and I still haven't found a good reason to switch to Go in my use cases.

If you don't care about performance, there's no reason to switch. Python is easy but it's very slow.

Python is only easy to write. Managing environments, dependencies, deployment, tooling, etc are all abysmal and Go gets very high marks in all of these areas (including ease-of-writing).

> If you don't care about performance

Or parallelism, or compiled binaries.

They're not really the same thing, IMO. Sure, Go is pitched as a systems language, but when Google themselves are rewriting OS components written in Go with Rust, you know something is up. Go seems like Python++... a more reliable and performant high level language. The GC nature makes it inappropriate, IMO, for low-level systems work. Sure, write apps in it. Fine. But I can't see writing drivers in Go.

I’m not writing drivers or OS components. Services and command-line tools. Go has a bunch of stuff in standard library to make that easier. My experience is that these tools are a bit rougher to write in Rust, due to the additional decisions (which third-party libraries) I have to make wrt command line parsing, HTTP, etc. Rust’s ecosystem reminds me a bit of NPM or Haskell in that way. Go reminds me of Python in that the decisions are easier or have lower impact.

You could just pick the first option that looks good enough and be done with it so you avoid having to understand them all.

There has to be a learning strategy for kitchen sink languages though.

Reply on news.ycombinator.com