11 ms·

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 t

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.

tokinonagare 2y ago
> some tools were written in Rust. The tools were a re-write Some memes just write themselves.
ram_rar 2y ago
> 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.
serial_dev 2y ago
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.
desipenguin 2y ago
When you read statements like [^1] "I did the other trick: you take your non-Rust job and make it a Rust job." from the likes of Luca Palmieri - what do you expect ? I don't blame them. If they were able to convince their manager to re-write python scripts in rust, good for them. They got "on the job/real life" rust experience. They solved the "chicken and the egg" problem in rust hiring - for themselves. when companies can fire engineers when they are in trouble, engineers are bound to "think for themselves" [^1]: https://filtra.io/rust-mainmatter-jun-24 https://filtra.io/rust-mainmatter-jun-24
randomdata 2y ago
Programming languages are quite uninteresting and not particularly notable. What ended up being so horrible about the codebase that you couldn't take any developer and throw them at the code?
meindnoch 2y ago
>Only the author "knew" Rust [...] because the dev wanted to learn Rust Many such cases. Recipe for disaster.
- rob74 2y ago
  a.k.a. "resume-driven development"
  - makeitdouble 2y ago
    Typically, devs polishing their resume instead of prioritising business metrics probably means the overall org is on the down slope.
    - mytailorisrich 2y ago
      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.
      - ndndjdjdn 2y ago
        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.
      - makeitdouble 2y ago
        I'd agree with ndndjdjdn in that management getting involved should be the last resort, and potentially only to veto a very bad decision. I think the main issue here is having a single dev going for Rust. Ideally someone interested in a new technology would pitch it to the team, and they'd discuss if they want to have a shot a it and if they can justify the investment for the whole team. That's where a tech that doesn't fit would be discussed and rejected, potentially with a proposition for a better option that devs are also interested in. Even if it starts with just a prototype, if it touches production the other members of the team should be able to review it and maintain if needed. That's this whole bit missing, and the team looking at it as a thing of life, that makes me think they're not focused on pushing things forward anymore at an org level.
physicsguy 2y ago
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.
- deleted 2y ago
  [deleted]
- Seattle3503 2y ago
  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.
gwd 2y ago
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.
- adamc 2y ago
  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.
  - sshine 2y ago
    > 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. You can certainly make a case for that being inevitable in some ways: Rust can be written in many ways to address different levels of abstraction, and when you stack those, you can require the reader to know about all of them. If someone gives me a piece of Python code, it can only be hard to understand if the domain is hard (e.g physics) or it is poorly written. In that way, Rust belongs with C++ and Haskell. The abstractions that Rust will introduce over time won’t grow in all directions like with C++ and Haskell (e.g. you won’t get higher-kinded types or GADTs in the next ten years).
atoav 2y ago
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.
- dijksterhuis 2y ago
  > 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).
  - hu3 2y ago
    perhaps Go could have been a good solution for simple, cross-compiled code.
    - dijksterhuis 2y ago
      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.
realusername 2y ago
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.
- amelius 2y ago
  Go is also a more productive language for many use cases.
  - jcgrillo 2y ago
    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?"
    - amelius 2y ago
      You forget that a lot of projects benefit greatly from generalized GC.
      - jcgrillo 2y ago
        No. I didn't forget. It has not been my experience that not having a garbage collector in rust was a problem in practice.
- sunshowers 2y ago
  On day 1, yes, a newbie to Go would be able to be more productive.
- ramon156 2y ago
  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?
steelegbr 2y ago
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.
- 6r17 2y ago
  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 ?
  - wmil 2y ago
    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.
    - smolder 2y ago
      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.
      - 6r17 2y ago
        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 !
selfmodruntime 2y ago
> 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.
- throwawaymaths 2y ago
  Strong "only use this subset of c++" energy
  - iknowstuff 2y ago
    except using a different set of rust is not gonna allow RCEs or leak your data to the internet
    - throwawaymaths 2y ago
      Eh. An enterprising young developer could build an ECS style system with references as u32 indices and all bets are off.
      - 01HNNWZ0MV43FF 2y ago
        "the worst of all are the stupid and diligent"
- sshine 2y ago
  > 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.
nicoburns 2y ago
> 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).
- Seattle3503 2y ago
  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.
  - cypressious 2y ago
    I really enjoy projects where the project and the scripts around it use the same language.
    - blandflakes 2y ago
      I find that sticking to a single stack is severely underrated.
- bsnnkv 2y ago
  > 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.
6r17 2y ago
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.
otabdeveloper4 2y ago
> 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.
- isoprophlex 2y ago
  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.
goodpoint 2y ago
> 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.
FridgeSeal 2y ago
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.
- sfn42 2y ago
  I work in a team where we use C# for our backends and React/TS for our frontends. And of course a lot of other stuff, like Docker, Terraform, Azure etc. I would very strongly encourage anyone who suggested introducing different tools in our project, not to do that. Not because I don't enjoy learning, but because it's a waste of time. I don't need to learn Rust, C# works fine. I don't need to learn Vue, React works fine. I don't see any value in learning yet another tool to do the same job, I'd much rather spend my time getting actual work done and getting better at using the tools we're already using.
- jcgrillo 2y ago
  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?
the8472 2y ago
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
marhee 2y ago
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.
- melodyogonna 2y ago
  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
  - loa_in_ 2y ago
    It isn't necessary, that's true. But that doesn't mean it wouldn't be beneficial.
mellosouls 2y ago
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.
- hu3 2y ago
  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.
  - givemeethekeys 2y ago
    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.
  - mellosouls 2y ago
    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
    - hu3 2y ago
      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.
cmatza 2y ago
"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.

tokinonagare 2y ago

> some tools were written in Rust. The tools were a re-write Some memes just write themselves.

ram_rar 2y ago

> 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.

serial_dev 2y ago

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.

desipenguin 2y ago

When you read statements like [^1] "I did the other trick: you take your non-Rust job and make it a Rust job." from the likes of Luca Palmieri - what do you expect ? I don't blame them. If they were able to convince their manager to re-write python scripts in rust, good for them. They got "on the job/real life" rust experience. They solved the "chicken and the egg" problem in rust hiring - for themselves. when companies can fire engineers when they are in trouble, engineers are bound to "think for themselves" [^1]: https://filtra.io/rust-mainmatter-jun-24 https://filtra.io/rust-mainmatter-jun-24

randomdata 2y ago

Programming languages are quite uninteresting and not particularly notable. What ended up being so horrible about the codebase that you couldn't take any developer and throw them at the code?

meindnoch 2y ago

>Only the author "knew" Rust [...] because the dev wanted to learn Rust Many such cases. Recipe for disaster.

rob74 2y ago
a.k.a. "resume-driven development"
- makeitdouble 2y ago
  Typically, devs polishing their resume instead of prioritising business metrics probably means the overall org is on the down slope.
  - mytailorisrich 2y ago
    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.
    - ndndjdjdn 2y ago
      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.
    - makeitdouble 2y ago
      I'd agree with ndndjdjdn in that management getting involved should be the last resort, and potentially only to veto a very bad decision. I think the main issue here is having a single dev going for Rust. Ideally someone interested in a new technology would pitch it to the team, and they'd discuss if they want to have a shot a it and if they can justify the investment for the whole team. That's where a tech that doesn't fit would be discussed and rejected, potentially with a proposition for a better option that devs are also interested in. Even if it starts with just a prototype, if it touches production the other members of the team should be able to review it and maintain if needed. That's this whole bit missing, and the team looking at it as a thing of life, that makes me think they're not focused on pushing things forward anymore at an org level.

physicsguy 2y ago

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.

deleted 2y ago
[deleted]
Seattle3503 2y ago
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.

gwd 2y ago

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.

adamc 2y ago
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.
- sshine 2y ago
  > 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. You can certainly make a case for that being inevitable in some ways: Rust can be written in many ways to address different levels of abstraction, and when you stack those, you can require the reader to know about all of them. If someone gives me a piece of Python code, it can only be hard to understand if the domain is hard (e.g physics) or it is poorly written. In that way, Rust belongs with C++ and Haskell. The abstractions that Rust will introduce over time won’t grow in all directions like with C++ and Haskell (e.g. you won’t get higher-kinded types or GADTs in the next ten years).

atoav 2y ago

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.

dijksterhuis 2y ago
> 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).
- hu3 2y ago
  perhaps Go could have been a good solution for simple, cross-compiled code.
  - dijksterhuis 2y ago
    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.

realusername 2y ago

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.

amelius 2y ago
Go is also a more productive language for many use cases.
- jcgrillo 2y ago
  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?"
  - amelius 2y ago
    You forget that a lot of projects benefit greatly from generalized GC.
    - jcgrillo 2y ago
      No. I didn't forget. It has not been my experience that not having a garbage collector in rust was a problem in practice.
sunshowers 2y ago
On day 1, yes, a newbie to Go would be able to be more productive.
ramon156 2y ago
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?

steelegbr 2y ago

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.

6r17 2y ago
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 ?
- wmil 2y ago
  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.
  - smolder 2y ago
    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.
    - 6r17 2y ago
      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 !

selfmodruntime 2y ago

> 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.

throwawaymaths 2y ago
Strong "only use this subset of c++" energy
- iknowstuff 2y ago
  except using a different set of rust is not gonna allow RCEs or leak your data to the internet
  - throwawaymaths 2y ago
    Eh. An enterprising young developer could build an ECS style system with references as u32 indices and all bets are off.
    - 01HNNWZ0MV43FF 2y ago
      "the worst of all are the stupid and diligent"
sshine 2y ago
> 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.

nicoburns 2y ago

> 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).

Seattle3503 2y ago
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.
- cypressious 2y ago
  I really enjoy projects where the project and the scripts around it use the same language.
  - blandflakes 2y ago
    I find that sticking to a single stack is severely underrated.
bsnnkv 2y ago
> 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.

6r17 2y ago

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.

otabdeveloper4 2y ago

> 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.

isoprophlex 2y ago
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.

goodpoint 2y ago

> 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.

FridgeSeal 2y ago

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.

sfn42 2y ago
I work in a team where we use C# for our backends and React/TS for our frontends. And of course a lot of other stuff, like Docker, Terraform, Azure etc. I would very strongly encourage anyone who suggested introducing different tools in our project, not to do that. Not because I don't enjoy learning, but because it's a waste of time. I don't need to learn Rust, C# works fine. I don't need to learn Vue, React works fine. I don't see any value in learning yet another tool to do the same job, I'd much rather spend my time getting actual work done and getting better at using the tools we're already using.
jcgrillo 2y ago
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?

the8472 2y ago

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

marhee 2y ago

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.

melodyogonna 2y ago
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
- loa_in_ 2y ago
  It isn't necessary, that's true. But that doesn't mean it wouldn't be beneficial.

mellosouls 2y ago

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.

hu3 2y ago
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.
- givemeethekeys 2y ago
  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.
- mellosouls 2y ago
  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
  - hu3 2y ago
    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.

cmatza 2y ago

"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.