2024: Google says replacing C/C++ with Rust is easy
2025: Google buys Rust
2026: Google shuts down Rust
this post was submitted on 09 Sep 2024
6 points (100.0% liked)
Programming
27118 readers
562 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
πππ€Wait, Isn't rust a community made project?
It is. Do not worry
Okay, Rust does look pretty cool and I am trying to learn it, but this makes me hesitant.
Also, did they rewrite it themselves or are they making Gemini do it and just didn't encounter bugs yet?
Rust is one of those things that every time I look into it, I don't really follow what makes it so good. What's a good starter project to learn the language and get a sense of what makes it worthwhile over the established stuff?
-
If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn't have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.
-
It has a very strong (and nicely designed) type system which gives an "if it compiles it works" kind of feel, similar to FP languages like Haskell (so they say anyway; I've not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.
-
The libraries and APIs are generally very well designed and nice to use. If you've ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get
string::starts_withbut Rust started with it (and much more!). -
Fast by default.
-
Modern tooling. No project setup hassle.
-
It's a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript's answer for ages was "serialise to JSON and back" which is crazy.
Downsides:
-
Slow compilation sometimes. I'd say it's on par with C++ these days.
-
Async Rust is kind of a mess. They shipped an MVP and it's still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can't.
-
Interop with C++ is somewhat painful because Rust doesn't have move constructors.
Great language overall. Probably the best at the moment.
I disagree with 5.
I am an electronics engineer, so admittedly only ever worked with C and Python scripting (and not a programmer by any means) but I literally stopped learning rust for embedded because every single tooling setup step was wrong or failed for both chips I was testing out (NRF chip and an esp32-C3). Maybe only embedded rust was still a mess tooling-wise, but I have no use case for learning userspace rust first. It would just be a waste of my limited free time π
I just would like to learn from your experience.
I have a different background, can't say I am developer but a coder who mainly do prototyping in short amount of time, and sometimes help out building microservices, backend stuffs. Go really fit the bill neatly for my job, so my first attempt jumping into the embedded world, as a hobbyist, was with TinyGo and found it completely different from userspace application development. To be honest, I did like it as a unified toolchain, but it was not yet that mature the time when I used it (I hope they are much better now) and I always had to go into the "machine" code file to find out things that should be documented better. That said, I was really happy when I got my head around multiplexed led array on the microbit, and even figured out how to drive a continuous rotation servo by timed highs and lows (TinyGo had no PWM support for microbit) for a car crusher, with an empty tissue box of course. Made my little one cry when he saw it the first time and thought his toy cars were crushed.
But when I got into more "serious" hobbyist realm, playing around with nRF52840, ESP32 and Cortex-M0, I found that Zephyr Project just feel right to me. Maybe because I am not a bare-metal magician by trade, I found the device tree concept so easy to understand and I managed to tune a DTS for ESP-EYE to use the correct address region for PSRAM, though I could only enable 4MB of it as I still couldn't understand why there are 2 separated address regions for a total 8MB of PSRAM!
By pure coincidence, IoT became the next big thing for the company I work in, so I am thinking about getting more tools in my shed. I will definitely look into CircuitPython. Never learned Python before because I just don't like it, without any objective reason I am afraid, but I reckon it is a great tool to build something really really quickly. Another language I want to learn, as you can tell, is Rust, because I can't expect my colleagues to know Zephyr when FreeRTOS is just a much more popular choice. I think one day I will have to look into FreeRTOS again but wouldn't hurt learning one more modern langauge that hopefully can do the trick easily.
However, with some initial digging, it scares me. From libraries and tutorials, one thing that bugs me is that it seems everyone has to do like Peripherals::take().unwrap() and many other long chains of method calls ending with .unwrap(). I feel like the borrow-checker is not quite ready for memory mapped IO but assumes every pointer is allocated on the heap. I just feel worried that one day they will say "okay, we actually need a different compiler for embedded, just like TinyGo for Go", and I have to relearn. Another thing that I don't know yet is, it seems not so easy to get them onto the chip? If I understand correctly, some of the nRF and ESP32 are on tier-1 support so I suppose they will be the easier choices to get started. I am interested to know from your experience what was wrong in the equation?
Thanks and my apologies for making it so long.
Memory safety for one. C is very memory unsafe and that has been the source of a great, great number of software vulnerabilities over the years. Basically, in many C programs it has been possible to force them to execute arbitrary code, and if a program is running with root privileges, an attacker can gain full control over a system by injecting the right input.
I have very limited knowledge of rust, but from what I remember writing memory unsafe programs is nigh impossible as the code wonβt really even compile. Someone else with more knowledge can probably give more detail.
One of the deep-pocketed founding members of the Rust Foundation says it's easy. I'm surprised.
Clearly Rust is a conspiracy.
Clearly Rust is a conspiracy.
Anyone in software development who was not born yesterday is already well aware of the whole FOMO cycle:
- hey there's a shiny new tool,
- it's so fantastic only morons don't use it,
- oh god what a huge mistake I did,
- hey, there's a shiny new tool,
I assume that you do know that tools improve objectively in the cycle and are making a joke on purpose.
If you had a grasp on the subject you'd understand that it takes more than mindlessly chanting "tools" to actually get tangible improvements, and even I'm that scenario often they come with critical tradeoff.
It takes more than peer pressure to make a case for a tool.
There you go again flinging insults at anyone who disagrees with you.
Yeah, because the new tools are never actually better, right? If condescending luddites like you had your way we'd still be living in the literal stone age. At every step of the way, people like you have smugly said that the older, more established ways of doing things were good enough and new ways were just a fad that would die out.
Your favorite language was dismissed as fad when it was new. High level languages were a fad. Computing was a fad. Electricity was a fad. See a pattern?
Nice job projecting with the "only morons" bit, BTW, when it is in fact you who started off by denigrating people whose preferences are different from yours.
Here's the thing, you're not going to force all of us to learn Rust
That seems like a poor attitude imo.
A valid point tho. Generally it is difficult to ask everybody to learn a new language.
I mean, I work as a software engineering and if I'm not doing continuing ed, be it about architecture, storage, or new languages, I'm going to be of less value in the marketplace. I've learnt languages I didn't particularly want to in the past for work (though I generally came to tolerate or even like some of them. Not lua, though; lua can go to hell).
If Rust truly is the better, safer option, then these people are holding everything back.
"learn Rust" in this case is learn it to a level where all of the little behaviour around cross language integrations are understood and security flaws won't be introduced. Expert level.
It's not "I did a pet project over the weekend".
You are correct and I am aware of that. However, it also seems that they both refuse to learn it and refuse to work with people at that expert level based on the recent drama, which seems very much like holding things back to me.
If you mean the drama I'm thinking off, that seemed to me to be a guy taking on a role that was always going to be 90% political because people are resistant, and sometimes downright hostile, to change and then flouncing off when it was 90% political.
That seems like a poor attitude imo.
Why do you believe that forcing something onto everyone around you is justifiable? I mean, if what you're pushing is half as good as what you're claiming it to be, wouldn't you be seeing people lining up to jump on the bandwagon?
It's strange how people push tools not based on technical merits and technological traits, but on fads and peer pressure.
It is literally being pushed for its technical merits and traits.
Memory safe code with comparable performance in the kernel seems like an absolute no brainer.
Also if you watch the video all he's asking for is consistent interfaces for the file systems. He's not even trying to get them to use rust. And the guy starts screeching about how he'll code however he wants.
Is it wrong to expect a consistent and well documented interface?
Pretty sure C is actually being pushed against its technical merits here.
It's wrong to force it. Most choices in history don't end up with the best one being used. Beta was better than VHS for example. Rust people are very bad at convincing others to try it, and objectively many people just don't want to or don't like it for various reasons.
Personally I highly dislike the syntax. People like familiar things, and to me it's just too different from C++.
If anything I think Swift will be an easier sell when the speed and cross-platform issues are solved.
I think the point is they aren't forcing it at all. It's being used with the blessing of Linux Jesus and the others are just throwing their toys out of the pram because they don't want to learn it.
Someone else linked the video on this post. They are rude as hell and the rust dev isn't even asking them to use it.
Again I think that's a bad attitude towards technology. Use the best tool for the job and you'd get used to the syntax pretty quickly.
It's like someone who started on python not wanting to learn a c style language.
It starts with "no, you don't have to learn it",
to "your changes are breaking Rust stuff, let's waste time together to fix it, else I call it 'bad attitude'"
to "you better make your stuff that way if you don't want to break Rust stuff (and waste your time me)"
to "do it my way, Rust is taking longer to fix and I would have to refactor all the code because of the lifetime cancer"
to the original senior kernel dev saying: "fuck it, I quit, the kernel is such a mess with the Rust BS" ... People don't want you at the party, make your own party with your own friends we don't want you here
It's not complicated.
I mean I've still yet to hear a reason not to use rust tbf.
But yes that's what working in a team is like.
I have to do stuff at work so I don't fuck over the frontend team. I don't throw a little tantrum about it.
I mean I've still yet to hear a reason not to use rust tbf.
You can't take NO as an answer, don't you?
That's bad attitude
Linux is not "work"; you surely don't grasp the reality of the situation here.
And "tbf", the incessant pushing of Rust from people like you is a perfectly fine reason to not use Rust...
You're unpleasant to talk to.