This comment echoes a common sentiment of Rust and Go somehow being in the same category (maybe because of the "systems programming language" buzzphrase) but they're really not.

Comparing a language with a fairly significant runtime and garbage collection to a language with basically no runtime and strict (albeit largely automated) compile-time memory management is comparing chalk and cheese. You might as well say "I tried C++ but ended up going with Python because it was quicker to code" -- of course it was!

If the desideratum is "I want a decently fast language that compiles to standalone binaries", which would be normal for CLI tools, then they certainly are in the running against each other. Having a runtime or a GC isn't that important of a consideration for most software I would think.

To me, the sentiment seems to be that Rust is explicitly tailored for code that cares about no runtime overhead. If you don't have those requirements, then don't use Rust.

This is why I reach for Go by default when writing CLI tools. You will get your job done faster, and it will be much easier to understand and maintain. You will be trading off many of the static guarantees that Rust gives, but it's worth it for CLI tools, most of the time.

If you are writing code with strict performance requirements, then consider Rust. Otherwise you'll likely be adding a whole bunch of complexity for not much gain, and your code will require much more cognitive overhead to understand and contribute to.

I don't think we should dismiss these comments so eagerly. Take a look at Nim - it's fast, efficient and elegant without the huge syntax overhead of Rust.

Isn't Nim's niche closer to Go's than to Rust's? It has garbage collection, at least by default.

I'm not an expert in Nim, so it would be great if others could jump in. But to my understanding, Nim's ORC "garbage collector" (I'd rather call it memory strategy) is very similar to Rust's approach, it's based on reference counting (RC). It can also handle cyclic references.

See here for more details: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

It is not at all like Rust; it is a garbage collection system based on reference counting, pretty similar to Swift. This is obscured by the documentation for each using similar terminology (like "move semantics" and "ownership") to refer to systems with different characteristics.

Thanks for clarification withoutboats2! It's really confusing as Nim's move semantics "feel" very similar to Rust's (except that Nim is more relaxed regarding "use after move" - it simply performs a copy). I'll need to learn a lot more about the different concepts.

I came to rust from c++ and I have to say I have never understood the 'darn complex' complaint.

In c++ there are foot-guns on every turn. Follow the links for some goodies:

https://en.cppreference.com/w/cpp/language/value_category

https://en.cppreference.com/w/cpp/language/reference_initial...

https://en.cppreference.com/w/cpp/language/template_speciali...

https://en.cppreference.com/w/cpp/language/overload_resoluti...

Well, you answered your own question. Many devs don't use C++ (unless they're forced to). And they consider C++ at least as complex.

The official CLion plugin for Rust is phenomenal, and almost feels like a first class IDE nowadays.

I appreciate Rust is more complex than other languages and much less easier to pick up and learn on the job though. It definitely takes a lot of practice to get to the point where traits/lifetimes/ownership etc feel like brilliant tools rather than needless complexity.

If only Crystal has full windows support, then I can confidently recommend it to you.

Building cli tools in crystal is fairly easy thank to the standard OptionParser library. `colorize` is almost perfect, too, in case you want to print some ascii colors. And just like ruby, invoking some shell command is simply wrapping the command with backticks. and FileUtils has ton of features.

Too bad Crystal now only works in POSIX.