3 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

by 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?
        pjmlp 9mo ago
        As mentioned I have no interest in ever using Carbon, the language still isn't 1.0, and full end to end compiler is yet to be made available.
- 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.

by sgt 9mo ago

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?
        pjmlp 9mo ago
        As mentioned I have no interest in ever using Carbon, the language still isn't 1.0, and full end to end compiler is yet to be made available.
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.