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 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.
> 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.
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.
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 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.
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
> 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.
> 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.
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.
> 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).
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.
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.
>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.
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.
Or the dev wants more money
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?
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.
On day 1, yes, a newbie to Go would be able to be more productive.
Go is also a more productive language for many use cases.
> 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.
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).
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.
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.
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.
Solvable by launching your own startup, using rust and running it for 3 years.
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.
> 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.
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…
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.
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.
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.
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.
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:
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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“.
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...)
> 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.
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 :)
nice pop-up that scrolls you to the top of the article
I was using brave and did not see that popup
> 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.