I would expect Rust to do well in these sorts of areas involving systems programming and low level development including projects like Firecracker.
The features that are very compelling is that installation is painless, static linking is encouraged and used widely and its APIs aren't tied to any specific platform, thus is a true cross-platform language done right. It would be better to compare it to C++ rather than C since they both interface and surpass the complexity of the language.
While the language is mature, the author fails to mention that most of the crates ecosystem is immature and some are unsafe. Especially in the domain the author is working in, there's a degree of risk in importing some crates which can compromise the safety of the project (use at your own risk).
Cross-compilation is there in Rust, it requires downloading the toolchain for the specific platform and Go has it truly built-in, so I'll give them that one. Lastly, it may be possible to use a cross-platform GUI library like gtk-rs, but it isn't widely adopted unlike Qt, Electron and Flutter. The question around that is whether if Rust is suitable for that use-case? As many ideas and crates for Rust GUI development are coming, for now I'd say soon.
The author is certainly bullish on Rust in general and in low-level development and so am I.
> The author is certainly bullish on Rust in general and in low-level development and so am I.
While I share your sentiment, I've recently talked to about 5 people who write software for low-level, security relevant things in airplanes. Imho the best application for Rust one could think of. None of them had even heard of Rust. But this is highly anecdotal of course.
There's a number of reasons. Anything in a regulated industry like that has to have everything approved by regulators. The whole compiler toolchain, all libraries, blah blah. All have to be certified versions before you can use them. You can't just pick up github latest compiler and expect to ship a safety critical device with it. Coders in regulated industries may have never even heard of github, much less rust. Different mindset.
Second, it's typically not x86 architectures. They'll have a specific CPU or SOC that they use, from a specific vendor, and other specific vendors that provide the (certified) compiler and possibly RTOS that is used to target that CPU. Those vendors have decades of investment in their C code. Some small change in the asm rust produces vs c (and I'd expect the difference to be much more than a small change) could just break everything in a finely tuned RTOS.
Third (and last one I can think of offhand), there are tons of things like static analyzers and such that can be used against C code and have been developed over decades to find many of the things Rust has built in. They're not as good as Rust at some things but better in others.
Oh, fourth, these companies already have huge codebases and libraries they've already written and are used to. Rewrites / refactors are less common in regulated industries because of all the documentation they require.
Okay, fifth, and perhaps the biggest one, at least in my experience, we didn't ever malloc / new in the app code anyway, because of the potential for out of memory errors. We created a couple big buffers up front and used those exclusively. So rust's ownership model wouldn't even help there iiuc. I imagine most safety critical devices are similar?
None of this is to say that Rust will never be useful in a regulated context, but it has a lot of hurdles to jump.
Rust’s ownership model isn’t useful just for heap-allocated things; it’s useful for all kinds of other safety guarantees, such as preventing unnecessary mutability.
To elaborate on this, nothing about ownership or borrowing has anything directly to do with heap or stack allocation. Allocation fits into the ownership and borrowing rules, not the other way around.
Nice. Is it frequently used in contexts outside of allocation? I assume allocation is the primary use, or at least it's the most talked about, but I have never done anything complex in rust.
One example of where it's used: to enforce correct usage of mutexes. Rust's `Mutex<T>` owns the data it protects. When you lock the Mutex, you get a reference to the data inside it, but it's impossible (a compile-time error) to store a copy of the reference beyond the point where you release the lock.
Cool. So the fifth point is largely nullified, which is a big one -- that the features of Rust would at least be useful in typical safety-critical code.
The most common AFAIK would be when using iterators. An iterator borrows (or mutably borrows, or takes ownership of, depending on how it's called; iter() vs iter_mut() vs into_iter()) the original collection, so the original collection can't be modified while being iterated. This means no "ConcurrentModificationException" or similar (or worse, silent corruption) can happen.
"Linear type systems are the internal language of closed symmetric monoidal categories, much in the same way that simply typed lambda calculus is the language of Cartesian closed categories. More precisely, one may construct functors between the category of linear type systems and the category of closed symmetric monoidal categories." (Wikipedia)
So now the only question is where closed symmetric monoidal categories are applicable :P
I expect people who write low-level, security relevant things are in rather short supply and so they have a pretty hefty workload. Unfortunately, that leaves little room to explore and research new technologies. Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks.
> Moreover, very, very few people look to improve their efficiency by learning entirely new tech stacks.
I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right). Also not everybody sits in a fancy startup in the Bay-Area and has even the skills or time to adapt. Most developers sit in a big company that has been doing their stuff for 10+ years and are not very susceptible to change. As an anecdotal example, I recently talked to a company that could not figure out why they could not attract talent. They claimed "we are so innovative, we even adapted PostgreSQL". Before that they used csv as their "database".
Isn't your post a bit controversial? You're writing that 99% of the developers don't care about new technologies and then that some company who adapted PostgreSQL can't attract talents.
Or they are not happy with those 99% of candidates?
Okay when I reread it, I see your point. I used their wording, in fact they can't attract anyone but they used the word "talent" for anyone that can code.
> I firmly believe (against the common HN sentiment) that 99% of the developers do exactly 0 exploration of new technology and they couldn't care less (which is their good right).
Is it though? It certainly is and should be your right to use whatever tools or language you want for your hobby projects on your own time, but in a professional setting or for production products, I think there's an argument to be made that software developers should have significant constraints on the sorts of tools and languages they should be permitted to use (domain-specific of course).
You may be interested in the 'Sealed Rust' initiative by Ferrous Systems GmbH, which does aim to introduce some version of Rust to traditional 'safety-critical' domains - see https://github.com/ferrous-systems/sealed-rust/tree/master/p... for details. A lot of hard work is involved.
That is I assume a heavily regulated and standard-compliant industry. You can't just pick any language you want. Rust is obviously not certified for such use and I would assume they can only pick something that is.
Them never hearing about Rust does not really speak to anything.
These industrial projects tend to have a massive amount of inertia (which is probably a good thing overall, you don't want people to migrate your plane autopilot to React.js because it's fashionable) so it doesn't surprise me that experienced devs who only deal with these codebases and don't lurk on HN aren't exposed to Rust.
If your used to web technology standards Rust being stable since 2015 makes it a mature tool. Almost outdated really. On the other hand if at your work C99 is still new and shiny Rust is basically brand new tech which might be worth looking into in a few years. People who work on long term, critical projects want boring, reliable tools.
Sorry, but Rust is NOT ready for embedded work, yet. The Rust Embedded guys are making great strides and doing great work, but trying to shove Rust into a critical infrastructure piece right now would be counterproductive, anger a lot of people and likely set Rust back.
As much as I think Rust is a good thing, the breakpoint is when the big game development companies start using it. That will tell everybody that Rust is "good enough" for actual production work.
At my place of work we used to use Ada for most projects. In more recent years a move to C/C++ has been made.
Now the trend is towards model-based design, where toolsets such as Simulink or SCADE provide certified code generators or code checkers to remove most of the manual element of generating code from design.
Would love to be able to use Rust, but will need to wait for a COTS tool chain that provides certification evidence for DO-178C Level A. Sealed Rust looks to be going that way, but it's no small task.
The best language for systems like that is ADA, and it's commonly used in avionics and related systems
I like to think of Rust as "memory-safe C++ 2.0", but ADA was designed for general robustness. Types like integers can have a valid range assigned to them, etc...
To be a truly safe language for hard realtime or embedded purposes, Rust would need a lot of features added. Things like guaranteed maximum stack allocation for function call chains, a proper allocator system, dependent types, and integration with proof systems.
Some of that is partly there or being worked on, but there's a lot of gaps.
I also regularly see Rust releases with unsafety that can be triggered by safe code. The invariants are being checked (mostly) by hand and mistakes slip through.
Worse still, Rust has a tiny standard library, leaving the bulk of what's needed for real software up to the "community". Unfortunately, crates have highly variable quality (coughactixcough) and it's just not a good idea to build something like a jumbo jet's avionics based on L33tHax0r's AwesomeCrate, if you know what I mean.
This all goes back to an opinion I've had about programming language design for some years now: It has one of the highest returns on investment of any human endeavour imaginable. It's roughly comparable to the development of a new vaccine.
For every feature or quality improvement in a language and its standard library, tens of thousands of programmers benefit, and then billions of end-users benefit indirectly from their improved productivity and higher product quality. Conversely, low investment in the core language translates to enormous inefficiency as many developers are forced to reinvent the wheel. The users then suffer from the square wheels or the round wheels that sometimes fall off.
Rust is a low-investment language. Its standard library doesn't hold a candle to something like the JDK or the .NET Framework. For crying out loud, it doesn't natively do: dates, times, guids, decimal/money, TLS, HTTPS, XML, i18n, databases, or even half of what was included in .NET v1.0 back in 2002! They're working on async, which in a basic form was stable in .NET v1.1 (2003) and fully fledged in v4.5 (2012), three years before Rust v1.0!
All of those features are provided by crates. Some of which are maintained by one random guy. From Russia. Or China. Or wherever. Some of which have unnecessary unsafety. Some of which have poor design, or don't interop well. Or worse, there's several competing crates and now you have to pick. Or you pick the one that looks right and it's just a wrapper around the C++ library. (There was some guy who was just spamming these out and squatting on the "crate name", forcing the real Rust crates to use less discoverable names.)
I like Rust, I do. But answer me this simple question: How do I process XML with Rust?
Which of these many crates is the one that's equivalent to System.Xml in C#? Which one can handle encodings other than UTF-8? Which one can read and write? Which one can handle entities? Which one can validate? Against XSD and DTDs? Do they do XPath? XSLT? Yes? No? Maybe? Partial? Who the fuck knows?
Back in the year 2000 I was using Apache Xerces from C++ and then 2 years later with C# v1.0 I was using System.Xml and I could do everything. It's 2020 and I don't think half that list is available from Rust, with or without third party crates.
Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmaintained when he gets a Real Job?
> Even if I were to pick one that works now, who's to know that it wasn't written by some university student only to be dropped on the floor and become unmaintained when he gets a Real Job?
You do the same thing you would do in any language where you depend on third party code: you do your due diligence. If no XML library meets your needs, then write your own. If that's not an option, then the Rust ecosystem isn't ready for your use case. Pretty simple. But it's ready for a lot of other use cases.
This is my point, and I know it sounds absurd, but think of it in terms of a business deal, or a product, or any "transaction".
If you have two "individual entities" making a roughly equal transaction, such as a business merger, then I would agree: if one of the two parties is concerned with something, it's up to them to do their own due diligence.
But if you have a 1-to-many deal going on, this then becomes unbalanced. Imagine the "1" is Visa, or Mastercard, and the many are their millions of credit card users.
Imagine for a second Visa or MC saying: "It's up to the credit card holder to verify the cryptographic security of any POS devices, as well as the security of the merchant's banking IT system."
That's insane, right?
It's an extreme example, but it's the same concept as a language's standard library. Not every developer is in a position to evaluate the quality of a bazillion crates, their transitive dependencies, and all possible future interactions between them.
If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality.
Now take this a step further. If I'm a consumer of "some developer's" app, which I run on my PC, how do I as an end-user have any confidence at all that it's using secure, maintained crates?
What if I use multiple rust apps? Do I have to check every one, every month, and all their crates, and all their dependencies?
With something like .NET or Java, even in a sysadmin role, I can be reasonably confident that a) it's a secure framework, b) all parts of it, c) I can patch it myself it isn't, d) and I only have to check one framework for many apps.
This is like the most fundamental theory of the efficiency of transactions. M:N is inefficient, M:1:N is vastly more efficient.[1] That's why we have Uber, and governments, and Ebay, and Amazon. That's why we have banks. Because instead of standing on a city street corner asking random people for loans, there are institutions that take responsibility of verification for all parties and provides a guarantee of future safety.
With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie.
Languages like Rust and JavaScript are passing the buck. They're the BitCoins of banking, and about as popular or effective. For every transaction it's "you have to do your own research", but that's literally impossible for most users, so they get their wallets drained. Ooops. They should have known better, right?
Or they should have just used a bank.
[1] Consider that for popular languages, the ratios of the language designers : programmers : users is roughly 100:100K:5B, or 1:1K:50K, give or take an order of magnitude depending on the language. The "1" on the left passing the buck to the "1K" in the middle is one thousand times less efficient than having that work being done on the left. So every time I hear something like "Rust shouldn't include X, use a crate", it makes me grind my teeth a little.
You've spent a lot of words ranting, but you're not telling me anything I don't know. I specifically did not engage with most of your rant in your initial comment because it seemed like you weren't interested in discussing trade offs. It seems like you still aren't. For example, I don't see anywhere in your comments where you acknowledge the benefits of a small standard library. Instead, all you do is lament the costs. Which is fair, and is why I answered your question matter-of-factly.
> If some developer starts using "xml-rs" or whatever, and 3 years later the diesel crate uses "rust-xml", then he's in for a rewrite through no fault of his own. There is literally nothing he could have done to protect himself from this eventuality.
This kind of thing happens regardless of who builds the libraries.
> With languages like Java or C# I have to trust only Oracle or Microsoft. Literally just two evaluations, and I'm done. I pass on Oracle and accept the risk of Microsoft, and then get on with my programming task. Easy as pie.
Last time I checked, both Java and C# have rich open source ecosystems. So yeah, if you don't use anything from that ecosystem other than what is developed by Oracle or Microsoft themselves, then sure, you'll do a lot less due diligence there. You don't really need to write hundreds of words to make that point. If that's what's important to you, then sure, there's a lot of stuff in the open source ecosystem (including probably Rust, depending on what you're doing) that you just won't be able to take advantage of. Which is fine, not everyone has the same risk profile.
Technology like Rust doesn't have to be All Things to All People at All Times. In order to hit your use case, it probably needs a company or an established/respected organization to start taking responsibility for maintaining a lot of code. I don't see that happening any time soon, but it's not like it's fundamentally impossible for it to happen. I think it's more likely that others will figure out how to adapt their risk profiles, personally. But that's just speculation.
> acknowledge the benefits of a small standard library.
I don't though. The perceived benefits of a small standard library exist only in circumstances that then cause the language ecosystem to fail to meet my requirements. These are also the requirements of many similar people in similar shoes, and also include the requirements of specialist usage such as avionics and the like.
The advantage of a small standard library is that it keeps the workload for the language designers manageable when they don't have the manpower to keep a large library properly maintained. The failures of Python's batteries included was IMHO caused by the Python team not having corporate backing and proper funding, not an inherent issue with a large std lib per se.
Rust is a low-investment language like Python: they're not investing sufficiently on the "left hand side" of the transaction. The advantage of a lean std lib is only to them, a small number of people. This is not an advantage to me, the consumer of the language.
Now, I get it, Rust was born out of Mozilla, and they're not Apple or Microsoft or Google. But that's the problem. They need to be picked up by a mega corp like, say, Amazon's AWS team to get the funding they need to do things properly.
> Last time I checked, both Java and C# have rich open source ecosystems.
They didn't for the first decade or two of their existence, and they both owe their large, cohesive standard libraries to that era.
I lament the open sourcing of the .NET framework, because the quality and cohesiveness has plummeted. There are glaring inconsistencies and bugs being thrown over the fence that would have never have made it past the kind of formal code review that occurs at only at corporations.
> This kind of thing happens regardless of who builds the libraries.
That's just not true. If a central, organised, well-funded body writes the standard library, then there is a consistency and cohesion that can never be achieved with an open source community. This is literally the Cathedral vs The Bazaar.
If I use System.Data.SqlClient then I can be confident that it will use System.Xml to return XML fields stored in a database. It'll never use BobsXmlLib or something random like that. That's the benefit to me of an architecture versus an evolution.
> Technology like Rust doesn't have to be All Things to All People at All Times.
Right now, it's not much to not many people. Its popularity is growing, sure, but it has enormous gaps that normally would be filled by the core language team. Some gaps might be filled by the community, but it's going to take a long, long time. These gaps stop many people using the language for production development.
I'm not making up that XML library scenario as some sort of exercise. This is a real problem that I have, in Rust, right now. I wanted to translate a pure C# XLSX parser I write for PowerShell into a Rust library and tool vaguely like "xsv". Something fun to do while on the coronavirus break.
I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream.
In C# this was trivial, even using the API that dates back to the v1.1 days. It would have been trivial in Java and C++ as well. In Rust... ugh. I'll revisit this next year, see if the XML crates have grown some features, performance, and stabilised a bit.
When step #1 is to ponder over comparison tables like this where the only full-featured crate is written in C, not Rust, I lose interest, and this is for something that's just a hobby: https://github.com/RazrFalcon/roxmltree#alternatives
PS: I see comments in crates like this all the time: "vkxml has been made for use with serde-xml-rs and, because of some quirky attributes required by serde-xml-rs, most likely will not work with any other serde xml parser." From: https://crates.io/crates/vkxml
> These gaps stop many people using the language for production development.
Every language has gaps. Rust had a lot more gaps two years ago than it does now. It's called progress. I personally don't see your particular use case being addressed any time soon. Oodles of people don't need everything developed by a single entity. The success of the Javascript ecosystem should at least make that clear. I freely recognize that some do though.
> I'm not making up that XML library scenario as some sort of exercise.
I didn't say you were? Your comments are so bloated and you keep rehashing every single point.
> I got bogged down just trying to find an XML library that can handle OOXML in a standards compliant fashion, and is popular enough to be maintained going forward, and is consumable downstream
We already covered this. Why do you keep repeating it? I literally addressed this in my very first comment to you. And you're still complaining about it. Why?
I already told you: Rust doesn't have to be All Things to All People at All Times. Maybe instead of focusing on responding to that with some quip you think is clever, you could recognize it for what it is: an acknowledgment that Rust may not be ready for your use case. Why in the world is that so hard for you to accept? Like, this isn't rocket science. If you need a high quality XML parser, and Rust doesn't have one and you can't write one yourself, then the answer is pretty simple. The thousands of words you've had to write to express this point---and then repeat over and over---is just absolutely baffling.
If instead you needed, say, a high quality JSON parser, then we wouldn't be having this conversation at all. You probably would have used `serde_json` and you would have been as happy as a pig in shit.
> The advantage of a lean std lib is only to them, a small number of people.
Definitely not true. In the Python ecosystem, the mindshare split between things like the standard library HTTP client and more popular third party projects like `requests` impacts everyone.
> This is not an advantage to me, the consumer of the language.
Of course it is. As a member of the Rust library team, I can tell you with absolute confidence that we had three choices given our timeline: 1) build a small high quality standard library that serves as a substrate on which high quality third party crates could be built, 2) build a large but low quality standard library that would likely have large pieces of it deprecated in the future as better third party options became available or 3) don't ship at all. Neither (2) nor (3) would be good for users.
Now we could reverse course at this point and start bringing more into the standard library. I personally don't see that happening because our current strategy is working pretty well (bloviating HN commenters not withstanding). But sure, it could happen. You may be bloviating, but as I already acknowledged, having a big standard library definitely has its own benefits. You're right about that. Being able to trust one (or fewer) entities is a worthwhile proposition. But at this point of time, if that's what you need, then Rust isn't a good fit. I said this before too, and I don't know why you're still giving me shit about it. Why can't we be two reasonable people that accept reality and understand trade offs? "Oh yeah, that makes sense. I'll check back on Rust in a couple years then" would be a great reply. But no, instead I get speculation, rehashing previous points, more complaints and snide back-handed quips. I don't know why. Maybe you just needed an outlet to rant. Well, I'm not your personal punching bag, buddy. Back off.
The features that are very compelling is that installation is painless, static linking is encouraged and used widely and its APIs aren't tied to any specific platform, thus is a true cross-platform language done right. It would be better to compare it to C++ rather than C since they both interface and surpass the complexity of the language.
While the language is mature, the author fails to mention that most of the crates ecosystem is immature and some are unsafe. Especially in the domain the author is working in, there's a degree of risk in importing some crates which can compromise the safety of the project (use at your own risk).
Cross-compilation is there in Rust, it requires downloading the toolchain for the specific platform and Go has it truly built-in, so I'll give them that one. Lastly, it may be possible to use a cross-platform GUI library like gtk-rs, but it isn't widely adopted unlike Qt, Electron and Flutter. The question around that is whether if Rust is suitable for that use-case? As many ideas and crates for Rust GUI development are coming, for now I'd say soon.
The author is certainly bullish on Rust in general and in low-level development and so am I.