Wedson Almeida Filho is a Microsoft engineer who has been prolific in his contributions to the Rust for the Linux kernel code over the past several years. Wedson has worked on many Rust Linux kernel features and even did a experimental EXT2 file-system driver port to Rust. But he’s had enough and is now stepping away from the Rust for Linux efforts.

From Wedon’s post on the kernel mailing list:

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them.

…

I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.

Lastly, I’ll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 – and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code."

  • Daniel Quinn@lemmy.caEnglish
    1202·
    2 months ago

    Oof, that video… I don’t have enough patience to put up with that sort of thing either. I wonder how plausible a complete Rust fork of the kernel would be.

    • rollmagma@lemmy.world
      991·
      2 months ago

      It’s always been this way. Except that it was kernel developers arguing with kernel developers over C code. Now it’s relative newcomers arguing with kernel developers over Rust code that the kernel devs don’t necessarily care about. Of course it’s going to be a mess.

      A fork is of course possible, but operating systems are huge and very complex, you really don’t want to alienate these folks that have been doing exclusively this for 30 years. It would be hard to keep the OS commercially viable with a smaller group and having to do both the day to day maintenance, plus the rewrite. It’s already difficult as it is currently.

      Rust will be a huge success in time, long after the current names have lost their impetus. This is not a “grind for 4 years and it’s done” project.

      • ramble81@lemm.ee
        1840·
        2 months ago

        folks that have been doing this exclusively for 30 years

        And yet the number of people I hear “just switch to Linux!” When the other person has been using Windows for 30 years blows my mind.

        Inertia is a hell of a drug.

        • superkret@feddit.org
          704·
          2 months ago

          I wouldn’t tell a Windows developer with 30 years experience to just switch to developing for Linux.
          Users are different. Most people who have used Windows for 30 years never touch anything outside of the desktop, taskbar and Explorer.

          • Hotzilla@sopuli.xyz
            12·
            2 months ago

            I have been using Windows for 30 years and Linux for 25 years (debian since 99’). I really would not bash (pun intended) windows users so much, there is place for both of them.

          • ILikeBoobies@lemmy.ca
            42·
            2 months ago

            It’s insane to find a windows user that doesn’t live in the terminal, it’s just not designed for it

            Linux has a gui for everything

    • Vincent@feddit.nl
      671·
      2 months ago

      That person in the audience was really grinding my gears. Just let the folks you’re talking to answer you; no need to keep going on your diatribe when it’s based on a false assumption and waste the whole room’s time.

      • moriquende@lemmy.world
        17·
        2 months ago

        let’s not lose focus of what’s important here, and that is a room full of people hearing my voice and paying attention to me for as long as I manage to hold it

    • floofloof@lemmy.caEnglish
      341·
      2 months ago

      I wonder how plausible a complete Rust fork of the kernel would be.

      It sounds highly impractical, and it would probably introduce more issues than Rust solves, even if there were enough people with enough free time to do it. Any change must be evolutionary if it’s going to be achievable.

    • cerement@slrpnk.net
      261·
      2 months ago

      NOT a fork of Linux, but Redox is aiming for a Unix-like OS based on Rust – but even with “source compatibility” with Linux/BSD and drivers being in userspace, my guess would be hardware drivers are still going to be a big speed bump

      • merthyr1831@lemmy.mlEnglish
        10·
        2 months ago

        All you need nowadays for a decent Unix-like is compatibility with a handful of Linux softwares and a web browser. Hell, if you could get WINE working on your kernel you could maybe support as many Windows apps/games as Linux for free.

        The big issue, as I see it, is performant drivers for a wide range of hardware. That doesn’t come easy, but I wonder if that can be addressed in a way I’m too inexperienced to know.

        But projects like Redox are a genuine threat to the hegemony of Linux - if memory safety isn’t given the true recognition it deserves, projects like Redox serve to be the same disrupting force as Linux once was for UNIX.

    • ikidd@lemmy.worldEnglish
      152·
      2 months ago

      Just fork and port Ext4 to Rust and let the little shit sit in his leaking kiddy pool out back.

    • WarmApplePieShrek@lemmy.dbzer0.comEnglish
      44·
      2 months ago

      You should do it. The Linux kernel is a C project. You can’t change a 30-year project on a dime. Make your own project with Rust and hookers.

  • youmaynotknow@lemmy.ml
    1052·
    2 months ago

    Ted Ts’o is a prick with a god complex. I understand his experience is hard to match, we all have something in our lives we’re that good at, but that does not need to lead to acting like a fucking religious fanatic.

    • pivot_root@lemmy.world
      1403·
      2 months ago

      I understand his experience is hard to match, we all have something in our lives we’re that good at

      At some point, that mix of experience and ego becomes a significant liability. He’s directly hurting the adoption of Rust in the kernel, while the C code he’s responsible for is full of problems that would have been impossible if written in safe Rust.

      CVE-2024-42304 — crash from undocumented function parameter invariants
      CVE-2024-40955 — out of bounds read
      CVE-2024-0775 — use-after-free
      CVE-2023-2513 — use-after-free
      CVE-2023-1252 — use-after-free
      CVE-2022-1184 — use-after-free
      CVE-2020-14314 — out of bounds read
      CVE-2019-19447 — use-after-free
      CVE-2018-10879 — use-after-free
      CVE-2018-10878 — out of bounds write
      CVE-2018-10881 — out of bounds read
      CVE-2015-8324 — null pointer dereference
      CVE-2014-8086 — race condition
      CVE-2011-2493 — call function pointer in uninitialized struct
      CVE-2009-0748 — null pointer dereference

      • Flipper@feddit.org
        28·
        2 months ago

        crash from undocumented function parameter invariants

        My favourite, as that was the exact point the dev was making in his talk, that the stuff is badly documented and that the function signature would document it perfectly.

        • WarmApplePieShrek@lemmy.dbzer0.comEnglish
          25·
          2 months ago

          My favorite, as that is the exact point made by anti-rust people.

          What kind of type signature would prove the first block of any directory in an ext4 filesystem image isn’t a hole?

          • pivot_root@lemmy.world
            131·
            2 months ago

            The first directory block is a hole. But type == DIRENT, so no error is reported. After that, we get a directory block without ‘.’ and ‘…’ but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash

            The problem isn’t that the block is a hole. It’s that the downstream function expects the directory block to contain . and .., and it gets given one without because of incorrect error handling.

            You can encode the invariant of “has dot and dot dot” using a refinement type and smart constructor. The refined type would be a directory block with a guarantee it meets that invariant, and an instance of it could only be created through a function that validates the invariant. If the invariant is met, you get the refined type. If it isn’t, you only get an error.

            This doesn’t work in C, but in languages with stricter type systems, refinement types are a huge advantage.

              • pivot_root@lemmy.world
                3·
                2 months ago

                If it were poorly designed and used exceptions, yes. The correct way to design smart constructors is to not actually use a constructor directly but instead use a static method that forces the caller to handle both cases (or explicitly ignore the failure case). The static method would have a return type that either indicates “success and here’s the refined type” or “error and this is why.”

                In Rust terminology, that would be a Result<T, Error>.

                For Go, it would be (*RefinedType, error) (where dereferencing the first value without checking it would be at your own peril).

                C++ would look similar to Rust, but it doesn’t come as part of the standard library last I checked.

                C doesn’t have the language-level features to be able to do this. You can’t make a refined type that’s accessible as a type while also making it impossible to construct arbitrarily.

    • IAmNotACat@lemmy.world
      372·
      2 months ago

      Agreed. His experience might be useful if he were there to engage, but he’s clearly not. It seems like he just wanted to shout down the project and it seems like he was somewhat successful.

    • qqq@lemmy.world
      378·
      2 months ago

      No intention of validating that behavior, it’s uncalled for and childish, but I think there is another bit of “nontechnical nonsense” on the opposite side of this silly religious war: the RIIR crowd. Longstanding C projects (sometimes even projects written in dynamic languages…?) get people that know very little about the project, or at least have never contributed, asking for it to be rewritten or refactored in Rust, and that’s likely just as tiring as the defensive C people when you want to include Rust in the kernel.

      People need to chill out on both sides of this weird religious war. A programming language is just a tool: its merits in a given situation should be discussed logically.

      • JackbyDev@programming.devEnglish
        101·
        2 months ago

        I imagine this mentality is frustrating because of how many times they have to explain that they weren’t forcing people to learn Rust and that the Rust bindings were second class citizens. They never said to rewrite the kernel in Rust.

        • wewbull@feddit.ukEnglish
          128·
          2 months ago

          That’s disengenuous though.

          • We’re not forcing you to learn rust. We’ll just place code in your security critical project in a language you don’t know.

          • Rust is a second class citizen, but we feel rust is the superior language and all code should eventually benefit from it’s memory safety.

          • We’re not suggesting that code needs to be rewritten in rust, but the Linux kernel development must internalise the need for memory safe languages.

          No other language community does what the rust community does. Haskellers don’t go to the Emacs project and say “We’d like to write Emacs modules, but we think Haskell is a much nicer and safer functional language than Lisp, so how about we add the capability of using Haskell and Lisp?”. Pythonistas didn’t add Python support to Rails along side Ruby.

          Rusties seem to want to convert everyone by Trojan horsing their way into communities. It’s extremely damaging, both to those communities and to rust itself.

          • CancerMancer@sh.itjust.works
            31·
            2 months ago

            It doesn’t help that the Rust community tends to bring extremely divisive politics with it in places and ways that just don’t need to happen, starting battles that aren’t even tangentially related to programming.

      • youmaynotknow@lemmy.ml
        21·
        2 months ago

        He’s the guy you hear vexing rust in the video posted. While both languages have their pros and cons, he chooses to just blast this other guy by repeating the same crap over and over without letting him reply. Basically the kind of person with a “I win because I’m louder” demeanor.

  • Findmysec@infosec.pubEnglish
    8217·
    2 months ago

    Who the fuck is this little shit? Can’t they even be a little considerate towards rust? Just because they have 15 years worth of inertia for C doesn’t mean they can close their eyes and say “nope, I’m not interested”. I do not see how the kernel can survive without making rust a first class citizen

  • antihumanitarian@lemmy.worldEnglish
    64·
    2 months ago

    The comments from that article are some of the most vitriolic I’ve ever seen on a technical issue. Goes to prove the maintainer’s point though.

    Some are good for a laugh though, like assertions that Rust in the kernel is a Microsoft sabotage op or LLVM is for grifters and thieves.

  • JackbyDev@programming.devEnglish
    561·
    2 months ago

    This is a little off topic and admittedly an oversimplification, but people saying Rust’s memory safety isn’t a big deal remind me of people saying static typing isn’t a big deal.

    • Vilian@lemmy.ca
      192·
      2 months ago

      Phoronix comments were always dumb, like, infuriating bad, I don’t even read them anymore, the moderation on that site don’t give a fuck about toxicity in there

      • Vivendi@lemmy.zip
        6·
        2 months ago

        Avis/Bridei/Artem has been active as a super troll on that forum for years and absolutely nothing had been done

      • vividspecter@lemm.ee
        4·
        2 months ago

        Beyond moderation, Phoronix is a case study in why downvotes are a good thing. Those idiots going on dumb tangents would continue, while the rest of us can read the actual worthwhile comments (which does happen, given AMD employees and the like comment there sometimes).

      • Chaotic Entropy@feddit.ukEnglish
        3·
        2 months ago

        I’ve asked one question, one time in those comments and it just got buried in people spitting venom at each other about their file system preferences.

    • morrowind@lemmy.ml
      171·
      2 months ago

      Phoronix comments are a special place on the internet. Don’t go there for a good discussion.

      • Possibly linux@lemmy.zipEnglish
        4·
        2 months ago

        I once started reading the comments on bcachefs. It was a extremely heated for no reason. People were screaming on the nature of btrfs

  • merthyr1831@lemmy.mlEnglish
    4715·
    2 months ago

    The video attached is a perfect example of the kind of “I’m not prepared to learn anything new so everyone else is wrong” attitude that is eating away at Linux like a cancer.

    If memory safety isn’t adopted into the kernel, and C fanaticism discarded, Linux will face the same fate as the kernels it once replaced. Does the Linux foundation want to drag its heels and stuff millions into AI ventures whilst sysadmins quietly shift to new kernels that offer memory safety, or does it want to be part of that future?

    • WarmApplePieShrek@lemmy.dbzer0.comEnglish
      2142·
      2 months ago

      If Linux gets rewritten in Rust it will be a new kernel, not Linux. You can make new kernels, even in Rust but they aren’t Linux. You can advertise them at Linux conferences but you can’t force every Linux dev to work on your new Rust kernel.

      • PotatoesFall@discuss.tchncs.de
        415·
        2 months ago

        There is no “your” new rust kernel. There is a gigantic ship of Theseus that is the Linux kernel, and many parts of it are being rewritten, refactored, removed an added all the time by god knows how many different people. Some of those things will be done in rust.

        Can we stop reacting to this the way conservatives react to gay people? Just let some rust exist. Nobody is forcing everyone to be gay, and nobody is forcing everybody to immediately abandon C and rewrite everything in rust.

      • witx@lemmy.sdf.org
        363·
        2 months ago

        Isn’t Linux still Linux even though probably a lot of the original code is gone? Why would slowly rewriting it whole, or just parts, in Rust make it stop being Linux?

      • merthyr1831@lemmy.mlEnglish
        11·
        2 months ago

        the crew on the Ship of Theseus would like a word with you. Because if you strip out every subsystem and replace them with a different language, everyone would still call it Linux and it would still work as Linux.

        Linux isn’t “a bunch of C code” it’s an API, an ABI, and a bunch of drivers bundled into a monorepo.

  • Caveman@lemmy.world
    332·
    2 months ago

    There’s always going to be pushback on new ideas. He’s basically asking people questions like “Hey how does your thing work? I want to write it in rust.” and gets the answer “I’m not going to learn rust.”.

    I think rust is generally a good thing and with a good amount of tests to enforce behavior it’s possible to a functionally equivalent copy of the current code with no memory issues in future maintenance of it. Rewriting things in rust will also force people to clarify the behavior and all possible theoretical paths a software can take.

    I’m not gonna lie though, if I would have worked on software for 20 years and people would introduce component that’s written in another language my first reaction would be “this feels like a bad idea and doesn’t seem necessary”.

    I really hope that the kernel starts taking rust seriously, it’s a great tool and I think it’s way easier to write correct code in rust than C. C is simple but lacks the guardrails of modern languages which rust has.

    The process of moving to rust is happening but it’s going to take a really long time. It’s a timescale current maintainers don’t really need to worry about since they’ll be retired anyway.

      • apt_install_coffee@lemmy.ml
        15·
        2 months ago

        For the same reason spoken languages often have semantic structures that make a literal translation often cumbersome and incorrect, translating nontrivial code from one language into another without being a near expert in both langauges, as well as being an expert in the project in question, can lead to differences in behaviour varying from “it crashes and takes down the OS with it”, to “it performs worse”.

        • MattMatt@lemmy.worldEnglish
          14·
          2 months ago

          I’ll add that even when you’re an expert in both languages, it’s common to see WTF’s in the original and not be sure if something is a bug or just weird behavior that’s now expected. Especially when going from a looser to a more strict language.

          I’ve translated huge projects and most of the risk is in “you know the original would do the wrong thing in these x circumstances – I’m pretty sure that’s not on purpose but… Maybe? Or maybe now someone depends on it being wrong like this?”

          • Caveman@lemmy.world
            4·
            2 months ago

            Also, even if you think it’s a bug it might be a feature that other people use and “fixing” changing it might break systems.

    • root@precious.net
      3·
      2 months ago

      From a developer standpoint you’re taking someone’s baby, cloning it into a language they don’t understand and deprecating the original. Worse, if you’re not actually interested in taking over the project you’ve now made it abandonware because the original developer lost heart and the person looking for commit counts on GitHub has moved on.

      Obviously these extremes don’t always apply, but a lot of open source relies on people taking a personal interest. If you destroy that, you might just destroy the project.

  • Ginny [they/she]@lemmy.blahaj.zone
    26·
    2 months ago

    I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.

    Maybe that’s not a bad thing? If you ask me the GNU people are missing a trick. Perhaps if they rewrote Hurd in Rust they could finally shed that “/Linux”.

    • fluxx@lemmy.world
      19·
      2 months ago

      Well, I’ve been a C/C++ dev for half of my career, I didn’t find Rust syntax ugly. Some things are better than others, but not a major departure from C/C++. ObjC is where ugly is at. And I even think swift is more ugly. In fact, I can’t find too many that are as close to C/C++ as Rust. As for logic… Well, I want to say you’ll get used to it, but for some things, it’s not true. Rust is a struggle. Whether it’s worth it, is your choice. I personally would take it over C++ any day.

    • OrekiWoof@lemmy.ml
      158·
      2 months ago

      I just don’t understand this. You get used to the syntax and borrow checker in a day or two. It’s a non-issue.

      • thevoidzero@lemmy.world
        10·
        2 months ago

        I wouldn’t say that. For primitives yeah, day or two. But if you want to build a proper program, it’ll take time to get used to it. For my first few projects I just used clone everywhere. Passing by reference and managing lifetimes, specially when writing libraries is something that takes time to get used to. I still don’t feel confident.

        Besides that I do like Rust though. Sometimes I feel like “just let me do that, C let’s me”, but I know it’s just adding safety where C wouldn’t care.

      • pivot_root@lemmy.world
        81·
        2 months ago

        Unless you’re a functional programming purist or coming from a systems programming background, it takes a lot longer than a few days to get used to the borrow checker. If you’re coming as someone who most often uses garbage-collected languages, it’s even worse.

        The problem isn’t so much understanding what the compiler is bitching about, as it is understanding why the paradigm you used isn’t safe and learning how to structure your code differently. That part takes the longest and only really starts to become easier when you learn to stop fighting the language.

        • OrekiWoof@lemmy.ml
          4·
          2 months ago

          I see that my previous comment is not the common reality apparently.

          I’m mainly a C# + js dev of a few years, and I would love to see what precisely other people here are having problems with, because I’ve had a completely different experience to most of the people replying.

      • Metype @lemmy.worldEnglish
        4·
        2 months ago

        I tried for about a week: reading documentation, viewing and modifying example programs, using a Rust IDE with warnings for all my silly mistakes, the works. I couldn’t manage to wrap my head around it. It’s so different from what I’m used to. If I could dedicate like a month to learn it I would, but I don’t have the time :/

    • ReakDuck@lemmy.ml
      4·
      2 months ago

      At rhe beginning, I did hate it. Now I slowly embrace it as it seems like a feature to be mkre verbose.

      But maybe it will never change and I will just gaslight myself liking it. Whatever… you cant take my fun away learning rust for half a year

        • ReakDuck@lemmy.ml
          1·
          2 months ago

          I hate how I can’t do everything I imagine in rust.

          But researching about why something isn’t possible, makes me realize that the code should never be wroten like the way I did… so I can’t blame rust for dissallowing me this.

    • Wooki@lemmy.world
      31·
      2 months ago

      You’ve been blue pilled by null. Once over the hurdle, it’s very eloquent.

      Null is ugly. Tony Hoare apology for inventing it should be enough reason to learn to do better.

  • ik5pvx@lemmy.world
    205·
    2 months ago

    At the cost of sounding naive and stupid, wouldn’t it be possible to improve compilers to not spew out unsafe executables? Maybe as a compile time option so people have time to correct the source.

    • chrash0@lemmy.world
      68·
      2 months ago

      the semantics of C make that virtually impossible. the compiler would have to make some semantics of the language invalid, invalidating patterns that are more than likely highly utilized in existing code, thus we have Rust, which built its semantics around those safety concepts from the beginning. there’s just no way for the compiler to know the lifetime of some variables without some semantic indication

    • it_depends_man@lemmy.worldEnglish
      51·
      2 months ago

      At the cost of sounding naive and stupid

      It may be a naive question, but it’s a very important naive question. Naive doesn’t mean bad.

      The answer is that that is not possible, because the compiler is supposed to translate the very specific language of C into mostly very specific machine instructions. The programmers who wrote the code, did so because they usually expect a very specific behavior. So, that would be broken.

      But also, the “unsafety” is in the behavior of the system and built into the language and the compiler.

      It’s a bit of a flawed comparison, but you can’t build a house on a foundation of wooden poles, because of the advantages that wood offers, and then complain that they are flammable. You can build it in steel, but you have to replace all of the poles. Just the poles on the left side won’t do.

      And you can’t automatically detect the unsafe parts and just patch those either. If we could, we could just fix them directly or we could automatically transpile them. Darpa is trying that at the moment.

      • ik5pvx@lemmy.world
        14·
        2 months ago

        Thank you and all the others that took time to educate me on what is for me a “I know some of those words” subject

    • snaggen@programming.dev
      16·
      2 months ago

      The problem is that C is a prehistoric language and don’t have any of the complex types for example. So, in a modern language you create a String. That string will have a length, and some well defined properties (like encoding and such). With C you have a char * , which is just a pointer to the memory that contains bytes, and hopefully is null terminated. The null termination is defined, but not enforced. Any encoding is whatever the developer had in mind. So the compiler just don’t have the information to make any decisions. In rust you know exactly how long something lives, if something try to use it after that, the compiler can tell you. With C, all lifetimes lives in the developers head, and the compiler have no way of knowing. So, all these typing and properties of modern languages, are basically the implementation of your suggestion.

    • zaphod@sopuli.xyz
      141·
      2 months ago

      Modern C compilers have a lot of features you can use to check for example for memory errors. Rusts borrow-checker is much stricter as it’s designed to be part of the language, but for low-level code like the Linux kernel you’ll end up having to use Rust’s unsafe feature on a lot of code to do things from talking to actual hardware to just implementing certain data structures and then Rust is about as good as C.

    • 0x0@programming.dev
      9·
      2 months ago

      Compilers follow specs and in some cases you can have undefined behavior. You can and should use compiler flags but should complement that with good programming practices (e.g. TDD) and other tools in your pipeline (such as valgrind).

      • henfredemars@infosec.pubEnglish
        4·
        2 months ago

        I’d like to add that there’s a difference between unsafe and unspecified behavior. Sometimes I’d like the compiler to produce my unsafe code that has specified behavior. In this case, I want the compiler to produce exactly that unsafe behavior that was specified according to the language semantics.

        Especially when developing a kernel or in an embedded system, an example would be code that references a pointer from a hardcoded constant address. Perhaps this code then performs pointer arithmetic to access other addresses. It’s clear what the code should literally do, but it’s quite an unsafe thing to do unless you as the developer have some special knowledge that you know the address is accessible and contains data that makes sense to be processed in such a manner. This can be the case when interacting directly with registers representing some physical device or peripheral, but of course, there’s nothing in the language that would suggest doing this is safe. It’s making dangerous assumptions that are not enforced as part of the program. Those assumptions are only true in the program is running on the hardware that makes this a valid thing to do, where that magical address and offsets to that address do represent something I can read in memory.

        Of course, pointer arithmetic can be quite dangerous, but I think the point still stands that behavior can be specified and unsafe in a sense.

    • henfredemars@infosec.pubEnglish
      2·
      2 months ago

      This has been done to a limited extent. Some compilers can check for common cases and you can enforce these warnings as errors. However, this is generally not possible as others have described because the language itself has behaviors that are not safe, and too much code relies on those properties that are fundamentally unsafe.

  • NauticalNoodle@lemmy.ml
    131·
    2 months ago

    I admit I’m biased towards C-languages out of sheer personal preference and limited exposure to Rust but I am wondering, are there any major technical barriers to Rust replacing these languages in it’s current form anymore?

    I know there has been a lot of movement towards supporting Rust in the last 6 years since I’ve become aware of it, but I also get flashbacks from the the early 00’s when I would hear about how Java was destined to replace C++, and the early 2010’s when Python was destined to replace everything only to realize that the hype fundamentally misunderstood the use case limitations of the various languages.

    • bonus_crab@lemmy.world
      6·
      2 months ago

      Its mainly a matter of stabilizing existing features in the language - there are rust modules in the linux kernel as of 6.1 but they have to be compiled with the nightly compiler.

      Rust is a very slow moving , get it right the first time esque, project. Important and relatively fundamental stuff is currently and has been useable and 99% unchanging for years but hasnt been included in the mainline compiler.

      Also certain libraries would be fantastic to have integrated into the standard library, like tokio, anyhow, thiserror, crossbeam, rayon, and serde. If that ever happens though itll be in like a decade.

  • kbal@fedia.io
    92·
    2 months ago

    3min 30s, sample for context

    If you keep watching for 10 minutes, it’s an interesting discussion. Too bad they had to cut it short due to time.