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.
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.
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.
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.
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.
It’s not enough to find one Rust shop, I need to expect the next shop also to value the time I invested.
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.
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.
