Rustaceans at the border [LWN.net]

Rustaceans at the border

Posted Apr 15, 2022 11:30 UTC (Fri) by fazalmajid (guest, #158016)
In reply to: Rustaceans at the border by q_q_p_p
Parent article: Rustaceans at the border

Totally agree. The Rust project’s cavalier attitude to language and compiler stability, the absurd compiler bootstrapping and limited platform support makes it throughly unsuitable for the Linux kernel., and that’s also why I won’t touch it despite the many benefits. Not to mention their belief that “curl something}bash” is acceptable practice.

to post comments

Rustaceans at the border

Posted Apr 15, 2022 12:51 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (11 responses)

> The Rust project’s cavalier attitude to language and compiler stability

I'm curious: What's "cavalier" about their attitude to language and compiler stability at this time?

For this question, I'm only interested in claims backed by concrete examples, relating to officially designated stable features of the compiler and language, postdating version 1.0 of the toolchain.

Rustaceans at the border

Posted Apr 15, 2022 18:14 UTC (Fri) by nix (subscriber, #2304) [Link] (10 responses)

Oh yeah, the system in which things are tested under nightly feature guards, getting stabilized and available to ordinary code only when ready, and only then broken if unsound or after an edition change (and the old versions continue to work under older editions), and the way that feature additions are validated against all of crates.io to make sure they don't break things before going in... it's just so totally cavalier! Nothing like the elegant and refined C world, where, say, the introduction into POSIX of getline() and its consequent promotion into the _POSIX_C_SOURCE glibc feature flag (formerly it was only visible under _GNU_SOURCE) could not possibly break dozens of unrelated packages that just happened to use that as an identifier with no way to fix it other than to change all of them.

(That's not to say Rust can't improve. My personal if-wishes-were-unicorns perfect-world wish: if Rust grew the same amazing system Swift has to allow generic types with a stable ABI without heaps of monomorphization code bloat, that would be fabulous. It is an incredibly intricate system though, so I can see why it hasn't happened, at least not yet: it certainly can't be used unchanged but would need some redesign, and I'm not even sure this is possible. I know others have mused about this before, because Rust's lack of a nice way to do the shared library stable-ABI thing is probably its biggest remaining downside compared to other, lesser languages like C. C++, of course, has the exact same flaw, but unlike Rust it's much harder to apply the same cunning Swift tricks to it.)

Rustaceans at the border

Posted Apr 15, 2022 19:05 UTC (Fri) by LoganDark (guest, #158019) [Link] (2 responses)

At least C++ has the benefit of "well USUALLY if you use the same C++ compiler it's compatible with pretty much all C++ libraries compiled by that compiler". Sometimes it's even compatible with other compilers. With Rust it's "the ABI is 100% undefined and changes basically every commit, you can't use generic types at all because they're not present at all in the library", etc.

At least Rust has the ability to declare C functions.

Rustaceans at the border

Posted Apr 15, 2022 22:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I see you've never used binary-only C++ libs.

Rustaceans at the border

Posted Apr 17, 2022 21:56 UTC (Sun) by bartoc (guest, #124262) [Link]

That Usually is because of monumental sacrifices in implementation quality (I am a C++ standard library maintainer). A regex that is slower than spinning up a java vm, doing the regex, and then shutting it down. A hash table that is 2x slower than it should be. An insane work stealing thread implementation that just exists to get around big kernel locks that were removed 20 years ago. A mutex that is huge and deadlocks under resource starvation. A buffered IO stream that buffers like 16 characters. A deque (linked list of buckets) with a bucket size optimized for caches from 1995. A span type that is always passed on the stack because we forgot to add the attribute to say we want the sane ABI, the one we cant make the default because that would break ABI. The only data structures that are pretty OK are the vector and the r-b tree. The lists are not horrible either, but “generic” linked lists are not terrifically useful things.

The ability to provide a stable ABI is great, but C++ has gotten into a position where the first “real” release of your library has a stable ABI and boy is that not a good thing.

Even with all the care that we take not to break abi we still break it accidentally in subtle ways from time-to-time, as do other implementations. The way C++ libraries are designed and the way the standard library in particular is specified are at complete odds with the ability to make any kind of future changes without breaking ABI. You can do such libraries, but they look like Qt, POCO, or a COM library rather than your typical boost/standard library.

Swift gets this very much right. I wish it integrated with a jit of some kind to allow slowly migrating to the “unstable abi” versions of stuff though (and switching back when the dependency changes)

Fun tidbit: I recall that for Windows Phone 7 apps were distributed as bytecode in the compiler’s intermediate format and compiled to a final executable on the phone during installation.

Rustaceans at the border

Posted Apr 17, 2022 10:35 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

> If Rust grew the same amazing system Swift has to allow generic types with a stable ABI without heaps of monomorphization code bloat, that would be fabulous

It's not just Swift. Ada uses similar system, too. And it supported it for much, much, MUCH longer.

> it certainly can't be used unchanged but would need some redesign, and I'm not even sure this is possible

Rust-the-language is certainly strict enough to support it. Rustc-the-compiler… nope.

This would be a multi-year effort and someone has to fund it. But it's definitely possible and I really wish someone would fund it.

Sadly Google is not one who needs or wants such a thing (they use static linking, mostly), Apple already has Swift… who can fund it, I wonder? Maybe Microsoft?

But yeah, it would be a nice and elegant solution for the stable ABI. Rust developers are thinking about small, very limited subset, but I really wish someone would fund development of real, polymorphic traits instead.

Rustaceans at the border

Posted Apr 19, 2022 10:40 UTC (Tue) by farnz (subscriber, #17727) [Link]

Amazon are the other entity that might choose to fund it - they're getting heavily into Rust as a language for AWS, and having a stable ABI for a Rust AWS Lambda runtime would be a neat thing.

Rustaceans at the border

Posted Apr 25, 2022 5:34 UTC (Mon) by ras (subscriber, #33059) [Link] (4 responses)

> cunning Swift tricks

Is there anywhere I can read about what these cunning Swift for generic are?

Rustaceans at the border

Posted Apr 25, 2022 10:54 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

There was an article that seemed to be by one of the devs that I had read, but I can't find it anymore (Firefox seems to expire history now…). Here's one I found that describes it; it may have a link to the "original" I'm thinking of.

https://gankra.github.io/blah/swift-abi/

Rustaceans at the border

Posted Apr 25, 2022 22:00 UTC (Mon) by ras (subscriber, #33059) [Link] (1 responses)

That was a good read.

Nothing particularly remarkable in how it's done. Generous use of vtables, thunks converting parameters by coping them, putting the return value on the heap. (I wonder if they considered a separate return value stack?) Thunks in vtables is novel - I haven't seen that before

But mostly it's stuff we've all done manually at some point. Android's compatibility libraries are the same thing done manually, on steroids. Is the major difference is seems to be Swift does it by default, making it automagic it with some nice tooling?

Rustaceans at the border

Posted Apr 26, 2022 13:03 UTC (Tue) by nix (subscriber, #2304) [Link]

Exactly. Because it's automatic it's everywhere. If it's only done manually you end up with only a few foundational libraries with stable ABIs, and an ecosystem that more or less doesn't use shared libs at all. If it's automatic you get pervasive sharing.

Rustaceans at the border

Posted Apr 26, 2022 13:01 UTC (Tue) by nix (subscriber, #2304) [Link]

That's the one I was thinking of too but for some reason couldn't find anywhere in my browser history. Thanks!