| ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
| Article Heatmap Negative Neutral Positive No Data |
| Aggregates
Evidence: High: 5 Medium: 10 Low: 3 No Data: 13 | Theme Radar | ||||||||||||||||||||||||||||
| Domain Context Profile
|
|
HN Discussion
20 top-level comments
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). 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. 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... 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. https://github.com/canonical/firefox-snap/blob/90fa83e60ffef... > 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. .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… 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. Ubuntu used to be the distro to go do, used to. - 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. 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. So far mostly that they pushed untested tools that even authors didn't think are production ready on ususpecting users. 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. > 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. They are vibe-translating C++ into Rust to change the licence. 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. |
| Score Breakdown |
|