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
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.
I've switched to using Rust from Python simply because of AI development
Many things that would only be caught at runtime in other languages are caught at compile time in Rust, making coding agents iterate until things compile and work well.
Rust also has great error messages, which help the agents in fixing compilation errors.
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.
It's also as bad as C.
I'm saying that the chasm to cross is a safe ABI.
1) It can't be that replacing 20 C/C++ shared objects with 20 Rust shared objects results in 20 copies of the Rust standard library and other dependencies that those Rust libraries pull in. But, today, that is what happens. For some situations, this is too much of a memory usage regression to be tolerable.
2) If you really have 20 libraries calling into one another using C ABI, then you end up with manual memory management and manual buffer offset management everywhere even if you rewrite the innards in Rust. So long as Rust doesn't have a safe ABI, the upside of a Rust rewrite might be too low in terms of safety/security gained to be worth doing
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
Wait, Rust can already communicate using the C ABI. In fact, it offers exactly the same capabilities as C++ in this regard (dynamic linking).
I was addressing this portion of your comment: "C's ABI and dynamic linking are the thing that enables the software to get huge". If the C ABI is what enables software to get huge then Rust is already there.
There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now.
> There is a second claim in your comment about a "safe ABI", but that is something that neither C or C++ offers right now.
Of course C and C++ are no safer in this regard. (Well, with Fil-C they are safer, but like whatever.)
But that misses the point, which is that:
- It would be a big deal if Rust did have a safe dynamic linking ABI. Someone should do it. That's the main point I'm making. I don't think deflecting by saying "but C is no safer" is super interesting.
- So long as this problem isn't fixed, the upside of using Rust to replace a lot of the load bearing stuff in an OS is much lower than it should be to justify the effort. This point is debatable for sure, but your arguments don't address it.
I think you're moving the goalposts significantly here.
E.g. the kernel wouldn't really benefit from a "safe ABI" because users calling into the kernel need to be considered malicious by default.
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.
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.
As a C++ developer, I regularly deal with people that think creating a compiled object file and throwing away the source code is acceptable, or decide to hide source code for "security" while distributing object files. This makes my life hell.
Rust preventing this makes my life so much better.
I mean yeah that's bad.
> Rust preventing this makes my life so much better.
I'm talking about a different issue, which is: how do you create software that's in the billions of lines of code in scale. That's the scale of desktop OSes. Probably also the scale of some other things too.
At that scale, you can't just give everyone the source and tell them to do a world compile. Stable ABIs fix that. Also, you can't coordinate between all of the people involved other than via stable ABIs. So stable ABIs save both individual build time and reduce cognitive load.
This is true even and especially if everyone has access to everyone else's source code
In some sense, the chasm I'm describing hasn't been crossed by C++ yet
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 there's no recourse.
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.
https://github.com/canonical/firefox-snap/blob/90fa83e60ffef...
Can't wait for this Rust clown show house of cards to collapse. Imagine a mechanic throwing out all his tools en masse to replace them with trendy new ones. This entire movement is driven by emotions and impulses, immature programmers who don't grasp the concept of leaving done software alone.
You should never trust a mechanic with shiny new tools.
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.
UI_at_80x24•1h ago
A lot of bug fixes/exploits are _CAUSED_ by the C+ core, but still... Tried & true vs new hotness?
bbkane•1h ago
UI_at_80x24•1h ago
rg, fzf, and several others that I can't think have proven to me that rust is the direction going forward.
petcat•1h ago
It seems like Rust is now just the default in all manner of critical systems.
0x457•39m ago
giancarlostoro•1h ago
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.
9rx•1h ago
throw384748•57m ago
Rust will be "repeatedly tried and tested" maybe in year 2040!
umanwizard•50m ago
Neither do most programming languages.
> You are lucky if current version, compiles two years old code!
That's not true.
Wobbles42•44m ago
Rust is trying to replace C++ and C in particular. Those languages have specifications.
Iridescent_•49m ago
umanwizard•43m ago
In C or C++, this isn't supposed to happen: a conformant implementation claiming to support e.g. C++17 would use ifdefs to gate off new C++20 library functions when compiling in C++17 mode.
ChadNauseam•27m ago
jjmarr•17m ago
mamcx•46m ago
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.