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?
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).
Rust is undoubtedly excellent. What tarnishes the picture is a small group of people that rewrite solid pieces of code into Rust, hijacking the original brand names (eg. "sudo") for the sole purpose of virtue signaling. And the later is why the come after the most stable pieces of software that warrant no rewrite at all, like coreutils.
It seems to me that the right approach would be to ignore those and still love Rust for what nice of a language it is.
Unfortunately, Ubuntu is all in on virtue signaling.
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.
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.
Eh, some people can work on moving to Rust, while others work on adding dynamic linking to Rust.
Or maybe we can some how get used to living with static linking. (I don't think so, but many seem to think so in spite of my advice to the contrary!)
Another possibility is to use IPC as the dynamic linking boundary of sorts, but this will consume lots more memory, and as is stated elsewhere in this thread, memory ain't cheap no more.
That would be great, but Rust relies on compile-time monomorphization for efficiency (very much like C++, if you consider templates polymorphic functions/classes).
This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider the usage of the "shape" of all parameters of a function.
There is absolutely nothing "pro-business" about permissive licenses. People choose permissive licenses for all kinds of reasons. For example, I personally use them because I believe they are more free and thus more in line with my values. You shouldn't project unsubstantiated statements onto people's motives like this.
There is no need for rust coreutils existence, thus one of the first things to do with a fresh ubuntu (like removing transparent peels on new devices) is to install the real coreutils, sudo and the rest.
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...
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.
> 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.
> This isn't the first time I've heard the "we'll change the std lib later" logic.
I'm not sure what this is referring to, but surely it's not referring to Rust. Adding things to the stdlib is way easier than "changing" the stdlib. And Rust adds stuff to the stdlib all the time, like, go read any blog post for a new release and see that there are usually 10+ new additions to the stdlib, which adds up to hundreds of new additions per year due to the six-week release schedule.
.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…
Yeah, IMO the small standard library in Rust is a big mistake, one of the few the language has made. When push comes to shove the stdlib is the only thing you can count on always being there. It's incredibly valuable to have more tools in the stdlib even if they aren't the best versions out there (for example, even if I normally use requests in Python urllib2 has saved my bacon before), and it doesn't hurt anything to have them there.
Non-system programmers like to trivialize choices of system programmers yet again. .NET is a GC platform running on a virtual machine. Bytecode compatibility and absolute performance are not that big of a deal on such platforms. You cannot / shouldn't run .NET on deeply embedded systems and bare metal where You want to strip as much standard library as possible and want as little magic in standard library as possible. In a language with big hosted system assumption this causes to runtime to be split and forces developers to define big API boundaries.
The use case of languages like Rust and C++ is that you can use the same compiler to write both bare-metal unhosted code (non-std for bootloaders, microcontrollers and kernels) and hosted code (uses std structures). As a system programmer that crosses the edge between two environments, I would like to share as much code as possible. Having a big standard library with hosted system assumption is a huge issue. In those cases you want the language works 99% the same and can use the same structs / libraries. Sometimes you also want to write non-std code on hosted environments for things like linkers.
Rust isn't even at the level of maturity of C yet in this regard. Rust's std / core is too big for really memory limited microcontrollers (<64 K space) and requires nasty hacks with weak ABI symbols to make things sane.
Having a huge baggage of std both causes issues like this for the users and also increases maintenance burden of the maintainers. Rust really wants to break its APIs as little as possible and small standard library is a great way to achieve that. C++ suffered a lot from this and it hampered its adoption for C codebases.
Some of these non-system programmers are ex-system programmers, coding since the mid-80's that foundly remember the days when C and C++ compilers had rich frameworks that would compete in features with what .NET and Java later came to be.
Unfortunelly too many modern system programmers never lived in that era, and are completly off on how nice the whole development experience could be like.
I think those two things are orthogonal. I'm not against somebody bundling up nice Rust libraries and providing a pre-install package or providing nice GUIs around (like Borland used to do and Qt still kind of does). Or an OS providing a nice set of libraries.
However, the standard library of a systems language has a special relationship with the compiler. This is the case for C and C++ where the compiler and the standard library also has a special relationship with the platform like GNU or musl with Linux, or MSVC and Windows. It makes changing APIs or modernizing infrastructure almost impossible without creating an entire new OS and porting all compilers and standard libraries to it. Moreover the newer C++ standards actually force you to define such a relationship (with std::initializer_list and threading stuff). It is basically impossible to make an OS-agnostic C++ compiler that doesn't leak its and platform's internals to the user.
Luckily Rust mostly abstracts around the platform-compiler boundary and its standard library so the platform dependencies are implementation details. Unlike C and C++, one can write Rust without caring about how the underlying OS does ABI. However, Rust compiler and Rust std has a special relationship. `Box` can only be defined as part of Rust standard library that's compiled together with the Rust compiler itself. Its special relationship is kind of a blocker for -Zbuild-std and std-aware Cargo which prevents size-optimizing std for embedded systems. Without that magic (i.e. compiling the compiler itself, or worse bootstrapping it) you cannot independently create a `Box`.
I want this kind of library to contain as little as possible since it is convenient to define these kinds of relationships and rely on magic. Modern C++ has too much such magic. Rust is mostly on a correct path with std, core, alloc etc. separations. These kinds of boundaries make it possible to share as much code as possible with many libraries without finding hacky ways around std (which you have to do with C++).
This doesn't mean that I wouldn't appreciate more actual functional libraries maintained by Rust Foundation-funded people and be part of the project or even easily installed. However those libraries should be effortlessly exchangeable. I think current Cargo ecosystem achieves this mostly. However I would appreciate a more curated Cargo repository that contains only a limited set of really well maintained packages (similar to Maven's repos in Java world).
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?
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.
> There are good crates for core things like cryptography
Speaking of cryptography, I've given up on setting up a Termux Python dev environment on an old Arm tablet, because some package has a dependency on the 'cryptography' module, which apparently requires the whole Rust toolchain to build. In a Python project. On a platform with limited storage. The documentation suggests pre-built binaries are an option, but I couldn't figure it out the last few times. It left me with a bad taste in my mouth.
Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem.
Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors.
Ubuntu and companies which embed Linux into their products will love this from a business perspective.
Consider: An end to end signature-enabled, verified, attestable, Linux environment with completely closed source util-linux and userland packages, down to the "ls" and "cd". Deliciously apocalyptic.
We're two stops away from this, and there are no shortage of momentum or funding to enable teh future.
> They are “looking to minimize discontinuity with the old ways”
Perhaps one of the best ways to achieve that goal is to not introduce any discontinuity? Like, take coreutils. It's one of the most stable pieces of Linux infrastructure. It's as solid as it gets. No one asked for rewrite of those in any language. No one wanted a rewrite. No one needed a rewrite. The rewrite serves no purpose[1].
[1] Credit where it's due: this rust slop prompted a creation of test suite for coreutils, which is truly a great achievement, hands down.
Putting aside Ubuntu's/Canonical's failed custom projects (e.g. upstart), they have a history of shipping software that isn't ready and turning the community against it, with pulseaudio being the headline example. I'm concerned that the upcoming Ubuntu LTS (which is only 2 months away) will add rust to that list.
If your issue is the license used then your issue isn't the language itself. Someone who wrote a coreutils replacement in D or something and licensed it as MIT you would still have an issue.
This noise around rust is aggravating. I loved Rust. Learned and used it from the first book but this garbage propaganda and MIT license thing is annoying so much
> After all, they said, why not just add dependencies to your Cargo.toml? It’s easy enough. And to be honest, they were right – at least at the time.
They weren't? Isn't it obvious that it's not easy because the challenge isn't literally adding dependencies to a file, but before that - finding/evaluating which of the alternative dependencies to add?
But anyway, that's a very shallow and wrong summary of what happened, the link itself has plenty of grounded non-hateful objections to the proposal, which would be as valid now as they were then.
44 comments
[ 2.9 ms ] story [ 65.9 ms ] threadA lot of bug fixes/exploits are _CAUSED_ by the C+ core, but still... Tried & true vs new hotness?
Rust is undoubtedly excellent. What tarnishes the picture is a small group of people that rewrite solid pieces of code into Rust, hijacking the original brand names (eg. "sudo") for the sole purpose of virtue signaling. And the later is why the come after the most stable pieces of software that warrant no rewrite at all, like coreutils.
It seems to me that the right approach would be to ignore those and still love Rust for what nice of a language it is.
Unfortunately, Ubuntu is all in on virtue signaling.
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.
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.
Or maybe we can some how get used to living with static linking. (I don't think so, but many seem to think so in spite of my advice to the contrary!)
Another possibility is to use IPC as the dynamic linking boundary of sorts, but this will consume lots more memory, and as is stated elsewhere in this thread, memory ain't cheap no more.
This means that any Rust ABI would have to cater for link-time specialization. I think this should be doable, but it would require a solution that's better than just to move the code generation into the linker. Instead, one would need to carefully consider the usage of the "shape" of all parameters of a function.
That's not important. What I want to see is the Rewrite-it-in-Rust movement move towards GPL.
GPL is pro-user. MIT is pro-business.
In their zeal to convert, they are happily replacing pro-user software with pro-business software. Their primary goal is to convert, not to safeguard.
If they shifted their goal from spreading Rust to protecting users, I'd be a lot happier about the community.
https://github.com/canonical/firefox-snap/blob/90fa83e60ffef...
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.
I'm not sure what this is referring to, but surely it's not referring to Rust. Adding things to the stdlib is way easier than "changing" the stdlib. And Rust adds stuff to the stdlib all the time, like, go read any blog post for a new release and see that there are usually 10+ new additions to the stdlib, which adds up to hundreds of new additions per year due to the six-week release schedule.
Yes, there’s always a couple of people who really push the boat out…
The use case of languages like Rust and C++ is that you can use the same compiler to write both bare-metal unhosted code (non-std for bootloaders, microcontrollers and kernels) and hosted code (uses std structures). As a system programmer that crosses the edge between two environments, I would like to share as much code as possible. Having a big standard library with hosted system assumption is a huge issue. In those cases you want the language works 99% the same and can use the same structs / libraries. Sometimes you also want to write non-std code on hosted environments for things like linkers.
Rust isn't even at the level of maturity of C yet in this regard. Rust's std / core is too big for really memory limited microcontrollers (<64 K space) and requires nasty hacks with weak ABI symbols to make things sane.
Having a huge baggage of std both causes issues like this for the users and also increases maintenance burden of the maintainers. Rust really wants to break its APIs as little as possible and small standard library is a great way to achieve that. C++ suffered a lot from this and it hampered its adoption for C codebases.
Unfortunelly too many modern system programmers never lived in that era, and are completly off on how nice the whole development experience could be like.
However, the standard library of a systems language has a special relationship with the compiler. This is the case for C and C++ where the compiler and the standard library also has a special relationship with the platform like GNU or musl with Linux, or MSVC and Windows. It makes changing APIs or modernizing infrastructure almost impossible without creating an entire new OS and porting all compilers and standard libraries to it. Moreover the newer C++ standards actually force you to define such a relationship (with std::initializer_list and threading stuff). It is basically impossible to make an OS-agnostic C++ compiler that doesn't leak its and platform's internals to the user.
Luckily Rust mostly abstracts around the platform-compiler boundary and its standard library so the platform dependencies are implementation details. Unlike C and C++, one can write Rust without caring about how the underlying OS does ABI. However, Rust compiler and Rust std has a special relationship. `Box` can only be defined as part of Rust standard library that's compiled together with the Rust compiler itself. Its special relationship is kind of a blocker for -Zbuild-std and std-aware Cargo which prevents size-optimizing std for embedded systems. Without that magic (i.e. compiling the compiler itself, or worse bootstrapping it) you cannot independently create a `Box`.
I want this kind of library to contain as little as possible since it is convenient to define these kinds of relationships and rely on magic. Modern C++ has too much such magic. Rust is mostly on a correct path with std, core, alloc etc. separations. These kinds of boundaries make it possible to share as much code as possible with many libraries without finding hacky ways around std (which you have to do with C++).
This doesn't mean that I wouldn't appreciate more actual functional libraries maintained by Rust Foundation-funded people and be part of the project or even easily installed. However those libraries should be effortlessly exchangeable. I think current Cargo ecosystem achieves this mostly. However I would appreciate a more curated Cargo repository that contains only a limited set of really well maintained packages (similar to Maven's repos in Java world).
Speaking of cryptography, I've given up on setting up a Termux Python dev environment on an old Arm tablet, because some package has a dependency on the 'cryptography' module, which apparently requires the whole Rust toolchain to build. In a Python project. On a platform with limited storage. The documentation suggests pre-built binaries are an option, but I couldn't figure it out the last few times. It left me with a bad taste in my mouth.
- SNAP which is only managed and supported by them
- Tried to reinvent the wheel with sudo-rs
- They are heavily focused into cloud, servers and business
- Following the Rust hype train
I used Ubuntu for 13y or so, it is a Windows within Linux world. Bloated, kernel panic, heavy, privacy issues.
Debian still the king to be used as servers, Mint Cinnamon is the king for desktop, gaming, video editing, 3D design, coding,it just works.
reinvent how? sudo-rs and a bunch of others are maintained by: https://trifectatech.org/ a non profit registered in Netherlands
Also Solaris and Aix are my favourite UNIX flavours.
The time to write M$ on my email signature during the 1990's is long gone.
Combine this with what Amutable (systemd guys) are building, and you can have monolithic, closed source, non-user-modifiable Linux distributions or flavors.
Ubuntu and companies which embed Linux into their products will love this from a business perspective.
Consider: An end to end signature-enabled, verified, attestable, Linux environment with completely closed source util-linux and userland packages, down to the "ls" and "cd". Deliciously apocalyptic.
We're two stops away from this, and there are no shortage of momentum or funding to enable teh future.
Ubuntu was always "let's just fuck up what just works in Debian" but this is another level, I have no idea why they are rushing it
Distros using Ubuntu as base should reconsider.
Perhaps one of the best ways to achieve that goal is to not introduce any discontinuity? Like, take coreutils. It's one of the most stable pieces of Linux infrastructure. It's as solid as it gets. No one asked for rewrite of those in any language. No one wanted a rewrite. No one needed a rewrite. The rewrite serves no purpose[1].
[1] Credit where it's due: this rust slop prompted a creation of test suite for coreutils, which is truly a great achievement, hands down.
Replacing solid code with vibe code basically, in the name of safety.
sudo-rs for example which is specifically mentioned has a drastically worst safety record than the C sudo.
This noise around rust is aggravating. I loved Rust. Learned and used it from the first book but this garbage propaganda and MIT license thing is annoying so much
They weren't? Isn't it obvious that it's not easy because the challenge isn't literally adding dependencies to a file, but before that - finding/evaluating which of the alternative dependencies to add?
But anyway, that's a very shallow and wrong summary of what happened, the link itself has plenty of grounded non-hateful objections to the proposal, which would be as valid now as they were then.