4 ms·

>I know intellectually, that there are sane/pragmatic people who appreciate Rust. For the most part that is almost everyone who works on rust and writes rust.

• influx 11mo ago
  It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.
  • chillingeffect 11mo ago
    Even worse, the license requirements (gpl->mit) will be less beneficial to the community than the rust replacements.
    • steveklabnik 11mo ago
      Rust has no specific license requirements on code written in it. People choose whatever license they prefer.
      • chillingeffect 11mo ago
        True, but you might want to look into the licenses people are actually choosing for Rust versions of coreutils/uutils and who's promoting them.
        • steveklabnik 11mo ago
          Sure, those authors chose that license because they did not really particularly care for the politics of licenses and chose the most common one in the Rust ecosystem, which is MIT/Apache 2. If folks want more Rust projects under licenses they prefer, they should start those projects.
          • kstrauser 11mo ago
            I released my most recent Rust project under the GPLv3. The first issue was someone asking me to relicense it under MIT. I politely declined. I bring this up because no matter what you choose, someone will wish it was otherwise.
          • chillingeffect 11mo ago
            > If folks want more Rust projects under licenses they prefer, they should start those projects. 100% true, but also hides a powerful fact: Our choices aren't limited to doing it ourselves. Listening to others and discussing how to do things as a group is the essence of community seeking long-term stability abd fairness. It'a how we got to the special place we are now. Not everyone can or should start their own open source project. Maybe theyre already doing another one. Maybe they don't know how to code. The viewpoint of others/users/customers is valid and should not only be listened to but asked for.
  • radlad 11mo ago
    systemd has been the de facto standard for over a decade now and is very stable. I have found that even most people who complained about the initial transition are very welcoming of its benefits now.
    • phicoh 11mo ago
      Depends a bit on how you define systemd. Just found out that the systemd developers don't understand DNS (or IPv6). Interesting problems result from that.
      • radlad 11mo ago
        > Just found out that the systemd developers don't understand DNS (or IPv6). Just according to Github, systemd has over 2,300 contributors. Which ones are you referring to? And more to the point, what is this supposed to mean? Did you encounter a bug or something? DNS on Linux is sort of famously a tire fire, see for example https://tailscale.com/blog/sisyphean-dns-client-linux https://tailscale.com/blog/sisyphean-dns-client-linux ... IPv6 networking is also famously difficult on Linux, with many users still refusing to even leave it enabled, frustratingly for those of us who care about IPv6.
        • phicoh 11mo ago
          Systemd-resolved invents DNS records (not really something you would like to see, makes debugging DNS issues a nightmare). But worse, it populates those DNS records with IPv6 link local addresses, which really have no place in DNS. Then, when after a nice debugging session why your application behaves so strangely, all the data in DNS is correct, why doesn't it work, you find that this issue has been reported before and was rejected as won't fix, works as intended.
          • Dagger2 11mo ago
            Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS. i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively) DNS records. The debug tool for this is `getent ahosts`. `dig` is certainly useful, but it makes direct DNS queries rather than going via the system's name resolution setup, so it can't tell you what your programs are seeing.
  • crote 11mo ago
    Well, what's the alternative? It is basic knowledge that memory safety bugs are a significant source of vulnerabilities, and by now it well-established that the first developer who can avoid C without introducing memory safety bugs hasn't been born yet. In other words: if you care about security at all, continuing with the status quo isn't an option. The C ecosystem has tried to solve the problem with a variety of additional tooling. This has helped a bit, but didn't solve the underlying problem. The C community has demonstrated that it is both unwilling and unable to evolve C into a memory-safe language. This means that writing additional C code is a Really Bad Idea. Software has to be maintained. Decade-old battle-tested codebases aren't static: they will inevitably require changes, and making changes means writing additional code. This means that your battle-tested C codebase will inevitably see changes, which means it will inevitably see the introduction of new memory safety bugs. Google's position is that we should simply stop writing new code in C: you avoid the high cost and real risk of a rewrite, and you also stop the neverending flow memory safety bugs. This approach works well for large and modular projects, but doing the same in coreutils is a completely different story. Replacing battle-tested code with fresh code has genuine risks, there's no way around that. The real question is: are we willing to accept those short-term risks for long-term benefits? And mind you, none of this is Rust-specific. If your application doesn't need the benefits of C, rewriting it in Python or Typescript or C# might make even more sense than rewriting it in Rust. The main argument isn't "Rust is good", but "C is terrible".
  • stouset 11mo ago
    That “battle-tested code” is often still an enduring and ongoing source of bugs. Maintainers have to deal with the burden of working in a 20+ year-old code base with design and architecture choices that probably weren’t even a great idea back then. Very few people are forcing “rewrite in rust” down anyone’s throats. Sometimes it’s the maintainers themselves who are trying to be forward-thinking and undertake a rewrite (e.g., fish shell), sometimes people are taking existing projects and porting them just to scratch an itch and it’s others’ decisions to start shipping it (e.g., coreutils). I genuinely fail to see the problem with either approach. C’s long reign is coming to an end. Some projects and tools are going to want to be ahead of the curve, some projects are going to be behind the curve. There is no perfect rate at which this happens, but “it’s battle-tested” is not a reason to keep a project on C indefinitely. If you don’t think {pet project you care about} should be in C in 50 years, there will be a moment where people rewrite it. It will be immature and not as feature-complete right out the gate. There will be new bugs. Maybe it happens today, maybe it’s 40 years from now. But the “it’s battle tested, what’s the rush” argument can and will be used reflexively against both of those timelines.
    • az09mugen 11mo ago
      As long as LLVM (C++ but still) is not rewritten is rust [0] , I don't buy it. C is like JavaScript, it's not perfect, is everywhere and you cannot replace it without a lot of effort and bugfix/regression tests. If I take for example sqlite (25 years old [3]) there are already 2 rewrites in rust [1] and [2], and each one has its bugs. And as an end user I'm more enclined to trust the battle-tested original for my prod than its copies. As long as I don't have the proof the rewrite is at least as good as the original, I'll stay with the original. Simple equals more maintainable. That's also why sqlite maintainers won't rewrite it in any other language [4]. The trade of rust is "you can lose features and have unexpected bugs like any other language, but don't worry they will be memory safe bugs". I'm not saying rust is bad and you should not rewrite anything in it, but IMHO rust programmers tend to overestimate the quality of the features they deliver [5] or something along these lines. Memory safe != good product [0] https://rustc-dev-guide.rust-lang.org/overview.html https://rustc-dev-guide.rust-lang.org/overview.html [1] https://github.com/epilys/rsqlite3 https://github.com/epilys/rsqlite3 [2] https://github.com/tursodatabase/turso/ https://github.com/tursodatabase/turso/ [3] https://sqlite.org/chronology.html https://sqlite.org/chronology.html [4] https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html [5] https://www.phoronix.com/news/Ubuntu-25.10-Broken-Upgrade https://www.phoronix.com/news/Ubuntu-25.10-Broken-Upgrade
  • eviks 11mo ago
    But the result of the battle test is the reason to throw the crippled veteran away!
  • vablings 11mo ago
    I agree that throwing away battle tested code is wasteful and often not required. Most people are not of the mindset of just throwing things away but there is a drive to make things better. There are some absolute monoliths such as the Linux kernel that will likely never break free of its C shackles and thats completely okay and acceptable to me
• kstrauser 11mo ago
  I agree with everything you've said here, except that the reality of speaking with a "rust first" developer is making me feel suddenly ancient. But that aside, the memory safety parts are a huge benefit, but far from the only one. Option and Result types are delightful. Exhaustive matching expressions that won't compile if you add a new variant that's not handled are huge. Types that make it impossible to accidentally pass a PngImage into a function expecting a str, even though they might both be defined as contiguous series of bytes down deep, makes lots of bugs impossible. A compiler that gives you freaking amazing error messages that tell you exactly what you did wrong and how you can fix it sets the standard, from my experience. And things like "cargo clippy" which tell you how you could improve your code, even if it's already working, to make it more efficient or more idiomatic, are icing on the cake. People so often get hung up on Rust's memory safety features, and dismiss is as through that's all it brings to the table. Far from it! Even if Rust were unsafe by default, I'd still rather use it that, say, C or C++ to develop large, robust apps because it has a long list of features that make it easy to write correct code, and really freaking challenging to write blatantly incorrect code. Frankly, I envy you, except that I don't envy what it's going to be like when you have to hack on a non-Rust code base that lacks a lot of these features. "What do you mean, int overflow. Those are both constants! How come it didn't let me know I couldn't add them together?"