7 ms·

I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I t

I like Zig, lots of great features that work in unison. However the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to. I think it will be a mainstream language though and gain a lot more traction after v1. There is also the issue of will people actually code by then.

cies 8mo ago
I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different. Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C! I expect LLMs to be really good at converting C to Zig. > There is also the issue of will people actually code by then. LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.
- flohofwoe 8mo ago
  > I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different. The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer. > I expect LLMs to be really good at converting C to Zig. While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions). Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
  - zozbot234 8mo ago
    Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
    - flohofwoe 8mo ago
      It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
      - zozbot234 8mo ago
        "You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.
        uecker 8mo ago
        I agree. I am not terribly convinced by C++ or Zig's comptime. You should be able to do this at run-time, and then just be able to make it a constant.
  - cies 8mo ago
    Zig's comptime is an addition. You don't have to use it. And some C-macros may translate quite cleanly to it. OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.
    - pjmlp 8mo ago
      Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.
- pmarreck 8mo ago
  I've been coding in Zig for nearly 2 months straight now. Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig. Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.) All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
  - cies 8mo ago
    I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.
testdelacc1 8mo ago
I wouldn’t worry about that. There’s plenty of software yet to be written, in many languages. If anything, Rust’s success has shown that it’s definitely possible for a new language to succeed if it offers something new. The other tailwind for Zig is that it’s easier than ever to translate an existing codebase with tests into a new language with AI.
- allthetime 8mo ago
  Their own libc project is wicked. They are gradually replacing C implementations with zig and in the mean time the C implementations effortlessly link and compile in the same compilation unit as the zig code.
pron 8mo ago
> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a more normal rate of adoption for a popular language could easily overtake it. > There is also the issue of will people actually code by then. Now that could be a bigger issue. :)
- metaltyphoon 8mo ago
  > Given that Rust is quite an old language now and its adoption is still so low, So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…
  - pron 8mo ago
    Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now. There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).
    - 8mo ago
zozbot234 8mo ago
The more compelling scenario is one where the unsafe subset of Rust itself becomes roughly as easy to use as Zig is today, though still with potential challenges wrt. properly interacting with safe code. That requires literally rethinking every language and standard library facility and asking "is this putting up artificial roadblocks or even invoking straight UB when one tries to use it idiomatically in unsafe contexts?", then coming up with more flexible, more "C like" facilities in that case. It's hard work but quite doable.
- kartoffelsaft 8mo ago
  The roadblock there is a cultural one. Among Rust devs if you ever find the need for an unsafe block then you need an explanation to back it up. If anything, the Rust language would benefit from adding as much friction to unsafe code as possible, so that you're only going to use it when you actually need it. In other words, the Rust approach to safety is to make as few unsafe LoC as possible, and the Zig approach is to make every unsafe line as safe as possible. As long as their philosophical approach to safety is such that Zig makes writing unsafe code easy and Rust avoids it as much as possible, then writing unsafe code in Zig will always be easier.
  - zozbot234 8mo ago
    No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue. > If anything, the Rust language would benefit from adding as much friction to unsafe code as possible The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.
  - phicoh 8mo ago
    The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language. This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code. I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.
flohofwoe 8mo ago
I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around). Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often). I think the era of 'pop star languages' is over, the programming language future is highly diverse (and that's a good thing).
- sgt 8mo ago
  > I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around). This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
  - zozbot234 8mo ago
    Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior. Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.
    - kartoffelsaft 8mo ago
      I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.
      - ceteia 8mo ago
        The GitHub project has some activity at least, and they might be coming with some announcement later this year. https://github.com/carbon-language/carbon-lang/ https://github.com/carbon-language/carbon-lang/
pmarreck 8mo ago
That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-and-the-shift-to-zig-what-it-means-for-developers-4117a7d5d7fa https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-a... https://www.youtube.com/watch?v=dJ5-41u-e7k https://www.youtube.com/watch?v=dJ5-41u-e7k https://weeklyrust.substack.com/p/why-roc-is-moving-away-from-rust https://weeklyrust.substack.com/p/why-roc-is-moving-away-fro... Perhaps there is room for both... via C FFI interop, of course, lol (C FFI will probably long outlast C itself...)
- wolvesechoes 8mo ago
  > why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) Both undoubtedly are talented programmers, but you overestimate impact and importance of these project. GitHub stars and HN posts are not very good indicator of what happens in the real world
  - cbmuser 8mo ago
    I'm not sure why your comment is being downvoted, but it's spot on. Rust has definitely gained some ground while they're hardly any relevant products using Zig.
    - pmarreck 8mo ago
      Ever heard of Bun? Uber? Turso? Vercel? (And the highly-regarded Ghostty terminal of course) I mean, less is true, but “hardly” is doing a lot of work there https://github.com/rofrol/zig-companies-and-organizations https://github.com/rofrol/zig-companies-and-organizations
- pjmlp 8mo ago
  That doesn't mean Microsoft, Google, Apple, Sony, Nintendo, AMD, Intel, NVidia will be jumping into Zig any time now, just because some HN celebrities blogged about it. Those are the companies I care about when chosing which programing languages to invest my time on.
Quothling 8mo ago
Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so that you can compile a requirements.txt and deploy your project without UV, which is handy when you use things like Azure specific Microsoft containers. Maybe it's just C++ teams being conservative, but a lot of them really seem to hate Rust when you talk with them for whatever reason. I can't imagine why though, but then I've only ever worked with C when I had to, and I have never worked with C++. From having played around with both C++ and Rust, I'd personally pick Rust, but I'm sure it's because I don't know enough. Either way I doubt I'll ever see Rust in a real world job in my corner of the world.
- pjmlp 8mo ago
  I guess C++ teams at Microsoft, Google, IBM, Adobe don't count.
  - hu3 8mo ago
    It's not as widespread in these companies as you and many Rust evangelists imply it is. Specially because it's not a drop-in replacement for C++. As Zig is for C. So when Zig hits 1.0 these companies will probably consider Zig much more than they do today. Understandably.
    - pjmlp 8mo ago
      First of all, if I am an evangelist of anything, it is about safe systems programming with automatic resource management languages, if I had a magic wand, we would be talking about languages like D and AOT C#, not Rust. Secondly, let us know when Amazon rewrites Firecracker in Zig, Android replaces Rust with Zig, or Mark Russinovich goes to some Zig conference explaining why Azure is dropping Rust for Zig, "Mark Russinovich, Microsoft Azure CTO tells Rust Nation UK 2025 why Azure is moving to Rust from C++" https://www.youtube.com/watch?v=SmUprpjCWjM https://www.youtube.com/watch?v=SmUprpjCWjM

cies 8mo ago

I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different. Zig OTOH is clearly, to me at least (opinion alert), a "better C". It even compiles C! I expect LLMs to be really good at converting C to Zig. > There is also the issue of will people actually code by then. LLMs don't take responsibility. So even if code is generated, a human will have to assess it. I think assessing Zig is easier than assessing C, which gives this language a selling point that holds out in the AI assisted programming future.

flohofwoe 8mo ago
> I don't think Rust is "a better C/C++". It's a new kind of beast. Interesting, but very different. The same can be said about Zig's comptime. It's entirely unlike anything C, C++ or Rust has to offer. > I expect LLMs to be really good at converting C to Zig. While it's possible to translate C to Zig code - and you don't need an LLM for that, it's a Zig compiler/build-system feature - the result will be quite different from a project that's developed in Zig from the ground up since the translation output wouldn't make use of Zig's unique features (and Zig isn't really unique as 'C translation target', C can also be translated to unsafe Rust, or even to Javascript - see early Emscripten versions). Also, the 'C compatibility' of Zig is implemented via a separate compiler frontend, Rust toolchains could do exactly the same thing by integrating the Clang frontend into the Rust compiler.
- zozbot234 8mo ago
  Using the same language for compile-time and run-time programming is compelling, but doing it properly requires using the same approaches that dependently typed languages use. Comptime is a bit half baked.
  - flohofwoe 8mo ago
    It's not just about writing imperative code that runs at compile time, the actual interesting comptime feature in Zig is that "types are comptime values", e.g. you can inspect types and build new types with regular (comptime) code. This is very different from the template/trait systems in C++ and Rust. What Zig's comptime system is missing is the ability to build functions bodies at comptime (e.g. some sort of comptime AST builder).
    - zozbot234 8mo ago
      "You can inspect types and build new types at compile time" is a key affordance of dependently typed languages.
      - uecker 8mo ago
        I agree. I am not terribly convinced by C++ or Zig's comptime. You should be able to do this at run-time, and then just be able to make it a constant.
- cies 8mo ago
  Zig's comptime is an addition. You don't have to use it. And some C-macros may translate quite cleanly to it. OTOH going from C++ (OO) to Rust (not OO, borrow checker) is a big leap.
  - pjmlp 8mo ago
    Not all C++ is OOP, and Rust does support OOP as per CS literature, so much so that I have had no issues rewriting Raytracing Weekend tutorial from C++ into Rust, while keeping the same OOP architecture from the tutorial.
pmarreck 8mo ago
I've been coding in Zig for nearly 2 months straight now. Or should I say, I've not written a single line of Zig because I've been managing AI's coding in Zig. Turns out Zig is a fantastic language to "centaur" on. (Reference is to "centaur chess" and which is also sort of becoming a term indicating close code design cooperation with an LLM.) All of that C code that the LLM trained on ends up helping it work out algorithms in Zig, except that Zig has waaaay more safety guarantees and checks. And is often faster compiled code than the equivalent C, which is astonishing.
- cies 8mo ago
  I like that I can easily smell bad Zig by looking at it, but I'm notoriously bad at smelling bad C.

testdelacc1 8mo ago

I wouldn’t worry about that. There’s plenty of software yet to be written, in many languages. If anything, Rust’s success has shown that it’s definitely possible for a new language to succeed if it offers something new. The other tailwind for Zig is that it’s easier than ever to translate an existing codebase with tests into a new language with AI.

allthetime 8mo ago
Their own libc project is wicked. They are gradually replacing C implementations with zig and in the mean time the C implementations effortlessly link and compile in the same compilation unit as the zig code.

pron 8mo ago

> the worry is by the time it reaches v1 Rust will have consumed the space that C/C++ used to Given that Rust is quite an old language now and its adoption is still so low, I don't think that should be much of a worry, although that doesn't mean Zig will be the option of choice, and not stabilising is certainly not a good sign. At Rust's adoption rate, a language that hasn't been invented yet and that would show a more normal rate of adoption for a popular language could easily overtake it. > There is also the issue of will people actually code by then. Now that could be a bigger issue. :)

metaltyphoon 8mo ago
> Given that Rust is quite an old language now and its adoption is still so low, So being part of 3 major OS (Windows, Android and now Linux), the big 3 cloud providers having SDKs for the language, used by so much tooling (js + python) and being part of major internet infrastructure means its “slow” adoption then wow…
- pron 8mo ago
  Very much so once you compare it to how quickly C++ (and, in fact, any language that's ever been in the top 5 or so) achieved similar milestones. Rust's adoption is very impressive when you compare it to, say, Haskell or Clojure, but not when you compare it to languages that achieved significant and long-lasting popularity. It's roughly similar to Ada's adoption when it was of a similar age (Ada was more prevalent then than Rust is now in some areas and less so in others). When work on Rust started twenty years ago, Java was younger than Rust is now. It was almost as close in time to the early work on C++ as we are now to the early work on Rust. Larger portions of operating systems were being written in C++ when it was younger than Rust is now. There's no denying Rust's popularity in open-source CLI dev tools for Python and JS/TS, but when you talk to C/C++ shops who've evaluated Rust and see how many of them end up using it (and to what extent) you see it's not like it's been with languages that ended up achieving real popularity (which includes not only super-popular languages like C, C++, and Java, but also mid-popular languages like Go).
  - 8mo ago

zozbot234 8mo ago

The more compelling scenario is one where the unsafe subset of Rust itself becomes roughly as easy to use as Zig is today, though still with potential challenges wrt. properly interacting with safe code. That requires literally rethinking every language and standard library facility and asking "is this putting up artificial roadblocks or even invoking straight UB when one tries to use it idiomatically in unsafe contexts?", then coming up with more flexible, more "C like" facilities in that case. It's hard work but quite doable.

kartoffelsaft 8mo ago
The roadblock there is a cultural one. Among Rust devs if you ever find the need for an unsafe block then you need an explanation to back it up. If anything, the Rust language would benefit from adding as much friction to unsafe code as possible, so that you're only going to use it when you actually need it. In other words, the Rust approach to safety is to make as few unsafe LoC as possible, and the Zig approach is to make every unsafe line as safe as possible. As long as their philosophical approach to safety is such that Zig makes writing unsafe code easy and Rust avoids it as much as possible, then writing unsafe code in Zig will always be easier.
- zozbot234 8mo ago
  No, it's not just a cultural thing. There are very real problems with standard Rust facilities not being accessible/usable from an unsafe context even though the C/C++/Zig idiomatic equivalent would be (i.e. would not invoke instant UB), and these problems are solvable. Sophisticated Rust developers are aware of the issue. > If anything, the Rust language would benefit from adding as much friction to unsafe code as possible The friction is there already. I'm not advocating for getting rid of explicit 'unsafe' markings, 'SAFETY' comments or even clunky boilerplate, just for closing a very real gap in capability.
- phicoh 8mo ago
  The goal of Rust is not so much to avoid unsafe, the goal is to maximize safe code. The reason is that you don't have to check safe code for all the guarantees to get from the Rust language. This has a big effect on unsafe code. When unsafe code gets called indirectly from safe code, the unsafe code has to make sure that whatever the safe code does, the result is still safe. This requires very careful design of the interface provided by the unsafe code. I think it is a research question whether Zig would make writing Rust unsafe code a lot easier. In particular the boundary between safe Rust and unsafe code written in Zig could become very tricky. Possibly tricky enough that it would be as complex to write as unsafe Rust today.

flohofwoe 8mo ago

I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around). Rust will also never replace C or C++ in any meaningful way, at best new code gets written in new languages (and Rust being only one among many, and among languages used for new projects will also be C and C++, just maybe not that often). I think the era of 'pop star languages' is over, the programming language future is highly diverse (and that's a good thing).

sgt 8mo ago
> I think Rust and Zig really don't overlap much when it comes to target audience. E.g. if you're attracted to Rust, you'll probably find Zig terrible (and the other way around). This is ironic since these two crowds are mostly solving the same type of problems. It's just democrats vs republicans type of split, some of it is just for show and philosophical.
- zozbot234 8mo ago
  Rust is solving the memory safety problem, Zig is solving the 'idiomatic interop with existing C coding patterns' problem. These couldn't be more different - C-like idiomatic code is generally antithetical to 'safe' modularity since it often relies on tacit global invariants for correct behavior. Interestingly, Carbon is kinda trying to tackle both at the same time (though starting from C++ in their case) which is a bit of a challenge.
  - kartoffelsaft 8mo ago
    I hear Cardon get mention on rare occasion, and with how rare that is I have to assume it's been completely stagnant. Does it offer anything over C++ in current year? Seems like C++ interop begets turning your language into C++ with different syntax in a way that C interop just doesn't.
    - ceteia 8mo ago
      The GitHub project has some activity at least, and they might be coming with some announcement later this year. https://github.com/carbon-language/carbon-lang/ https://github.com/carbon-language/carbon-lang/

pmarreck 8mo ago

That won't happen if there are legitimate reasons why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) chose Zig over Rust for their work. They both blogged about it https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-and-the-shift-to-zig-what-it-means-for-developers-4117a7d5d7fa https://tomas-svojanovsky.medium.com/mitchell-hashimoto-go-a... https://www.youtube.com/watch?v=dJ5-41u-e7k https://www.youtube.com/watch?v=dJ5-41u-e7k https://weeklyrust.substack.com/p/why-roc-is-moving-away-from-rust https://weeklyrust.substack.com/p/why-roc-is-moving-away-fro... Perhaps there is room for both... via C FFI interop, of course, lol (C FFI will probably long outlast C itself...)

wolvesechoes 8mo ago
> why both Mitchell Hashimoto (creator of Ghostty etc.) and Richard Feldman (of Elm fame, creator of Roc-lang) Both undoubtedly are talented programmers, but you overestimate impact and importance of these project. GitHub stars and HN posts are not very good indicator of what happens in the real world
- cbmuser 8mo ago
  I'm not sure why your comment is being downvoted, but it's spot on. Rust has definitely gained some ground while they're hardly any relevant products using Zig.
  - pmarreck 8mo ago
    Ever heard of Bun? Uber? Turso? Vercel? (And the highly-regarded Ghostty terminal of course) I mean, less is true, but “hardly” is doing a lot of work there https://github.com/rofrol/zig-companies-and-organizations https://github.com/rofrol/zig-companies-and-organizations
pjmlp 8mo ago
That doesn't mean Microsoft, Google, Apple, Sony, Nintendo, AMD, Intel, NVidia will be jumping into Zig any time now, just because some HN celebrities blogged about it. Those are the companies I care about when chosing which programing languages to invest my time on.

Quothling 8mo ago

Zig is a drop-in for C. I'm not sure what Rust is but around here no C++ teams seem to be adopting it. Zig on the other hand is seeing adoption in teams who write C for Python binaries. Not a whole lot of it since it's not exactly safe or "stable", but some. Now I'm aware that things like UV are build with Rust, but part of why UV is adopted so widely isn't just that it's fast. It's that it is a drop-in for pip, so that you can compile a requirements.txt and deploy your project without UV, which is handy when you use things like Azure specific Microsoft containers. Maybe it's just C++ teams being conservative, but a lot of them really seem to hate Rust when you talk with them for whatever reason. I can't imagine why though, but then I've only ever worked with C when I had to, and I have never worked with C++. From having played around with both C++ and Rust, I'd personally pick Rust, but I'm sure it's because I don't know enough. Either way I doubt I'll ever see Rust in a real world job in my corner of the world.

pjmlp 8mo ago
I guess C++ teams at Microsoft, Google, IBM, Adobe don't count.
- hu3 8mo ago
  It's not as widespread in these companies as you and many Rust evangelists imply it is. Specially because it's not a drop-in replacement for C++. As Zig is for C. So when Zig hits 1.0 these companies will probably consider Zig much more than they do today. Understandably.
  - pjmlp 8mo ago
    First of all, if I am an evangelist of anything, it is about safe systems programming with automatic resource management languages, if I had a magic wand, we would be talking about languages like D and AOT C#, not Rust. Secondly, let us know when Amazon rewrites Firecracker in Zig, Android replaces Rust with Zig, or Mark Russinovich goes to some Zig conference explaining why Azure is dropping Rust for Zig, "Mark Russinovich, Microsoft Azure CTO tells Rust Nation UK 2025 why Azure is moving to Rust from C++" https://www.youtube.com/watch?v=SmUprpjCWjM https://www.youtube.com/watch?v=SmUprpjCWjM