[pizza234]

I'm a Rust "fanboy" (if one wants to say so), and I still think that the use cases for Rust are just a minority in the landscape of modern languages (that is, where there is a choice).

Rust has a mind-boggling overhead, for many reasons (and I'm not talking about the borrow checker, which I think one gets used to after some time), even if the language itself is consistent and ergonomic (within the intended constraints).

To me, they have very different use cases - one will definitely know when Rust is required or it's an appropriate pick. For the rest, Go is fine. I think that those who put them on the same basket, haven't really used one of them.

Regarding systems programming, my opinion is that they require the lack of a runtime (not just because of the performance, but also, for the framework(s) written with low-level primitives in mind), but this is arguable (in particular, there's no clearcut definition of what systems programming is).

[nu11ptr]

Also a Rust "fanboy" and I would disagree. I'm amazed how productive I am in Rust (about 6 months in). I've written tons of Go as well, and I write Rust faster (What I was expecting was to write better code, but have it take longer, but turned out not to be true). I also thought the language would be too "low level" for the type code I write (I wrote in Go and Python mostly before, though I've written in many languages in the past), but I found it scales very well up and down to low and high level challenges (Serde _rocks_). At this point, I use Rust for everything except a couple hundred line script (Python for that).

I'm not saying everyone would fit in that camp and it is a harder language to get started in for sure, but I think the borrow checker scares away too many people. It is a learning curve, but when it clicks, you will realize that every language has ownership and borrowing... you just didn't realize it because the GC allowed you to be sloppy about it. Once you do, it makes you a better programmer (just like coding in Haskell does).

[pizza234]

> I've written tons of Go as well, and I write Rust faster

The overhead in Rust, when compared to comparable languages, is very concrete. On top of my head:

- using hash maps is more convoluted (in some cases, arrays also need some boilerplate as well)

- bidirectional/circual references need to be handled (and are also ugly); algorithms programming in Rust is typically more complex because of this

- lifetimes (which also spread virally when introduced)

- explicit allocation types

- (smart) pointer types in general

- interior mutability; which may also required additional design (including: will the mutexes destroy performance?)

Some of them intersect with each other and pile up (allocation types; pointer types; interior mutability).

There is certainly overhead in Golang (I think it's not very ergonomic for a functional style, for example), but it's nothing comparable.

Overhead takes time; unless one has a time machine, it makes a programming language concretely "slower".

The above is just the concrete overhead. The abstract overhead (=things to keep in mind) is another story (e.g. proliferation of types because of the ownership, traits...). I understand, say, that path types are a necessary evil, but they're surely ugly to handle.

> you just didn't realize it because the GC allowed you to be sloppy about it

It's not sloppy where it's not needed. A significant part of the Rust overhead is due to the rigorous philosophy of the language, which enforces constraints also when they're not required. This is absolutely fine, but it's not realistic to think that it has no cost.

[nu11ptr]

I thought this as well before I had used the language for major projects, but in practice, I found it not the case (at least for me). Your list of concerns I do not find to be anything I think about day to day as I'm coding. I just write code normally for the most part. Yes, you do have to think about your data structures and how you will use them, but in other languages I found myself redesigning these later because I had come up with the wrong paradigm - in Rust I find myself getting these correct the first time, so perhaps the restrictions I find helpful here (I suspect the earlier poster commenting how certain languages fit your thinking patterns may be on to something).

My Rust code typically 'just works' the first time or close to it (something I haven't experienced since writing Haskell and Ocaml), but in other languages I would not experience this, and I'd spend more time debugging. I have gotten stuck a few times in Rust as part of my learning journey, but overall, I'm still proceeding at least as fast if not faster than I wrote in Go and other languages.

Rust is definitely not perfect, and I see some of the warts, but I don't want to write a major project in anything else at this point.

[dagmx]

Ironically I've been using a lot of hashmaps in some code recently...and the rust implementation is pretty damn ergonomic.

Certainly better than C++ or C# IMHO, and even my Python colleagues were amazed how easy it was to work with.

[hpen]

I have only touched Rust & Go but I would only consider Rust where I would previously have used C or C++. The stuff that needs to be fast, low memory, and what not. I see Go as more of a Java. Good for backend systems. Also CLIs.