I've read the Rust book, maintained someone else's Rust code once, and written a few of my toy programs. But I find that idiomatic Rust is difficult to grok. All the constructs required for safety seem to obfuscate the control flow. There also seems to be a weird schizophrenic combination of imperative and functional styles in idiomatic Rust.
> All the constructs required for safety seem to obfuscate the control flow
A couple thoughts on this point, speaking as an admitted Rust fan:
- A lot of this has gotten better since "non-lexical lifetimes" were stabilized. In particular, it used to be somewhat common to need extra pairs of nested curly braces, to convince the borrow checker that some reference you'd taken really wasn't going to be used again. But today that is almost never necessary.
- In some cases, I find Rust's safety-oriented APIs clearer and nicer than their equivalents in other languages. For me, the big one is Mutex<T>. In Rust, a Mutex is a container, and you can only access its contents by locking it. It's impossible to forget to lock a Mutex when you access the thing it protects.
Does Rust have a reach outside the C/C++ section of the market? Or is it only popular in its own bubble, where developers are now excited to see many of their once painful problems now fixed?
I think you're seeing Rust used more and more frequently for backend services, like at Dropbox and NPM. Some of those are high-performance, "C++ish" services, as I think Dropbox's was. But a lot of others might plausibly have been written in Java, C#, or Go. In NPM's case, they rewrote a service in Rust that was previously running on NodeJS.
Yeah, it's surprising. A lot of Python people are in the community too, such as Armin, the creator of Flask.
I can't speak for Rubyists, but I find it a very strong complementary skill to Python, as it allows for writing things that are impractical in Python. And Rust feels friendlier as a Python-complement than C. Especially parallel C.
Receiving a compiler error in Rust is more appealing to me than debugging a segfault or race condition in C, especially since Rust will always tell me when one exists. Or more importantly, I can feel comfortable pushing new fast low-level code to production knowing it's not a risk. There's no ambiguity. "fearless concurrency" is not just a buzzword, it's partly what makes Rust fun and practical (for me). As well as the incredibly-fast start-up time of my Rust code compared to Python.
It is also appealing for Python programmers because of the increasingly-decent support for mixing the two languages without overhead, including publishing pure-Rust packages as python modules^1
Steve Klabnik and Sean Griffin were both early adopters of Rust (and are now fairly visible members of the community), and I believe that helped sow the seeds of the language in parts of the Ruby community [0].
I think Rust managed to also cultivate a community that was very much like Ruby’s [1], which brought people over.
[0] cf. Klabnik’s “Rust for Rubyists”
[1] mostly being very “people-oriented” in terms of inclusivity and documentation, as well as putting effort into ensuring that the language and its tooling provide a lot of “developer happiness”
Fundamentally, I don't think it should be surprising that someone who loves Ruby would look at Rust. That it's very different is the entire point! Why learn something that's extremely similar, that won't expand what you can do very much?
Anecdotal, but I've not really seen that either. It seems the majority of the ruby devs I know who aren't still doing ruby (it seems most rails gigs these days are maintence work) jumped to elixir/phoenix.
Long may that continue, elixir/phoenix is really good stuff.
Seems very anecdotal indeed - I have trouble believing that Ruby is mostly maintenance now or that a significant portion (say, >5%) of Ruby devs have switched to Elixir.
I've been in several companies that do both Rails and Phoenix. Everywhere Rails is used mostly because management doesn't want to fire loyal and good programmers who aren't interested in learning Elixir/Phoenix. A second, and very often cited reason is that their Rails app is working fine and they don't see why should they rewrite it.
Both are completely fair.
Not going to claim my anecdotal evidence is universal -- just adding a data point.
I am a daily user of fd (find), rg (grep), exa (ls), bat (cat), and am planning to try out sd (sed).
These tools are in my opinion significantly better than the classical UNIX tools: they can be orders of magnitude faster, understand .gitignore, have more intuitive command-line options, and make better use of colors.
