The Case for Rust in the base system

[1] https://rust-gcc.github.io/

This is also why we LTS versions.

Sure, it's nice to be able to tinker and hack to see if you can upgrade them yourselves, but is it worth maintaining architecture support for that kind of use case? Not asserting that is definitely not, but I think it's worth considering.

So the main set of platforms you're looking at are ones that are functional enough to have modern, stable C compilers, aren't too quirky that reasonably portable C code would "just" work, and yet ones that you don't already have support for in Rust. Outside of the embedded space, there's like... fewer than 5 architectures left, the most notable of which probably being Alpha.

> According to research, up to 850 billion lines of COBOL code are currently running in nearly 30,000 organizations, typically in critical production environments. 90 percent of Fortune 500 companies rely on it. Never has there been this much COBOL in circulation and the volume is only likely to increase for the foreseeable future.

https://www.chrly.pt/en/2023/06/14/cobol-the-immortal-langua...

Rust is not immune to security vulnerabilities. And at the end of the day, social engineering will steal more data than "hacking the mainframe". Why break in when you can just ask to be let in?

OpenBSD has a great security track record because they resist excessive change and prefer simplicity. For those who want to add Rust to the core of FreeBSD my primary question: is it really necessary? Or is it just because a bunch of Rustaceans want to?

So COBOL everywhere it is. Let it be written, let it be done.

There is 32-bit x86 tier 1 targets like i686-unknown-linux-gnu.

> The only Tier 1 architectures are [...] only the absolute mainstream. Not exactly a bastion of architecture support.

Tier 1 means that the target has the full testsuite run against it for each single pull request. Running the CI is computationally extremely complex, and it is hard to provide a reliable and fast CI service for most architectures.

For everything above the line, Swift is definitely viable today. Expect shiny new stuff from Apple to be Swift first, or even sometimes Swift only. If you're an Apple First developer, you should learn Swift, or you are going to be relegated to maintaining legacy software in the next maybe 3-5 years.

Microsoft is already solidly on the Rust bandwagon. So yes, Rust for NT is very possible. Unlike Apple though the Microsoft corporation has always been able to do a bunch of things at once, even if it doesn't always do them all well -- it doesn't need a singular focus to achieve success. So don't expect Microsoft to magically pull effort off C++ and .NET to do more Rust.

One thing C++ programmers might be interested to learn, is that this doesn't only apply to simple variables and references; it also applies to library data structures and their methods. The Rust compiler doesn't really "know" what the .clear() method on a Vec does, but it knows enough to prevent you from calling that method while you're holding references to the Vec's elements.

Mozilla is still a member of the foundation, so they do support it in that sense, but they are one of many companies that do so.

Cybersecurity issues make Rust a good choice for writing parsers for example. File format parsers handle scary data from the internet (JPEG, X.509, etc), and those often contain addresses and offsets that turn into raw pointers in the implementation, so they're a common source of security bugs. At the same time, they're usually isolated behind a reasonably tight API, so it can be practical to rewrite them in Rust even when all the calling code is still C or C++ or even Python.

On the other hand, fewer-mistakes-sucking-up-dev-time is an especially big deal in multithreaded code. There was a story from Mozilla about how they'd tried to add threading to part of Firefox (I think it might've been the CSS engine?) and failed multiple times, but then they succeeded in Rust. Threading bugs tend to be painful to reproduce, and Rust's compile-time checks are extremely valuable there.

These memory-related exploits disappear with Rust aside from in "unsafe" blocks (possibly the worst named keyword in any language... it should have been called "trusted"), and that means you have a smaller and more easily auditable attack surface for these types of memory-related exploits. Some code (e.g., FFI) can't be verified as memory-safe by the Rust compiler at compilation time so "unsafe" is there as an escape hatch. I've written a bunch of Rust since 2014 building things like webservers, realtime futures processing algorithms, MEV bots, etc., and I've only had to use "unsafe" a few times.

I've also worked in security on products at Fortune 100 companies, and C is a constant nightmare for CVEs. I think I have PTSD from having to update libcurl. The more software we have written in memory safe languages, the better off we all are.

Yes, thank you for pointing that out, ive had a bad headache for most of the day and knew I was saying the wrong term when I wrote it, but couldn't for the life of me remember what the right one was! And yeah I'm pretty familiar with this, although I wasn't aware of OCaml's strides

Yes, it is very much true that rust cannot yet represent monads as type classes directly, since it does not have any form of higher kinded types yet — which is the reason why I said second only to Haskell. If it could represent monads directly, than I would have placed it equal to Haskell — as I would have placed scala!

But I do think it is important to highlight that it does have pervasive useful monad use in the language, and an interface that allows you to use a very large common set of powerful transformations on them via the iterator trait, and it uses the monads that exist in the language and the ability to use that trait on any monad a lot to increase the power of the language in a way no other language besides ones with superior monad support does that I know of. So I would argue that while it is still second to Haskell, it is still far above almost any other language not equal to Haskell in this respect. Which is what I meant by saying second only to haskell!

Also, HKTs are something that the rust team seems to be very actively looking to rectify with an in progress implementation currently available in nightly, so that won't be true for very long.

I believe that a monad is basically any container that has both a constructor and a flat_map function (and there may be one other requirement that I've forgotten). The special ability that Haskell has is the ability to write code that is generic over any such container.

In my opinion they are, because any group of types and functions that implements a module signature must be wrapped up into a module that satisfies that signature at the point of use of any value that needs to satisfy that module signature, instead of a type just satisfying the given signature if the correct functions exist to manipulate it, which means in my opinion there's a lot less flexibility and it works more like constructing a new value of a certain type then it does having constrained parametric polymorphism in the way Haskell does. I think this is why although they technically can be used to imitate rust traits or Haskell type classes and allow a function to polymorphically take any type of that satisfies a certain interface, it isn't in practice used like that almost at all, whereas it absolutely is in Rust and Haskell. Witness for instance how both rust and Haskell have a generic type class for iteration that allows you to take anything that is iterable and use the whole module of functions available for iterables on it, so for instance in Rust you can use many of the same methods on a vector and an array and error checking monads, whereas in ocaml, even though something similar is in principle possible, it's almost never done that I've seen, because you have to essentially declare that I type implements a signature and how it does on every point of use where you want to pass a value of that type into a function that requires something with a certain signature. Instead functions are duplicated between modules for different types, like lists and arrays. Maybe that isn't underpowered per se, but it's certainly a practical consideration in the use of first class modules that mitigates a lot of what they are theoretically capable of that seems in my opinion to fall directly out of the conceptual model of using first class modules to do constrained parametric polymorphism, since values then must become modules.

As for the ability to represent the signature of monads — yes both ocaml and Haskell can currently do that while rust cannot, but there is actually currently active work on an RFC that would rectify that. So I suppose overall you might say that rust's type system is currently less powerful then the other two, but I really don't think that will be true over the long run, and it certainly isn't true of necessity, and rust has a type system with a great many benefits in practical power over OCaml's otherwise, in ways I feel impact day to day use more.

I will admit that because the library ecosystem in Rust is younger, you do see things like Clap's breaking changes more often than in other languages.

It's much harder to manage a large codebase/application with Python, but it excels at data science and research programming, which Go and Java do not.

(Obviously, there is overlap between all, and you could do anything in any language.)

Sure, there will be a small C ABI shim but the developer experience writing in Rust I think is worth it.

Also, nowadays whenever I want to write a fast Python extension, I don't think twice before using pyo3, super simple to write and build.