Embedded Rust in Production?

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.

Many such cases. Recipe for disaster.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

Fixed it for you. You wouldn't believe the quality of the average applicant for a basic standard Python position if I told you.

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.

Huh? There's tons of good developers looking for jobs right now, more so in Rust.

Web stuff is about developer speed. So familiarity, libraries, and tooling. There are plenty of good options.

Anything that needs to be performant can go in it's own service.

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

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.

You can add typing tools now, though? CI pipeline runs mypy and that gets you a long way.

Rust is a complex but overall good language for writing solid software, C++ is making a deal with the devil in exchange for speed.

Greasing the wheels of the corporate meatgrinder with Rust is almost impossible, actual work quality notwithstanding.

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

Can I hire 1000 Rust devs at the drop of a hat off the street? Well, no. Have I ever struggled to find competent Rust devs, or high level people who were happy to learn? Nope.

I would absolutely not be afraid to use it because of “hiring concerns”. If your current devs can’t or won’t learn anything new, they’re not very good at their job. If you can’t or won’t hire because you can’t find a super-senior at the drop of a hat, well, your hiring process is broken and no language will really help there.

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

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

And the problem with new kernels is how to reuse the huge trove of already-written drivers. Nobody is going to start rewriting everything in any language, be it Rust or any other -- does not matter. That's why the ABI and "please commit to a standard" points are so difficult and thorny in the kernel ecosystem; people want to reuse.

Had both of these languages' ecosystems and communities not dragged their feet and go full elitist on newcomers then Rust might not have ever been created.

So sure, Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program and then spending the other half on trying to do the same in OCaml I just threw my hands in the air and said "frak this, there has to be a better way".

Hence I landed on Rust. You and others can always say "skill issue!" but that's hugely missing the point; I want to use my skills on solving the actual problem, not on the logistics. We're not in the 1970s anymore and a weirdly huge number of people still haven't gotten that message.

I don't argue with the portability and longevity of Perl but it too has its problems.

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.

That's certainly true of the last 10 years of Ocaml tooling evolution.

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.

rather different to my

While they should get wider buy-in first then if the choice is technically justified within reason, its perfectly appropriate

Memory corruption bugs are no joke. If you've got staff that already knows C++, their ramp up time for Rust will be much shorter compared to typical devs working only in Python, JS, etc.

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

The typical answer is "The jobs market will provide".

The issue with that method is that you end up competing with everyone and, usually, your company is not the top employer.

OTOH, some companies decide to use technology and invest in knowing the community, by hosting events or meetups, by frequently sending their devs to conferences on company time, etc. Usually, the people hired are above average, and are also able to train juniors if the market dries up. These companies typically are the safest in terms of ability to maintain their stack, but have to account for the fact that alienating their existing devs becomes a big risk.

The real harm comes for companies that choose niche tooling but believe the market will provide.

When you want a decent paycheck, but instead get a descent into computing madness.

If we both start from that point then I think we might find a common ground.

Python, Ruby, Go, PHP, C#, Java, TypeScript, Elixir.

Performance benchmarks when writing APIs as 1st concern? Really? 99% of the cases this should be the last criteria.

Monthly reminder that a good part of instagram still runs on Django/Python.

Go is in many ways leap years ahead of most AOT languages I've used in anger. Yes, sometimes you miss XYZ, but seldom is that an issue outside of personal preferences.

What you do get though is amazing tooling and little-to-no downtime. Builds basically don't take any time, tests run past, pipelines are quick.

go test ./... finishes faster than you can print Determining projects to restore... to the screen. It's a very liberating experience that is hard to go back from.

Case in point from the article:

> it is not viable (for us) to retrain a C developer to Rust

What? Why the hell not?

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.

Typescript, Python, Go, Swift, and even Bash depending on the situation are all quicker to code in than Rust.

If any of those languages are inadequate for the requirements whether they be memory-bound, CPU-bound, or sensitive to gc pauses, Rust is an excellent option that is far superior to C++ in 2024 and beyond.

The notion of "one true language" has always been and will always remain a fool's errand.

I have my very real pet peeves with Golang -- lack of sum types and thus no exhaustive pattern matching is the top one -- but I can't argue with results. Every time I wanted to whip up something quickly, Golang has gotten the job done and then some.

I'm not talking primarily about Perl as a technology in and of itself, but as a long-term technology choice in terms of being able to find people to maintain and improve it.

The Xen Project has a bunch of support stuff (automated testing and tooling around doing security work) written Perl. It was just about a reasonable decision when it started to be written 10-15 years ago; Golang was too young, Rust wasn't written yet, and Python had its downsides. But when the author of the code left the project 2-3 years ago, and there was 1) nobody with a similar level of expertise to maintain it, 2) nobody particularly wanted to gain that expertise, and 3) it wasn't easy to find someone else to pay to do maintenance.

If you've managed to find people who can maintain those perl scripts, more power to you; but it unless perl5 can get some momentum back, it seems like it's going to be harder and harder to find replacements.

I would probably concede that it depends on context - for devs paid at the top of the market to simply churn stuff out factory-style there is less justification for self-improvement on work time.

For the majority though there is always give and take between responsible employees and employers, and building skills as discussed is normal.

Unlike Go that only really requires experience in general programming to become rapidly productive, Rust basically requires that you read The Book in its entirety before you even think about applying that knowledge in production. There are just to many interdependent concepts to hand wave away the prep time. It all (mostly) makes sense once you've familiarized yourself with the basic concepts, but it's a training step you simply cannot skip without inflicting a fair amount of pain on yourself and others.

C++ is better than it used to be, but it was truly atrocious in that regard for decades. It was simply the least worst option for those decades.

I do not consider it the least worst option anymore.

So XenServer embracing OCaml is nothing like Random Gamdev writing some scripts in Rust without the team deciding to embrace the change.

This was not what Google and others found when they studied it.

https://www.theregister.com/AMP/2024/03/31/rust_google_c/

> More significant, Bergstrom said, is the comparison of rewrites of C++ code into Rust.

> "In every case we've seen a decrease by more than 2x in the amount of effort required to both build the services in Rust as well as maintain and update those services written in Rust," he said.

Rust may have an advantage in certain places (no segfaults is a definite win). But replacing working Python scripts is almost certainly not that place. Also, for a C++ developer, Rust isn't as easy to learn as Java.

Rust may get there. But don't use Java's success to predict Rust's trajectory.

Unfortunately it does nothing in terms of exhaustiveness, but it effectively gives you sum types which IME are so, so much easier to work with than state pattern or other inject-an-object-abstractions. Not having to design an API (that later leaks) is rewarding enough.

It's strangely efficient as well. I've experimented with implementing sum types via tagged C-style unions and at every (ad hoc, micro) benchmark I've tried them against, type switching on an interface comes out on top.

This looks like pipe dream of those Rust devs who usually claim that Rust borrow checker is easiest thing since heating HotPocket in microwave.

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.

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.

This is all it takes to build a linux arm64 binary:

  env GOOS=linux GOARCH=arm64 go build your_program

This is how you list all possible targets:

  go tool dist list

  #!/usr/bin/bash
  archs=(amd64 arm64 ppc64le ppc64 s390x)

  for arch in ${archs[@]}
  do
    env GOOS=linux GOARCH=${arch} go build -o your_program_${arch}
  done

Some memes just write themselves.

A good rule of thumb would be: is correctness and code confidence more important than learning curve and compile times? If so Rust, otherwise JS or Python (with possibly parts in Rust).

looks on par with rust then. go is the next one for me to dive into when im doing fiddling with rust audio stuff.

regardless, wouldn’t have worked at last job as no-one knew go either. would have been easier probably to get someone in, but i spent a year trying to get one new hire to no avail, so doubtful.

Tbh I don't find myself to be "slow" in rust. Sure for quick exploratory stuff the notebook-environment and introspection capabilities of a dynamic language are definitely nice (e.g. when taking apart some unknown JSON data format), but especially when it comes to complex logic and refactorings Rusts type system is really making a big positive impact on productivity.

Sure TypeScripts type system is also powerful, but Rust is consistently better at infering types from closures and function calls, and the existing types and tooling story is miles ahead of TS. (and I've never encountered an easier to setup/use model checking language integration than Kani)

For one-offs where correctness doesn't matter, sure throw $SCRIPTING_LANG at it. But once you want correct software, I'd still choose Rust in a heartbeat.

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.

Viability of a language is certainly a consideration, but the characteristics of the language also matter.

What you couldn't really predict about Java in, say, 2000, was how much the complexity of its ecosystem would grow. In 2000 (or 2005) it was fairly easy to move in and out of Java from project to project. That is not true today. My fear on the Rust front is that it's going to be another C++, where the complexity is considerable and requires more or less full-time expertise.

Rust is a different beast, much more complex from the outset, and not trivial to learn (as Java was). It will grow if that's where the best jobs are, but I don't think it is going to grow in the way Java did, because the difficulty and dynamics are different. There was a good stretch at the beginning where Java was both very helpful on your resume and really easy to learn.

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.

For instance, coming from C Unix programming, it took me 2 hours to try OCaml 15 years ago or so, because Ocaml tooling, at that time, was the same as C. Basically, I made a generic rule for my makefiles to call ocamlopt instead of gcc and I was good to go. Installing a dependency was just the usual "./configure && make install"

This was simple for me, but not for students with no Unix background. In that context "opam install" was simpler, although it's objectively more complex as it adds a few additional layers on top of the same process.

I moved away from makefiles long ago and I don't regret it, for a multitude of reasons that are well explained in many places.

`cargo add ...` is great and I wish every language offered a tool like that.

I use `just` for project tasks, but there are many others.

You mean: I still need make

For example, build.rs replaces some uses of a makefile.

> build everything that's not just code

Have you heard of: Just, Nix, Bazel, Helm, Terraform?

Depending on the situation, there are many things you can build that aren't strictly code where you can use a bunch of other tools than make.

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.

I came for the job opportunities.

I stayed for the tooling.

> Haskell and OCaml are great but after I spent half an afternoon trying to bring in a dependency in a little-more-than-hello-world Haskell program

I had a similar experience trying to make Haskell's LSP work in test files. After ten years of using Haskell for academic and hobby projects, I still couldn't make the red squigglies go away in test files. With Rust I struggle similarly when dealing with cross-compilation and a complex set of feature flags on Nix. But at least this is not "Hello World!" failing.

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.

Sure, not the same usage patterns, I get that of course, and I love the idea of Nix but they could have went about it very differently with a much better UX / DX... and they refused.

Side topic though, sorry for the digression. Main point was that if you use Rust normally without any weird and not fully accounted for wrappers then everything works fine. I just fired Neovim in a personal project I haven't touched in a year -- 20-30 seconds of LSP compiling stuff and I saw my project-wide compiler warnings immediately after.

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

Then everyone will know, numerically, whether Python is worth it. Maybe it is!

Maybe Python, but it doesn't compile to a static bin.

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

I don’t think it’s reckless to have e.g. Haskell or OCaml as your go-to language for a decade, and switch it out with Rust.

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

The second one was Sun's Distributed Objects Everywhere project being canceled, and the Objective-C code being reborn into the first J2EE proposal.

There was nothing else like that for business software other than Smalltalk and later .NET, however most Java vendors were ex-Smalltalkers, and in 2001 .NET was a no-go for anyone that would care about supporting UNIX deployments as well.

In 2001, we were moving away from scripting + write extensions into C, into Java, and only pivoted into .NET because being a MSFT partner with access to the "partner eyes only" betas from Microsft before .NET was announced, additionally there was some ideas to move away from UNIX customers.

However by 2006, while at Nokia Networks, a strong UNIX shop back then, the large majority of their applications were going into the Rewrite into Java phase.

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.

ie: security is rarely a problem when selling software