Dynamic linking with a safe ABI, where if you change and recompile one library then the outcome has to obey some definition of safety, and ABI stability is about as good as C or Objective-C or Swift.
Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.
> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.
Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).
C++ ABI stability is the main reason improvements to the language get rejected.
You cannot change anything that would affect the class layout of something in the STL. For templated functions where the implementation is in the header, ODR means you can't add optimizations later on.
Maybe this was OK in the 90s when companies deleted the source code and laid off the programmers once the software was done, but it's not a feature Rust should ever support or guarantee.
The "stable ABI" is C functions and nothing else for a very good reason.
I think if Rust wants to evolve even more aggressively than C++ evolves, then that is a chasm that needs to be crossed.
In lots of domains, having a language that doesn't change very much, or that only changes very carefully with backcompat being taken super seriously, is more important than the memory safety guarantees Rust offers.
What's the stat of single-compiler version ABI? I mean - if the compiler guaranteed that for the same version of the compiler the ABI can work, we could potentially use dynamic linking for a lot of things (speed up iterative development) without committing to any long term stable API or going through C ABI for everything.
Dynamic linking is also great for compile time of debug builds. If a large library or application is split up into smaller shared libraries, ones unaffected by changes don't need to be touched at all. Runtime dynamic linking has a small overhead, but it's several orders of magnitude faster than compile-time linking, so not a problem in debug builds.
for developer turnaround time, it is huge. we explicitly do not statically link Ardour because as developers we are in the edit-compile-debug cycle all day every day, and speeding up the link step (which dynamic linking does dramatically, especially with parallel linkers like lld) is a gigantic improvement to our quality of life and productivity.
I found c ABI a bit too difficult in rust compared to c or zig. Mainly because of destructors. I am guessing c++ would be difficult in a similar way.
Also unsafe rust has always on strict-aliasing, which makes writing code difficult unless you do it in certain ways.
Having glue libraries like pyo3 makes it good in rust. But that introduces bloat and other issues. This has been the biggest issue I had with rust, it is too hard to write something so you use a dependency. And before you know it, you are bloating out of control
Not really. The foreign ABI requires a foreign API, which adds friction that you don't have with C exporting a C API / ABI. I've never tried, but I would guess that it adds a lot of friction.
COM is interesting as it implements interfaces using the C++ vtable layout, which can be done in C. Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.
You can also access .NET/C# objects/interfaces via COM. It has an interface to allow you to get the type metadata but that isn't necessary. This makes it possible to e.g. get the C#/.NET exception stack trace from a C/C++ application.
One particular chasm to keep an eye on, possibly even more relevant than Ubuntu using Rust: When it comes to building important stuff, Ubuntu sticks to curl|YOLO|bash instead of trusting trust in their own distributions.
When people say "curl|bash", this usually means secondary fetches, random system config changes, likely adding stuff to user's .bashrc
But it's not quite that bad in this particular case - they are fetching pre-built static toolchain, and running old-school install script, just like in 1990s. The social convention for those is quite safer.
(Although I agree, it is pretty ironic that they prefer this to using ppa or binary packaged into deb...)
In practice, very rarely. Lots of 'curl | sh' do secondary fetches, and those don't come with hash checks. And even if they come with hash checks _today_, there is no guarantee next version won't quietly remove them.
Aren't the versions of Rust in stable Linux distributions like, a century old? Or at least they were last I checked what Debian and Ubuntu LTS were distributing. I think it's because they don't like static linking.
I think an issue hindering Rust adoption is ecosystem immaturity. So many crates are pre-1.0, or just basic wrappers around a C library. There are good crates for core things like cryptography, but finding something production-ready for something like SAML is tough.
Unrelated to the language debate, but it seems a lot of people here missed the fact that Rust Coreutils project is licensed under MIT, and I am not sure if I feel that it is the appropriate license for such project. As much as FSF's philosophy has bad PR at times with Stallman, the GPL licenses really do protect open source. Who knows what Canonical would do when all parts of Ubuntu become MIT...
They did, until the automatic copyright laundering machine was invented. Pretty much every piece of GPL code ever written is now being magically transmuted into MIT/BSD or proprietary code, and the FSF has no solution.
A discussion on licenses will go sideways very quickly. GPL does limit the adoption of software in certain environments. So it really depends on your goals. Do you want an OSS project that will be useable by everyone (including corporations) or do you want to guarantee that the software will always be OSS and guarantee that Corporations can’t benefit from it without contributing back (potentially requiring them to open their own proprietary code).
There’s a lot of moral perspective that people apply to this decision, but not all developers have the same goals for their software. MIT is more flexible in its use than GPL, but doesn’t help ensure that software remains open.
Really good references to "crossing the chasm" between early adopter needs and mainstream needs. In addition to the Ubuntu coreutils use case, I wonder what other chasms Rust is attempting to cross. I know Rust for Linux (though I think that's still relegated to drivers?) and automotive (not sure where that is).
If you want to take a look at some of the "big drivers", the Project Goals[1] is the right place. These are goals proposed by the community and the language developers put together, they are not explicit milestones or must-haves, but they do serve as a guideline to what the project tries to put its time and effort on.
There are big pushes in pretty much every direction. The projects that really stand out to me are pyo3 (Replace c++ python modules with rust), Dioxus (react-like web framework), The ferrocine qualified compiler (automotive)
I think right now the ecosystem is pretty ripe and with DARPA TRACTOR there are only more and more reasons every day to put rust on your toolbelt.
I am secretly hoping that eventually we break free from the cycle of "hire a senior dev and he likes rust so the company switches" over to hey let's hire some good mid-level and junior rust developers
Are mid level and junior developers being hired anywhere for any reason right now? I don't mean specifically rust developers. I mean software developers.
The author refers to a few things that he thinks will appeal to the "early majority," but I feel like that's a weakness of the article. Is the author part of the "early majority?" (doesn't seem like it). Does he have the same problems that they have? How does he know?
.NET has a _huge_ platform library and you know what? It’s a pleasure. So many things are just the standard way of doing things. When things are done weirdly, you can usually get a majority in favour of standardising it.
Yes, there’s always a couple of people who really push the boat out…
I've been a fan of all rust-based utilities that I've used. I am worried that 20+ (??) years of bug fixes and edge-case improvements can't be accounted for by simply using a newer/better code-base.
A lot of bug fixes/exploits are _CAUSED_ by the C+ core, but still... Tried & true vs new hotness?
I do get what you mean, but Rust has been baking for a decade, finally took off after 10 years of baking, and now that is been repeatedly tried and tested it is eating the world, as some developers suggested it could eventually do so. I however do think this shows a different problem:
If nobody writes unit tests, how do you write them when you port over projects to ensure your new language doesn't introduce regressions. All rewrites should be preceded by strong useful unit tests.
Ideally, but if a project wasn't written with tests at the time then finding a working time machine can be a challenge. If you try to add them later you won't capture all the nuance that went into the original program. After all, if the implementation code was expressive enough to capture that nuance, you'd already have your test suite, so to speak. Tests are written to fill in the details that the rest of the code isn't able to express.
> years of bug fixes and edge-case improvements can't be accounted for by simply using a newer/better code-base.
Partially is in fact true: Just because the Rust use a better type system (after ML) + better resource model (aka borrow checker), and if you are decently good, you eliminate, forever!, tons of problems.
It can't solve things that arise by complex interactions or just lack of port subtle details like in parsing poor inputs (like html) but is true that changing the language in fact solve tons of things.
> Jon made the provocative comment that we needed to revisit our policy around having a small standard library. He’s not the first to say something like that, it’s something we’ve been hearing for years and years
It sounds to me like you "cross the chasm" a little too early. As a user I don't care about your "chasms" I care about high quality durable systems. This isn't the first time I've heard the "we'll change the std lib later" logic. I've yet to see it actually work.
Most of the platforms were successfully petitioned to have rust sdk mandatory added so that rust code can be added to the platforms. The previously situation was rust was not allowed because the external dependency of the rust sdk was blocked.
Note that the rust having no stable api is not fixed, so I think there's a bunch of internal systems on each platform to hard lock the rust dependencies across multiple rust users.
There's some friction between platform packagers and the code that the author wrote exactly as it was written.
Indeed. With AI lifting legacy code bases into Rust got a whole lot easier, and purging the blight of C from the world, excepting the most deeply embedded of applications, got a whole lot closer.
Really? You think AI writes better Rust than Python? Can you give me some examples? I strictly code Django, and Claude Code is really good at following my lead with it.
I don't care that the non-gnu coreutils are using rust. I care that they aren't GPL licensed.
This means Canonical can offer proprietary patches on top of these packages and sell them as part of their "enterprise" offerings and this gives me the ick.
Here's the chasm I want to see Rust cross:
Dynamic linking with a safe ABI, where if you change and recompile one library then the outcome has to obey some definition of safety, and ABI stability is about as good as C or Objective-C or Swift.
Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.
> Until that happens, it'll be hard to adopt Rust in a lot of C/C++ strongholds where C's ABI and dynamic linking are the thing that enables the software to get huge.
Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).
That's an unsafe ABI.
C++ ABI stability is the main reason improvements to the language get rejected.
You cannot change anything that would affect the class layout of something in the STL. For templated functions where the implementation is in the header, ODR means you can't add optimizations later on.
Maybe this was OK in the 90s when companies deleted the source code and laid off the programmers once the software was done, but it's not a feature Rust should ever support or guarantee.
The "stable ABI" is C functions and nothing else for a very good reason.
I think if Rust wants to evolve even more aggressively than C++ evolves, then that is a chasm that needs to be crossed.
In lots of domains, having a language that doesn't change very much, or that only changes very carefully with backcompat being taken super seriously, is more important than the memory safety guarantees Rust offers.
What's the stat of single-compiler version ABI? I mean - if the compiler guaranteed that for the same version of the compiler the ABI can work, we could potentially use dynamic linking for a lot of things (speed up iterative development) without committing to any long term stable API or going through C ABI for everything.
The big question is does Rust want to play being adopted by those vendors, or it would leave them alone with languages that embrace native libraries.
Dynamic linking is also great for compile time of debug builds. If a large library or application is split up into smaller shared libraries, ones unaffected by changes don't need to be touched at all. Runtime dynamic linking has a small overhead, but it's several orders of magnitude faster than compile-time linking, so not a problem in debug builds.
for developer turnaround time, it is huge. we explicitly do not statically link Ardour because as developers we are in the edit-compile-debug cycle all day every day, and speeding up the link step (which dynamic linking does dramatically, especially with parallel linkers like lld) is a gigantic improvement to our quality of life and productivity.
The C ABI can already be used, it comes with all the existing safety guarantees that C will provide. Isn’t this as good as C?
It is as good as C.
It's also as bad as C.
I'm saying that the chasm to cross is a safe ABI.
I found c ABI a bit too difficult in rust compared to c or zig. Mainly because of destructors. I am guessing c++ would be difficult in a similar way.
Also unsafe rust has always on strict-aliasing, which makes writing code difficult unless you do it in certain ways.
Having glue libraries like pyo3 makes it good in rust. But that introduces bloat and other issues. This has been the biggest issue I had with rust, it is too hard to write something so you use a dependency. And before you know it, you are bloating out of control
Not really. The foreign ABI requires a foreign API, which adds friction that you don't have with C exporting a C API / ABI. I've never tried, but I would guess that it adds a lot of friction.
Indeed, Victor Ciura from Microsoft DevDiv has several talks on how this is currently an adoption problem at Microsoft.
They have been working around it with DLLs, and COM/WinRT, but still the tooling isn't ideal.
COM is interesting as it implements interfaces using the C++ vtable layout, which can be done in C. Dynamic COM (DCOM) is used to provide interoperability with Visual Basic.
You can also access .NET/C# objects/interfaces via COM. It has an interface to allow you to get the type metadata but that isn't necessary. This makes it possible to e.g. get the C#/.NET exception stack trace from a C/C++ application.
One particular chasm to keep an eye on, possibly even more relevant than Ubuntu using Rust: When it comes to building important stuff, Ubuntu sticks to curl|YOLO|bash instead of trusting trust in their own distributions.
https://github.com/canonical/firefox-snap/blob/90fa83e60ffef...
When people say "curl|bash", this usually means secondary fetches, random system config changes, likely adding stuff to user's .bashrc
But it's not quite that bad in this particular case - they are fetching pre-built static toolchain, and running old-school install script, just like in 1990s. The social convention for those is quite safer.
(Although I agree, it is pretty ironic that they prefer this to using ppa or binary packaged into deb...)
I don't get it. What's the chasm here?
You can curl stuff and run it just gotta have hashes in place.
In theory, yes.
In practice, very rarely. Lots of 'curl | sh' do secondary fetches, and those don't come with hash checks. And even if they come with hash checks _today_, there is no guarantee next version won't quietly remove them.
Aren't the versions of Rust in stable Linux distributions like, a century old? Or at least they were last I checked what Debian and Ubuntu LTS were distributing. I think it's because they don't like static linking.
Hasn’t the right way to install rust has always been using rust up? I am an Ubuntu user and never once tried apt for rust.
I think an issue hindering Rust adoption is ecosystem immaturity. So many crates are pre-1.0, or just basic wrappers around a C library. There are good crates for core things like cryptography, but finding something production-ready for something like SAML is tough.
Unrelated to the language debate, but it seems a lot of people here missed the fact that Rust Coreutils project is licensed under MIT, and I am not sure if I feel that it is the appropriate license for such project. As much as FSF's philosophy has bad PR at times with Stallman, the GPL licenses really do protect open source. Who knows what Canonical would do when all parts of Ubuntu become MIT...
> the GPL licenses really do protect open source.
They did, until the automatic copyright laundering machine was invented. Pretty much every piece of GPL code ever written is now being magically transmuted into MIT/BSD or proprietary code, and the FSF has no solution.
A discussion on licenses will go sideways very quickly. GPL does limit the adoption of software in certain environments. So it really depends on your goals. Do you want an OSS project that will be useable by everyone (including corporations) or do you want to guarantee that the software will always be OSS and guarantee that Corporations can’t benefit from it without contributing back (potentially requiring them to open their own proprietary code).
There’s a lot of moral perspective that people apply to this decision, but not all developers have the same goals for their software. MIT is more flexible in its use than GPL, but doesn’t help ensure that software remains open.
What evil deeds are you worried about in particular? What are you afraid people will do now that coreutils is MIT?
Just today I found that rust-coreutils makes installing cuda toolkit impossible, related to use of `dd`: https://forums.developer.nvidia.com/t/cuda-runfile-wont-extr...
Do you have more details? The thread you linked was about gzip, not dd.
The .run file is a shell script with a compressed archive appended:
Where Edit: this is apparently packaged with Makeself, and various sources report issues with rust-coreutils. For example https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...Really good references to "crossing the chasm" between early adopter needs and mainstream needs. In addition to the Ubuntu coreutils use case, I wonder what other chasms Rust is attempting to cross. I know Rust for Linux (though I think that's still relegated to drivers?) and automotive (not sure where that is).
If you want to take a look at some of the "big drivers", the Project Goals[1] is the right place. These are goals proposed by the community and the language developers put together, they are not explicit milestones or must-haves, but they do serve as a guideline to what the project tries to put its time and effort on.
[1]: https://rust-lang.github.io/rust-project-goals/
There are big pushes in pretty much every direction. The projects that really stand out to me are pyo3 (Replace c++ python modules with rust), Dioxus (react-like web framework), The ferrocine qualified compiler (automotive)
I think right now the ecosystem is pretty ripe and with DARPA TRACTOR there are only more and more reasons every day to put rust on your toolbelt.
I am secretly hoping that eventually we break free from the cycle of "hire a senior dev and he likes rust so the company switches" over to hey let's hire some good mid-level and junior rust developers
Are mid level and junior developers being hired anywhere for any reason right now? I don't mean specifically rust developers. I mean software developers.
The author refers to a few things that he thinks will appeal to the "early majority," but I feel like that's a weakness of the article. Is the author part of the "early majority?" (doesn't seem like it). Does he have the same problems that they have? How does he know?
He is the Rust project lead, and the Rust project has been doing quite a bit of user, adopter, and non-adopter interviews over the past few years.
.NET has a _huge_ platform library and you know what? It’s a pleasure. So many things are just the standard way of doing things. When things are done weirdly, you can usually get a majority in favour of standardising it.
Yes, there’s always a couple of people who really push the boat out…
I've been a fan of all rust-based utilities that I've used. I am worried that 20+ (??) years of bug fixes and edge-case improvements can't be accounted for by simply using a newer/better code-base.
A lot of bug fixes/exploits are _CAUSED_ by the C+ core, but still... Tried & true vs new hotness?
Don't hate me for this, but... is 20 years of Rust really new?
https://en.wikipedia.org/wiki/Rust_(programming_language)
I do get what you mean, but Rust has been baking for a decade, finally took off after 10 years of baking, and now that is been repeatedly tried and tested it is eating the world, as some developers suggested it could eventually do so. I however do think this shows a different problem:
If nobody writes unit tests, how do you write them when you port over projects to ensure your new language doesn't introduce regressions. All rewrites should be preceded by strong useful unit tests.
But the 90s was only 20-years ago!
lol, you got me. Stupid old brain not calculating time correctly.
Ideally, but if a project wasn't written with tests at the time then finding a working time machine can be a challenge. If you try to add them later you won't capture all the nuance that went into the original program. After all, if the implementation code was expressive enough to capture that nuance, you'd already have your test suite, so to speak. Tests are written to fill in the details that the rest of the code isn't able to express.
Rust does not even have a specification, and stable release yet! You are lucky if current version, compiles two years old code!
Rust will be "repeatedly tried and tested" maybe in year 2040!
> years of bug fixes and edge-case improvements can't be accounted for by simply using a newer/better code-base.
Partially is in fact true: Just because the Rust use a better type system (after ML) + better resource model (aka borrow checker), and if you are decently good, you eliminate, forever!, tons of problems.
It can't solve things that arise by complex interactions or just lack of port subtle details like in parsing poor inputs (like html) but is true that changing the language in fact solve tons of things.
I think it's worth trying!
It absolutely is worth trying. I look forward to it being battle tested and proven. I just don't want to be the one doing the testing.
rg, fzf, and several others that I can't think have proven to me that rust is the direction going forward.
Is Rust still considered "new hotness"? I feel like the industry has long-since moved past that perceived "blocker".
It seems like Rust is now just the default in all manner of critical systems.
Rust - no. sudo-rs not hotness, but relatively new.
Sudo no longer supporting path inheritance kinda sucks
> Jon made the provocative comment that we needed to revisit our policy around having a small standard library. He’s not the first to say something like that, it’s something we’ve been hearing for years and years
It sounds to me like you "cross the chasm" a little too early. As a user I don't care about your "chasms" I care about high quality durable systems. This isn't the first time I've heard the "we'll change the std lib later" logic. I've yet to see it actually work.
a few weeks ago it was all about Zig, now it's all about Rust, Clojure or Elixir next?
Rust was first
Why am I hearing about Rust a lot these days? Did anything significant happen?
What do you mean by “these days”? To me, it seems like rust is a pretty constant factor on HN for at least two years now.
Most of the platforms were successfully petitioned to have rust sdk mandatory added so that rust code can be added to the platforms. The previously situation was rust was not allowed because the external dependency of the rust sdk was blocked.
Note that the rust having no stable api is not fixed, so I think there's a bunch of internal systems on each platform to hard lock the rust dependencies across multiple rust users.
There's some friction between platform packagers and the code that the author wrote exactly as it was written.
there has been a few adopters of rust... linux formally choosing it for some of their systems being the most notable recently(maybe a few months ago).
AI has made it exceptionally easy to program with.
I've switched to using Rust from Python simply because of AI development
Indeed. With AI lifting legacy code bases into Rust got a whole lot easier, and purging the blight of C from the world, excepting the most deeply embedded of applications, got a whole lot closer.
Really? You think AI writes better Rust than Python? Can you give me some examples? I strictly code Django, and Claude Code is really good at following my lead with it.
I don't care that the non-gnu coreutils are using rust. I care that they aren't GPL licensed.
This means Canonical can offer proprietary patches on top of these packages and sell them as part of their "enterprise" offerings and this gives me the ick.