On my work we migrated from C++ to Rust.
this post was submitted on 29 Nov 2024
5 points (54.7% liked)
Rust
6124 readers
19 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
I wonder what criteria he has for considering Rust to be a success. Everyone stops writing C++ overnight? Obviously stupid.
Rust is a massive success. This guy is just impatient. Rust is better than C++ in the same way ARM is better than x86. Intel is still alive but would you invest?
I think OP measure of success was getting a job. I think they are wrong because I hear about lots of folks doing cool things. But I get where they are coming from.
The x86 architecture is a relatively small factor to consider investing in Intel right now
ARM isn't better than x86 though. If you're talking about Apple's M-series chips, the most important difference is the manufacturing process (Apple buys up all of the next gen production capacity), not the instruction set architecture.
A better example is EVs vs gas engines for around town usage, EVs require less maintenance, are cheaper to fuel, and have more torque (more fun to drive). Likewise, Rust has more safety guarantees, nicer idioms, and nifty modern features, and if C++ and Rust were both released today, there'd be almost no reason to prefer C++.
ARM is very very obviously superior to x86. You won't be able to find anyone informed that will say otherwise.
Probably the biggest way it is better is that instructions are always 2 or 4 bytes which makes wide decoders a lot easier.
The decoder isn't your bottleneck, it's a pretty insignificant detail in the grand scheme of things. We could all be using x86 in our wearables and whatnot if Intel didn't sit on their hands while ARM got big under their noses.
I personally prefer ARM to x86, but it's not for any technical merit of the ISA, I just happen to like simple things. I don't interface with the CPU directly anyway, so it's moot, and I'd probably like RISC-V better as well if I had one laying around despite it being worse as an actual product right now (fewer optimizations, nobody is building it on the latest nodes, etc).
What matters the most to me is actual products. The M-series of chips are fantastic, as are modern AMD CPUs. I'd prefer the former for general use because of the node it's produced on, and I'd prefer the latter for computation and gaming because they're well designed for it. From a product standpoint, I only care about ARM vs x86 for software compatibility, and then the specific iteration of the ISA becomes important.
The OP does have a fair point. Rust jobs are harder to find and generally require niche knowledge in some area more then rust knowledge.
Reading the comments it seems like there may be a bunch of Rust jobs, they're just not advertised as much and many of them are filled by senior people with expertise in other areas and languages. In particular it seems like a lot of jobs at Amazon in the AWS department use it heavily. It might simply be too new to really see heavy recruiting for new hires yet. In another decade as teams expand and senior people move to other positions or retire we might see a sudden surge in companies looking for Rust devs.
I know plenty of senior C++ devs who would love to use Rust professionally. Maybe most Rust jobs simply fill easily internally and don't get reach the public?
That's my guess. All the openings are being filled internally and never even make it to public listings.
Which validates the authors point - it can be hard to find or get a job writing rust. Much more so than other languages. Even if there technically are jobs around, just knowing rust wont help that much in obtaining one.
Perhaps but it's also a subtle but important distinction between "there are no Rust jobs" and "there are no open Rust jobs". The former implies it's a dead end skill set while the latter implies potential openings in the future. It may just be one of those things where you need to keep your ears open for openings and jump on one when you see it. Personally I think Rust is just getting started and there will be a ton of job opening's, just maybe not for a little while longer.
there are no Rust jobs
Neither OP nor I claimed that. Only that it is hard to find a job in rust or that knowing rust will not help you get a job today (more so than any other language that is). I do also think that rust has a bright future - but as things stand today it can be hard to get a rust job (at least ones that are not just for cryptocurrencies/blockchain). And it could take 5 or more years for significant change in that area.
What was claimed is that you can't get a Rust job which implies there are no Rust jobs, so it's important to call out the distinction. This was further implied by the tone of the article title which implied that the author was leaving Rust for good. While the contents of the article was more nuanced the title counts for a lot and has to be taken into consideration.
On the whole cryptocurrencies/blockchain jobs thing I'm not even sure I'd consider those real jobs. The overwhelming majority of those are startups that pay in equity and I expect nearly 100% of them to fail making that "equity" utterly worthless. I'd only consider positions in established companies paying actual salaries as real jobs.
If they're seniors then why not slowly introduce Rust to their existing codebases?
Some do. But introducing new language to a team is non-trivial. And maintaining a project in more than one language has its own challenges. Rewrites of course are risky and expensive. So, Rust tends to get introduced very incrementally, for smaller projects, or for green field dev. Look at all the drama in the Linux kernel.
The best route to a Rust job is to convince management to port your existing project to Rust. Rust doesn't seem to have hit the tipping point yet, but it seems to be getting closer every year.
Angry crab noises
I have only skimmed the surface of learning Rust, but I am wondering what it has over Ada. The memory safety features that Rust emphasizes have been standard there for 40 years, and just as unglamorous compared to C++.
I tend to focus on scripting nowadays... R and Pyrhon... with the odd C++ for high-speed algorithms because it is popular. But is Rust merely a new face on Ada?
Rust is already dramatically more popular and widespread than ADA ever was ( outside the US military ). Devs that use Rust say they love it. I do not believe that is the rule for ADA.
Rust is also very well suited to extending existing C and C++ code bases. I do not know enough about ADA to compare but it is my sense that it is not as strong there.
There is no ADA in the Linux or Windows kernels.
Well, I suppose the DoD association probably turned off a lot of people... but the language lived up to its promise of being a strict schoolmarm so if that is what people are looking for these days it is still an option. It can link with C, not sure about C++.I am not sure what being in the Linux or Windows kernels says other than reinforcement of the popularity contest... Windows is proprietary, and Rust being in Linux is hardly controversy-free.
Anyway, thanks for your thoughts. I also found this:
But is Rust merely a new face on Ada?
They share some features. But what language does not share any features with any other language? Any new language these days will be heavily inspired by and take features from other languages while making changes to or pulling in features from other places to create a mix that is unique to that new language. Rust is far more than just its GCless memory safety features and I am not even sure if they are inspired by ada or were just arrived at a similar solution to ada - they are not exactly a one to one matching with how ada does anything. If anything I believe that rust is much more heavily inspired by ocaml than ada.
From what I understand, Ada does not have an equivalent to Rust's borrow checker. There's efforts to replicate that for Ada, but it's not there yet.
Thanks for the helpful response. The BC looks like a potentially very useful anti-bugging tool.