5 ms·

I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. It's a mature, serious competitor to

I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. It's a mature, serious competitor to well established languages like C++ and C#. This is particularly important when trying to compare the experience of using Rust to other languages in the "better C/C++" space like Zig and Odin -- these are much newer and have more rough edges than Rust.

tialaramex 21d ago
Rust 1.0 was in 2015. Most of these languages you're thinking of out of the Handmade Community didn't even start development until around the point Rust 1.0 shipped. In theory Odin 2027, the 1.0 release of Bill's Odin language, is scheduled for, as the name suggests, early 2027. Zig does not have an announced 1.0 schedule, and who knows for the other two famous Handmade languages. From the rash of "C++ successor" languages a few years ago, Carbon is still being worked on, Herb Sutter's "Cpp2" seems dead or at least in a coma, Hylo is probably also in a coma, it has several "Write this text" type blog posts, dated 2025 for example...
- hiccuphippo 21d ago
  > other two famous Handmade languages Jai and... C3? FilC?
  - tialaramex 21d ago
    Jai and C3. I do not consider FilC to be a distinct programming language. AIUI the C I wrote twenty years ago would work with Filip's approach, maybe it needs minor tweaks in a few cases (mmap stunts for example) but likely not for much of what I wrote.
- zamalek 21d ago
  To Odin's credit, it is used for production software that _isn't_ a toy (by the language's own authors). It is probably 1.0 quality already.
  - afdbcreid 21d ago
    Zig too. But this is far from being mainstream. Rust took around 5 years I think to become accepted in major companies, and those languages are harder to justify.
    - zamalek 21d ago
      I've started distrusting anything good people have to say about Zig because of the wide variety of untrue claims made about it - unless those claims come from Andrew himself. Last time I was assured that compile-time memory guarantees were possible and were going to happen (they didn't: the recent announcement is runtime/debug assertions). Zig is still making massive breaking changes, and while that is not a bad thing, it makes it categorically _not_ production ready.
      - pjmlp 20d ago
        Also note that isn't much different from debug heap that MSCV was already having in 2000[0], assuming you didn't want to shell out some money to Insure++{1], BoundsChecker[2] and similar products. Or something like SoftBound, from 2009, https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf It hasn't been for lack of choice. [0] - https://learn.microsoft.com/en-us/cpp/c-runtime-library/debug-versions-of-heap-allocation-functions?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/debu... [1] - https://www.parasoft.com/products/parasoft-insure/ https://www.parasoft.com/products/parasoft-insure/ [2] - https://en.wikipedia.org/wiki/BoundsChecker https://en.wikipedia.org/wiki/BoundsChecker
  - tialaramex 21d ago
    If you want to imagine a "1.0 quality" which means "Is used in some software that isn't a toy" then all kinda of crap counts. Bill has given specific goals, I don't think he'll meet them or perhaps even understands how high those bars are†, but even by his understanding Odin hasn't reached those goals. Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use. One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired. † In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.
- pjmlp 21d ago
  From what I could understand regarding Sean Parent's last interview at ADSP, Hylo is most likely not happening at all, given the raise of AI tooling, with Dave Abrahams re-focusing into non-computing related work going forward, https://adspthepodcast.com/2026/08/21/Episode-300.html https://adspthepodcast.com/2026/08/21/Episode-300.html Cpp2 was Herb's experiment and doesn't seem to be developed much further now, https://github.com/hsutter/cppfront/discussions/1450 https://github.com/hsutter/cppfront/discussions/1450 Google is still quite keen in having Carbon, for the purpose of migrating existing C++ codebases, for new code there is Rust, Go, Kotlin, Java, Swift and co. "Carbon: graduating from the experiment - NDC Toronto 2026" https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9 https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9
- ryukoposting 21d ago
  As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves. Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.
  - afdbcreid 21d ago
    Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.
    - ryukoposting 18d ago
      It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with. If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust! It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art. This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.
  - skavi 21d ago
    All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.
- 4k0hz 21d ago
  [dead]
Havoc 21d ago
For me it was the inclusion in the kernel. That locks it in as here to stay
- stillpointlab 21d ago
  I thought it got pushed back out? Wasn't there a big drama about this and Linus weighed in? Linus is a wise operator at this point. I often see him come in like a hammer to bash down squabbling, but then he allows the situation to evolve once things quiet down. I only saw the hammer so I'm not sure what the current state is now.
  - Mond_ 21d ago
    Where did you hear that it got pushed back out? It's going strong as far as I can tell.
    - stillpointlab 21d ago
      I was thinking of the public clash in 2025 between Christoph Hellwig which lead to the resignation of Hector Martin, lead of the Asahi Linux project. It looks like later, in December 2025, Rust was officially moved from experimental to official: https://lwn.net/Articles/1049831/ https://lwn.net/Articles/1049831/
      - bilkow 21d ago
        I think what Linus pushed back on was specifically "social media brigading" as a solution to internal issues: https://lkml.org/lkml/2025/2/6/1292 https://lkml.org/lkml/2025/2/6/1292
        MBCook 20d ago
        In this case it arguably helped. I do wonder how much longer that stalemate would have gone on without the blow up. I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.
nicoburns 21d ago
Indeed, unless you're using Safari, you're almost certainly using Rust code to read this webpage.
- afdbcreid 21d ago
  Allegedly, there is Rust in macOS (but maybe not in iOS), so maybe it's true even if you're using Safari.
  - pjmlp 20d ago
    Why, when they have Swift for that role?
stusmall 21d ago
>I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore I see this on here a lot on this site, but Rust hasn't been that in over a decade. Rust's devotion to post 1.0 stability is massive and has involved some interesting design choices. I started writing run in 2015(?) and only hit one breaking change in the language. It was a niche bug in a macro that was fixed later in a later release. Just watching hackernews you see lots of news about it, but these are additive and not breaking things. I was still writing lots of mio-style async code after async await was out. You don't have to adapt new style or libraries. I used to have a joke that you could tell a codebase's age based on the error handling libraries used, but even with that it was additive. Often multiple would exist in different parts of the same code base. "Oh wow, I've gone deep on this refactor.... I'm starting to see error_chain"
- i2talics 21d ago
  Hah, I remember error_chain. One of my projects during an internship was upgrading a bunch of the old error handling libraries to the new things. I'm glad that corner of the ecosystem has stabilized now. At that same job we hit a pretty nasty breaking change where mem::uninitialized() was deprecated and this turned out to cause a lot of critical async libraries to explode at runtime. But these sorts of things don't really happen anymore. The editions system is an excellent design and a big contributor to making the language and stdlib reliable.
grougnax 21d ago
[dead]
hn_submit 21d ago
I'm personally a big fan of garbage collected languages. It's just unfortunate that Microsoft chose C# not to be Ahead-of-Time (AOT) compiled but running on a virtual machine like Java (after which it was modeled after). Alas, that ship has sailed and Rust has many interesting features so I'm comfy with it taking over the role of C/C++ over the next decades.
- el_benhameen 21d ago
  Native AOT with C#/.net has come a long way, fwiw. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
  - hn_submit 20d ago
    Some deployments can be AOT compiled (ASP.NET, mobile), others (like WinForms, WPF) cannot. That makes it confusing and fickle since not all language features work with AOT. Microsoft needs to choose for AOT Full Monty and leave the CLR behind.
    - kbolino 20d ago
      The CLR is the reason most C# games are moddable.
      - throwaway273748 20d ago
        For a definition of moddable that boils down to "download random executable blobs from some anonymous Discord and let them completely loose on your device". With predictable consequences. [0] Whereas Bethesda and Paradox (mainline strategy) games are examples of games that are intentionally moddable, with Cpp cores wrapping sanely defined content sandboxes. Frankly I'd rather the C# style of modding didn't exist at all. It usually means the devs haven't thought about how mods should hook in at all, beyond "inject whatever you want and we'll break it on almost every update. Also, we don't have the resources to review mods so expect them to occasionally be/come malware. We take no responsibility even though we're literally the ones distributing the malware to you via our first party mod store." [0] https://www.pcgamesn.com/cities-skylines-2/hacked-mod https://www.pcgamesn.com/cities-skylines-2/hacked-mod
shevy-java 21d ago
I was making the same argument just a moment before, using TIOBE. Now TIOBE is awful, but Rust is at rank #10 right now. I think this settles the older discussion as to whether Rust will prevail or not.
- i2talics 21d ago
  Meh, I don't really trust TIOBE. It's at best a very noisy signal. And languages can end up on there for unusual reasons.
fishfasell 21d ago
Rust is a serious contender for the next mainstream, widely adopted low level language.
- hn_submit 20d ago
  I would say it already is. But it takes time for all software to be rewritten in Rust.
krater23 21d ago
I expect that using Rust is in some years just the sign for vibe coded shit that only doesn't crashes every two minutes because the compiler is stopping the AI from doing the really dumb things.
hulitu 20d ago
> I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. I bet you never heard of Microsoft. Fast, they don't move. But boy, are they slow at fixing bugs.
teddyh 20d ago
Get back to me when Rust has a stable ABI and can produce dynamically linked binaries.
- tcfhgj 20d ago
  Rust supports opting into the C ABI
  - teddyh 20d ago
    So does any other language which wants to be useful; being able to call C functions is table stakes for a systems programming language. But Rust itself can still only generate static binaries, because Rust doesn’t have a stable ABI.
    - tcfhgj 20d ago
      I am not talking about calling C functions, but about providing a stable ABI for your binary.
      - teddyh 18d ago
        Can a Rust program be compiled, by the normal Rust compiler, into a dynamically linked binary, linked to Rust libraries, by “opting in” to the C ABI?
        bryanlarsen 15d ago
        More than C++ can.

tialaramex 21d ago

Rust 1.0 was in 2015. Most of these languages you're thinking of out of the Handmade Community didn't even start development until around the point Rust 1.0 shipped. In theory Odin 2027, the 1.0 release of Bill's Odin language, is scheduled for, as the name suggests, early 2027. Zig does not have an announced 1.0 schedule, and who knows for the other two famous Handmade languages. From the rash of "C++ successor" languages a few years ago, Carbon is still being worked on, Herb Sutter's "Cpp2" seems dead or at least in a coma, Hylo is probably also in a coma, it has several "Write this text" type blog posts, dated 2025 for example...

hiccuphippo 21d ago
> other two famous Handmade languages Jai and... C3? FilC?
- tialaramex 21d ago
  Jai and C3. I do not consider FilC to be a distinct programming language. AIUI the C I wrote twenty years ago would work with Filip's approach, maybe it needs minor tweaks in a few cases (mmap stunts for example) but likely not for much of what I wrote.
zamalek 21d ago
To Odin's credit, it is used for production software that _isn't_ a toy (by the language's own authors). It is probably 1.0 quality already.
- afdbcreid 21d ago
  Zig too. But this is far from being mainstream. Rust took around 5 years I think to become accepted in major companies, and those languages are harder to justify.
  - zamalek 21d ago
    I've started distrusting anything good people have to say about Zig because of the wide variety of untrue claims made about it - unless those claims come from Andrew himself. Last time I was assured that compile-time memory guarantees were possible and were going to happen (they didn't: the recent announcement is runtime/debug assertions). Zig is still making massive breaking changes, and while that is not a bad thing, it makes it categorically _not_ production ready.
    - pjmlp 20d ago
      Also note that isn't much different from debug heap that MSCV was already having in 2000[0], assuming you didn't want to shell out some money to Insure++{1], BoundsChecker[2] and similar products. Or something like SoftBound, from 2009, https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf https://llvm.org/pubs/2009-06-PLDI-SoftBound.pdf It hasn't been for lack of choice. [0] - https://learn.microsoft.com/en-us/cpp/c-runtime-library/debug-versions-of-heap-allocation-functions?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/debu... [1] - https://www.parasoft.com/products/parasoft-insure/ https://www.parasoft.com/products/parasoft-insure/ [2] - https://en.wikipedia.org/wiki/BoundsChecker https://en.wikipedia.org/wiki/BoundsChecker
- tialaramex 21d ago
  If you want to imagine a "1.0 quality" which means "Is used in some software that isn't a toy" then all kinda of crap counts. Bill has given specific goals, I don't think he'll meet them or perhaps even understands how high those bars are†, but even by his understanding Odin hasn't reached those goals. Unlike Jai you can just download Odin and see for yourself, it has the particular things Bill prioritized (swizzling, a very particular way to do generic programming) and it doesn't have things which Bill feels are a mistake (most obviously package management, but also closures, first class user-defined types, macros, I could go on). The resulting perf isn't very good, and to me it "feels" clumsy to use. One of the striking things in the Handmade languages is that they're so often wedded to LLVM and so in that respect they're much worse than C which of course isn't even wedded to modern architectural choices like 8-bit bytes, much less LLVM. Zig is the most free of this peculiar curse, which is ironic because years ago Bill called out Zig as unable to escape this, while insisting Odin would not require LLVM - the reverse of what actually transpired. † In particular Bill thinks he's going to completely specify the language. Anyone who works on this problem for WG14 (C), WG21 (C++) or Rust knows that's basically a rabbit hole made entirely of more rabbit holes. I think Oracle's Java has a complete specification, and maybe TC39 has one for "Javascript" neither of those were uh, cheap or easy.
pjmlp 21d ago
From what I could understand regarding Sean Parent's last interview at ADSP, Hylo is most likely not happening at all, given the raise of AI tooling, with Dave Abrahams re-focusing into non-computing related work going forward, https://adspthepodcast.com/2026/08/21/Episode-300.html https://adspthepodcast.com/2026/08/21/Episode-300.html Cpp2 was Herb's experiment and doesn't seem to be developed much further now, https://github.com/hsutter/cppfront/discussions/1450 https://github.com/hsutter/cppfront/discussions/1450 Google is still quite keen in having Carbon, for the purpose of migrating existing C++ codebases, for new code there is Rust, Go, Kotlin, Java, Swift and co. "Carbon: graduating from the experiment - NDC Toronto 2026" https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9 https://www.youtube.com/watch?v=WJl4ftb5Fxg&t=9
ryukoposting 21d ago
As an embedded dev, it still feels a decade away, at least. Rust is perfectly usable as a lang to make a little module that links into your main project as a .a file. But, as the language for your whole embedded codebase? Forget it. I have a litany of complaints including Cargo fuckery, ecosystem neglect, lack of first-party support, excessive code size, bad documentation, and bad IR that wastes stack by creating copies on immutable moves. Don't get me wrong, Rust is lightyears ahead of any other alleged C/C++ successor. But I work in a space where C and C++ have been the only option for the last 30 years with absolutely no production-ready alternative. It looks like that won't be changing anytime soon, which is disappointing.
- afdbcreid 21d ago
  Rust is already used in production for embedded (although only here and there). Not all places are ready, but I don't believe it's a decade away anymore.
  - ryukoposting 18d ago
    It really depends what you count as "used in production." I don't count "one Rust library crate linked into your Zephyr/FreeRTOS/whatever project." I have yet to see any production bare-metal codebase written exclusively in Rust, at least at the kind of scale I deal with. If you're in the middle of a supply chain like I am, often times your code is actually a reference design that gets forked by an OEM, tweaked to their liking, and integrated into a product. If the OEMs don't know Rust, they aren't gonna like it if I start handing them Rust reference code. Spoiler alert: they don't know Rust! It goes the other way, too. A huge part of my job is working with drivers from Microchip, or Infineon, or Nordic, or whoever. They won't give me drivers in Rust. I could LLM my way out of that problem, but now I fully own my drivers with no first-party support, which is a huge step backwards from the current state of the art. This isn't Rust's fault, of course, but it means that there's a ton of inertia, and that magnifies the effects of the issues that are Rust's fault.
- skavi 21d ago
  All reasonable pain points. On the "Cargo fuckery" though, you might consider switching to an alternate build system like Bazel. Comes with its own set of issues (rustc isn't tied to Cargo, but the third party ecosystem definitely assumes it). But for embedded where you're cross compiling and working with C and C++ as well, I find it's a better solution than Cargo.
4k0hz 21d ago
[dead]

Havoc 21d ago

For me it was the inclusion in the kernel. That locks it in as here to stay

stillpointlab 21d ago
I thought it got pushed back out? Wasn't there a big drama about this and Linus weighed in? Linus is a wise operator at this point. I often see him come in like a hammer to bash down squabbling, but then he allows the situation to evolve once things quiet down. I only saw the hammer so I'm not sure what the current state is now.
- Mond_ 21d ago
  Where did you hear that it got pushed back out? It's going strong as far as I can tell.
  - stillpointlab 21d ago
    I was thinking of the public clash in 2025 between Christoph Hellwig which lead to the resignation of Hector Martin, lead of the Asahi Linux project. It looks like later, in December 2025, Rust was officially moved from experimental to official: https://lwn.net/Articles/1049831/ https://lwn.net/Articles/1049831/
    - bilkow 21d ago
      I think what Linus pushed back on was specifically "social media brigading" as a solution to internal issues: https://lkml.org/lkml/2025/2/6/1292 https://lkml.org/lkml/2025/2/6/1292
      - MBCook 20d ago
        In this case it arguably helped. I do wonder how much longer that stalemate would have gone on without the blow up. I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.

nicoburns 21d ago

Indeed, unless you're using Safari, you're almost certainly using Rust code to read this webpage.

afdbcreid 21d ago
Allegedly, there is Rust in macOS (but maybe not in iOS), so maybe it's true even if you're using Safari.
- pjmlp 20d ago
  Why, when they have Swift for that role?

stusmall 21d ago

>I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore I see this on here a lot on this site, but Rust hasn't been that in over a decade. Rust's devotion to post 1.0 stability is massive and has involved some interesting design choices. I started writing run in 2015(?) and only hit one breaking change in the language. It was a niche bug in a macro that was fixed later in a later release. Just watching hackernews you see lots of news about it, but these are additive and not breaking things. I was still writing lots of mio-style async code after async await was out. You don't have to adapt new style or libraries. I used to have a joke that you could tell a codebase's age based on the error handling libraries used, but even with that it was additive. Often multiple would exist in different parts of the same code base. "Oh wow, I've gone deep on this refactor.... I'm starting to see error_chain"

i2talics 21d ago
Hah, I remember error_chain. One of my projects during an internship was upgrading a bunch of the old error handling libraries to the new things. I'm glad that corner of the ecosystem has stabilized now. At that same job we hit a pretty nasty breaking change where mem::uninitialized() was deprecated and this turned out to cause a lot of critical async libraries to explode at runtime. But these sorts of things don't really happen anymore. The editions system is an excellent design and a big contributor to making the language and stdlib reliable.

grougnax 21d ago

[dead]

hn_submit 21d ago

I'm personally a big fan of garbage collected languages. It's just unfortunate that Microsoft chose C# not to be Ahead-of-Time (AOT) compiled but running on a virtual machine like Java (after which it was modeled after). Alas, that ship has sailed and Rust has many interesting features so I'm comfy with it taking over the role of C/C++ over the next decades.

el_benhameen 21d ago
Native AOT with C#/.net has come a long way, fwiw. https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/ https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...
- hn_submit 20d ago
  Some deployments can be AOT compiled (ASP.NET, mobile), others (like WinForms, WPF) cannot. That makes it confusing and fickle since not all language features work with AOT. Microsoft needs to choose for AOT Full Monty and leave the CLR behind.
  - kbolino 20d ago
    The CLR is the reason most C# games are moddable.
    - throwaway273748 20d ago
      For a definition of moddable that boils down to "download random executable blobs from some anonymous Discord and let them completely loose on your device". With predictable consequences. [0] Whereas Bethesda and Paradox (mainline strategy) games are examples of games that are intentionally moddable, with Cpp cores wrapping sanely defined content sandboxes. Frankly I'd rather the C# style of modding didn't exist at all. It usually means the devs haven't thought about how mods should hook in at all, beyond "inject whatever you want and we'll break it on almost every update. Also, we don't have the resources to review mods so expect them to occasionally be/come malware. We take no responsibility even though we're literally the ones distributing the malware to you via our first party mod store." [0] https://www.pcgamesn.com/cities-skylines-2/hacked-mod https://www.pcgamesn.com/cities-skylines-2/hacked-mod

shevy-java 21d ago

I was making the same argument just a moment before, using TIOBE. Now TIOBE is awful, but Rust is at rank #10 right now. I think this settles the older discussion as to whether Rust will prevail or not.

i2talics 21d ago
Meh, I don't really trust TIOBE. It's at best a very noisy signal. And languages can end up on there for unusual reasons.

fishfasell 21d ago

Rust is a serious contender for the next mainstream, widely adopted low level language.

hn_submit 20d ago
I would say it already is. But it takes time for all software to be rewritten in Rust.

krater23 21d ago

I expect that using Rust is in some years just the sign for vibe coded shit that only doesn't crashes every two minutes because the compiler is stopping the AI from doing the really dumb things.

hulitu 20d ago

> I hope announcements like this show that Rust is not a fledgling little language that moves fast and breaks things anymore. I bet you never heard of Microsoft. Fast, they don't move. But boy, are they slow at fixing bugs.

teddyh 20d ago

Get back to me when Rust has a stable ABI and can produce dynamically linked binaries.

tcfhgj 20d ago
Rust supports opting into the C ABI
- teddyh 20d ago
  So does any other language which wants to be useful; being able to call C functions is table stakes for a systems programming language. But Rust itself can still only generate static binaries, because Rust doesn’t have a stable ABI.
  - tcfhgj 20d ago
    I am not talking about calling C functions, but about providing a stable ABI for your binary.
    - teddyh 18d ago
      Can a Rust program be compiled, by the normal Rust compiler, into a dynamically linked binary, linked to Rust libraries, by “opting in” to the C ABI?
      - bryanlarsen 15d ago
        More than C++ can.