Embedded Rust in Production?

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.

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.

> Rust is much more likely to follow Java's trajectory than OCaml's

I'd rather compare Rust to Haskell and Kubernetes.

  Haskell:
  - Dozens of handfuls of experts open to remote work.
  - Lots of aspiring juniors who see no way to enter the market.
  - Most employers are R&D-heavy academic consulting environments.

  Kubernetes:
  - Wildly hyped and cherished among people who don't have the complexity to warrant the purchase.
  - Eventually criticised for being overly complex and suitable only at a certain size and setup.

> it's only going to be easier and easier to find Rust developers.

I imagine it's never been easier to find Haskell developers and Kubernetes developers, either.

Yet, one's wish to code Haskell professionally does not necessarily align with one's market value.

It seems like there's a lot more open for Kubernetes, so Rust could go that way.

Unlike Haskell, Rust seems to gain industry acceptance.

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.

Nobody is stealing anything, what a weird comment.

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

Haskell and OCaml have a lot of what Rust has (namely exhaustive pattern matching + sum types, typeclasses and the like) but Rust has stellar tooling.

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

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

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

RE: scripts, I find Golang better and better for this nowadays. Uber-fast compilation, to the point of it being acceptable to just instead do `go run your_thing.go` even, and you have access to a very solid runtime and many libraries for most of what people usually need.

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

I do have one ear for that argument that "everything ought to be simpler". But what I've observed over and over is that many systems tends to become more complex as the result of people wanting to make them more newbie friendly.

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

The kind of people that recklessly move from shiny language to the newest shiny language in town are the same kind of people that believe that you could kick out a dev writing systems in Java and stick a dev whose experience has only been Haskell and O'Caml and have the new dev hit the ground running

Another use case is when you need a systems language for a user-facing app (even if not directly connected to the internet) and would have reached for C++ previously.

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

> you have to ask how you will grow and maintain things going forward.

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

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

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

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

> descent money

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

I guess you could argue both ways and it depends on your starting point. I did not mean to say "make it newbie friendly", I meant "I want adding a dependency to my project to be a 10 seconds job, not a week-long endeavor".

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

The longevity of Go is also a thing. I have not encountered a single Go project that used to compile but now doesn't because it hadn't been touched.

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

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

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

Agreed 100%.

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

> I don’t love Perl, but we have 10+ year old Perl scripts at work that work fine.

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

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

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

haha, nice catch, thanks for the smile. :)

Right -- you can choose a niche technology, as long as you're willing to commit to the additional costs of doing more training, being involved in the community, and so on. Those additional costs (and/or the risk of not doing so) need to be factored into the decision to use a technology.

If a company chooses non standard tools then they are doing it with the knowledge that they will have to train new hires in it. Random employee using non standard tools without the company making the decision to pivot to embracing it, aka training existing\new employees in that tool, is just making stuff that your company will have to throw away and redo.

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

But 28 years ago with Java, it had a clear edge in a certain space. It came with a ton of libraries, so you didn't have to write a bunch of code. And it had garbage collection, so a bunch of problems just went away. For code that didn't have to be close to the metal, it was clearly superior. And it was pretty easy to learn for C++ developers.

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

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

I've gotten far with type switching on an interface that amounts to a single function that does nothing.

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

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

Can you point me at an article that demonstrates Golang type switching? Does not ring bell at the moment for me so I'd love to see the code.

Thanks, for some reason I never stumbled upon this. Very valuable, I am bookmarking it.

> I think Rust is much more likely to follow Java's trajectory than OCaml's:

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

Java had a lot of things going on for it. Huge marketing push, whole set of everything both language and lib-wise, and killer domain which was SIM and mobile which if you wanted to do it was your only choice. Rust has no such things at the level Java had when it rose. It's more of an organic grassroots movement certain companies have started to pick up.

Yea it did, and its important when making comparisons to not glaze over it. Java with the, write once and run anywhere mantra due to the JVM was a huge deal. Granted, in some ways it didn't pan out as well as advertised (embedded Java), but for an enterprise desktop application, it was definitely a huge win for the time.

Still leaves a lot to be desired versus Object Pascal from Apple/Borland days, or Delphi afterwards.

Apparently there was something to it, otherwise we wouldn't have every other day a WebAssembly startup being upvoted.

What makes those better?

The language features, designed for full stack systems programming, IDE tooling, the frameworks bundled with the compiler, first class support for binary libraries ecosystem, no culture against modern times...

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.

I dunno. Java was pretty easy to learn for its first decade. Eventually, the complexity of Java and, especially, its toolchain ballooned. By then there were already a lot of Java developers, though.

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

Yes it does very much depend on your starting point.

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

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

Yep, it's about your background.

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

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

Even when i use cargo or go or node, make is still needed to build everything that's not just code.

If you say so. There are plenty of tools that can do more or less the same without having to remember weird bash-isms and pattern expansion rules.

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

> make is still needed

You mean: I still need make

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

> build everything that's not just code

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

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

> Rust has stellar tooling

I came for the job opportunities.

I stayed for the tooling.

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

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

Well to be fair to Rust, Nix can drive anyone crazy. I tried that one too and figured they sniffed way too much of their own drugs, if you pardon the expression. In the meantime I learned `just` in 10 minutes.

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

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

Again if it's so great fork the kernel and make it great. People will flock to you if you can manage.

The thing about Perl developers is they tend to stick around. At the last Perl shop I worked for, the average employment time must have exceeded 10 years. I could say the same of Prolog and 25 year average employments.

People used to whip up Delphi GUI apps in an hour or two. I'm not sure how to achieve this so efficiently with "modern" tools and languages.

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

The real comparison is between Rust and C++, even though folks seem to be pushing Rust for web services and internal tooling. And modern C++ is an absolute monster in terms of complexity, often just dancing around problems that Rust solves pretty elegantly with ownership and lifetimes.

I know there are many others, but make does any job, is very simple (once you have realized that recursive make is not needed for decades), is not tied to a specific environment, had been around for ages and will still be around 20 years from now. I don't think I'm easily satisfied with tools, but I have never had a reason to look for another tool that would solve a problem i don't have.

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

If you like Makefile, you’ll like Just.

I’ve been that guy, and I certainly believe in myself. ;-)

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.

However that comparision misses that C++ is reaching 50's, while Rust still isn't allowed to drink.

Most of that stuff can actually be done in compiled managed languages, and people reach out to C++ because of bias against anything with automatic resource management, even if C++ like features are part of the package.

In 2000, Java was still about doing dancing applets, businesses only started taking Java marketing seriously after two things happened, Hotspot became a thing, making it more appealing than C++ for cross-platform server code, versus dealing with the mess of writing portable C++ code when most compilers were a mix of C++ARM and catching up to C++98, with C++ compiler specific frameworks being heavily used.

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.

What's your point? Doesn't it only matter where things are now, not how long it took to get there? Or is this about more people knowing C++?