Access to competant Rust developers can be a challenge even for large companies.
I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust.
The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake). I pointed out to the Technical Director that this was a big mistake and the teams had taken on a large amount of technical debt for no reason other than the ego of the wanna-be-rust-developer. Since I "knew" Rust he wanted me to maintain it. My advice was to go back to the Python scripts and I left.
This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choice of language or tooling than whether it's fast or slow or reliable at one instant in time -- you have to ask how you will grow and maintain things going forward.
That said, obviously all languages were in that state at some point. Twenty-eight years ago you might have said the same thing about Java. Twenty-four years ago, Perl might have looked like a better choice than Python; now it's clearly the opposite. XenServer took a gamble and wrote their main control stack in OCaml in 2008; on the whole that has had some benefits, but the number of OCaml developers has not significantly grown, and it's not easy to hire people.
That said, I think Rust is much more likely to follow Java's trajectory than OCaml's: My prediction is that it's only going to be easier and easier to find Rust developers.
> I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine.
I'm not talking primarily about Perl as a technology in and of itself, but as a long-term technology choice in terms of being able to find people to maintain and improve it.
The Xen Project has a bunch of support stuff (automated testing and tooling around doing security work) written Perl. It was just about a reasonable decision when it started to be written 10-15 years ago; Golang was too young, Rust wasn't written yet, and Python had its downsides. But when the author of the code left the project 2-3 years ago, and there was 1) nobody with a similar level of expertise to maintain it, 2) nobody particularly wanted to gain that expertise, and 3) it wasn't easy to find someone else to pay to do maintenance.
If you've managed to find people who can maintain those perl scripts, more power to you; but it unless perl5 can get some momentum back, it seems like it's going to be harder and harder to find replacements.
The thing about Perl developers is they tend to stick around. At the last Perl shop I worked for, the average employment time must have exceeded 10 years. I could say the same of Prolog and 25 year average employments.
RE: scripts, I find Golang better and better for this nowadays. Uber-fast compilation, to the point of it being acceptable to just instead do `go run your_thing.go` even, and you have access to a very solid runtime and many libraries for most of what people usually need.
I don't argue with the portability and longevity of Perl but it too has its problems.
The longevity of Go is also a thing. I have not encountered a single Go project that used to compile but now doesn't because it hadn't been touched.
Go is in many ways leap years ahead of most AOT languages I've used in anger. Yes, sometimes you miss XYZ, but seldom is that an issue outside of personal preferences.
What you do get though is amazing tooling and little-to-no downtime. Builds basically don't take any time, tests run past, pipelines are quick.
go test ./... finishes faster than you can print Determining projects to restore... to the screen. It's a very liberating experience that is hard to go back from.
I have my very real pet peeves with Golang -- lack of sum types and thus no exhaustive pattern matching is the top one -- but I can't argue with results. Every time I wanted to whip up something quickly, Golang has gotten the job done and then some.
I've gotten far with type switching on an interface that amounts to a single function that does nothing.
Unfortunately it does nothing in terms of exhaustiveness, but it effectively gives you sum types which IME are so, so much easier to work with than state pattern or other inject-an-object-abstractions. Not having to design an API (that later leaks) is rewarding enough.
It's strangely efficient as well. I've experimented with implementing sum types via tagged C-style unions and at every (ad hoc, micro) benchmark I've tried them against, type switching on an interface comes out on top.
The language features, designed for full stack systems programming, IDE tooling, the frameworks bundled with the compiler, first class support for binary libraries ecosystem, no culture against modern times...
I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though.
Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.
I wish and I'm sure Rust will get there some day but is there a no-brainer usecase today where it's really important to use Rust, one important enough to overlook the initial learning curve, developer scarcity and evolving ecosystem?
If there's a killer open product out there where the primary supported language is Rust(Linux kernel might as well be it someday), or if a big company launches a successful product in Rust then adoption may accelerate. For now its mostly limited to cryptocurrencies, performance critical paths or rewrite of hidden core components but nothing flashy.
"Nobody ever gets fired for buying IBM". Unless teams can say the same about their choice of Rust, people are going to be risk averse and prefer using safest choice as long as its good enough.
Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously.
Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.
Nobody is stealing anything, what a weird comment.
And the problem with new kernels is how to reuse the huge trove of already-written drivers. Nobody is going to start rewriting everything in any language, be it Rust or any other -- does not matter. That's why the ABI and "please commit to a standard" points are so difficult and thorny in the kernel ecosystem; people want to reuse.
> you have to ask how you will grow and maintain things going forward.
The typical answer is "The jobs market will provide".
The issue with that method is that you end up competing with everyone and, usually, your company is not the top employer.
OTOH, some companies decide to use technology and invest in knowing the community, by hosting events or meetups, by frequently sending their devs to conferences on company time, etc. Usually, the people hired are above average, and are also able to train juniors if the market dries up. These companies typically are the safest in terms of ability to maintain their stack, but have to account for the fact that alienating their existing devs becomes a big risk.
The real harm comes for companies that choose niche tooling but believe the market will provide.
Right -- you can choose a niche technology, as long as you're willing to commit to the additional costs of doing more training, being involved in the community, and so on. Those additional costs (and/or the risk of not doing so) need to be factored into the decision to use a technology.
Twenty-four years ago, Python already looked better to me. I maintained a big Perl 5 app. Yuck. The problem wasn't that you couldn't write it, the problem was that you had to be able to read widely differing styles of Perl... and if you wanted to read library code, it was a huge pain. I quit maintaining that system in 2005, and it has barely changed since, from what I'm told.
Viability of a language is certainly a consideration, but the characteristics of the language also matter.
What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.
> Rust is much more likely to follow Java's trajectory than OCaml's
I'd rather compare Rust to Haskell and Kubernetes.
Haskell:
- Dozens of handfuls of experts open to remote work.
- Lots of aspiring juniors who see no way to enter the market.
- Most employers are R&D-heavy academic consulting environments.
Kubernetes:
- Wildly hyped and cherished among people who don't have the complexity to warrant the purchase.
- Eventually criticised for being overly complex and suitable only at a certain size and setup.
> it's only going to be easier and easier to find Rust developers.
I imagine it's never been easier to find Haskell developers and Kubernetes developers, either.
Yet, one's wish to code Haskell professionally does not necessarily align with one's market value.
It seems like there's a lot more open for Kubernetes, so Rust could go that way.
Unlike Haskell, Rust seems to gain industry acceptance.
Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling.
Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created.
So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way".
Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.
> Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program
I had a similar experience trying to make Haskell's LSP work in test files. After ten years of using Haskell for academic and hobby projects, I still couldn't make the red squigglies go away in test files. With Rust I struggle similarly when dealing with cross-compilation and a complex set of feature flags on Nix. But at least this is not "Hello World!" failing.
Well to be fair to Rust, Nix can drive anyone crazy. I tried that one too and figured they sniffed way too much of their own drugs, if you pardon the expression. In the meantime I learned `just` in 10 minutes.
Sure, not the same usage patterns, I get that of course, and I love the idea of Nix but they could have went about it very differently with a much better UX / DX... and they refused.
Side topic though, sorry for the digression. Main point was that if you use Rust normally without any weird and not fully accounted for wrappers then everything works fine. I just fired Neovim in a personal project I haven't touched in a year -- 20-30 seconds of LSP compiling stuff and I saw my project-wide compiler warnings immediately after.
I do have one ear for that argument that "everything ought to be simpler". But what I've observed over and over is that many systems tends to become more complex as the result of people wanting to make them more newbie friendly.
That's certainly true of the last 10 years of Ocaml tooling evolution.
I guess you could argue both ways and it depends on your starting point. I did not mean to say "make it newbie friendly", I meant "I want adding a dependency to my project to be a 10 seconds job, not a week-long endeavor".
If we both start from that point then I think we might find a common ground.
Yes it does very much depend on your starting point.
For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install"
This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.
If a company chooses non standard tools then they are doing it with the knowledge that they will have to train new hires in it. Random employee using non standard tools without the company making the decision to pivot to embracing it, aka training existing\new employees in that tool, is just making stuff that your company will have to throw away and redo.
So XenServer embracing OCaml is nothing like Random Gamdev writing some scripts in Rust without the team deciding to embrace the change.
The kind of people that recklessly move from shiny language to the newest shiny language in town are the same kind of people that believe that you could kick out a dev writing systems in Java and stick a dev whose experience has only been Haskell and O'Caml and have the new dev hit the ground running
But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers.
Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java.
Rust may get there. But don't use Java's success to predict Rust's trajectory.
Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.
Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.
I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java.
For the latter it’s still kinda of "everybody can write some code that will run everywhere". The former is more like "you can have performance, consistency and correctness in a shallowly-C-like syntax", which is more likely to tease the average HN reader, but probably not the average programmer who is in to earn some descent money or as a way to start before moving up in the businesses hierarchy.
And you see there are some people which enthusiast to push Rust into the Linux kernel, while I doubt that in Java projects of similar size there is that much ardor for even introducing it in some part of it, let alone propose a full rewrite.
> I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java.
I don't think the origin lame was that it would compete for the same segment, but that it would reach the same level of ubiquity. It could do that by opening up a new non-existent segment, eg smart contracts on the block chain. Or it could take a little from multiple domains.
> I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust.
> The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
I can believe this, but it's funny because I work on a project where the main product is written in Rust, and it's the build tools written in Python that are the technical debt that nobody really wants to touch! In our case I suspect rewriting them in Rust will end up being the right thing to do (if/when we can justify the switching costs).
That makes sense, as the bulk of your developers are probably Rust devs. Homogeneity favors Rust in this case. Also Rusts existing build system is (unsurprisingly) built around Rust, so it makes sense to keep with it.
> I can believe this, but it's funny because I work on a project where the main product is written in Rust, and it's the build tools written in Python that are the technical debt that nobody really wants to touch!
Oh hi! You must be my teammate!
I joined a team like this and just started a personal build/dev/ops tool repo in Rust for things that I needed but were not automated. Over time it has become an "official" repo and renamed to be blessed with an official "org" package prefix.
When I started this project and people were interested, I was asked why I didn't just add to the Python repo; I said that others are free to rewrite them if they want to, but I can't justify spending days messing around with Python to achieve what I can in less than 30 minutes with Rust when I need to quickly automate a tedious task.
Edit: A lot of downvotes on this, but in case it wasn't clear - the team is happy that someone took the time to scaffold a repo in Rust that everyone feels more confident in contributing to, since the overwhelming majority of the codebase is written in Rust and the Python tools repo is full of annoying runtime errors that could be trivially caught at compile time.
The end result is more people feeling more empowered to automate repetitive and tedious tasks which can easily be fudged when executed manually instead of suffering with them because someone who isn't even here anymore decided to start a tools repo in Python for a team that almost exclusively writes code in Rust.
The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake).
While they should get wider buy-in first then if the choice is technically justified within reason, its perfectly appropriate (and normal) for devs to pick up new languages in this way when existing expertise is not available on staff. No competent dev will accept their skills atrophying due to overly rigid political/tech choices.
That's how skills are built, its always been thus in such environments, and thats ok.
No one has the "right", as you put it. The learning of and using Rust was approved by the employee's superiors.
If anything, companies expecting employees to know their specific tech stack on day 1 of the job is much less common an expectation outside of Software engineering.
Fairer, but that's probably the point and tone you should have quoted with then. ;)
I would probably concede that it depends on context - for devs paid at the top of the market to simply churn stuff out factory-style there is less justification for self-improvement on work time.
For the majority though there is always give and take between responsible employees and employers, and building skills as discussed is normal.
You're not likely to be paid top of the market at a firm whose biggest concern is that you might be more flexible and a faster learner than anyone else they were able to hire.
> Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
There are two dialects of Rust. One can be written immediately by beginners, the other is for experts.
I make sure to write scripts in the first dialect. It uses `clone` all over the place, does not make use of any async runtime, and makes extensive use of "anyhow" for error creation and logging.
I advise all my peers to do the same, if they find a need for Rust in tiny scripts or applications.
If it's just a few tools that are essentially scripts and they don't even warrant a full-time dev then wouldn't a random senior dev do?
I have had to touch things in languages I'm not familiar with and initially it's slow due to having to look things up, but plenty knowledge still does transfer. Opening a file is still opening a file, updating dependencies is still updating dependencies. Plus python devs should be used to changing tooling all the time ;P
Embedded developers that know Rust is an even smaller pool than Rust developers in general. It’s almost two non-intersecting groups of people since embedded in general is less well paid in many countries and so doesn’t attract people interested in the latest and greatest hyped up language.
As a Rust dev looking for a new job, this is my experience. I filter out the embedded jobs because knowing Rust only half the equation for those roles.
"competent" is a bit of a word there, there are very few shops right now that are willing to hire actually junior rust devs. The jobs are out there but they're all for mid level at a minimum roles in the Rust ecosystem specifically.
Tons of people would jump ship to be able to use Rust, it has a lot of love in the community.
"Being totally unwilling to accept anyone junior, or who is new to the stack" is a disease in this industry, and it's really apparent when some 200 person+ company is only hiring principal level rust devs.
As a Rust/Python dev I previously decided against Rust in a work context as I deemed it would make me the sole person who knows what is going on, while python feels much more like a lingua franca of programming nowadays.
I would decide this on a case by case basis tho, Rust is different, but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not. Rust is different, but unless you want a complete rewrite or new complex features any developer should be able to get into it if you give them a little time.
And the strictness of Rust makes it unlikely that they break things in a bad way, which is good.
> but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not
there’s also the fairly easy cross compilation to bear in mind.
i built a container entrypoint binary via python to stick in all our containers at last job.
getting that to cross compile was going to be a bunch of pain i wasn’t willing to go down for a simple “download files from S3, run a sub process, upload files to S3” pre-execution wrapper.
digital ocean infra + self hosted gitlab —> no readily available windows instances.
so everyone had to use linux to dev these containers with wine+mono.
being able to cross compile would have been brilliant here. i made the decision to not do this in rust for future maintenance reasons. but then people avoided using this thing because they couldn’t run on windows :/
(i know there’s that paid for package but the license fee is mind boggling from what i remember).
from what i looked at, go was a bit more complicated than rust for cross compilation. but it was still a lot less complicated than sorting it out for python. dunno. was at least two years since i looked at it, but i remember rust coming out on top in my mind.
unfortunately the same maintenance issue applied -- it was a python / R shop so no-one else would have been able to change the code once i left.
thats definitely not the commands the guide i looked at had lol
looks on par with rust then. go is the next one for me to dive into when im doing fiddling with rust audio stuff.
regardless, wouldn’t have worked at last job as no-one knew go either. would have been easier probably to get someone in, but i spent a year trying to get one new hire to no avail, so doubtful.
> The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
Only If I had a dollar for everytime this happens. Choosing a language for the company is a business decision. we have a similar issue with Elixir and now the entire team is spending a quarter just to get rid of it. For anyone building startup on LLMs , this is one killer application I would pay for. The generated code doesn't event have to 100% correct, just right enough for devs to tweek would go a long way.
While I get most of your points, I believe some companies sometimes can or maybe even should experiment with new languages, and see what benefits it brings them.
The important part is evaluating the experiment and having the courage to say “well that didn’t work out, let’s go back to the original version”.
They should have evaluated what is “slightly faster”, how much money it saves and how much it will cost extra to maintain it.
Indeed. The few times I've encountered Rust in the wild it's been for a project that didn't need it (web or IO bound applications) and someone's "My First Rust Project". It's difficult or even at times beyond the budget of smaller organisations to then hire a seasoned Rust dev to unpick whatever mess you got in to.
Don't get me wrong, Rust has a niche where it's the right choice. But being a popular language of the day, it's getting used a lot in the wrong places.
Project that does not need rust "Web, or IO" -> What would you actually choose to make an API then ? Python ? Ruby ? Did you compare benchmarks from rust server to python servers ? Did you actually feel the difference ?
Most web servers aren't doing anything computationally complex and there's a lot of tech to help you scale to multiple servers, so single server performance usually isn't really critical.
Web stuff is about developer speed. So familiarity, libraries, and tooling. There are plenty of good options.
Anything that needs to be performant can go in it's own service.
I will say that a rust service, even when doing relatively simple stuff, can scale well in the cloud due to small memory footprint, fast startup time when auto-scaling in containers, and no need for a JIT to "warm up" before it has high throughout and consistent low latency. Building something with these qualities on a framework like Rocket is pretty straightforward, IME.
Building a web app with rocket is like using a fine BMW to go on highway. It just feels right- I love Guards and what not he added in his framework ; absolutely refreshing work !
Did you not offer to rewrite it in Python? I was a techical director at a company where we worked a lot with frontend contractors. Some loved typescript others were fans of vanilla js. When the balanced tipped there were rewrites from one to the other (ts to js to ts again), the first one two months full time, the second was interspersed with feature development. Of course the developers were very happy they could do it; it improved the solutions and afterward they both had 1) extreme product ownership 2) excellent company problem domain knowledge. So, a win-win for everyone. So I think, especially as it is a smaller part, than translating back in to Python would be warranted (provided you like it and would stay a while), not a big deal and a quite natural option.
That's a horrible rule of thumb, because C++ adds a ton of complexity with little reward except for speed. Rust adds less complexity (still a lot ofc), but it also gives you awesome tooling and dependency management (much better than python for example), and and extemely powerful typesystem and functional programming features, that make writing correct code extremely easy.
Rust is a complex but overall good language for writing solid software, C++ is making a deal with the devil in exchange for speed.
If a garbage collected language can easily do the job, choose the garbage collected language. I like Rust, but it is NOT the fastest language to develop in.
Typescript, Python, Go, Swift, and even Bash depending on the situation are all quicker to code in than Rust.
If any of those languages are inadequate for the requirements whether they be memory-bound, CPU-bound, or sensitive to gc pauses, Rust is an excellent option that is far superior to C++ in 2024 and beyond.
The notion of "one true language" has always been and will always remain a fool's errand.
I write most of my stuff in a combination of Python, JS/TS and Rust these days with some form of Interop between them. I.e. mostly Python Marimo notebook with JS visualisations, and PyO3 Rust bindings.
Tbh I don't find myself to be "slow" in rust. Sure for quick exploratory stuff the notebook-environment and introspection capabilities of a dynamic language are definitely nice (e.g. when taking apart some unknown JSON data format), but especially when it comes to complex logic and refactorings Rusts type system is really making a big positive impact on productivity.
Sure TypeScripts type system is also powerful, but Rust is consistently better at infering types from closures and function calls, and the existing types and tooling story is miles ahead of TS. (and I've never encountered an easier to setup/use model checking language integration than Kani)
For one-offs where correctness doesn't matter, sure throw $SCRIPTING_LANG at it. But once you want correct software, I'd still choose Rust in a heartbeat.
Nope. C++ has mostly downsides, Rust has significant upsides.
A good rule of thumb would be: is correctness and code confidence more important than learning curve and compile times? If so Rust, otherwise JS or Python (with possibly parts in Rust).
Perfectly normal for people to want to develop their skills and to enhance their value.
The thing is that this is not a developer's decision, this is a management decision. The developer might pitch for Rust or even start developing in Rust but if that is not right for the org then their manager should say 'no'.
So ultimately this is a red flag about management.
Needing the managers permission is more of a "wartime" mode.
For peacetime the management should set a culture of peer review and data and logic driven discussion. The culture would ideally have a Rust lover sit there and think "would love to do this in Rust but...." because they know their peers will be affected by this decision.
The problem with management approval required is it usually meams no or bias towards management pressures. A management veto that is occasionally used may be better.
Disclosure: not a Rust programmer but pretty neutral on it. It is on my radar if I get a problem Node or Go can't solve.
God I feel like I’m taking crazy pills when I read these threads.
Can I hire 1000 Rust devs at the drop of a hat off the street? Well, no. Have I ever struggled to find competent Rust devs, or high level people who were happy to learn? Nope.
I would absolutely not be afraid to use it because of “hiring concerns”. If your current devs can’t or won’t learn anything new, they’re not very good at their job. If you can’t or won’t hire because you can’t find a super-senior at the drop of a hat, well, your hiring process is broken and no language will really help there.
The underlying (absurd) assumption is that the sum total potential of a developer you hire to do a job is statically determined by their past experience at interview time. This is the problem with "Human Resources" thinking, it fails to account for all the, well, human stuff.
Case in point from the article:
> it is not viable (for us) to retrain a C developer to Rust
What concerns me even more than the talent pool is that Rust is a language that isn't straightforward to learn.
I can be confident to teach any average developer about Go without any prior experience relatively quickly, I'm not so confident I could do the same with Rust.
These comments make it seem like it's impossible for people to learn Rust. I have to admit that it takes a fair bit longer than other languages, but so is c/c++. Is there a bias towards not using Rust by other devs? Is it a scary language?
A garbage collector really takes away a huge amount of cognitive overhead. In doing away with it, Rust requires that you understand the borrow checker and lifetimes, even if minimally due to extensive use of .clone() in your early code. This ties into all of the different kinds of strings in Rust from str to string to vec[u8], etc.
Unlike Go that only really requires experience in general programming to become rapidly productive, Rust basically requires that you read The Book in its entirety before you even think about applying that knowledge in production. There are just to many interdependent concepts to hand wave away the prep time. It all (mostly) makes sense once you've familiarized yourself with the basic concepts, but it's a training step you simply cannot skip without inflicting a fair amount of pain on yourself and others.
I'd put even more concerns on C++. All the same concerns plus all the concerns that arise from the compiler not helping you nearly as much. It's easy with C++ to be lulled into a false sense of security because it compiles, and your trivial happy path works. Under load or with unforeseen input, the chance for memory corruption is massive even for experts let alone beginners because it only takes one to bring down a whole process.
C++ is better than it used to be, but it was truly atrocious in that regard for decades. It was simply the least worst option for those decades.
I do not consider it the least worst option anymore.
My experience is the opposite. I spend a lot more time in a debugger when I work with golang than when I'm working with rust. Sure, there's a learning curve with rust's borrow checker, but once you figure out how to use it I find rust to be a much more "flow state" development experience, with less interruptions of the form "what is this program actually doing and why?"
I switched up from python to rust for some processing pipeline at work - rust has a lot of advantages over it specifically for typing and speed, the work itself it a little bit longer to develop. But the quality output is not even comparable, the code itself is way more readable and explicit than in python code.
There is not a lot you can do to make your python code as good in terms of reliability or clarity of intent. I'm sorry to hear that you did not have a good experience with it, but frankly speaking, I cannot look at python code anymore because of the inherent "hidden" work that it creates, variables being passed trough without much care for their exact meaning, hidden "bugs" that make the overall job way more annoying to debug.
Python is like that person that tells you everything is fine but is mostly wrong and won't even tell about that. Whereas Rust will just straight up tell you what's wrong in the draft.
I prefer the honesty and the little additional overhead work to getting lost in debugs for weeks bc some person has inputed the wrong shape for some vals or whatnot.
The peace of mind is saving me a ton on maintenance as well.
(project is a 2years on with distributed python pipeline with a bunch of IA processing - switching up to rust was not the easiest thing to do considering some parts had to stay in python because of code ownership being someone's else - the stack is a rust/python stack now with some parts being left out in python depending on the actual needs of update)
I understand very well that some people do not want to code in rust, specifically because they might not have the time or the will to do so. But objectively these people do not have to define the pipeline execution except for the actual order of execution, nor do they need to maintain every part of the code because it's just not their job.
Now if you are to compare the exact benefits of rust vs python for a company, the server pricing will just speak itself and the choice will be made depending on the cost of production, the lifetime of the code, and the actual benefits.
If I was to do some API today, I'd 50000% go for rust and I DO think of python as the `no-coder coder` thing. I initially learned C, switched up to Python for jobs, and the code quality of python is just downright bad. It does not push me in the right direction AT ALL.
The fact that we used a scripting language with no typing for tools that need any kind of guarantee for years does not mean it's the best way to do it.
Also to answer the problem concerning `rust` dev's being non-existant on the market, and no job being open is really simple : even tough rust has 10 years on the developer market on this is really young and need to learn.
You need 3 years of practice to get 3 years of experience with rust. There is no way around that. And there is just not enough experienced people with this language yet to make it a shift. I'm not saying there is none, i'm saying it's not yet democratized.
> You need 3 years of practice to get 3 years of experience with rust.
This is the major barrier. It's a difficult language to learn for people who've worked with a compiled, strictly typed language with manual memory management. That barrier is much higher for people who've only ever used a dynamic, interpreted language.
I'm on-the-fence about orchestration of pipelines with Python since I've experienced a lot of the issues you're talking about, but you can just abstract the Python algorithm parts in to APIs that your pipelines call and separate out those two concerns. Then it's clear who has maintenance responsibility, it separates out the algorithms from data collection + calling, and it doesn't introduce a big barrier next time someone wants to implement something that depends on the latest and greatest algorithm written in Python, which writing in Rust inevitably does.
To me though, I don't really understand the use of Rust in non-systems programming. For a lot of the use cases people talk about, Go seems like a better fit with a lot less of the pain since it's a much simpler language. When teaching people a language I'd much rather do that with Go than Rust, and that matters in an environment where developers who know either are not really that commonly available (at least here in the UK).
> This is the major barrier. It's a difficult language to learn for people who've worked with a compiled, strictly typed language with manual memory management.
This was not what Google and others found when they studied it.
> More significant, Bergstrom said, is the comparison of rewrites of C++ code into Rust.
> "In every case we've seen a decrease by more than 2x in the amount of effort required to both build the services in Rust as well as maintain and update those services written in Rust," he said.
The Rust codebase I’ve built on run faster, don’t crash, are more correct, and take only marginally longer than the first python version. They’re easier to maintain, they’re easier to upgrade their dependencies, I’m more confident about asserting guarantees from the codebase, and it’s an easier time onboarding people and having them meaningfully contribute. There’s no more death-by-a-thousand-cuts that I experienced with Python codebases. I don’t have to worry about my Rust codebases blowing up at 2am because of some random exception.
> The fact that we used a scripting language with no typing for tools that need any kind of guarantee for years does not mean it's the best way to do it.
You can add typing tools now, though? CI pipeline runs mypy and that gets you a long way.
The author complains there are few developers available to maintain Rust code.
I see very few job postings, and almost all of them are either cryptocurrencies (I don't want to waste my life on this), or "3 years professional Rust development in production" (disqualifies self-learners).
Given that nowadays most applications are not replied, it makes little sense to spend time even browsing the postings.
There really is a strange dichotomy. Plenty of Rust developers have trouble finding jobs and apparently companies have trouble finding Rust developers.
For being a relatively new language, there are almost no "entry level" positions.
Just take a look at https://rustjobs.dev/. Most of them are well paid remote jobs, but they are asking for +3 years of "professional experience" with rust, "with a proven track record of building and deploying production-quality code", and more. Hell, iirc, i saw one asking for proof of contributions to the rust repo (eg, being a core maintainer).
edit: to be fair, i saw one position a while ago asking to be willing to learn rust
> For being a relatively new language, there are almost no "entry level" positions.
Isn’t this a fairly well-known phenomenon though?
- new language makes waves. The people who picked it up early do some impressive stuff.
- early early adopter companies either snap them, or internally make the choice to learn it too. In turn, they do some stuff with it.
- gets a reputation for being the hot new thing. Other companies “want in on it”- they want to be able to do the fancy cool things the other places did, but they don’t have the patience, time or culture to grow it themselves so they aim to hire out seniors and everyone with lots of prior experience. <——- many orgs are here.
- proliferates enough that it’s well and truly mainstream. Also known as the “hire 1000 Java devs and throw bodies at stuff” stage of hiring and availability. Python, Node, Java, PHP, etc are here.
As someone who has been searching for a Rust job lately, few rust roles are only Rust. Many are Rust + another niche domain.
- Must have 5 years of Rust and 8 years of embedded experince
or
- Must have 5 years of Rust snd 10 years of writing SQL engines.
or
- Must have 2 years Rust experience and 5 years with Linux kernel development.
etc...
If you are looking to hire someone with specific domain experience, it makes more sense to compromise on the Rust language side of things. A developer can learn Rust on the job, but it is harder to learn to write a production SQL engine on the job. But that means you aren't hiring Rust devs.
Developers who just specialize in Rust are behind their peers who are domain experts when it comes to looking for a job.
IMO that means Rust will "win" not when a bunch of undifferentiated developers learn Rust, but when the domain experts learn Rust. e.g. Kernel maintainers.
> 3 years professional Rust development in production" (disqualifies self-learners).
It doesn't necessarily. Very few jobs postings that require "N years of experience in language A" actually require that. Most will accept N years of total experience and some smaller amount of experience (not necessarily professional) in language A.
Chances are that recruiters just ignore your resume without even thinking about it.
Especially if there are other candidates who do have that much experience in a specific language. Even if you are a better candidate overall (whatever that means), you need to pass the resume screening first.
> Chances are that recruiters just ignore your resume without even thinking about it.
That's why should always try to avoid recruiters and apply direct if possible!
> Especially if there are other candidates who do have that much experience in a specific language.
True. But the context of this discussion is that there are not very many candidates with the (nominally) required experience (i.e. several years of professional Rust experience). And that's often the case as job specs often have unreasonable requirements.
A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.
Without this, using even very simple hardware interfaces (like an SPI/I2C bus) is gonna be a huge pain, because you'll have to comb through reference manuals and register descriptions for your processor and piece everything together yourself instead of just calling a few API functions (this is also very error-prone and using Rust is not really gonna help one bit).
The only chance to get even halfway decent rust integration is to pick one of the like 3 most popular hardware platforms among hobby enthusiasts (think ESP32, raspberry pico), which is simply not viable for a LOT of embedded applications.
So I still think its probably a really bad idea for a typical embedded-shop to fully go for rust right now-- the downsides from lacking tooling/libraries, reduced developer pool and the need to train extant devs appear very hard to overcome to me.
For some complex peripherals (especially wireless) this may be the case, but in my experience it's often much easier to write small abstractions for what you need in the mode you need it in (for serial, timers, IO, DMA, ...) than relying on manufacturer SDKs, which are often so poorly documented that you need the reference manual anyways to understand the peripheral to then understand the abstraction, which is often much more complex to use than it needs to be for my use cases. With abstractions in Rust or, for something quickly thrown together, in uPython you're at least getting "you're holding it wrong errors".
Interfacing with the peripheral registers themselves is also a bit simpler with Rust in my experience, as a proper .svd already contains bitfield setups with enums and R/RW/W1 information to at least set the bits you want instead of the Macro-Hell in C some manufacturers throw at you.
> A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.
If you have a reference implementation in C it's not such a big job to set up something like an I2C or SPI peripheral. At it's core, you're making a sequence of writes to some memory locations. Most of the manufacturer libraries are quite low quality, and very easy to misuse. In my experience trying to do anything that pushes the hardware, you will end up combing through the reference manuals anyway.
I've done a bit of embedded rust, and the huge benefit - just like on desktop - is that code which compiles tends to do what you intended. Obviously there's still scope for logic errors, but that takes away a huge amount of debugging time.
Even with the vendor libraries last time I had to poke at a CAN bus I ended up having to go to that same level because the C helper libraries omitted key features of the interface.
There's a number of micros these days where the same libraries are provided using SVD[1] that will generate interfaces which is handy.
Not a Rust dev, but couldn’t you use FFI to call the C routines from Rust?
Of course you‘ll have glue code which is seldom pretty, and depending on the amount of Rust actually involved at runtime it might be questionable to do in the first place.
Absolutely! But this is a huge amount of complexity in build system/linker setup/debugger that you are gonna have to stay on top of. The gains from using Rust need to be overwhelming to justify a setup like that.
Also consider that calling those FFI APIs from Rust is not gonna do anything for you by itself-- you are basically just calling C functions with extra steps... To actually get anything out of it, you'll then likely have to wrap the whole hardware interface in a "rustified" API (which, again, you'll probably have to write and maintain yourself...)
Many years ago, our project had a library that would link our Ada code to the low level operating system calls that are in C (network, shared libraries etc).
Once it was written the code was stable, but you bring back not so pleasant memories of building / testing. It might just be our make files were unnecessarily complex or we were building libraries not executables…
I think it’s a pretty mixed bag, but yeah no one really has a lot of support for rust, but c++ support is quite common and “good enough” for lots of things where you’d like more complicated but zero-cost abstractions. RAII, getting rid of pointers, maps, vectors, etc
The irony in this article is that even the much lauded ESP32 integration is essentially all of the important stuff like WiFi continuing to run and live in the C world, while they have a little Rust frontend for all the hipsters to believe their great bugfree Rust code is making the world spin.
Basically, this is a company who uses ESP32 to read serial data from batteries using UART and retransmits it in json over MQTT. They apparently had buggy C code to do that (for unspecified reasons) and successfully rewrote that in Rust.
Conclusion, you can write ESP32 code in Rust. No information on what that actually entails sadly.
Some more information on ESP32 on Rust. Espressif (the organisation behind ESP32) spent effort to properly support Rust on their chips, see their documentation: https://docs.esp-rs.org/book/
Another nice resource for Rust embedded is https://embassy.dev/ which also supports STM32, Nordic chips, and RP2040.
IMO, the coolest feature about Rust embedded is that Async Rust works! This makes building a HTTP server for your embedded chip easy.
I was just about to point this out in my own comment but yours sums it up quite nicely. As an embedded software guy this article gives next to no specifics or details on what the bugs were and how they got solved with Rust.
Yes I wonder what was wrong with the C code. Was it fixable, was it just a single loop code that ran or could they have used something like FreeRTOS to handle multiple tasks with less chance of bugs?
I would have liked to have more details because it's easy to have memory related issues when using a serial protocol in a memory constrained environment and I was wondering if somehow some feature of Rust helped them.
I would guess that the more expressive type system is very nice but I don't expect memory safery features to be that useful in this context. Would like to hear from someone with real world experience on that.
If you're parsing a serial protocol on an embedded system where you're only getting a byte-at-a-time (from a register), or possibly up to 8 at a time, then a parser combinator library such as nom should make it very easy to create a bulletproof parser.
Definitely much easier than in C, where I've resorted to using Ragel for safely parsing serial protocols (and also in Go!) since it generates a single small dependency free source file containing the state machine and your "actions", but nom is much more expressive.
Parser combinators are notoriously poor performance and memory-wise. They are somewhat nice to write if you like the style and don’t mind the tax but we are talking about ESP32 here.
Unless they are inexperienced, the issue is unlikely to be the state machine anyway and more likely to be in how they manage buffering of long message to avoid running out of RAM.
As someone who is using Rust in production for a year now [0], albeit in a different industry -- webdev, I really like the language. Sure, the first steps were rough, but eventually DX became decent, and the safety guarantees of Rust allow me to have a safe mind when developing and deploying (something I can't say about other popular dynamic languages).
Having said that, I agree with one of the commenters in this thread: Rust is essentially a solution looking for a problem. It is a great language, but it fails to find its niche. Rust developers are nowhere to be found, companies are not hiring Rust developers (except if you want to work in crypto).
I think it solves many problems regarding safety in lower level languages and with some great language features, so I can't really understand your take. Sure, C++ is more established with the benefits that entails, but that's not because of the language.
I don't disagree with you. My comment was merely to agree with another commenter who said that there is a catch-22: Rust developers can't find jobs, while companies who are looking for Rust developers can't find candidates, because Rust can't really find its place in the industry outside the crypto world.
Ah, right! I think rust will find more use but it takes time. Many existing technologies and languages are probably good enough for most suitable projects with historical baggage. Maybe crypto industry is just in a good position to try new, safer languages for new projects, who knows.
Nowadays, Linux kernel also has some drivers written in rust so I'm hopeful.
It has definitely found a niche in the crypto space, specifically with the node clients and the underlying new cryptography libraries they use. For instance, the more efficient Ethereum devs can make their node clients, the cheaper it is to run and the more people around the world can run it, which increases decentralization. Rust makes this possible without compromising on stability and maintainability.
The problem is that I still see all crypto as "scam", thus choosing Rust makes a non-viable choice for career progression. But I don't care about career progression anymore, so :shrug.png:
There’s a guy who I work with who went to work for a crypto place that then exploded (as they all tend to do). He had quite a difficult time finding a new position, and was asked multiple times about working for a scammy company. So perhaps don’t underestimate the negative effect it can have career wise…
If you wouldn't write your program in C or C++, then it's not the problem that Rust is trying to solve.
Rust has some nice high-level features and tools, so it gets used in other areas like web dev too, but in the end, it is a systems programming language. It is a low-level language, even though it may not feel like that a lot of the time.
Let's say I want to use a real type-safe language to write web applications. So rails/python/JavaScript/php is out of the window. I'm left with two big options: Java/Kotlin and C#. If I want to avoid Microsoft, I'm left with Java. And in fact, this is the industry standard for "real" web development: financial, enterprise, etc.
But Java is cumbersome. It's very `FizBazBarFooAbstractInterface` type of cumbersome. Kotlin makes it nicer, but Kotlin didn't get much adoption in the web industry. C/C++ is too low level for web development. Rust is the perfect language, in my opinion of course, to fill this niche.
Oh, there is also Go. Which is, by the way, also a system programming language. But nobody argues that Go shouldn't be used to write web services.
Never considered. I grew up coding in C, so always wanted to come back to something similar. After being spoiled by PHP/JS, couldn't go back to C/C++. Rust offered me a modern, C-like language, so I just learned it and applied forcefully wherever I could.
I remember looking into Rust for a personal project, on embedded, in 2016. After poking through all of it I decided against doing that because it was clear I'd be spending a lot of time getting Rust working at all instead of doing anything for the project itself. So C it was.
The thing I have to say in the context of the article is this: There is no way to know whether a complete rewrite in C would have yielded similar results to Rust. The phrase "C prototype" made me squirm, even more so when reading that in the context of critical infrastructure. It is known by now (or should be) that such prototypes live on like zombies, so unless it is really some throwaway (from the point of architecture!), these things tend to live on for longer than most feel comfortable with. And, being so critical in function, maintainability is one of the primary concerns.
Yes, Rust will, eventually, at some point, maybe? the go-to language we use in the embedded field, but we are talking not just about a language replacement, we are talking ecosystem replacement. That is not going to happen overnight.
That said, as some mentioned Java, Perl, and such things: I revived a personal Perl 5 project not too long ago that was more than 20 years old by that point. Needed a small change because the latest installment of Perl 5 is a bit more restrictive with some borderline syntax things (good), but other than that it just worked. In the larger context of the project there is also some C code for binary file processing, also >20 years old. Needed a renaming of a POSIX function (arguments and functionality all the same, though), and then it worked, even compiled as native 64 bit code. Granted, there are not that many dependencies beside POSIX, and the code was even back then written to a level of quality that allowed it to run on all sorts of (POSIX) platforms already.
Which is why "C prototype" sounds to me like "we cobbled something together", and all sorts of bugs are no surprise then. You can cut only so many corners before it becomes an issue, especially in software that is used all the time and in a critical place of a system. This needs to be done right, else you will waste a lot of time (and money!) afterwards.
Imho Rust will be not much further in embedded world in 2026 than it was in 2016. I managed to get in the role where I have hiring decisions to make. From this perspective I need somebody to be able to work with existing projects in C from the 2006 instead of knowing cool new language. There is no single advantage for a company selling products to change the language used. Transition will only cost money.
Regarding C prototype. I wrote it. 6000 lines of code, works nicely, 4200 lines of code were Xilinx driver calls to move data between the hardware blocks. So changing the language will not really bring any benefit. Maybe even opposite - one must study the register calls and read data sheets to create equivalent functions in other language. The code wasn’t beautiful, was created as “prototype” and was at the end the version shipped to a client.
The embedded rust ecosystem has invanced a pretty insane degree since then. I have an ongoing embedded project and I have had to use C FFI calls a total of zero times in a ~100kloc codebase. There are native rust HAL libraries autogenerated from manufacturer published device specs that are insanely good, and take advantage of rust type system features to offer vastly superior APIs compared to mfgr provided C libs
I am a C/C++ dev learning Rust on my own, and enjoying it. I am finally starting to enjoy the jiu jitsu match with the compiler/borrow-checker and the warm “my code is safe” afterglow … but I have a question for the more experienced Rust devs out there, particularly in light of the OP’s observation about “lots of unsafe” in the Rust embedded realm (which makes sense).
If your Rust project leans heavily on unsafe code and/or many libraries that use lots of unsafe, then aren’t you fooling yourself to some degree; i.e. trusting that the unsafe code you write or that written by the 10 other people who wrote the unsafe libs you’re using is ok? Seems like that tosses some cold water on the warm afterglow.
> As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.
That is not true. It is possible to have two pieces of validated unsafe code that are "safe" in isolation but when you use them in the same codebase, create something unsafe. This is especially true in embedded contexts, where you are often writing code that touches fixed memory offsets, and other shared globals like peripherals.
In some cases you might have the excuse that, well, you did say on the tin not to do this with the unsafe element. For example if I use Bob's "I need exclusive control of GPIOs 2, 3 and 6" and also Kate's "I need exclusive control of GPIOs 1, 2 and 4" unsafe code, then it's my fault, they did both tell me this requirement and they clash.
But in general this is specifically a bug in the unsafe code. The Rustonomican is very clear that it's not the safe code's fault that your unsafe code doesn't work. In the scenarios with conflicting libraries I guess it's the fault of somebody who linked conflicting libraries, but it's definitely never the safe code.
As expected, the people problem is the biggest factor. Turns out getting C folks to learn Rust is a difficult proposition (hello, lkml) but the other way around it isn't too much of a problem.
I wonder how much of it is low-level experienced developers only ever using C fail to see that C is not the universally best tool (or, 'if all you have is a hammer, everything looks like a nail' question).
I generally speaking agree, but I would be more specific:
If the person in question has a true passion for the craft, you can regardless of the age/seniority of the developer (at least in my experience). In fact, learning something like a new programing language is a big undertaking and if your work doesn't offer incentives/rewards the will has to come from the person him/herself and so that's why the passion bit I mentioned above.
In my experience I also notice that more senior/older devs are more reluctant to learn new things, but I am unsure if that's due having their passion destroyed by many years of bullshit companies politics, pointless meetings/trainings, and adherence to the latest flavor of agile development every quarter or simply an age thing (I'm not there yet and so I can't tell first hand).
The big problem with learning new programming languages is that you're going to suck at it for years until you reach the same level of familiarity with the new one.
Suck here is more of an emotional thing. They can output high quality code fairly quickly. The issue is not knowing all of the quirks of the language and all development being slower and more difficult.
Dropping down to simpler tasks while learning the language is a huge ego blow.
And this is where LLMs help tremendously: you know exactly what you want to do, you don't know how to do it specifically like it should be done in the language you're learning, you query the latent space of the internet using plain english and you get an answer.
It was a good argument literally a couple years ago less a few weeks before the chatgpt first release. Nowadays it's basically a moot point.
I'm surprised at how useful the latest openai model is for me when it comes to either learn a python library or a new language, such as cl, for example.
When you learn a language, you don't just learn how to use the syntax of that language idiomatically. You also need to learn to use the different tools in that ecosystem
Would this not also be partially connected to not wanting to throw away your 15 years experience with C for 1 year experience in Rust assuming the company actually ditches C? (or any other direct replacement language/tool scenario)
Sounds like a way to replace yourself by 2 low pay students who also have 1 year of Rust experience.
I'm genuinely surprised there are Rust developers out there that don't know C. Perhaps I'm showing my age, or my ignorance to how much CS education (even self-taught) has changed.
It's still thought but it's mostly a pointer course from my recent experience. It's a low credit subject where you play around with arrays and strings, maybe there will be an overflow calculation as well. Whereas something like Rust you'd do in a high credit course project where you have freedom over the tech stack and actually produce something with functionality.
Edit: My point with the replacement is not that juniors don't/won't have C on their CV but that a manager would be more willing to replace an experienced dev with 1 year exp in the current tool with 2 worse devs also with 1 year exp in the current tool compared to replacing an experienced dev with say 10 years of experience in the current tool with 2 worse devs with 1 year experience in the current tool.
I understood (and agree) with your original point. My comment about not having C experience/knowledge came from the article, where it really did sound like just that.
I studied physics, not CS, so I can't really speak to the CS curriculum part. But I am someone who has written rust professionally for a few years so I'll describe how I got there. I think the most experience I've ever had with C was writing a fourth order Runge-Kutta routine and calling it from python for a college project. Maybe 20 lines of C? In industry for the first 5yr I wrote lots of python and java code for web APIs and "big data" systems. Simultaneously around 2015 I started getting interested in rust because it seemed interesting, and like it would probably play a big role in the next 20yr--memory safety without a garbage collector is inherently compelling if you've spent time trying to make java GC act right. Eventually I got a job which was a full time rust gig. After about 3 years of that I ended up in a golang shop. So I've written some tens of thousands of lines of rust and only a few lines of C. I read C, but it would take a while for me to get comfortable writing it. But I wouldn't, probably, because I can use rust instead.
That's really just being a Luddite, I understand the mindset but that's a very poor strategy if one cares about job security. A (good!) senior developer has a ton of value outside of the pure mastery of a language specs, not to mention that learning a language for 1 year with 15 years of prior knowledge really doesn't lead to the same level as a student who does the same.
That kind of value only matters as long as you can find an ecosystem of companies that can be convinced to pay you what you think that value is worth. Many companies can't be convinced to do so and the companies that can are overflown by candidates smarter than you that have regular contributions in top rated github repos if they haven't made super popular frameworks and libraries
It's a RoI. Are you just telling them to learn something new or are you explaining the benefits and costs of learning Rust when they could be learning X?
The article says that the author wanted to hire someone who knows both Rust and C to maintain his company's embedded projects, but was unwilling to hire a C developer and wait for them to learn Rust. I'm not sure how this supports your point. I would argue that it's more that most companies aren't willing to let their employees spend a significant amount of time learning new skills.
It's widespread practice to notate who owns what in the comments in C code. "Ownership" as a concept comes from well established C best practices and a good C developer is going to understand exactly what you mean if you say something like "Caller owns the memory returned from this function" etc.
To get robust software out of C you don't have many options other than to adopt these rules. You can have useful software which breaks all of these, but you don't want to maintain it.
Robustness is relative. You can certainly write a cli that does everything in an arena; your GC is the OS and so going out of scope -- who cares. doing nothing and eliminating whole classes of errors from consideration (UAF e.g.) is incredibly maintainable.
Or, as the old tale goes, your GC might be the software literally exploding (it's in an air to air missile)
Using pointers correctly and safely in C basically requires tracking pointer rules substantially similar to the rust pointer rules, but in your head. Most people who don't do this just write incorrect code, although it might only rarely cause a serious problem.
The problem I have with articles like this is that if we were to substitute anything in for 'Rust', it would read the same. I imagine if they had re-written it in C it would also be better than before. If it was an advert for anything, it might be chucking away a dodgy prototype and starting again (which is surprisingly rare).
Anyhow, on the other side of the coin, it's good to see newer languages getting a proper outing in real world situations. Proving stuff is 'up to it' can be a bit of a long haul, so every data point is useful.
It depends how proficient you're in Rust. Once Rust itself is not a difficulty for you, there's a lot of productivity gained from having a modern language with many conveniences, and great tooling.
Rust moves more bugs to compile time, so you will technically spend more time getting the code to compile, but in my experience in 99% of cases it's a time saving. And it lets you be more confident about a program correct by construction, rather than merely fuzzed and not observed to crash. The 1% of counter-examples is trying to be too clever with generic interfaces and hitting Rust's limits.
Didn't they just have a shitty implementation written in C (could have been any other language...it's not the language!) and than learned from the past mistakes and written a new implementation in Rust(could have been any other language)?
And now the author tries to attribute it's success to Rust?
I've done many rewrites of C in C, and C in Rust, and there is a big difference that is directly attributable to Rust.
The safety of references, no raw malloc, no null pointers, compiler-checked thread-safety of types, consistent and enforced error handling help a lot to make robust programs, and allow making bigger refactorings without fear of screwing something up.
The Turing Tarpit means that theoretically everything you can write in Rust you could have written in C, but in practice Rust enables things that wouldn't be worth the risk/effort in C, even when doing a ground-up rewrite.
Maybe. But them the dev wouldn’t have been able to add „Completed a migration of legacy C codebase to Rust with zero issues in production“ to their resume.
Also might have been easier to get budget for „build something new to replace old thing“ than „fix pesky bugs in somewhat-working existing thing“.
Given the difference in availability of jobs and the amount of code out there, unless you are working in startup world or on web dev, this would be a major red flag on a resume in a lot of cases. Even the use of the word "legacy" is a problem. Like, this isn't "legacy" you asshole, this is our companies highest revenue product with a decade of hard work behind it and we don't want somebody that is going to be constantly trying to shill rust when we hired you to help maintain an important C codebase that is part of the foundation of the business. We need you to get good at C, despite all its flaws and issues, not complain.
This kind of attitude only works in an exceedingly small part of the software world that just happens to be disproportionately represented on sites like HN. Elsewhere, it's not a good luck to be using words like "legacy" on a resume without a lot of explanatory text about why exactly it really was legacy and deserved a full rewrite.
“Legacy” is just the tech industry’s passive aggressive euphemism that means “it’s old and I haven’t learned how it works.”
I have the same sense as you: when someone tells me they rewrote their company’s “legacy” code, my spidey sense perks up. Now I’m wondering if there was really a good reason or if he just refuses to learn an existing code base.
If you're going to try using rust for esp32 development, you'll use the wrapper libraries that Espressif maintains. When things don't work correctly, you'll be dealing with a larger problem space as you try to figure out whether the problem is your implementation / logic, the lower-level libraries, or the wrapper libraries. I don't know what benefits you're gaining using rust if you're not using a native rust (to the metal) stack of libraries.
If only Oxide found a need for esp32 modules, perhaps they would be up for the task?
I’m doing some C on esp32 currently, and wondered about switching to rust, and I understand that simple cases with Rust are solid. I’m definitely interested in trying it out.
However we need to work with a lot of the hardware apis like twai, ble, lte, ota, etc. It seems like support is spotty or it’s DIY.
It’s also worth keeping mind the remark about developer availability. I can generally answer questions about the C to someone who’s not experienced in C, while Rust might be another story.
I can somewhat attest to this! I have a pretty extensive prototype of using Rust on ESP32 in production. I wrote a reference implementation for ESP32 platforms deployed via BRSKI, a secure remote key bootstrapping protocol which builds upon attestation keys and public key infrastructure.
I'm largely using `esp-idf-svc` for most things, which is a Rust-native wrapper around ESP-IDF code. For anything closer to the hardware, I'm using `esp-idf-sys` which is just a thin wrapper around the the `ESP-IDF` SDK.
Hi! Thanks for your reply. First time hearing about Brski, I’ll have a look
I guess your takeaway is that despite spotty support, the benefits of rust are net positive? I guess learning to call C from Rust is gonna be part of it too right ?
I'm ignorant about Rust, but to me it's just static type language akin to C#. And C# has IOT library which seems to target Rust most usual use case, namely on embedded platform. C# also has memory safety just like Rust.
So why do we need Rust at all? What's the use case for it?
Rust compiles to native machine code. C# compiles to bytecode which runs in a runtime environment. That adds a huge amount of overhead, and means you don't have direct access to the hardware registers. The .net IoT framework is targeting computers running operating systems.
When you compile rust for an embedded target it's running "bare metal" - there's no operating system, the microcontroller literally just starts running the instructions your compiler put at memory address 0. If you want anything an operating system offers - task scheduling, memory allocation, file system access, network access etc - you have to compile it into the binary that's loaded into the microcontroller.
Only languages which compile directly to machine code are really suitable for that - C, C++, Rust (plus a long list of less common ones - this list of languages which can compile using LLVM is a good place to start https://github.com/learn-llvm/awesome-llvm?tab=readme-ov-fil...)
Here are examples where C# is successfully used as a language for an embedded target.
In addition to that, compiling to bytecode is just one way to execute it out of many, and the statement does not correspond to reality. I'm not arguing C# is a good language for IoT. I'd personally use Rust for that in almost every situation, but the amount of false claims in this discussion is disheartening.
Is it really true though? I don't have much knowledge about embedded development, but as far as I know, Java has been used in many embedded systems, and was running on phones' SIM-cards. Please correct me if I am wrong.
I think that most modern embedded systems are nowadays more powerful than my first desktop computer — is it really still worth for the majority of embedded projects to count every byte at the expense of developers' productivity (and overall project success, as a result)?
SIM cards are a weird exception because they have a hardware computer designed to run a subset of Java. Normally Java compiles to a bytecode which is run by the Java VM - in SIM cards the VM is a hardware implementation of the Java VM. That's super uncommon - most processors in the world have a different instruction set, like ARM or RISC or x86. Java can't compile to instructions in those languages. Rust can.
Yes, you can run a VM on one of those processors in which you run a language like C# or Java. Look at MicroPython as a successful example. But the code which runs that VM has to be written in something. Typically that has been C and C++ - but Rust can also do it.
You're right though - a lot of what we call "embedded computing" could be done using a modern VM interpreted language. There are some languages out there - MicroPython and Squirrel come to mind - which can run on the memory and storage constrained environment of a microcontroller. The mainstream implementations of Java and C# use way to much memory - they've been optimised for desktop environments. Microcontrollers often have 64 - 1024 kB of RAM.
You could ship products with application processors like the Raspberry Pi, running an OS, and write your application in whatever language you like. But that costs 1-2 orders of magnitude more money. A cheap microcontroller is $1. By the time you've added the RAM, flash and supporting power rails, a cheap application processor is $10+. Then you have to maintain an OS - that's a lot of engineering time. Sometimes it's worth it, sometimes it's not - the tradeoff depends on the product.
Not sure how well it fits reality, but it’s also to a large extend how dramatic can be the result of a fault of your system.
If it’s embedded in a coffee machine, maybe all cost-effective taken into account it’s ok to have an over-bloated software stack maintained by the cheapest folk the manager could found.
Now if you are working on embedded software for some vehicle like a critical part of a car, a train or a spaceship, considerations of safety for both ethic and legal reasons might lead to different tradeoffs and conclusions.
C# is the language with the best degree of control over allocation among all GC-based languages. You can write code that is completely allocation-free including abstractions. Most "data processing" APIs in the standard library do not allocate at all or allocate once for initializing e.g. lookup tables.
The actual issue is existing selection of runtimes for embedded platforms is limited: https://nanoframework.net/ and https://www.wildernesslabs.co/device (to be fair, a friend of mine uses the second one for automating his lab for his microfluidics devices research project, so it is useful).
You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics (C++ lite if you will), that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all.
I'm not saying it's an optimal choice for embedded, only pointing out that you can write allocation-free code with confidence. Patterns that allocate are known - predominantly boxing and closures. You can easily avoid both, you can also declare your structs as 'ref struct' which completely prohibits placing them on the heap, either as a box or as a part of heap-allocated memory inside some other object/struct.
I would argue that using JSON in embedded, especially on ESP32, is another no-go. I'd wage that using a binary format and later on, after you're out of ESP32, convert it to JSON would be a bigger performance gain than the evangelic tone of this article vis-a-vis of Rust.
You're missing that Rust has safety in terms of multithreading, which C# doesn't have. Writing a data race in C# is the default, writing thread safe code takes work. In Rust, the default is that it's safe, you have to jump through a lot of hoops to try to make it not thread safe. The same is true for async, which in C# is also a problem.
In all C# codebases I've seen, you have threads and tasks, and you often run into multiple threads or tasks holding a mutable reference to the same data. That's not legal in Rust without synchronization/locking.
If you don't believe me, just spin up a new main.rs file and write code that has a data race.
While it is true that Rust is a strictly superior option for highly concurrent systems code, it still leaves areas where you can make a mistake regarding lock management and other advanced forms of synchronization.
In addition to that, .NET as platform is fairly tolerant to misuse and calling the code that is not thread-safe from multiple threads concurrently usually leads to logic bugs or "stop modifying this collection concurrently, please" exceptions but not to catastrophic memory safety issues like it happens in C/C++.
> The same is true for async, which in C# is also a problem.
Now, this one is strictly not true. Async primitives are thread-safe. In Rust, you must synchronize because at the very least you must deterministically deallocate memory used by shared state between the tasks. In C#, this complexity is handled for you by a GC (ironically, you get negative sentiment towards async from people having experienced Python's async or Rust's async complexity, assuming the same applies to C#). In some scenarios, it is also a throughput optimization since it reduces memory contention by not modifying the cachelines shared between the cores, lending itself into better performance on many-core systems - the memory is modified/reclaimed when it's no longer in use, while the actively shared data is placed elsewhere.
I think the thing you're missing here is that "Internet of Things" usually means machines way beefier than "embedded."
IoT is roughly equivalent to a Raspberry Pi - the thing will usually have an operating system that you're running on top of, and most of your existing knowledge about computers will port over.
Embedded is the chip in a happy meal toy, or your microwave in 1995. There is no "operating system." Your code is the only code running on the machine.
That kind of embedded work, like connect-the-dots pcb layout work, went overseas 15-20 years ago. The typical new embedded project in the US today has minimally a not-particularly-resource-constrained 8-bit processor with gobs of fancy peripherals, something like the PIC Q10 series or the ST equivalent. The median would be a 32-bit ARM Cortex M.
Typical IoT SoCs are a step up from that but it’s not huge. The ESP32 is pretty representative but there are significant other options - see what Amazon supports in FreeRTOS as a starter.
It’s a big leap from small IoT SoCs to SBCs like the Pi.
TL;DR we had some buggy C code and fixed the bugs then rewrote it in Rust and wow we didn't have as many bugs... that we already fixed.
Rewriting something is not the same as the first effort. Try green fielding see how long it can she develop it once you already had the first basic C code it's pretty trivial to convert it to rust most of the time especially just using other libraries.
And imagine that. You fixed all the bugs in the prototype and the second rewrite didn't have as many bugs. That's his nothing about the second versions language it just says you fixed all the bugs in the prototype.
In particular, you could teach it to Physics PhDs, which might be useful as today they are mostly taught Python and so they end up leaning on libraries to go faster because the Python isn't fast enough.
Once upon a time a specialist in Computational Chemistry or Physics or whatever would be expected to learn Fortran, and it makes lots of sense to use Rust for the same purpose in the interim (eventually a WUFFS-like special purpose language seems like a better fit to be able to deliver absolute safety and better performance by not needing to care about generality)
Access to competant Rust developers can be a challenge even for large companies.
I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust.
The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake). I pointed out to the Technical Director that this was a big mistake and the teams had taken on a large amount of technical debt for no reason other than the ego of the wanna-be-rust-developer. Since I "knew" Rust he wanted me to maintain it. My advice was to go back to the Python scripts and I left.
This question of "what tools / languages" should we use was introduced to me (during an interview, actually) as "technical strategy". There is more to the choice of language or tooling than whether it's fast or slow or reliable at one instant in time -- you have to ask how you will grow and maintain things going forward.
That said, obviously all languages were in that state at some point. Twenty-eight years ago you might have said the same thing about Java. Twenty-four years ago, Perl might have looked like a better choice than Python; now it's clearly the opposite. XenServer took a gamble and wrote their main control stack in OCaml in 2008; on the whole that has had some benefits, but the number of OCaml developers has not significantly grown, and it's not easy to hire people.
That said, I think Rust is much more likely to follow Java's trajectory than OCaml's: My prediction is that it's only going to be easier and easier to find Rust developers.
I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine.
The python scripts of the same vintage have to be reworked because python versions and importantly supporting libraries have changed.
This is mainly because Perl hasn’t changed, with the failure of perl6 to launch. But it’s an interesting comparison.
I’ll agree Rust will be like like Java.
> I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine.
I'm not talking primarily about Perl as a technology in and of itself, but as a long-term technology choice in terms of being able to find people to maintain and improve it.
The Xen Project has a bunch of support stuff (automated testing and tooling around doing security work) written Perl. It was just about a reasonable decision when it started to be written 10-15 years ago; Golang was too young, Rust wasn't written yet, and Python had its downsides. But when the author of the code left the project 2-3 years ago, and there was 1) nobody with a similar level of expertise to maintain it, 2) nobody particularly wanted to gain that expertise, and 3) it wasn't easy to find someone else to pay to do maintenance.
If you've managed to find people who can maintain those perl scripts, more power to you; but it unless perl5 can get some momentum back, it seems like it's going to be harder and harder to find replacements.
The thing about Perl developers is they tend to stick around. At the last Perl shop I worked for, the average employment time must have exceeded 10 years. I could say the same of Prolog and 25 year average employments.
RE: scripts, I find Golang better and better for this nowadays. Uber-fast compilation, to the point of it being acceptable to just instead do `go run your_thing.go` even, and you have access to a very solid runtime and many libraries for most of what people usually need.
I don't argue with the portability and longevity of Perl but it too has its problems.
The longevity of Go is also a thing. I have not encountered a single Go project that used to compile but now doesn't because it hadn't been touched.
Go is in many ways leap years ahead of most AOT languages I've used in anger. Yes, sometimes you miss XYZ, but seldom is that an issue outside of personal preferences.
What you do get though is amazing tooling and little-to-no downtime. Builds basically don't take any time, tests run past, pipelines are quick.
go test ./... finishes faster than you can print Determining projects to restore... to the screen. It's a very liberating experience that is hard to go back from.
Agreed 100%.
I have my very real pet peeves with Golang -- lack of sum types and thus no exhaustive pattern matching is the top one -- but I can't argue with results. Every time I wanted to whip up something quickly, Golang has gotten the job done and then some.
I've gotten far with type switching on an interface that amounts to a single function that does nothing.
Unfortunately it does nothing in terms of exhaustiveness, but it effectively gives you sum types which IME are so, so much easier to work with than state pattern or other inject-an-object-abstractions. Not having to design an API (that later leaks) is rewarding enough.
It's strangely efficient as well. I've experimented with implementing sum types via tagged C-style unions and at every (ad hoc, micro) benchmark I've tried them against, type switching on an interface comes out on top.
Can you point me at an article that demonstrates Golang type switching? Does not ring bell at the moment for me so I'd love to see the code.
https://go.dev/tour/methods/16
Thanks, for some reason I never stumbled upon this. Very valuable, I am bookmarking it.
Still leaves a lot to be desired versus Object Pascal from Apple/Borland days, or Delphi afterwards.
What makes those better?
The language features, designed for full stack systems programming, IDE tooling, the frameworks bundled with the compiler, first class support for binary libraries ecosystem, no culture against modern times...
I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though.
Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.
I wish and I'm sure Rust will get there some day but is there a no-brainer usecase today where it's really important to use Rust, one important enough to overlook the initial learning curve, developer scarcity and evolving ecosystem?
If there's a killer open product out there where the primary supported language is Rust(Linux kernel might as well be it someday), or if a big company launches a successful product in Rust then adoption may accelerate. For now its mostly limited to cryptocurrencies, performance critical paths or rewrite of hidden core components but nothing flashy.
"Nobody ever gets fired for buying IBM". Unless teams can say the same about their choice of Rust, people are going to be risk averse and prefer using safest choice as long as its good enough.
Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously.
Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.
[flagged]
Nobody is stealing anything, what a weird comment.
And the problem with new kernels is how to reuse the huge trove of already-written drivers. Nobody is going to start rewriting everything in any language, be it Rust or any other -- does not matter. That's why the ABI and "please commit to a standard" points are so difficult and thorny in the kernel ecosystem; people want to reuse.
Again if it's so great fork the kernel and make it great. People will flock to you if you can manage.
> you have to ask how you will grow and maintain things going forward.
The typical answer is "The jobs market will provide".
The issue with that method is that you end up competing with everyone and, usually, your company is not the top employer.
OTOH, some companies decide to use technology and invest in knowing the community, by hosting events or meetups, by frequently sending their devs to conferences on company time, etc. Usually, the people hired are above average, and are also able to train juniors if the market dries up. These companies typically are the safest in terms of ability to maintain their stack, but have to account for the fact that alienating their existing devs becomes a big risk.
The real harm comes for companies that choose niche tooling but believe the market will provide.
Right -- you can choose a niche technology, as long as you're willing to commit to the additional costs of doing more training, being involved in the community, and so on. Those additional costs (and/or the risk of not doing so) need to be factored into the decision to use a technology.
Twenty-four years ago, Python already looked better to me. I maintained a big Perl 5 app. Yuck. The problem wasn't that you couldn't write it, the problem was that you had to be able to read widely differing styles of Perl... and if you wanted to read library code, it was a huge pain. I quit maintaining that system in 2005, and it has barely changed since, from what I'm told.
Viability of a language is certainly a consideration, but the characteristics of the language also matter.
What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.
> Rust is much more likely to follow Java's trajectory than OCaml's
I'd rather compare Rust to Haskell and Kubernetes.
> it's only going to be easier and easier to find Rust developers.I imagine it's never been easier to find Haskell developers and Kubernetes developers, either.
Yet, one's wish to code Haskell professionally does not necessarily align with one's market value.
It seems like there's a lot more open for Kubernetes, so Rust could go that way.
Unlike Haskell, Rust seems to gain industry acceptance.
Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling.
Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created.
So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way".
Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.
> Rust has stellar tooling
I came for the job opportunities.
I stayed for the tooling.
> Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program
I had a similar experience trying to make Haskell's LSP work in test files. After ten years of using Haskell for academic and hobby projects, I still couldn't make the red squigglies go away in test files. With Rust I struggle similarly when dealing with cross-compilation and a complex set of feature flags on Nix. But at least this is not "Hello World!" failing.
Well to be fair to Rust, Nix can drive anyone crazy. I tried that one too and figured they sniffed way too much of their own drugs, if you pardon the expression. In the meantime I learned `just` in 10 minutes.
Sure, not the same usage patterns, I get that of course, and I love the idea of Nix but they could have went about it very differently with a much better UX / DX... and they refused.
Side topic though, sorry for the digression. Main point was that if you use Rust normally without any weird and not fully accounted for wrappers then everything works fine. I just fired Neovim in a personal project I haven't touched in a year -- 20-30 seconds of LSP compiling stuff and I saw my project-wide compiler warnings immediately after.
I do have one ear for that argument that "everything ought to be simpler". But what I've observed over and over is that many systems tends to become more complex as the result of people wanting to make them more newbie friendly.
That's certainly true of the last 10 years of Ocaml tooling evolution.
I guess you could argue both ways and it depends on your starting point. I did not mean to say "make it newbie friendly", I meant "I want adding a dependency to my project to be a 10 seconds job, not a week-long endeavor".
If we both start from that point then I think we might find a common ground.
Yes it does very much depend on your starting point.
For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install"
This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.
Yep, it's about your background.
I moved away from makefiles long ago and I don't regret it, for a multitude of reasons that are well explained in many places.
`cargo add ...` is great and I wish every language offered a tool like that.
Even when i use cargo or go or node, make is still needed to build everything that's not just code.
> make is still needed
You mean: I still need make
For example, build.rs replaces some uses of a makefile.
> build everything that's not just code
Have you heard of: Just, Nix, Bazel, Helm, Terraform?
Depending on the situation, there are many things you can build that aren't strictly code where you can use a bunch of other tools than make.
If you say so. There are plenty of tools that can do more or less the same without having to remember weird bash-isms and pattern expansion rules.
I use `just` for project tasks, but there are many others.
If a company chooses non standard tools then they are doing it with the knowledge that they will have to train new hires in it. Random employee using non standard tools without the company making the decision to pivot to embracing it, aka training existing\new employees in that tool, is just making stuff that your company will have to throw away and redo.
So XenServer embracing OCaml is nothing like Random Gamdev writing some scripts in Rust without the team deciding to embrace the change.
The kind of people that recklessly move from shiny language to the newest shiny language in town are the same kind of people that believe that you could kick out a dev writing systems in Java and stick a dev whose experience has only been Haskell and O'Caml and have the new dev hit the ground running
> I think Rust is much more likely to follow Java's trajectory than OCaml's:
This looks like pipe dream of those Rust devs who usually claim that Rust borrow checker is easiest thing since heating HotPocket in microwave.
But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers.
Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java.
Rust may get there. But don't use Java's success to predict Rust's trajectory.
Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.
Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.
Apparently there was something to it, otherwise we wouldn't have every other day a WebAssembly startup being upvoted.
I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java.
For the latter it’s still kinda of "everybody can write some code that will run everywhere". The former is more like "you can have performance, consistency and correctness in a shallowly-C-like syntax", which is more likely to tease the average HN reader, but probably not the average programmer who is in to earn some descent money or as a way to start before moving up in the businesses hierarchy.
And you see there are some people which enthusiast to push Rust into the Linux kernel, while I doubt that in Java projects of similar size there is that much ardor for even introducing it in some part of it, let alone propose a full rewrite.
> I don’t know about your later claim. To my shallow knowledge of Rust, it doesn’t try to compete on the same segment as Java.
I don't think the origin lame was that it would compete for the same segment, but that it would reach the same level of ubiquity. It could do that by opening up a new non-existent segment, eg smart contracts on the block chain. Or it could take a little from multiple domains.
> descent money
When you want a decent paycheck, but instead get a descent into computing madness.
haha, nice catch, thanks for the smile. :)
> I recently finished a contract at a (very large game dev) company where some tools were written in Rust. The tools were a re-write of python scripts and added no new functionality but were slightly faster in Rust. > The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
I can believe this, but it's funny because I work on a project where the main product is written in Rust, and it's the build tools written in Python that are the technical debt that nobody really wants to touch! In our case I suspect rewriting them in Rust will end up being the right thing to do (if/when we can justify the switching costs).
That makes sense, as the bulk of your developers are probably Rust devs. Homogeneity favors Rust in this case. Also Rusts existing build system is (unsurprisingly) built around Rust, so it makes sense to keep with it.
I really enjoy projects where the project and the scripts around it use the same language.
I find that sticking to a single stack is severely underrated.
> I can believe this, but it's funny because I work on a project where the main product is written in Rust, and it's the build tools written in Python that are the technical debt that nobody really wants to touch!
Oh hi! You must be my teammate!
I joined a team like this and just started a personal build/dev/ops tool repo in Rust for things that I needed but were not automated. Over time it has become an "official" repo and renamed to be blessed with an official "org" package prefix.
When I started this project and people were interested, I was asked why I didn't just add to the Python repo; I said that others are free to rewrite them if they want to, but I can't justify spending days messing around with Python to achieve what I can in less than 30 minutes with Rust when I need to quickly automate a tedious task.
Edit: A lot of downvotes on this, but in case it wasn't clear - the team is happy that someone took the time to scaffold a repo in Rust that everyone feels more confident in contributing to, since the overwhelming majority of the codebase is written in Rust and the Python tools repo is full of annoying runtime errors that could be trivially caught at compile time.
The end result is more people feeling more empowered to automate repetitive and tedious tasks which can easily be fudged when executed manually instead of suffering with them because someone who isn't even here anymore decided to start a tools repo in Python for a team that almost exclusively writes code in Rust.
The only reason these tools were written in Rust was because the dev wanted to learn Rust (a big but common mistake).
While they should get wider buy-in first then if the choice is technically justified within reason, its perfectly appropriate (and normal) for devs to pick up new languages in this way when existing expertise is not available on staff. No competent dev will accept their skills atrophying due to overly rigid political/tech choices.
That's how skills are built, its always been thus in such environments, and thats ok.
Sorry but employees are not entitled to get paid to learn whatever technology they want during work.
And I say that as an employee.
There's some flexibility to choose tooling but with autonomy comes responsibility.
Replacing a bunch of working Python scripts with Rust is not just irresponsible, it's disrespectful and isolating towards coworkers.
No one has the "right", as you put it. The learning of and using Rust was approved by the employee's superiors.
If anything, companies expecting employees to know their specific tech stack on day 1 of the job is much less common an expectation outside of Software engineering.
Sorry but employees are not entitled to get paid to learn whatever technology they want during work, in their own special ivory towers.
rather different to my
While they should get wider buy-in first then if the choice is technically justified within reason, its perfectly appropriate
My point is about this:
> No competent dev will accept their skills atrophying due to overly rigid political/tech choices.
Competent dev to me is one that delivers value. I say that as a dev but I'm pretty sure stakeholders would agree.
It's perfectly reasonable to hone your skills outside of paying hours if you chose to expand to new technology outside of your employer's stack.
Fairer, but that's probably the point and tone you should have quoted with then. ;)
I would probably concede that it depends on context - for devs paid at the top of the market to simply churn stuff out factory-style there is less justification for self-improvement on work time.
For the majority though there is always give and take between responsible employees and employers, and building skills as discussed is normal.
You're not likely to be paid top of the market at a firm whose biggest concern is that you might be more flexible and a faster learner than anyone else they were able to hire.
> Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
There are two dialects of Rust. One can be written immediately by beginners, the other is for experts.
I make sure to write scripts in the first dialect. It uses `clone` all over the place, does not make use of any async runtime, and makes extensive use of "anyhow" for error creation and logging.
I advise all my peers to do the same, if they find a need for Rust in tiny scripts or applications.
> There are two dialects of Rust. One can be written immediately by beginners, the other is for experts.
I believe it's more like a spectrum.
I'm 3 years into my Rust career.
I started with .clone() everywhere.
Then I moved on to write highly async code with tokio and std.
Now I'm somewhere entirely unfamiliar, writing highly portable no-std Rust for bare-metal and wasm.
It takes some time to know the difference between std and core.
It takes some effort to write modular, allocation-free code (static allocations only).
It takes some rediscovery of what crates will work for you.
It's a steep curve, and I don't imagine everyone likes it.
Strong "only use this subset of c++" energy
except using a different set of rust is not gonna allow RCEs or leak your data to the internet
Eh. An enterprising young developer could build an ECS style system with references as u32 indices and all bets are off.
If it's just a few tools that are essentially scripts and they don't even warrant a full-time dev then wouldn't a random senior dev do?
I have had to touch things in languages I'm not familiar with and initially it's slow due to having to look things up, but plenty knowledge still does transfer. Opening a file is still opening a file, updating dependencies is still updating dependencies. Plus python devs should be used to changing tooling all the time ;P
Embedded developers that know Rust is an even smaller pool than Rust developers in general. It’s almost two non-intersecting groups of people since embedded in general is less well paid in many countries and so doesn’t attract people interested in the latest and greatest hyped up language.
As a Rust dev looking for a new job, this is my experience. I filter out the embedded jobs because knowing Rust only half the equation for those roles.
"competent" is a bit of a word there, there are very few shops right now that are willing to hire actually junior rust devs. The jobs are out there but they're all for mid level at a minimum roles in the Rust ecosystem specifically.
Tons of people would jump ship to be able to use Rust, it has a lot of love in the community.
"Being totally unwilling to accept anyone junior, or who is new to the stack" is a disease in this industry, and it's really apparent when some 200 person+ company is only hiring principal level rust devs.
> Access to competent developers can be a challenge for companies.
Fixed it for you. You wouldn't believe the quality of the average applicant for a basic standard Python position if I told you.
At least you can pretend you've hired someone that's going to solve your python problens. And to mgmt, that's sometimes the only thing that matters.
Greasing the wheels of the corporate meatgrinder with Rust is almost impossible, actual work quality notwithstanding.
As a Rust/Python dev I previously decided against Rust in a work context as I deemed it would make me the sole person who knows what is going on, while python feels much more like a lingua franca of programming nowadays.
I would decide this on a case by case basis tho, Rust is different, but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not. Rust is different, but unless you want a complete rewrite or new complex features any developer should be able to get into it if you give them a little time.
And the strictness of Rust makes it unlikely that they break things in a bad way, which is good.
> but if e.g. what you wrote derives most of its business logic from its configuration, or the usecase is so generic changes aren't gonna be a thing for a while, why not
there’s also the fairly easy cross compilation to bear in mind.
i built a container entrypoint binary via python to stick in all our containers at last job.
getting that to cross compile was going to be a bunch of pain i wasn’t willing to go down for a simple “download files from S3, run a sub process, upload files to S3” pre-execution wrapper.
digital ocean infra + self hosted gitlab —> no readily available windows instances.
so everyone had to use linux to dev these containers with wine+mono.
being able to cross compile would have been brilliant here. i made the decision to not do this in rust for future maintenance reasons. but then people avoided using this thing because they couldn’t run on windows :/
(i know there’s that paid for package but the license fee is mind boggling from what i remember).
perhaps Go could have been a good solution for simple, cross-compiled code.
from what i looked at, go was a bit more complicated than rust for cross compilation. but it was still a lot less complicated than sorting it out for python. dunno. was at least two years since i looked at it, but i remember rust coming out on top in my mind.
unfortunately the same maintenance issue applied -- it was a python / R shop so no-one else would have been able to change the code once i left.
AFAIK Go has one of, if not the easiest cross compilation stories.
This is all it takes to build a linux arm64 binary:
You can even run that from Windows and it will just work.This is how you list all possible targets:
If you want to generate binaries for many linux distros, you can even use a simple bash script:thats definitely not the commands the guide i looked at had lol
looks on par with rust then. go is the next one for me to dive into when im doing fiddling with rust audio stuff.
regardless, wouldn’t have worked at last job as no-one knew go either. would have been easier probably to get someone in, but i spent a year trying to get one new hire to no avail, so doubtful.
fair enough
> The reality was that these tools were unmaintainable by the rest of the company. Only the author "knew" Rust and it was hard to justify a new hire Rust developer to maintain this small set of tools.
Only If I had a dollar for everytime this happens. Choosing a language for the company is a business decision. we have a similar issue with Elixir and now the entire team is spending a quarter just to get rid of it. For anyone building startup on LLMs , this is one killer application I would pay for. The generated code doesn't event have to 100% correct, just right enough for devs to tweek would go a long way.
While I get most of your points, I believe some companies sometimes can or maybe even should experiment with new languages, and see what benefits it brings them.
The important part is evaluating the experiment and having the courage to say “well that didn’t work out, let’s go back to the original version”.
They should have evaluated what is “slightly faster”, how much money it saves and how much it will cost extra to maintain it.
Indeed. The few times I've encountered Rust in the wild it's been for a project that didn't need it (web or IO bound applications) and someone's "My First Rust Project". It's difficult or even at times beyond the budget of smaller organisations to then hire a seasoned Rust dev to unpick whatever mess you got in to.
Don't get me wrong, Rust has a niche where it's the right choice. But being a popular language of the day, it's getting used a lot in the wrong places.
Project that does not need rust "Web, or IO" -> What would you actually choose to make an API then ? Python ? Ruby ? Did you compare benchmarks from rust server to python servers ? Did you actually feel the difference ?
Most web servers aren't doing anything computationally complex and there's a lot of tech to help you scale to multiple servers, so single server performance usually isn't really critical.
Web stuff is about developer speed. So familiarity, libraries, and tooling. There are plenty of good options.
Anything that needs to be performant can go in it's own service.
I will say that a rust service, even when doing relatively simple stuff, can scale well in the cloud due to small memory footprint, fast startup time when auto-scaling in containers, and no need for a JIT to "warm up" before it has high throughout and consistent low latency. Building something with these qualities on a framework like Rocket is pretty straightforward, IME.
Building a web app with rocket is like using a fine BMW to go on highway. It just feels right- I love Guards and what not he added in his framework ; absolutely refreshing work !
Have you heard of something called climate change ?
> What would you actually choose to make an API then ? Python ? Ruby ?
Python, Ruby, Go, PHP, C#, Java, TypeScript, Elixir.
Performance benchmarks when writing APIs as 1st concern? Really? 99% of the cases this should be the last criteria.
Monthly reminder that a good part of instagram still runs on Django/Python.
Did you not offer to rewrite it in Python? I was a techical director at a company where we worked a lot with frontend contractors. Some loved typescript others were fans of vanilla js. When the balanced tipped there were rewrites from one to the other (ts to js to ts again), the first one two months full time, the second was interspersed with feature development. Of course the developers were very happy they could do it; it improved the solutions and afterward they both had 1) extreme product ownership 2) excellent company problem domain knowledge. So, a win-win for everyone. So I think, especially as it is a smaller part, than translating back in to Python would be warranted (provided you like it and would stay a while), not a big deal and a quite natural option.
I don't think it needs rewriting if the original version was in Python. What you need to do is return the original Python version
>Only the author "knew" Rust [...] because the dev wanted to learn Rust
Many such cases. Recipe for disaster.
I think the rule of thumb should be that if you wouldn’t write aomething in C++, then you shouldn’t use Rust.
That's a horrible rule of thumb, because C++ adds a ton of complexity with little reward except for speed. Rust adds less complexity (still a lot ofc), but it also gives you awesome tooling and dependency management (much better than python for example), and and extemely powerful typesystem and functional programming features, that make writing correct code extremely easy.
Rust is a complex but overall good language for writing solid software, C++ is making a deal with the devil in exchange for speed.
If a garbage collected language can easily do the job, choose the garbage collected language. I like Rust, but it is NOT the fastest language to develop in.
Typescript, Python, Go, Swift, and even Bash depending on the situation are all quicker to code in than Rust.
If any of those languages are inadequate for the requirements whether they be memory-bound, CPU-bound, or sensitive to gc pauses, Rust is an excellent option that is far superior to C++ in 2024 and beyond.
The notion of "one true language" has always been and will always remain a fool's errand.
I write most of my stuff in a combination of Python, JS/TS and Rust these days with some form of Interop between them. I.e. mostly Python Marimo notebook with JS visualisations, and PyO3 Rust bindings.
Tbh I don't find myself to be "slow" in rust. Sure for quick exploratory stuff the notebook-environment and introspection capabilities of a dynamic language are definitely nice (e.g. when taking apart some unknown JSON data format), but especially when it comes to complex logic and refactorings Rusts type system is really making a big positive impact on productivity.
Sure TypeScripts type system is also powerful, but Rust is consistently better at infering types from closures and function calls, and the existing types and tooling story is miles ahead of TS. (and I've never encountered an easier to setup/use model checking language integration than Kani)
For one-offs where correctness doesn't matter, sure throw $SCRIPTING_LANG at it. But once you want correct software, I'd still choose Rust in a heartbeat.
You missed the point of the rule of thumb. Maybe rephrasing it as if 15 years ago you would have written it in C++ would help.
Nope. C++ has mostly downsides, Rust has significant upsides.
A good rule of thumb would be: is correctness and code confidence more important than learning curve and compile times? If so Rust, otherwise JS or Python (with possibly parts in Rust).
a.k.a. "resume-driven development"
Typically, devs polishing their resume instead of prioritising business metrics probably means the overall org is on the down slope.
Perfectly normal for people to want to develop their skills and to enhance their value.
The thing is that this is not a developer's decision, this is a management decision. The developer might pitch for Rust or even start developing in Rust but if that is not right for the org then their manager should say 'no'.
So ultimately this is a red flag about management.
Slightly disagree.
Needing the managers permission is more of a "wartime" mode.
For peacetime the management should set a culture of peer review and data and logic driven discussion. The culture would ideally have a Rust lover sit there and think "would love to do this in Rust but...." because they know their peers will be affected by this decision.
The problem with management approval required is it usually meams no or bias towards management pressures. A management veto that is occasionally used may be better.
Disclosure: not a Rust programmer but pretty neutral on it. It is on my radar if I get a problem Node or Go can't solve.
Or the dev wants more money
> some tools were written in Rust. The tools were a re-write
Some memes just write themselves.
God I feel like I’m taking crazy pills when I read these threads.
Can I hire 1000 Rust devs at the drop of a hat off the street? Well, no. Have I ever struggled to find competent Rust devs, or high level people who were happy to learn? Nope.
I would absolutely not be afraid to use it because of “hiring concerns”. If your current devs can’t or won’t learn anything new, they’re not very good at their job. If you can’t or won’t hire because you can’t find a super-senior at the drop of a hat, well, your hiring process is broken and no language will really help there.
The underlying (absurd) assumption is that the sum total potential of a developer you hire to do a job is statically determined by their past experience at interview time. This is the problem with "Human Resources" thinking, it fails to account for all the, well, human stuff.
Case in point from the article:
> it is not viable (for us) to retrain a C developer to Rust
What? Why the hell not?
What concerns me even more than the talent pool is that Rust is a language that isn't straightforward to learn.
I can be confident to teach any average developer about Go without any prior experience relatively quickly, I'm not so confident I could do the same with Rust.
These comments make it seem like it's impossible for people to learn Rust. I have to admit that it takes a fair bit longer than other languages, but so is c/c++. Is there a bias towards not using Rust by other devs? Is it a scary language?
A garbage collector really takes away a huge amount of cognitive overhead. In doing away with it, Rust requires that you understand the borrow checker and lifetimes, even if minimally due to extensive use of .clone() in your early code. This ties into all of the different kinds of strings in Rust from str to string to vec[u8], etc.
Unlike Go that only really requires experience in general programming to become rapidly productive, Rust basically requires that you read The Book in its entirety before you even think about applying that knowledge in production. There are just to many interdependent concepts to hand wave away the prep time. It all (mostly) makes sense once you've familiarized yourself with the basic concepts, but it's a training step you simply cannot skip without inflicting a fair amount of pain on yourself and others.
It doesn't match my experience with Rust. How much code you wrote in Rust?
I'd put the same concerns for C and C++ to be fair. The learning curve just isn't the same as most other mainstream languages.
I'd put even more concerns on C++. All the same concerns plus all the concerns that arise from the compiler not helping you nearly as much. It's easy with C++ to be lulled into a false sense of security because it compiles, and your trivial happy path works. Under load or with unforeseen input, the chance for memory corruption is massive even for experts let alone beginners because it only takes one to bring down a whole process.
C++ is better than it used to be, but it was truly atrocious in that regard for decades. It was simply the least worst option for those decades.
I do not consider it the least worst option anymore.
Go is also a more productive language for many use cases.
My experience is the opposite. I spend a lot more time in a debugger when I work with golang than when I'm working with rust. Sure, there's a learning curve with rust's borrow checker, but once you figure out how to use it I find rust to be a much more "flow state" development experience, with less interruptions of the form "what is this program actually doing and why?"
You forget that a lot of projects benefit greatly from generalized GC.
No. I didn't forget. It has not been my experience that not having a garbage collector in rust was a problem in practice.
On day 1, yes, a newbie to Go would be able to be more productive.
I switched up from python to rust for some processing pipeline at work - rust has a lot of advantages over it specifically for typing and speed, the work itself it a little bit longer to develop. But the quality output is not even comparable, the code itself is way more readable and explicit than in python code.
There is not a lot you can do to make your python code as good in terms of reliability or clarity of intent. I'm sorry to hear that you did not have a good experience with it, but frankly speaking, I cannot look at python code anymore because of the inherent "hidden" work that it creates, variables being passed trough without much care for their exact meaning, hidden "bugs" that make the overall job way more annoying to debug.
Python is like that person that tells you everything is fine but is mostly wrong and won't even tell about that. Whereas Rust will just straight up tell you what's wrong in the draft.
I prefer the honesty and the little additional overhead work to getting lost in debugs for weeks bc some person has inputed the wrong shape for some vals or whatnot.
The peace of mind is saving me a ton on maintenance as well. (project is a 2years on with distributed python pipeline with a bunch of IA processing - switching up to rust was not the easiest thing to do considering some parts had to stay in python because of code ownership being someone's else - the stack is a rust/python stack now with some parts being left out in python depending on the actual needs of update)
I understand very well that some people do not want to code in rust, specifically because they might not have the time or the will to do so. But objectively these people do not have to define the pipeline execution except for the actual order of execution, nor do they need to maintain every part of the code because it's just not their job.
Now if you are to compare the exact benefits of rust vs python for a company, the server pricing will just speak itself and the choice will be made depending on the cost of production, the lifetime of the code, and the actual benefits.
If I was to do some API today, I'd 50000% go for rust and I DO think of python as the `no-coder coder` thing. I initially learned C, switched up to Python for jobs, and the code quality of python is just downright bad. It does not push me in the right direction AT ALL.
The fact that we used a scripting language with no typing for tools that need any kind of guarantee for years does not mean it's the best way to do it.
Also to answer the problem concerning `rust` dev's being non-existant on the market, and no job being open is really simple : even tough rust has 10 years on the developer market on this is really young and need to learn.
You need 3 years of practice to get 3 years of experience with rust. There is no way around that. And there is just not enough experienced people with this language yet to make it a shift. I'm not saying there is none, i'm saying it's not yet democratized.
> You need 3 years of practice to get 3 years of experience with rust.
This is the major barrier. It's a difficult language to learn for people who've worked with a compiled, strictly typed language with manual memory management. That barrier is much higher for people who've only ever used a dynamic, interpreted language.
I'm on-the-fence about orchestration of pipelines with Python since I've experienced a lot of the issues you're talking about, but you can just abstract the Python algorithm parts in to APIs that your pipelines call and separate out those two concerns. Then it's clear who has maintenance responsibility, it separates out the algorithms from data collection + calling, and it doesn't introduce a big barrier next time someone wants to implement something that depends on the latest and greatest algorithm written in Python, which writing in Rust inevitably does.
To me though, I don't really understand the use of Rust in non-systems programming. For a lot of the use cases people talk about, Go seems like a better fit with a lot less of the pain since it's a much simpler language. When teaching people a language I'd much rather do that with Go than Rust, and that matters in an environment where developers who know either are not really that commonly available (at least here in the UK).
> This is the major barrier. It's a difficult language to learn for people who've worked with a compiled, strictly typed language with manual memory management.
This was not what Google and others found when they studied it.
https://www.theregister.com/AMP/2024/03/31/rust_google_c/
> More significant, Bergstrom said, is the comparison of rewrites of C++ code into Rust.
> "In every case we've seen a decrease by more than 2x in the amount of effort required to both build the services in Rust as well as maintain and update those services written in Rust," he said.
I can 100% understand your take on `go` and will probably think of it more often !
100% this. Well put.
The Rust codebase I’ve built on run faster, don’t crash, are more correct, and take only marginally longer than the first python version. They’re easier to maintain, they’re easier to upgrade their dependencies, I’m more confident about asserting guarantees from the codebase, and it’s an easier time onboarding people and having them meaningfully contribute. There’s no more death-by-a-thousand-cuts that I experienced with Python codebases. I don’t have to worry about my Rust codebases blowing up at 2am because of some random exception.
I am defs not going back.
> The fact that we used a scripting language with no typing for tools that need any kind of guarantee for years does not mean it's the best way to do it.
You can add typing tools now, though? CI pipeline runs mypy and that gets you a long way.
> Access to competant Rust developers can be a challenge even for large companies.
Huh? There's tons of good developers looking for jobs right now, more so in Rust.
The author complains there are few developers available to maintain Rust code.
I see very few job postings, and almost all of them are either cryptocurrencies (I don't want to waste my life on this), or "3 years professional Rust development in production" (disqualifies self-learners).
Given that nowadays most applications are not replied, it makes little sense to spend time even browsing the postings.
There really is a strange dichotomy. Plenty of Rust developers have trouble finding jobs and apparently companies have trouble finding Rust developers.
For being a relatively new language, there are almost no "entry level" positions.
Just take a look at https://rustjobs.dev/. Most of them are well paid remote jobs, but they are asking for +3 years of "professional experience" with rust, "with a proven track record of building and deploying production-quality code", and more. Hell, iirc, i saw one asking for proof of contributions to the rust repo (eg, being a core maintainer).
edit: to be fair, i saw one position a while ago asking to be willing to learn rust
> For being a relatively new language, there are almost no "entry level" positions.
Isn’t this a fairly well-known phenomenon though?
- new language makes waves. The people who picked it up early do some impressive stuff.
- early early adopter companies either snap them, or internally make the choice to learn it too. In turn, they do some stuff with it.
- gets a reputation for being the hot new thing. Other companies “want in on it”- they want to be able to do the fancy cool things the other places did, but they don’t have the patience, time or culture to grow it themselves so they aim to hire out seniors and everyone with lots of prior experience. <——- many orgs are here.
- proliferates enough that it’s well and truly mainstream. Also known as the “hire 1000 Java devs and throw bodies at stuff” stage of hiring and availability. Python, Node, Java, PHP, etc are here.
Yeah though bear in mind most job requirements are really job desirables. No skilled jobs say "0 years experience, no track record required".
Asking for proof of contribution to the Rust repo is insane though.
As someone who has been searching for a Rust job lately, few rust roles are only Rust. Many are Rust + another niche domain.
- Must have 5 years of Rust and 8 years of embedded experince
or
- Must have 5 years of Rust snd 10 years of writing SQL engines.
or
- Must have 2 years Rust experience and 5 years with Linux kernel development.
etc...
If you are looking to hire someone with specific domain experience, it makes more sense to compromise on the Rust language side of things. A developer can learn Rust on the job, but it is harder to learn to write a production SQL engine on the job. But that means you aren't hiring Rust devs.
Developers who just specialize in Rust are behind their peers who are domain experts when it comes to looking for a job.
IMO that means Rust will "win" not when a bunch of undifferentiated developers learn Rust, but when the domain experts learn Rust. e.g. Kernel maintainers.
Salary and job conditions. Companies want low salary and worse conditions. Candidates want the opposite. An equilibrium is not necessarily reached
This sounds like a matchmaking problem that could probably be solved by a competent Python developer, if we can find one.
> 3 years professional Rust development in production" (disqualifies self-learners).
It doesn't necessarily. Very few jobs postings that require "N years of experience in language A" actually require that. Most will accept N years of total experience and some smaller amount of experience (not necessarily professional) in language A.
Chances are that recruiters just ignore your resume without even thinking about it.
Especially if there are other candidates who do have that much experience in a specific language. Even if you are a better candidate overall (whatever that means), you need to pass the resume screening first.
> Chances are that recruiters just ignore your resume without even thinking about it.
That's why should always try to avoid recruiters and apply direct if possible!
> Especially if there are other candidates who do have that much experience in a specific language.
True. But the context of this discussion is that there are not very many candidates with the (nominally) required experience (i.e. several years of professional Rust experience). And that's often the case as job specs often have unreasonable requirements.
this is the ideal but does not appear to really be the practice -- regardless of whether you're applying direct or not.
Solvable by launching your own startup, using rust and running it for 3 years.
I see postings occasionally for FAANG and Microsoft jobs, and very randomly and rarely from small shops.
A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.
Without this, using even very simple hardware interfaces (like an SPI/I2C bus) is gonna be a huge pain, because you'll have to comb through reference manuals and register descriptions for your processor and piece everything together yourself instead of just calling a few API functions (this is also very error-prone and using Rust is not really gonna help one bit).
The only chance to get even halfway decent rust integration is to pick one of the like 3 most popular hardware platforms among hobby enthusiasts (think ESP32, raspberry pico), which is simply not viable for a LOT of embedded applications.
So I still think its probably a really bad idea for a typical embedded-shop to fully go for rust right now-- the downsides from lacking tooling/libraries, reduced developer pool and the need to train extant devs appear very hard to overcome to me.
For some complex peripherals (especially wireless) this may be the case, but in my experience it's often much easier to write small abstractions for what you need in the mode you need it in (for serial, timers, IO, DMA, ...) than relying on manufacturer SDKs, which are often so poorly documented that you need the reference manual anyways to understand the peripheral to then understand the abstraction, which is often much more complex to use than it needs to be for my use cases. With abstractions in Rust or, for something quickly thrown together, in uPython you're at least getting "you're holding it wrong errors".
Interfacing with the peripheral registers themselves is also a bit simpler with Rust in my experience, as a proper .svd already contains bitfield setups with enums and R/RW/W1 information to at least set the bits you want instead of the Macro-Hell in C some manufacturers throw at you.
> A very important point that the article neglects is that for a lot of embedded platforms, you have to heavily rely on the hardware manufacturers libraries and tooling. All of that stuff is typically gonna be targeted at C.
If you have a reference implementation in C it's not such a big job to set up something like an I2C or SPI peripheral. At it's core, you're making a sequence of writes to some memory locations. Most of the manufacturer libraries are quite low quality, and very easy to misuse. In my experience trying to do anything that pushes the hardware, you will end up combing through the reference manuals anyway.
I've done a bit of embedded rust, and the huge benefit - just like on desktop - is that code which compiles tends to do what you intended. Obviously there's still scope for logic errors, but that takes away a huge amount of debugging time.
Even with the vendor libraries last time I had to poke at a CAN bus I ended up having to go to that same level because the C helper libraries omitted key features of the interface.
There's a number of micros these days where the same libraries are provided using SVD[1] that will generate interfaces which is handy.
[1] https://docs.rs/svd2rust/latest/svd2rust/
Not a Rust dev, but couldn’t you use FFI to call the C routines from Rust? Of course you‘ll have glue code which is seldom pretty, and depending on the amount of Rust actually involved at runtime it might be questionable to do in the first place.
Absolutely! But this is a huge amount of complexity in build system/linker setup/debugger that you are gonna have to stay on top of. The gains from using Rust need to be overwhelming to justify a setup like that.
Also consider that calling those FFI APIs from Rust is not gonna do anything for you by itself-- you are basically just calling C functions with extra steps... To actually get anything out of it, you'll then likely have to wrap the whole hardware interface in a "rustified" API (which, again, you'll probably have to write and maintain yourself...)
Many years ago, our project had a library that would link our Ada code to the low level operating system calls that are in C (network, shared libraries etc).
Once it was written the code was stable, but you bring back not so pleasant memories of building / testing. It might just be our make files were unnecessarily complex or we were building libraries not executables…
Rust solved this by autogenning code from mfgr published device xml descriptors. Eg https://embassy.dev/
Better than any C(++) embedded hal I've used
I think it’s a pretty mixed bag, but yeah no one really has a lot of support for rust, but c++ support is quite common and “good enough” for lots of things where you’d like more complicated but zero-cost abstractions. RAII, getting rid of pointers, maps, vectors, etc
The irony in this article is that even the much lauded ESP32 integration is essentially all of the important stuff like WiFi continuing to run and live in the C world, while they have a little Rust frontend for all the hipsters to believe their great bugfree Rust code is making the world spin.
The article is really light on actual details.
Basically, this is a company who uses ESP32 to read serial data from batteries using UART and retransmits it in json over MQTT. They apparently had buggy C code to do that (for unspecified reasons) and successfully rewrote that in Rust.
Conclusion, you can write ESP32 code in Rust. No information on what that actually entails sadly.
Some more information on ESP32 on Rust. Espressif (the organisation behind ESP32) spent effort to properly support Rust on their chips, see their documentation: https://docs.esp-rs.org/book/
Another nice resource for Rust embedded is https://embassy.dev/ which also supports STM32, Nordic chips, and RP2040.
IMO, the coolest feature about Rust embedded is that Async Rust works! This makes building a HTTP server for your embedded chip easy.
Most embedded code is pretty bad at async - that could be a game changer.
I was just about to point this out in my own comment but yours sums it up quite nicely. As an embedded software guy this article gives next to no specifics or details on what the bugs were and how they got solved with Rust.
Yes I wonder what was wrong with the C code. Was it fixable, was it just a single loop code that ran or could they have used something like FreeRTOS to handle multiple tasks with less chance of bugs?
I would have liked to have more details because it's easy to have memory related issues when using a serial protocol in a memory constrained environment and I was wondering if somehow some feature of Rust helped them.
I would guess that the more expressive type system is very nice but I don't expect memory safery features to be that useful in this context. Would like to hear from someone with real world experience on that.
If you're parsing a serial protocol on an embedded system where you're only getting a byte-at-a-time (from a register), or possibly up to 8 at a time, then a parser combinator library such as nom should make it very easy to create a bulletproof parser.
Definitely much easier than in C, where I've resorted to using Ragel for safely parsing serial protocols (and also in Go!) since it generates a single small dependency free source file containing the state machine and your "actions", but nom is much more expressive.
Deeply doubt so.
Parser combinators are notoriously poor performance and memory-wise. They are somewhat nice to write if you like the style and don’t mind the tax but we are talking about ESP32 here.
Unless they are inexperienced, the issue is unlikely to be the state machine anyway and more likely to be in how they manage buffering of long message to avoid running out of RAM.
[dead]
As someone who is using Rust in production for a year now [0], albeit in a different industry -- webdev, I really like the language. Sure, the first steps were rough, but eventually DX became decent, and the safety guarantees of Rust allow me to have a safe mind when developing and deploying (something I can't say about other popular dynamic languages).
Having said that, I agree with one of the commenters in this thread: Rust is essentially a solution looking for a problem. It is a great language, but it fails to find its niche. Rust developers are nowhere to be found, companies are not hiring Rust developers (except if you want to work in crypto).
[0]https://yieldcode.blog/post/one-year-of-rust-in-production/
I think it solves many problems regarding safety in lower level languages and with some great language features, so I can't really understand your take. Sure, C++ is more established with the benefits that entails, but that's not because of the language.
I don't disagree with you. My comment was merely to agree with another commenter who said that there is a catch-22: Rust developers can't find jobs, while companies who are looking for Rust developers can't find candidates, because Rust can't really find its place in the industry outside the crypto world.
Ah, right! I think rust will find more use but it takes time. Many existing technologies and languages are probably good enough for most suitable projects with historical baggage. Maybe crypto industry is just in a good position to try new, safer languages for new projects, who knows.
Nowadays, Linux kernel also has some drivers written in rust so I'm hopeful.
It has definitely found a niche in the crypto space, specifically with the node clients and the underlying new cryptography libraries they use. For instance, the more efficient Ethereum devs can make their node clients, the cheaper it is to run and the more people around the world can run it, which increases decentralization. Rust makes this possible without compromising on stability and maintainability.
The problem is that I still see all crypto as "scam", thus choosing Rust makes a non-viable choice for career progression. But I don't care about career progression anymore, so :shrug.png:
There’s a guy who I work with who went to work for a crypto place that then exploded (as they all tend to do). He had quite a difficult time finding a new position, and was asked multiple times about working for a scammy company. So perhaps don’t underestimate the negative effect it can have career wise…
If you wouldn't write your program in C or C++, then it's not the problem that Rust is trying to solve.
Rust has some nice high-level features and tools, so it gets used in other areas like web dev too, but in the end, it is a systems programming language. It is a low-level language, even though it may not feel like that a lot of the time.
I disagree.
Let's say I want to use a real type-safe language to write web applications. So rails/python/JavaScript/php is out of the window. I'm left with two big options: Java/Kotlin and C#. If I want to avoid Microsoft, I'm left with Java. And in fact, this is the industry standard for "real" web development: financial, enterprise, etc.
But Java is cumbersome. It's very `FizBazBarFooAbstractInterface` type of cumbersome. Kotlin makes it nicer, but Kotlin didn't get much adoption in the web industry. C/C++ is too low level for web development. Rust is the perfect language, in my opinion of course, to fill this niche.
Oh, there is also Go. Which is, by the way, also a system programming language. But nobody argues that Go shouldn't be used to write web services.
Besides popularity (not denying that popularity is important!) is there a reason you'd prefer Rust over OCaml?
Never considered. I grew up coding in C, so always wanted to come back to something similar. After being spoiled by PHP/JS, couldn't go back to C/C++. Rust offered me a modern, C-like language, so I just learned it and applied forcefully wherever I could.
Makes sense, thanks.
Please excuse me for pointing out you don't disagree with the post you're saying you're disagreeing with.
My disagreement was referring to the statement that Ruts should be used only in-places where you'd consider C/C++.
The niche is anywhere C or C++ is used, which it excels at
I remember looking into Rust for a personal project, on embedded, in 2016. After poking through all of it I decided against doing that because it was clear I'd be spending a lot of time getting Rust working at all instead of doing anything for the project itself. So C it was.
The thing I have to say in the context of the article is this: There is no way to know whether a complete rewrite in C would have yielded similar results to Rust. The phrase "C prototype" made me squirm, even more so when reading that in the context of critical infrastructure. It is known by now (or should be) that such prototypes live on like zombies, so unless it is really some throwaway (from the point of architecture!), these things tend to live on for longer than most feel comfortable with. And, being so critical in function, maintainability is one of the primary concerns.
Yes, Rust will, eventually, at some point, maybe? the go-to language we use in the embedded field, but we are talking not just about a language replacement, we are talking ecosystem replacement. That is not going to happen overnight.
That said, as some mentioned Java, Perl, and such things: I revived a personal Perl 5 project not too long ago that was more than 20 years old by that point. Needed a small change because the latest installment of Perl 5 is a bit more restrictive with some borderline syntax things (good), but other than that it just worked. In the larger context of the project there is also some C code for binary file processing, also >20 years old. Needed a renaming of a POSIX function (arguments and functionality all the same, though), and then it worked, even compiled as native 64 bit code. Granted, there are not that many dependencies beside POSIX, and the code was even back then written to a level of quality that allowed it to run on all sorts of (POSIX) platforms already.
Which is why "C prototype" sounds to me like "we cobbled something together", and all sorts of bugs are no surprise then. You can cut only so many corners before it becomes an issue, especially in software that is used all the time and in a critical place of a system. This needs to be done right, else you will waste a lot of time (and money!) afterwards.
Imho Rust will be not much further in embedded world in 2026 than it was in 2016. I managed to get in the role where I have hiring decisions to make. From this perspective I need somebody to be able to work with existing projects in C from the 2006 instead of knowing cool new language. There is no single advantage for a company selling products to change the language used. Transition will only cost money.
Regarding C prototype. I wrote it. 6000 lines of code, works nicely, 4200 lines of code were Xilinx driver calls to move data between the hardware blocks. So changing the language will not really bring any benefit. Maybe even opposite - one must study the register calls and read data sheets to create equivalent functions in other language. The code wasn’t beautiful, was created as “prototype” and was at the end the version shipped to a client.
I made this with rust in 2020 http://yager.io/vumeter/vu.html
The embedded rust ecosystem has invanced a pretty insane degree since then. I have an ongoing embedded project and I have had to use C FFI calls a total of zero times in a ~100kloc codebase. There are native rust HAL libraries autogenerated from manufacturer published device specs that are insanely good, and take advantage of rust type system features to offer vastly superior APIs compared to mfgr provided C libs
I am a C/C++ dev learning Rust on my own, and enjoying it. I am finally starting to enjoy the jiu jitsu match with the compiler/borrow-checker and the warm “my code is safe” afterglow … but I have a question for the more experienced Rust devs out there, particularly in light of the OP’s observation about “lots of unsafe” in the Rust embedded realm (which makes sense).
If your Rust project leans heavily on unsafe code and/or many libraries that use lots of unsafe, then aren’t you fooling yourself to some degree; i.e. trusting that the unsafe code you write or that written by the 10 other people who wrote the unsafe libs you’re using is ok? Seems like that tosses some cold water on the warm afterglow.
Yes, safe Rust is only as safe as the underlying unsafe code is.
The power of unsafe is that it‘s opt-in, making the surface area of „dangerous“ code smaller, more visible and easier to reason about.
As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.
> As long as the unsafe parts are safe, you can rest assured that the safe parts will be safe too.
That is not true. It is possible to have two pieces of validated unsafe code that are "safe" in isolation but when you use them in the same codebase, create something unsafe. This is especially true in embedded contexts, where you are often writing code that touches fixed memory offsets, and other shared globals like peripherals.
In some cases you might have the excuse that, well, you did say on the tin not to do this with the unsafe element. For example if I use Bob's "I need exclusive control of GPIOs 2, 3 and 6" and also Kate's "I need exclusive control of GPIOs 1, 2 and 4" unsafe code, then it's my fault, they did both tell me this requirement and they clash.
But in general this is specifically a bug in the unsafe code. The Rustonomican is very clear that it's not the safe code's fault that your unsafe code doesn't work. In the scenarios with conflicting libraries I guess it's the fault of somebody who linked conflicting libraries, but it's definitely never the safe code.
Another way to see the benefit of this approach is that if you have a memory violation, then you only have to look in the unsafe blocks.
So, yes the less numerous they are, the more you gain from it.
> If your Rust project leans heavily on unsafe code and/or many libraries that use lots of unsafe, then aren’t you fooling yourself to some degree
That's why every unsafe block needs a SAFETY block.
Is using vec.get_unchecked(6) safe? No. Is it safe for a vector that will under all circumstances (i.e. invariant) have exactly 64 element. Yes.
As long as for all possible inputs in safe function your SAFETY block holds, that code is considered safe.
I hate how prevalent AI "art" has become on articles like these.
It is soo cheesy. The crab is even pulling a YT thumbnail face.
https://www.reddit.com/r/Phobia/comments/webj9b/ai_generated...
As expected, the people problem is the biggest factor. Turns out getting C folks to learn Rust is a difficult proposition (hello, lkml) but the other way around it isn't too much of a problem.
I wonder how much of it is low-level experienced developers only ever using C fail to see that C is not the universally best tool (or, 'if all you have is a hammer, everything looks like a nail' question).
> I wonder how much of it is low-level experienced developers only ever using C fail to see that C is not the universally best tool
I'd say that's it. From my own experience with software developers, convincing some of them to learn something new is practically impossible.
I generally speaking agree, but I would be more specific:
If the person in question has a true passion for the craft, you can regardless of the age/seniority of the developer (at least in my experience). In fact, learning something like a new programing language is a big undertaking and if your work doesn't offer incentives/rewards the will has to come from the person him/herself and so that's why the passion bit I mentioned above.
In my experience I also notice that more senior/older devs are more reluctant to learn new things, but I am unsure if that's due having their passion destroyed by many years of bullshit companies politics, pointless meetings/trainings, and adherence to the latest flavor of agile development every quarter or simply an age thing (I'm not there yet and so I can't tell first hand).
The big problem with learning new programming languages is that you're going to suck at it for years until you reach the same level of familiarity with the new one.
Suck here is more of an emotional thing. They can output high quality code fairly quickly. The issue is not knowing all of the quirks of the language and all development being slower and more difficult.
Dropping down to simpler tasks while learning the language is a huge ego blow.
And this is where LLMs help tremendously: you know exactly what you want to do, you don't know how to do it specifically like it should be done in the language you're learning, you query the latent space of the internet using plain english and you get an answer.
It was a good argument literally a couple years ago less a few weeks before the chatgpt first release. Nowadays it's basically a moot point.
I'm surprised at how useful the latest openai model is for me when it comes to either learn a python library or a new language, such as cl, for example.
When you learn a language, you don't just learn how to use the syntax of that language idiomatically. You also need to learn to use the different tools in that ecosystem
Would this not also be partially connected to not wanting to throw away your 15 years experience with C for 1 year experience in Rust assuming the company actually ditches C? (or any other direct replacement language/tool scenario)
Sounds like a way to replace yourself by 2 low pay students who also have 1 year of Rust experience.
I'm genuinely surprised there are Rust developers out there that don't know C. Perhaps I'm showing my age, or my ignorance to how much CS education (even self-taught) has changed.
It's still thought but it's mostly a pointer course from my recent experience. It's a low credit subject where you play around with arrays and strings, maybe there will be an overflow calculation as well. Whereas something like Rust you'd do in a high credit course project where you have freedom over the tech stack and actually produce something with functionality.
Edit: My point with the replacement is not that juniors don't/won't have C on their CV but that a manager would be more willing to replace an experienced dev with 1 year exp in the current tool with 2 worse devs also with 1 year exp in the current tool compared to replacing an experienced dev with say 10 years of experience in the current tool with 2 worse devs with 1 year experience in the current tool.
I understood (and agree) with your original point. My comment about not having C experience/knowledge came from the article, where it really did sound like just that.
I studied physics, not CS, so I can't really speak to the CS curriculum part. But I am someone who has written rust professionally for a few years so I'll describe how I got there. I think the most experience I've ever had with C was writing a fourth order Runge-Kutta routine and calling it from python for a college project. Maybe 20 lines of C? In industry for the first 5yr I wrote lots of python and java code for web APIs and "big data" systems. Simultaneously around 2015 I started getting interested in rust because it seemed interesting, and like it would probably play a big role in the next 20yr--memory safety without a garbage collector is inherently compelling if you've spent time trying to make java GC act right. Eventually I got a job which was a full time rust gig. After about 3 years of that I ended up in a golang shop. So I've written some tens of thousands of lines of rust and only a few lines of C. I read C, but it would take a while for me to get comfortable writing it. But I wouldn't, probably, because I can use rust instead.
That's really just being a Luddite, I understand the mindset but that's a very poor strategy if one cares about job security. A (good!) senior developer has a ton of value outside of the pure mastery of a language specs, not to mention that learning a language for 1 year with 15 years of prior knowledge really doesn't lead to the same level as a student who does the same.
That kind of value only matters as long as you can find an ecosystem of companies that can be convinced to pay you what you think that value is worth. Many companies can't be convinced to do so and the companies that can are overflown by candidates smarter than you that have regular contributions in top rated github repos if they haven't made super popular frameworks and libraries
I honestly don't see as throwing it away.
The more you know the better software engineer you are with everything else being equal (IMHO).
Also, if you need to gradually add rust to an existing codebase the C knowledge is extremely valuable.
It's a RoI. Are you just telling them to learn something new or are you explaining the benefits and costs of learning Rust when they could be learning X?
It's surprising because I personally jump at an opportunity to try something new.
Well, with some exceptions...
The article says that the author wanted to hire someone who knows both Rust and C to maintain his company's embedded projects, but was unwilling to hire a C developer and wait for them to learn Rust. I'm not sure how this supports your point. I would argue that it's more that most companies aren't willing to let their employees spend a significant amount of time learning new skills.
Getting Rust developers to become Embedded Engineers is very interesting. Since it is easier to learn Rust than it is to learn C.
I think writing broken C is easier than writing correct Rust is easier than writing correct C.
A lot of C(++) devs just like that they can mostly get away with writing broken code
How much of the embedded jobs are Rust? Maybe 1 percent?
The complexity of Rust is on another level, it's a huge language.
It’s a tradeoff. The ownership rules are mostly the same as C. The difference is that Rust enforces them at compile time.
Hrm. These are the top level Rust ownership rules according to the book[1]:
C has none of these. Or borrowing, etc.[1] https://doc.rust-lang.org/book/ch04-01-what-is-ownership.htm...
It's widespread practice to notate who owns what in the comments in C code. "Ownership" as a concept comes from well established C best practices and a good C developer is going to understand exactly what you mean if you say something like "Caller owns the memory returned from this function" etc.
To get robust software out of C you don't have many options other than to adopt these rules. You can have useful software which breaks all of these, but you don't want to maintain it.
Robustness is relative. You can certainly write a cli that does everything in an arena; your GC is the OS and so going out of scope -- who cares. doing nothing and eliminating whole classes of errors from consideration (UAF e.g.) is incredibly maintainable.
Or, as the old tale goes, your GC might be the software literally exploding (it's in an air to air missile)
Using pointers correctly and safely in C basically requires tracking pointer rules substantially similar to the rust pointer rules, but in your head. Most people who don't do this just write incorrect code, although it might only rarely cause a serious problem.
The problem I have with articles like this is that if we were to substitute anything in for 'Rust', it would read the same. I imagine if they had re-written it in C it would also be better than before. If it was an advert for anything, it might be chucking away a dodgy prototype and starting again (which is surprisingly rare).
Anyhow, on the other side of the coin, it's good to see newer languages getting a proper outing in real world situations. Proving stuff is 'up to it' can be a bit of a long haul, so every data point is useful.
> Rust takes longer to write than C
> but spent basically zero time debugging
that's the difference to rewriting it in C
One could argue that when the program is finished without bugs, then it is maybe completed. So does it take actully longer to write with Rust?
It depends how proficient you're in Rust. Once Rust itself is not a difficulty for you, there's a lot of productivity gained from having a modern language with many conveniences, and great tooling.
Rust moves more bugs to compile time, so you will technically spend more time getting the code to compile, but in my experience in 99% of cases it's a time saving. And it lets you be more confident about a program correct by construction, rather than merely fuzzed and not observed to crash. The 1% of counter-examples is trying to be too clever with generic interfaces and hitting Rust's limits.
Reposted:
2024-02-20 (3 comments): https://news.ycombinator.com/item?id=39446699
2024-02-04 (0 comments): https://news.ycombinator.com/item?id=39251131
Didn't they just have a shitty implementation written in C (could have been any other language...it's not the language!) and than learned from the past mistakes and written a new implementation in Rust(could have been any other language)? And now the author tries to attribute it's success to Rust?
I've done many rewrites of C in C, and C in Rust, and there is a big difference that is directly attributable to Rust.
The safety of references, no raw malloc, no null pointers, compiler-checked thread-safety of types, consistent and enforced error handling help a lot to make robust programs, and allow making bigger refactorings without fear of screwing something up.
The Turing Tarpit means that theoretically everything you can write in Rust you could have written in C, but in practice Rust enables things that wouldn't be worth the risk/effort in C, even when doing a ground-up rewrite.
Maybe. But them the dev wouldn’t have been able to add „Completed a migration of legacy C codebase to Rust with zero issues in production“ to their resume. Also might have been easier to get budget for „build something new to replace old thing“ than „fix pesky bugs in somewhat-working existing thing“.
Given the difference in availability of jobs and the amount of code out there, unless you are working in startup world or on web dev, this would be a major red flag on a resume in a lot of cases. Even the use of the word "legacy" is a problem. Like, this isn't "legacy" you asshole, this is our companies highest revenue product with a decade of hard work behind it and we don't want somebody that is going to be constantly trying to shill rust when we hired you to help maintain an important C codebase that is part of the foundation of the business. We need you to get good at C, despite all its flaws and issues, not complain.
This kind of attitude only works in an exceedingly small part of the software world that just happens to be disproportionately represented on sites like HN. Elsewhere, it's not a good luck to be using words like "legacy" on a resume without a lot of explanatory text about why exactly it really was legacy and deserved a full rewrite.
“Legacy” is just the tech industry’s passive aggressive euphemism that means “it’s old and I haven’t learned how it works.”
I have the same sense as you: when someone tells me they rewrote their company’s “legacy” code, my spidey sense perks up. Now I’m wondering if there was really a good reason or if he just refuses to learn an existing code base.
Not to mention it could also be more fun, something that sometimes can be more important than we think :)
For the dev, absolutely:)
If you're going to try using rust for esp32 development, you'll use the wrapper libraries that Espressif maintains. When things don't work correctly, you'll be dealing with a larger problem space as you try to figure out whether the problem is your implementation / logic, the lower-level libraries, or the wrapper libraries. I don't know what benefits you're gaining using rust if you're not using a native rust (to the metal) stack of libraries.
If only Oxide found a need for esp32 modules, perhaps they would be up for the task?
If you “embed” ulisp on that Platform, the serial interface seems have issues. Wonder whether this is the case of embedded rust?
I’m doing some C on esp32 currently, and wondered about switching to rust, and I understand that simple cases with Rust are solid. I’m definitely interested in trying it out.
However we need to work with a lot of the hardware apis like twai, ble, lte, ota, etc. It seems like support is spotty or it’s DIY.
It’s also worth keeping mind the remark about developer availability. I can generally answer questions about the C to someone who’s not experienced in C, while Rust might be another story.
> It seems like support is spotty or it’s DIY
I can somewhat attest to this! I have a pretty extensive prototype of using Rust on ESP32 in production. I wrote a reference implementation for ESP32 platforms deployed via BRSKI, a secure remote key bootstrapping protocol which builds upon attestation keys and public key infrastructure.
I'm largely using `esp-idf-svc` for most things, which is a Rust-native wrapper around ESP-IDF code. For anything closer to the hardware, I'm using `esp-idf-sys` which is just a thin wrapper around the the `ESP-IDF` SDK.
You can see the project here: https://github.com/hm-seclab/open-brski
Hope this helps! I'm by no means an expert but I sometimes help contribute to the Rust ESP32 ecosystem, so ask away if you want :)
Hi! Thanks for your reply. First time hearing about Brski, I’ll have a look
I guess your takeaway is that despite spotty support, the benefits of rust are net positive? I guess learning to call C from Rust is gonna be part of it too right ?
I'm ignorant about Rust, but to me it's just static type language akin to C#. And C# has IOT library which seems to target Rust most usual use case, namely on embedded platform. C# also has memory safety just like Rust.
So why do we need Rust at all? What's the use case for it?
Anything that I'm missing?
Rust compiles to native machine code. C# compiles to bytecode which runs in a runtime environment. That adds a huge amount of overhead, and means you don't have direct access to the hardware registers. The .net IoT framework is targeting computers running operating systems.
When you compile rust for an embedded target it's running "bare metal" - there's no operating system, the microcontroller literally just starts running the instructions your compiler put at memory address 0. If you want anything an operating system offers - task scheduling, memory allocation, file system access, network access etc - you have to compile it into the binary that's loaded into the microcontroller.
Only languages which compile directly to machine code are really suitable for that - C, C++, Rust (plus a long list of less common ones - this list of languages which can compile using LLVM is a good place to start https://github.com/learn-llvm/awesome-llvm?tab=readme-ov-fil...)
- https://nanoframework.net/
- https://www.wildernesslabs.co/device
Here are examples where C# is successfully used as a language for an embedded target.
In addition to that, compiling to bytecode is just one way to execute it out of many, and the statement does not correspond to reality. I'm not arguing C# is a good language for IoT. I'd personally use Rust for that in almost every situation, but the amount of false claims in this discussion is disheartening.
It's kinda like getting the benefits of F#'s type system but with compilation to native code without garbage collection or data races.
> Anything that I'm missing?
C# is garbage collected. This is a no-go in many/most embedded software applications.
C# also grants you poor explicit control over heap/stack allocation: this is essential for embedded development.
Is it really true though? I don't have much knowledge about embedded development, but as far as I know, Java has been used in many embedded systems, and was running on phones' SIM-cards. Please correct me if I am wrong.
I think that most modern embedded systems are nowadays more powerful than my first desktop computer — is it really still worth for the majority of embedded projects to count every byte at the expense of developers' productivity (and overall project success, as a result)?
SIM cards are a weird exception because they have a hardware computer designed to run a subset of Java. Normally Java compiles to a bytecode which is run by the Java VM - in SIM cards the VM is a hardware implementation of the Java VM. That's super uncommon - most processors in the world have a different instruction set, like ARM or RISC or x86. Java can't compile to instructions in those languages. Rust can.
Yes, you can run a VM on one of those processors in which you run a language like C# or Java. Look at MicroPython as a successful example. But the code which runs that VM has to be written in something. Typically that has been C and C++ - but Rust can also do it.
You're right though - a lot of what we call "embedded computing" could be done using a modern VM interpreted language. There are some languages out there - MicroPython and Squirrel come to mind - which can run on the memory and storage constrained environment of a microcontroller. The mainstream implementations of Java and C# use way to much memory - they've been optimised for desktop environments. Microcontrollers often have 64 - 1024 kB of RAM.
You could ship products with application processors like the Raspberry Pi, running an OS, and write your application in whatever language you like. But that costs 1-2 orders of magnitude more money. A cheap microcontroller is $1. By the time you've added the RAM, flash and supporting power rails, a cheap application processor is $10+. Then you have to maintain an OS - that's a lot of engineering time. Sometimes it's worth it, sometimes it's not - the tradeoff depends on the product.
Not sure how well it fits reality, but it’s also to a large extend how dramatic can be the result of a fault of your system.
If it’s embedded in a coffee machine, maybe all cost-effective taken into account it’s ok to have an over-bloated software stack maintained by the cheapest folk the manager could found.
Now if you are working on embedded software for some vehicle like a critical part of a car, a train or a spaceship, considerations of safety for both ethic and legal reasons might lead to different tradeoffs and conclusions.
C# is the language with the best degree of control over allocation among all GC-based languages. You can write code that is completely allocation-free including abstractions. Most "data processing" APIs in the standard library do not allocate at all or allocate once for initializing e.g. lookup tables.
The actual issue is existing selection of runtimes for embedded platforms is limited: https://nanoframework.net/ and https://www.wildernesslabs.co/device (to be fair, a friend of mine uses the second one for automating his lab for his microfluidics devices research project, so it is useful).
> C# is the language with the best degree of control over allocation among all GC-based languages.
It's the best, but if I can't say: "never heap allocate under any circumstances," it's a problem.
You can :) It just requires going out of your way a bit. It effectively works as C with better type system and generics (C++ lite if you will), that can be either JIT or AOT compiled (statically linked too). For example https://github.com/bflattened/bflat has a target flavour that does not support GC at all.
I'm not saying it's an optimal choice for embedded, only pointing out that you can write allocation-free code with confidence. Patterns that allocate are known - predominantly boxing and closures. You can easily avoid both, you can also declare your structs as 'ref struct' which completely prohibits placing them on the heap, either as a box or as a part of heap-allocated memory inside some other object/struct.
I would argue that using JSON in embedded, especially on ESP32, is another no-go. I'd wage that using a binary format and later on, after you're out of ESP32, convert it to JSON would be a bigger performance gain than the evangelic tone of this article vis-a-vis of Rust.
You're missing that Rust has safety in terms of multithreading, which C# doesn't have. Writing a data race in C# is the default, writing thread safe code takes work. In Rust, the default is that it's safe, you have to jump through a lot of hoops to try to make it not thread safe. The same is true for async, which in C# is also a problem.
In all C# codebases I've seen, you have threads and tasks, and you often run into multiple threads or tasks holding a mutable reference to the same data. That's not legal in Rust without synchronization/locking.
If you don't believe me, just spin up a new main.rs file and write code that has a data race.
Easy. Decide to use an ecs system because of its lower memory footprint. Pass around integer indices. Use two threads. Data race.
This was recently discussed: https://news.ycombinator.com/item?id=41801124
While it is true that Rust is a strictly superior option for highly concurrent systems code, it still leaves areas where you can make a mistake regarding lock management and other advanced forms of synchronization.
In addition to that, .NET as platform is fairly tolerant to misuse and calling the code that is not thread-safe from multiple threads concurrently usually leads to logic bugs or "stop modifying this collection concurrently, please" exceptions but not to catastrophic memory safety issues like it happens in C/C++.
You can read more on its low-level memory model here: https://github.com/dotnet/runtime/blob/main/docs/design/spec...
> The same is true for async, which in C# is also a problem.
Now, this one is strictly not true. Async primitives are thread-safe. In Rust, you must synchronize because at the very least you must deterministically deallocate memory used by shared state between the tasks. In C#, this complexity is handled for you by a GC (ironically, you get negative sentiment towards async from people having experienced Python's async or Rust's async complexity, assuming the same applies to C#). In some scenarios, it is also a throughput optimization since it reduces memory contention by not modifying the cachelines shared between the cores, lending itself into better performance on many-core systems - the memory is modified/reclaimed when it's no longer in use, while the actively shared data is placed elsewhere.
I think the thing you're missing here is that "Internet of Things" usually means machines way beefier than "embedded."
IoT is roughly equivalent to a Raspberry Pi - the thing will usually have an operating system that you're running on top of, and most of your existing knowledge about computers will port over.
Embedded is the chip in a happy meal toy, or your microwave in 1995. There is no "operating system." Your code is the only code running on the machine.
That kind of embedded work, like connect-the-dots pcb layout work, went overseas 15-20 years ago. The typical new embedded project in the US today has minimally a not-particularly-resource-constrained 8-bit processor with gobs of fancy peripherals, something like the PIC Q10 series or the ST equivalent. The median would be a 32-bit ARM Cortex M.
Typical IoT SoCs are a step up from that but it’s not huge. The ESP32 is pretty representative but there are significant other options - see what Amazon supports in FreeRTOS as a starter.
It’s a big leap from small IoT SoCs to SBCs like the Pi.
nice pop-up that scrolls you to the top of the article
I was using brave and did not see that popup
TL;DR we had some buggy C code and fixed the bugs then rewrote it in Rust and wow we didn't have as many bugs... that we already fixed.
Rewriting something is not the same as the first effort. Try green fielding see how long it can she develop it once you already had the first basic C code it's pretty trivial to convert it to rust most of the time especially just using other libraries.
And imagine that. You fixed all the bugs in the prototype and the second rewrite didn't have as many bugs. That's his nothing about the second versions language it just says you fixed all the bugs in the prototype.
> Since Rust, and especially embedded Rust (lots of FFI & unsafe), is quite hard to learn, it is not viable (for us) to retrain a C developer to Rust.
Rust does not need a phd in quantum physics. Anybody can learn it with a bit of patience.
In particular, you could teach it to Physics PhDs, which might be useful as today they are mostly taught Python and so they end up leaning on libraries to go faster because the Python isn't fast enough.
Once upon a time a specialist in Computational Chemistry or Physics or whatever would be expected to learn Fortran, and it makes lots of sense to use Rust for the same purpose in the interim (eventually a WUFFS-like special purpose language seems like a better fit to be able to deliver absolute safety and better performance by not needing to care about generality)
Has anyone tried Nim in embedded systems? I wonder how it went.
ESP32. ESP-IDF, not no_std.
Really? https://join.com/companies/stabl/12642327-initiative-applica...