5 ms·

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 ot

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 9mo 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 9mo 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 9mo 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 9mo 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/
      - pjmlp 9mo ago
        There is an announcement already planned at NDC Toronto 2026. > Carbon: graduating from the experiment https://ndctoronto.com/agenda/carbon-graduating-from-the-experiment/be09a27e1d46 https://ndctoronto.com/agenda/carbon-graduating-from-the-exp... As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects. They are the very first ones to assert that for green field projects there are already plenty of safe languages to chose from.
        ceteia 9mo ago
        What concerns me is that the design of Carbon in aspects seem to have serious issues already now. In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon? https://docs.carbon-lang.dev/docs/design/pattern_matching.html https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...
        pjmlp 9mo ago
        I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in. Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.
        ceteia 9mo ago
        Are you really OK with runtime "expression patterns"? match (0, 1, 2) { case (F(), 0, G()) => ... } > Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern. How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor. And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?
  - ceteia 9mo ago
    I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems. https://docs.carbon-lang.dev/docs/project/roadmap.html https://docs.carbon-lang.dev/docs/project/roadmap.html
  - sgt 9mo ago
    I was more referring to the type of things 90% of the developers are likely to build. In most cases that'll be command line tools, libraries or API's.
    - giovannibonetti 9mo ago
      That's the space where Go shines
- grayhatter 9mo ago
  > 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. This is a painfully shallow framing. Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer. The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems. Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.
junon 9mo ago
> Rust will also never replace C or C++ in any meaningful way Not only do I disagree it never will, I think it's already well on its way to doing exactly that.
- LexiMax 9mo ago
  C? Never. I feel like that ship has sailed, it's too primordial and tied to too many system ABI's to ever truly go away. I think we'll see a lot of Rust or Zig replacing certain popular C programs and libraries, but I don't think C will ever go away. C++ on the other hand? Possibly, though I think that it's just as much because of the own-goals of the C++ standards committee as it is the successes of Rust. I don't really consider Zig a competitor in this space because if you're reaching for C++, you are reaching for a level of abstraction that Zig is unwilling to provide.
  - junon 9mo ago
    They said the same thing about Fortran, COBOL, etc. Still "around" but not the de facto.
- cv5005 9mo ago
  Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.
  - junon 9mo ago
    https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift
    - pjmlp 9mo ago
      So far I have seen no plans to replace the reference implementation with Cranelift.

sgt 9mo 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 9mo 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 9mo 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 9mo 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/
    - pjmlp 9mo ago
      There is an announcement already planned at NDC Toronto 2026. > Carbon: graduating from the experiment https://ndctoronto.com/agenda/carbon-graduating-from-the-experiment/be09a27e1d46 https://ndctoronto.com/agenda/carbon-graduating-from-the-exp... As for it being widely adopted, people keeping missing the point that Carbon is mostly for Google themselves, as means to integrate into existing C++ projects. They are the very first ones to assert that for green field projects there are already plenty of safe languages to chose from.
      - ceteia 9mo ago
        What concerns me is that the design of Carbon in aspects seem to have serious issues already now. In case that you are well familiar with for instance pattern matching, might you have any opinions on the pattern matching that is currently proposed for Carbon? https://docs.carbon-lang.dev/docs/design/pattern_matching.html https://docs.carbon-lang.dev/docs/design/pattern_matching.ht...
        pjmlp 9mo ago
        I am not a Google employee, as such I don't care where they take Carbon, other than being a technology nerd that had compiler design as one of the areas I majored in. Regarding the linked pattern matching proposal, it seems alright to me, not everything has to be ML like.
        ceteia 9mo ago
        Are you really OK with runtime "expression patterns"? match (0, 1, 2) { case (F(), 0, G()) => ... } > Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern. How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor. And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?
- ceteia 9mo ago
  I am not sure how Carbon will go. The Carbon compiler is not ready to be used yet by the public as I understand it, and the roadmap has not been updated for some time now, it seems. https://docs.carbon-lang.dev/docs/project/roadmap.html https://docs.carbon-lang.dev/docs/project/roadmap.html
- sgt 9mo ago
  I was more referring to the type of things 90% of the developers are likely to build. In most cases that'll be command line tools, libraries or API's.
  - giovannibonetti 9mo ago
    That's the space where Go shines
grayhatter 9mo ago
> 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. This is a painfully shallow framing. Yes, programming languages solve problems by emitting instructions that a programmable logic chip can use to preform calculations on input resulting in output. And the scaffolding you use to get there isn't just a matter of philosophical show. Rust as a first order decision will refuse to emit perfectly valid programs because it's unable to prove it's correctness. Zig will emit any program it has enough information to do so. People coding in rust off load much of the effort in understanding and proving that correctness to the compiler. In Zig that relationship is reversed, where the compiler offloads that responsibility to the programmer. The person you responded to is correct. For some people. Rust solves the difficult and annoying problems, for others it creates difficult and annoying problems. Some people like creating art, some people like creating software. I guess you could frame that as philosophical, but to call it a political show, belies ignorance to the interactions between systems and predispositions of individuals.

junon 9mo ago

> Rust will also never replace C or C++ in any meaningful way Not only do I disagree it never will, I think it's already well on its way to doing exactly that.

LexiMax 9mo ago
C? Never. I feel like that ship has sailed, it's too primordial and tied to too many system ABI's to ever truly go away. I think we'll see a lot of Rust or Zig replacing certain popular C programs and libraries, but I don't think C will ever go away. C++ on the other hand? Possibly, though I think that it's just as much because of the own-goals of the C++ standards committee as it is the successes of Rust. I don't really consider Zig a competitor in this space because if you're reaching for C++, you are reaching for a level of abstraction that Zig is unwilling to provide.
- junon 9mo ago
  They said the same thing about Fortran, COBOL, etc. Still "around" but not the de facto.
cv5005 9mo ago
Is it? rust has to ditch llvm to be able to replace c++ - or rewrite llvm in rust.
- junon 9mo ago
  https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift
  - pjmlp 9mo ago
    So far I have seen no plans to replace the reference implementation with Cranelift.