[jstx1]

I've done some beginner Rust and Go programming (read "the books" on both, written small programs) and I'm wondering which one to spend more time on or try to get a job with in the future. When I see discussions like this one about Rust, I start to worry that it's unnecessarily complicated and difficult to work with and that this will only get worse in the future to the point that it won't be a good fit for many of the use cases that it's pitched for. Am I wrong to think this?

[toolz]

If you're trying to break into the industry you're not going to be working on problems that the language really matters. Pick a popular language, learn enough to be dangerous and specialize once you find categories of problems that interest you. Go and rust are only compared a lot because they're sexy buzzwords - they do not target the same problems and they aren't competing languages. Learning both at some point could prove valuable, but personally I'd never recommend go to anyone for anything anyways.

[jstx1]

> they do not target the same problems and they aren't competing languages.

Is this really true? All the problems that are solvable in Go should be solvable in Rust too right (but not vice versa because Go is GCed)? They might not compete on every front but there definitely should be overlap in the use cases.

[toolz]

There is a ton of overlap with every general purpose programming language. So it's correct to say you can solve the vast majority of problems with the majority of programming languages, but languages differentiate themselves in many different ways. One of the main differences between rust and go is that go is a garbage collected language. That feature alone typically creates a large divide in what languages are trying to achieve.

[jstx1]

I feel like you’re ignoring my point. The GC prevents Go from competing with Rust on some use cases. But that still leaves a lot of overlap of potential use cases and if your work falls in that region of use cases, you get to pick between the two languages (and a bunch of others too).

[toolz]

I feel like I covered the fact that there's a large overlap between most languages, but to clarify more - when a software team chooses a language they aren't choosing a language based on the overlap, they are choosing it based on the language specific features they think will benefit them the most across the problems they most often try to solve. Go and rusts unique features do no compete with each other like rust/c++ would or like go/elixir (which I feel these two languages are much more comparable in the problems they focus on solving.

Go generally targets small microservices and can be quite limiting (imho) to larger projects because the language semantics are extremely simple and are not geared towards projects with numerous business domains.

Rust on the other hand has extremely powerful generics which enable sophisticated code sharing and composition to enable large projects. Rust also very purposefully targets embedded systems and low level systems programming. You can do these things in go, but it is not something the language is designed to do as a first class priority.

[loudmax]

Go is very easy to learn. You can be up and running with Go very quickly and it's fantastic for simple applications. The time investment to be reasonably good at writing Go is low. There's little reason not to learn Go.

Rust is difficult to learn, unless you already have a lot of experience with existing low level languages. Getting complex programs up and running with Rust is cumbersome. But the performance is excellent, you can have a high degree that your program is rock solid, and there are entire classes of security issues don't happen in Rust. For the types of applications where Rust does well, it does very well indeed. The time investment to become a decent Rust programmer is high, but this higher barrier to entry can make your programming skills even more valuable since there's less supply to meet the demand.

[hgomersall]

Rust is hard without a doubt. I'm suspicious it's really only hard because it front loads the effort over, say, c++, but it is hard. Expect maybe a year to be proficient, but there's a point long before that it becomes a delight.

Async is hard again, taking more months to feel proficient. I've again a suspicion that much of the resistance to async is due to people who have done the first effort to feel comfortable in rust and expect async to fit right in, but it doesn't, because it's hard too.

Threads are also hard, but under rust they better map to existing thread models, so pre-existing skills are useful and so someone skilled in threads and rust will be skilled in threads with rust.

For sure, there are missing pieces of the async world like async traits, but they will come.