Why the developers who use Rust love it so much | Hacker News Reader

Why the developers who use Rust love it so much

stackoverflow.blog

22 pointsayoisaiah15 comments

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.

Discussed before at: https://news.ycombinator.com/item?id=23437202 Should be flagged as a dupe.

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?

a lot of ruby people are into it, and there is some Go crossover.

a lot of us who don’t like that almost every new language turned into a jitted or interpreted universe like Go and Rust

I can see the crossover with Go, but Ruby?! What is the reason behind its attractiveness in the Ruby community?

I get that some developers believe that Rust is "better than Ruby" and that Rust has far more momentum, but their use cases are very different.

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.

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”

Don't forget Yehuda Katz.

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?

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

1. https://github.com/PyO3/pyo3

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.

Any cool projects to try out? I remember there was one to replace coreutils.

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.

Reply on news.ycombinator.com