14 ms·

What it means that Ubuntu is using Rust

189 points by zdw 8mo ago

psyclobe 8mo ago
it means, no more sudo -E it means no more stdbuf piping
UI_at_80x24 8mo ago
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?
- bbkane 8mo ago
  I think it's worth trying!
  - UI_at_80x24 8mo ago
    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.
    - ozgrakkurt 8mo ago
      Rg/grep is kind of like make/ninja imo. It’s not so much about the language as it is about the hindsight/developer/project
- petcat 8mo ago
  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.
  - 0x457 8mo ago
    Rust - no. sudo-rs not hotness, but relatively new.
  - squeefers 8mo ago
    apart from safety critical systems.... whats that all about? youd think with all the safety guarantees itd be good for something like that
  - jacquesm 8mo ago
    No, it's Node.js. I kid you not. I keep coming across Node in places where I really would not expect it.
- giancarlostoro 8mo ago
  Don't hate me for this, but... is 20 years of Rust really new? https://en.wikipedia.org/wiki/Rust_(programming_language) 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 8mo ago
    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.
    - squeefers 8mo ago
      he has no answer for this
    - giancarlostoro 8mo ago
      Tests are written for various goals: integration testing, to prevent regressions, and in the same effort to prevent regressions to protect mission critical / business logic code. If all those nuances are captured by good tests, you arguably have "100%" test coverage, you don't need to test every single line of code ever written to have 100% test coverage in my eyes. But then when you go to translate your project to a new language, you port the tests first, then test against those tests. This is my personal belief on this anyway.
  - throw384748 8mo ago
    [flagged]
- mamcx 8mo ago
  > 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.
  - squeefers 8mo ago
    > but is true that changing the language in fact solve tons of things. *so long as you dont use unsafe rust **unsafe rust required for systems programming ***rust is a systems language ****does changing a default actually solve anything?
bbkane 8mo ago
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).
- vablings 8mo ago
  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
  - Wobbles42 8mo ago
    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.
    - throwaway27448 8mo ago
      Sure. There was an article a week or two ago about IBM aggressively hiring juniors. Of course the fact that is noteworthy probably means something in itself....
      - red-iron-pine 8mo ago
        IBM is also not known for holding on to bodies -- IBM layoff stories abound. a glut of junior hires now does not a pretty picture make in the long-term sense
    - vablings 8mo ago
throwaway613746 8mo ago
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.
- a456463 8mo ago
  agreed!
system2 8mo ago
Why am I hearing about Rust a lot these days? Did anything significant happen?
- iFire 8mo ago
  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.
- canadiantim 8mo ago
  AI has made it exceptionally easy to program with. I've switched to using Rust from Python simply because of AI development
  - system2 8mo ago
    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.
    - mikepurvis 8mo ago
      I think the argument is more that working rust code is better than working Python, and AI assistance makes it more tenable for average developers to successfully produce working rust code, and in particular is helpful for navigating the gap between "code written" and "code compiling" (eg why is the borrow checked mad at me).
    - theLiminator 8mo ago
      I think relative to the typical Rust code it likely does worse than AI relative to the typical Python code. But due to the compiler, it's possible you might get more correctness out of AI-generated rust code on average.
pizlonator 8mo ago
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.
- eptcyka 8mo ago
  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?
  - ahartmetz 8mo ago
    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.
  - pizlonator 8mo ago
    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.
    - sagarm 8mo ago
      There is no existing safe ABI, so this cannot be an adoption barrier.
      - pizlonator 8mo ago
        Lots of reasons why it is. I'll give you two. 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
stabbles 8mo ago
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-extract/351343 https://forums.developer.nvidia.com/t/cuda-runfile-wont-extr...
- nightpool 8mo ago
  Do you have more details? The thread you linked was about gzip, not dd.
  - stabbles 8mo ago
    The .run file is a shell script with a compressed archive appended: MS_dd "$0" $offset $s | eval "gzip -cd" | UnTAR t Where MS_dd() { blocks=`expr $3 / 1024` bytes=`expr $3 % 1024` dd if="$1" ibs=$2 skip=1 obs=1024 conv=sync 2> /dev/null | \ { test $blocks -gt 0 && dd ibs=1024 obs=1024 count=$blocks ; \ test $bytes -gt 0 && dd ibs=1 obs=1024 count=$bytes ; } 2> /dev/null } 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/+bug/2125535 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
- egorfine 8mo ago
  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.
psyclobe 8mo ago
Sudo no longer supporting path inheritance kinda sucks
nekiwo 8mo ago
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...
- jsheard 8mo ago
  > 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.
  - oblio 8mo ago
    Well, this could be handled with a new anti AI license and I guess crowd funding a massive lawsuit to set precedent against AI companies.
- bluejekyll 8mo ago
  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.
  - bigstrat2003 8mo ago
    > MIT is more flexible in its use than GPL, but doesn’t help ensure that software remains open. Sure it does. The original software will always remain open. It isn't like people can somehow take that away.
edelbitter 8mo ago
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/90fa83e60ffef6c72c28288cda381de25d518f5b/snapcraft.yaml#L149-L159 https://github.com/canonical/firefox-snap/blob/90fa83e60ffef...
- tokyobreakfast 8mo ago
  [flagged]
  - acomjean 8mo ago
    “Done software”?
    - tokyobreakfast 8mo ago
      [flagged]
  - castis 8mo ago
    should we trust someone whos HN account is just as shiny?
- kingstnap 8mo ago
  You can curl stuff and run it just gotta have hashes in place.
  - theamk 8mo ago
    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.
    - kibwen 8mo ago
deepriverfish 8mo ago
a few weeks ago it was all about Zig, now it's all about Rust, Clojure or Elixir next?
- kelvinjps10 8mo ago
  Rust was first
themafia 8mo ago
> 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.
- kibwen 8mo ago
  > 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.
  - LtWorf 8mo ago
    Wake me up when it can do what python or java can do with their.
    - CyberDildonics 8mo ago
      What does this mean? What is it? Their what?
moomin 8mo ago
.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…
- bigstrat2003 8mo ago
  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.
  - hombre_fatal 8mo ago
    On the other hand, a worse implementation in the stdlib can make it harder for the community to crystalize the best third-party option since the stdlib solution doesn't have to "compete in the arena". Go has some of these. Maybe a good middle-ground is something like Rust's regex crate where the best third-party solution gets blessed into a first-party package, but it is still versioned separately from the language.
  - jabl 8mo ago
    I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib. With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it. Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see. But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?
harpiaharpyja 8mo ago
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?
- aapoalas 8mo ago
  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.
dabinat 8mo ago
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.
- oconnor663 8mo ago
  I wouldn't read too much into pre-1.0 versions. Folks take SemVer pretty seriously, and that makes some folks reluctant to declare v1.0 even when a crate has been in use and "mostly stable" for years. There can also be compatibility issues with a 1.0 bump if a crate's types are common in public APIs, e.g. the `libc` crate. I'm a big fan of the curated list of crates at blessed.rs, or honestly just looking at download numbers. (Obviously not a perfect system.)
  - ninkendo 8mo ago
    IME, a 1.0 version is usually when a project starts taking backwards compatibility seriously. A pre-1.0 library may be plenty stable enough in terms of bugs, but being pre-1.0 means they’re likely going to change their mind on the API contract at some point. That is the major problem for me… I don’t actually mind that much if a library has bugs… those can always be fixed. But when a library does a total 180 on the API contract, or removes things, or just changes their mind on what the abstraction should be (often it feels like they’re just feng shui’ing things), that’s a major problem. And it’s what people mean when they say “immaturity”: if I build on top of this, is it all going to break horribly at some point in the future when the author changes their mind? People often say “just don’t update then”, but that’s (a) a sure fire way to accumulate tech debt in your codebase (because some day may come when you must update), and (b) you’re no longer getting what could be critical updates to the library.
- rascul 8mo ago
  gettext took over 30 years to get to 1.0 last month.
- overfeed 8mo ago
  > 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.
h4kunamata 8mo ago
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.
- Qem 8mo ago
  > Mint Cinnamon is the king for desktop Mint LMDE great too. Builds upon a Debian base, instead of Ubuntu.
- oblio 8mo ago
  > - SNAP which is only managed and supported by them > - Tried to reinvent the wheel with sudo-rs Upstart, Mir, Launchpad, Bazaar, Unity, Juju...
- bboozzoo 8mo ago
  > - Tried to reinvent the wheel with sudo-rs reinvent how? sudo-rs and a bunch of others are maintained by: https://trifectatech.org/ https://trifectatech.org/ a non profit registered in Netherlands
- pjmlp 8mo ago
  Nowadays I only use Windows, Android and WebOS privately, macOS at work when assigned an Apple device, and cloud specific Linux distros. 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.
umairnadeem123 8mo ago
[dead]
bayindirh 8mo ago
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.
- benrutter 8mo ago
  History probably says I'm being naive, but I feel like I don't hate this possibility (hear me out!). Personally, I'd always choose to use a distribution with open source userland packages and utils, but if closed source alternatives exist and conform to the same specifications (i.e. we get "embrace" without the "extend and extinguish") then I don't mind if a company has closed sourced tech, especially if it'll help there business case, potentially boosting funding for open source linux projects. Maybe that's all naive, I guess we'll find out if ubuntu really do go for more and more closed source options.
  - bayindirh 8mo ago
    I understand the optimism, but after being burned by what Microsoft did to the Linux community for the last 20+ years, I'll just distance myself more from Ubuntu ecosystem. When you put Snaps, Juju, uutils, etc. as a list, it all smells like a path to lockdown, not dissimilar to what RedHat did with their "unbranded" patches recently (IBM being IBM, which was unsurprising). Also, remembering how Canonical worked together with Microsoft on some projects like WSL, which felt like "Surrender servers to Linux, and save the Windows desktop by allowing Linux run as a slave inside a VM" type of deal, I do not trust them a bit. So, Linux is maturing, but it'll also bring a couple of very big cracks through ecosystem, and it'll be noisy and painful. Personally, I'm on Debian for the last 20+ years, and not planning to move anywhere for now. I understand that there needs to be an economy, but money is not more important than destroying what we're standing on. Let it be physical like our planet, or virtual like the free software and the culture we built around it.
PunchyHamster 8mo ago
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.
- dgxyz 8mo ago
  Debian stable just works now. I am not sure why a layer smeared over the top of these is a win for anyone. It's all bloat.
egorfine 8mo ago
> 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.
dankobgd 8mo ago
it means it is using rust
aragilar 8mo ago
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.
- cgfjtynzdrfht 8mo ago
  [dead]
athoneycutt 8mo ago
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.
jurschreuder 8mo ago
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.
- a456463 8mo ago
  But rust!! and AI!! and safety!!! /s 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
eviks 8mo ago
> 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.

189 points by zdw 8mo ago

it means, no more sudo -E it means no more stdbuf piping

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?

bbkane 8mo ago
I think it's worth trying!
- UI_at_80x24 8mo ago
  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.
  - ozgrakkurt 8mo ago
    Rg/grep is kind of like make/ninja imo. It’s not so much about the language as it is about the hindsight/developer/project
petcat 8mo ago
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.
- 0x457 8mo ago
  Rust - no. sudo-rs not hotness, but relatively new.
- squeefers 8mo ago
  apart from safety critical systems.... whats that all about? youd think with all the safety guarantees itd be good for something like that
- jacquesm 8mo ago
  No, it's Node.js. I kid you not. I keep coming across Node in places where I really would not expect it.
giancarlostoro 8mo ago
Don't hate me for this, but... is 20 years of Rust really new? https://en.wikipedia.org/wiki/Rust_(programming_language) 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 8mo ago
  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.
  - squeefers 8mo ago
    he has no answer for this
  - giancarlostoro 8mo ago
    Tests are written for various goals: integration testing, to prevent regressions, and in the same effort to prevent regressions to protect mission critical / business logic code. If all those nuances are captured by good tests, you arguably have "100%" test coverage, you don't need to test every single line of code ever written to have 100% test coverage in my eyes. But then when you go to translate your project to a new language, you port the tests first, then test against those tests. This is my personal belief on this anyway.
- throw384748 8mo ago
  [flagged]
mamcx 8mo ago
> 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.
- squeefers 8mo ago
  > but is true that changing the language in fact solve tons of things. *so long as you dont use unsafe rust **unsafe rust required for systems programming ***rust is a systems language ****does changing a default actually solve anything?

bbkane 8mo ago

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).

vablings 8mo ago
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
- Wobbles42 8mo ago
  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.
  - throwaway27448 8mo ago
    Sure. There was an article a week or two ago about IBM aggressively hiring juniors. Of course the fact that is noteworthy probably means something in itself....
    - red-iron-pine 8mo ago
      IBM is also not known for holding on to bodies -- IBM layoff stories abound. a glut of junior hires now does not a pretty picture make in the long-term sense
  - vablings 8mo ago

throwaway613746 8mo ago

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.

a456463 8mo ago
agreed!

system2 8mo ago

Why am I hearing about Rust a lot these days? Did anything significant happen?

iFire 8mo ago
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.
canadiantim 8mo ago
AI has made it exceptionally easy to program with. I've switched to using Rust from Python simply because of AI development
- system2 8mo ago
  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.
  - mikepurvis 8mo ago
    I think the argument is more that working rust code is better than working Python, and AI assistance makes it more tenable for average developers to successfully produce working rust code, and in particular is helpful for navigating the gap between "code written" and "code compiling" (eg why is the borrow checked mad at me).
  - theLiminator 8mo ago
    I think relative to the typical Rust code it likely does worse than AI relative to the typical Python code. But due to the compiler, it's possible you might get more correctness out of AI-generated rust code on average.

pizlonator 8mo ago

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.

eptcyka 8mo ago
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?
- ahartmetz 8mo ago
  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.
- pizlonator 8mo ago
  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.
  - sagarm 8mo ago
    There is no existing safe ABI, so this cannot be an adoption barrier.
    - pizlonator 8mo ago
      Lots of reasons why it is. I'll give you two. 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

stabbles 8mo ago

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-extract/351343 https://forums.developer.nvidia.com/t/cuda-runfile-wont-extr...

nightpool 8mo ago
Do you have more details? The thread you linked was about gzip, not dd.
- stabbles 8mo ago
  The .run file is a shell script with a compressed archive appended: MS_dd "$0" $offset $s | eval "gzip -cd" | UnTAR t Where MS_dd() { blocks=`expr $3 / 1024` bytes=`expr $3 % 1024` dd if="$1" ibs=$2 skip=1 obs=1024 conv=sync 2> /dev/null | \ { test $blocks -gt 0 && dd ibs=1024 obs=1024 count=$blocks ; \ test $bytes -gt 0 && dd ibs=1 obs=1024 count=$bytes ; } 2> /dev/null } 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/+bug/2125535 https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bu...
egorfine 8mo ago
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.

psyclobe 8mo ago

Sudo no longer supporting path inheritance kinda sucks

nekiwo 8mo ago

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...

jsheard 8mo ago
> 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.
- oblio 8mo ago
  Well, this could be handled with a new anti AI license and I guess crowd funding a massive lawsuit to set precedent against AI companies.
bluejekyll 8mo ago
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.
- bigstrat2003 8mo ago
  > MIT is more flexible in its use than GPL, but doesn’t help ensure that software remains open. Sure it does. The original software will always remain open. It isn't like people can somehow take that away.

edelbitter 8mo ago

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/90fa83e60ffef6c72c28288cda381de25d518f5b/snapcraft.yaml#L149-L159 https://github.com/canonical/firefox-snap/blob/90fa83e60ffef...

tokyobreakfast 8mo ago
[flagged]
- acomjean 8mo ago
  “Done software”?
  - tokyobreakfast 8mo ago
    [flagged]
- castis 8mo ago
  should we trust someone whos HN account is just as shiny?
kingstnap 8mo ago
You can curl stuff and run it just gotta have hashes in place.
- theamk 8mo ago
  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.
  - kibwen 8mo ago

deepriverfish 8mo ago

a few weeks ago it was all about Zig, now it's all about Rust, Clojure or Elixir next?

kelvinjps10 8mo ago
Rust was first

themafia 8mo ago

> 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.

kibwen 8mo ago
> 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.
- LtWorf 8mo ago
  Wake me up when it can do what python or java can do with their.
  - CyberDildonics 8mo ago
    What does this mean? What is it? Their what?

moomin 8mo ago

.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…

bigstrat2003 8mo ago
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.
- hombre_fatal 8mo ago
  On the other hand, a worse implementation in the stdlib can make it harder for the community to crystalize the best third-party option since the stdlib solution doesn't have to "compete in the arena". Go has some of these. Maybe a good middle-ground is something like Rust's regex crate where the best third-party solution gets blessed into a first-party package, but it is still versioned separately from the language.
- jabl 8mo ago
  I don't think the situation is that comparable to python, since in python the library has to be present at runtime. And with the dysfunctional python packaging there's potentially a lot of grey hairs saved by not requiring anything beyond the stdlib. With Rust, it's an issue at compile-time only. You can then copy the binary around without having to worry about which crates were needed to build it. Of course, there is the question of trust and discoverability. Maybe Rust would be served by a larger stdlib, or some other mechanism of saying this is a collection of high-quality well maintained libraries, prefer these if applicable. Perhaps the thing the blog post author hints at would be a solution without having to bundle everything into the stdlib, we'll see. But I'd be somewhat vary of shoveling a lot of stuff into stdlib, it's very hard to get rid of deprecated functionality. E.g. how many command-line argument parsers are there in the python stdlib? 3?

harpiaharpyja 8mo ago

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?

aapoalas 8mo ago
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.

dabinat 8mo ago

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.

oconnor663 8mo ago
I wouldn't read too much into pre-1.0 versions. Folks take SemVer pretty seriously, and that makes some folks reluctant to declare v1.0 even when a crate has been in use and "mostly stable" for years. There can also be compatibility issues with a 1.0 bump if a crate's types are common in public APIs, e.g. the `libc` crate. I'm a big fan of the curated list of crates at blessed.rs, or honestly just looking at download numbers. (Obviously not a perfect system.)
- ninkendo 8mo ago
  IME, a 1.0 version is usually when a project starts taking backwards compatibility seriously. A pre-1.0 library may be plenty stable enough in terms of bugs, but being pre-1.0 means they’re likely going to change their mind on the API contract at some point. That is the major problem for me… I don’t actually mind that much if a library has bugs… those can always be fixed. But when a library does a total 180 on the API contract, or removes things, or just changes their mind on what the abstraction should be (often it feels like they’re just feng shui’ing things), that’s a major problem. And it’s what people mean when they say “immaturity”: if I build on top of this, is it all going to break horribly at some point in the future when the author changes their mind? People often say “just don’t update then”, but that’s (a) a sure fire way to accumulate tech debt in your codebase (because some day may come when you must update), and (b) you’re no longer getting what could be critical updates to the library.
rascul 8mo ago
gettext took over 30 years to get to 1.0 last month.
overfeed 8mo ago
> 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.

h4kunamata 8mo ago

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.

Qem 8mo ago
> Mint Cinnamon is the king for desktop Mint LMDE great too. Builds upon a Debian base, instead of Ubuntu.
oblio 8mo ago
> - SNAP which is only managed and supported by them > - Tried to reinvent the wheel with sudo-rs Upstart, Mir, Launchpad, Bazaar, Unity, Juju...
bboozzoo 8mo ago
> - Tried to reinvent the wheel with sudo-rs reinvent how? sudo-rs and a bunch of others are maintained by: https://trifectatech.org/ https://trifectatech.org/ a non profit registered in Netherlands
pjmlp 8mo ago
Nowadays I only use Windows, Android and WebOS privately, macOS at work when assigned an Apple device, and cloud specific Linux distros. 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.

umairnadeem123 8mo ago

[dead]

bayindirh 8mo ago

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.

benrutter 8mo ago
History probably says I'm being naive, but I feel like I don't hate this possibility (hear me out!). Personally, I'd always choose to use a distribution with open source userland packages and utils, but if closed source alternatives exist and conform to the same specifications (i.e. we get "embrace" without the "extend and extinguish") then I don't mind if a company has closed sourced tech, especially if it'll help there business case, potentially boosting funding for open source linux projects. Maybe that's all naive, I guess we'll find out if ubuntu really do go for more and more closed source options.
- bayindirh 8mo ago
  I understand the optimism, but after being burned by what Microsoft did to the Linux community for the last 20+ years, I'll just distance myself more from Ubuntu ecosystem. When you put Snaps, Juju, uutils, etc. as a list, it all smells like a path to lockdown, not dissimilar to what RedHat did with their "unbranded" patches recently (IBM being IBM, which was unsurprising). Also, remembering how Canonical worked together with Microsoft on some projects like WSL, which felt like "Surrender servers to Linux, and save the Windows desktop by allowing Linux run as a slave inside a VM" type of deal, I do not trust them a bit. So, Linux is maturing, but it'll also bring a couple of very big cracks through ecosystem, and it'll be noisy and painful. Personally, I'm on Debian for the last 20+ years, and not planning to move anywhere for now. I understand that there needs to be an economy, but money is not more important than destroying what we're standing on. Let it be physical like our planet, or virtual like the free software and the culture we built around it.

PunchyHamster 8mo ago

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.

dgxyz 8mo ago
Debian stable just works now. I am not sure why a layer smeared over the top of these is a win for anyone. It's all bloat.

egorfine 8mo ago

> 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.

dankobgd 8mo ago

it means it is using rust

aragilar 8mo ago

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.

cgfjtynzdrfht 8mo ago
[dead]

athoneycutt 8mo ago

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.

jurschreuder 8mo ago

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.

a456463 8mo ago
But rust!! and AI!! and safety!!! /s 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

eviks 8mo ago

> 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.