Ask HN: Is Learning Rust a Must?
Everywhere I read , I notice people talk about rust and how everything is being rewritten in rust. Is learning rust is must now ?
Rust is a good language in many ways - generally well-designed, innovative, aimed at some under-served but important use-cases, very educational to learn, and surrounded by a lively community.
But only a tiny fraction of the world's work and innovation is being done in Rust. There is a huge amount of interesting stuff happening in other languages. There is also much more work available in other languages - even interesting, well-paid work.
Reasons to learn Rust right now:
1. You need to learn a low-level systems language, for use on a platform that Rust supports; i think Rust is a better bet for many uses than C++ already.
2. You have copious time to invest in learning, and ownership type systems are the most interesting or powerful thing you don't currently know.
3. There is some specific piece of software you want to get involved with, and it's written in Rust.
Sidenote, i think a lot of the tech crowd forgets how much industry will lag behind popularity, for a whole bunch of good reasons. My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust. We would have a ton of candidates in Python, JavaScript(Node), even Go. Hell even PHP.
The fact is that applicants tend to follow jobs, so you get a chicken-egg problem. New languages have a huge hill to climb in adoption and it takes years for companies to build up large codebases in new languages to result in a large job pool.
Take any previously popular, old and uninteresting language and know it well - and you can get jobs for years and years and years to come. There's just a ton of code out there written in it that needs support, extension, etc.
I always recommend learning Rust but it is certainly not a must.
But for Rust, looking for language experience might be the right choice since the learning curve is relatively steep and takes time. Unless, of course, the company is okay giving 2 months to just learn.
Yea, this is our opinion. Our options are limited due to the smaller talent pool, so the time it takes for devs to "spin up" is something we consider. We can't hire a full team of devs who take 2 months to spin up. We can, maybe, do 5 young devs and 5 seasoned devs.
I've personally found that devs who have experience with C++ are almost a direct shoe-in. They know all the concepts and the transition seems easy, especially since they're already interested in Rust. Having hired a few dynamic language folks though, they have a higher barrier to entry with Rust. A lot more concepts to learn.
We have a large codebase in Rust. We're hiring devs who want to use Rust. Why is that "doing something wrong"?
edit: Maybe you think we require full Rust mastery on hiring. We don't. Though we make it clear that work on a Rust codebase is ~~expected~~ required, and familiarity with generalized concepts like static/dynamic dispatch are important. We hire young Rust devs all the time.
I don't mean saying something like "our tech stack is in Rust." More like "3-5 years experience in Rust" under the job requirements.
It's not hard to learn a new language or train it in good engineers. If you're limiting your candidate pool based on particular language experience you are severely limiting the growth potential of the business. That's just been my experience.
And if your reasoning is something like, "Rust is hard and it's going to take N weeks to onboard a dev to contribute and we can't afford that" then it's an even bigger red flag about the engineering capacity of the business and state of development.
I think i addressed this in my edit. We are not doing this.
I learned Rust (and C++!) at my current job, with Java being the only statically typed language i knew before that.
Unless you have reason to believe that a significant fraction of otherwise smart and capable static-language programmers will just never be able to learn Rust. I have no idea if that is true or not, and it would be interesting if it was.
I believe i said exactly this. Specifically i said:
> We're hiring devs who want to use Rust.
Which seems clear to me. My edit also addresses new Rust devs. Our requirement is that you want to work in Rust. Which shouldn't be shocking or controversial.
> My shop uses Rust, and all our hires are aimed at Rust, and it's still not easy - there's not a ton of people who know Rust.
Which rather implies that you are trying to hire people who already know Rust. You then asked rhetorically:
> So we should hire to bring on people who want to work in PHP, and then force them to use Rust?
Suggesting that you saw this as the only alternative to hiring people who already know Rust. I was pointing out a third possibility which i thought you had omitted.
So i wouldn't agree that this was exactly what you said. But, of course, i am very happy to hear that this is what you are doing!
The "hard" parts of Rust are the usage of lifetimes in generic heavy code (especially combined with function traits in order to be generic over closures), object pinning, and soundly operating in unsafe. Those are advanced topics to be sure, but they are not something you would expose a newbie to in the early days of onboarding.
And for those same reasons we know building C++ is giant pain in the butt.
Given the opportunity, I would seriously consider Rust when rearchitecting a system to peel off small bits I can do 100% RUST because I then can escape C++ dependency/cmake/DPKG/RPM hell to something closer to GO.
When I deal with old C++ code not brought up to current build spec at our place I can waste 30-40% of my time getting various things to build. Getting the old code into the new system is now easier, but I killed a week learning it. And should I have to deal with a library off the beaten path who's dependencies I don't know, getting it into the new build system will be a pain-plus because I will then have to find/compute/assess its dependencies.
Getting out from all this nonsense is, I think, is an undersold part of RUST. You still get static types, C++ performance, memory safety, and you get a running start to CDCI because at least getting the darn PR built is a 4 to 6 Phd job of hand holding C++ through dep management.
The primary reason, I think was because there was no legacy code I had to deal with.
For greenfield projects I’d opt for Rust over C++.
First, I think knowing concepts from various languages makes better programmers. But Rust in particular is part of a family of languages along with C++ that are very powerful and versatile, but that require a strong discipline in order to write correct programs. And while C++ is more widespread currently, learning Rust teaches you this discipline, simply because the compiler will keep rejecting your programs until you understand it. C++ compilers on the other hand happily accept nonsensical programs, and it is hard to find modern C++ experts to teach this skill (and sometimes it is even hard to get experts agree on what the discipline is!). Yet in some areas where C++ has few alternatives, unreliable software can have huge consequences. So learning Rust is important because it will also make of you a better C++ programmer.
What we like to read and write about may not be very well correlated with reality.
Rust is a very niche language, gaining attention, and a serious contender to be an important language but it's probably not going to take over any space and even if it does, it's going to take a long while.
You definitely don't need to learn Rust.
It's a neat language though and it's worth tooling around in for a bit, at very least to get a feel for the 'borrow checker'.
Basically, Rust seems like a good replacement for most C++ applications. It offers memory and thread safety guarantees with no or minimal overhead and a speed comparable to C++.
I am currently working on two projects: one in python, one in Rust. I am a proficient C/C++ dev but I think I will ditch C++ in the near future. I am not sure it makes sense to replace C with Rust unless safety is required.
I don't see rust replacing python. Rust is painful to write, it is longer than C++ and python is much more productive when you can afford the overhead.
The number of jobs available to purely write Rust code in the world is still very very small.
Like all other programming languages, only if you need it and if it fits your use-case. Otherwise a better language can be used instead.
If it were me, the language I'd learn and use is the one that makes me the most money possible. At this stage for me, it is not Rust.
Of the 20th century.
I'm sure you know that we are in the 21st century.
If you are interested in systems work you will need to know some C++ even if you don’t like it.
What I really want is a theorem prover attached to a macro assembler, that might scratch the rust itch better than rust.
I spent a lot of time working in the semantic web space heading in the direction of "low/no code" and was struck at how logic-basic programming (not just constraint languages but production rules and other approaches) has been dead in the water since the 1980s despite the tools getting much better and numerous but isolated success stories.
Lately I got into the Arduino hobby and I've developed a number of things that are basically "traverse an object graph in program memory with several cursors" while doing a few streams of I/O.
(Imagine I have a SPI lightstrip on my car and program memory has a set of dingbats, color palettes, a picture of a McLaren F1 and instructions to put it all together. For now I tell the driver to use the cruise control, someday it reads from maybe the CAN bus, GPS and accelerometer and runs a Kalman filter to stick the GFX to the ground)
In a program like that the functions divide neatly into several layers and everything can be statically allocated and the more I think about it, the more I think the way C thinks about functions (return values, calling conventions, etc.) is not a good fit for the problem. I have no need for the stack, can allocate a few registers for the interrupt handlers, etc.
Thus I think "C sucks" and I am no fan of gas (designed by somebody who hates assembly language but doesn't see the C-thulhu in old-school C compilers.)
There are lots of papers where people apply theorem proving to assembly and seem to have an easier time than they do with languages like C. Maybe the behavior of the system is better defined, maybe you get into combinatorical problems with automatic allocation, etc.
My C programs statically allocate as much as possible and have notes that say what color the functions are and informally justify that the thing works. I feel like a dork knowing how much wasted activity the C code is doing behind my back and think about re-writing it in AVR-8 assembly with even more detailed notes...
... so if those "notes" were a machine-readable proof that the memory allocation and other things in the program were correct and otherwise the system could SMT solve for things I don't want to code by hand that would be sweet.
(A positive in this application is that the program is going to be small but the compiler is going to run on a much bigger machine.)
As a business though I don't believe it.
Even a Pascal-like or FORTRAN-like language without any real technical innovation is a bad enough sell for this market; Arduino using C is good for "education" because learning some C is useful, even if it teaches bad habits like BASIC.
Portability is a problem too. I think AVR-8 is beautiful but it is a dead end but when the going gets tough I am going to swap in an RP2040 and add some transistors to shift levels.
On top of that, expecting people to learn multiple new technologies is a big ask. I am sure many people think "C sucks" but jumping to the system I envision means learning assembly language, theorem proving, and a few other things. I could write many C programs in the time it would take to get that system up to the point where I could use it, and the investment would be several times that before other people could use it.
It’s not enough to find one Rust shop, I need to expect the next shop also to value the time I invested.
I switched from Go because i wanted more language features. Rust isn't a competitor to Go imo, but indirectly it was for me. I never use C, and while i could use C++, i ultimately wanted a good dev UX. I chose Rust for my developer experience, not because it was a "better C/C++", of which i don't need.
So i imagine you know this, is it the syntax you're trying to avoid? Ie wrapping a lot of things in RC's is annoying?
(Yes, GC tuning is painful, but better than rewriting code hoping you might end up with the same behavior.)
My big issue with Go's GC, or GC's in general, is consistency. Go's GC can still be variable in pause time iirc. But it's been ~3 years since i've worked in it - so maybe my memory is wrong :)
About the consistency, I think that's not a GC problem in general. For example, Java's ZGC has constant pause times: https://malloc.se/blog/zgc-jdk16.
It seems to have a bright future, but for the time being isn’t established enough to be worth learning for sake of industry relevance.
If you simply like Rust, go ahead and invest time into learning it. There are companies looking for developers.
It’s just not “the standard” at the time being.