7 ms·

I don't understand what he wanna imply. Both are programming languages, and we should just let people decide what is best for them. How is Rust lang creating a

I don't understand what he wanna imply. Both are programming languages, and we should just let people decide what is best for them. How is Rust lang creating a problem that Zig lang developer is saying "Let us exists".

somethingor 4y ago
Some potential context: https://news.ycombinator.com/item?id=32781696 https://news.ycombinator.com/item?id=32781696
j-pb 4y ago
The rust philosophy is very correctness oriented and safety focused. This, combined with a general frustration with how broken software engineering is as a whole, has led to the mindset in part of the rust community that using anything less than very rigorous type checking is unprofessional and dangerous (think Therac-25, https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25). Zig is in a sense the antithesis to that statement, in that it eschews complex tools like a sophisticated type system, in favour of simplicity and programmer enforced contracts, with the reasoning that it is easier to informally proof correctness of a simple system, than to formally proof correctness of a very complex system. The correctness of the latter often being a somewhat shallow property that is still able to miss the intended semantics (think memory vs logic bugs). The closest analogy in programming language communities is probably clojure vs scala or haskell. In fact there is an interesting paper on code quality, where clojure compared quite favourably to statically typed languages, despite it's dynamic nature. https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
- zozbot234 4y ago
  Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. The Rust devs are still working on giving a full semantics for the 'unsafe' superset of the language, and this currently involves quite a few pitfalls that just don't exist elsewhere in the same way. (And btw, unsafe code cannot be ignored altogether since it comes up naturally in any interaction with outside, non-Rust code. Additionally, idiomatically "safe" APIs can sometimes introduce restrictions that leave some performance gains on the table compared to well-written unsafe interfaces.)
  - j-pb 4y ago
    Yes I wholeheartedly agree, rust is definitely overpromising in that department. The language has grown too large too quickly imho, and having the compiler as a formally verifying aide when the foundations/axioms aren't defined yet certainly leaves a bad aftertaste for me. In a sense rust hasn't managed to reach it's de Bruijn criterion yet, see https://lawrencecpaulson.github.io/2022/01/05/LCF.html https://lawrencecpaulson.github.io/2022/01/05/LCF.html However, the very same can be said for zig. Given that it is such a simple language, development has focused on a many interesting things including incredible performance, but one has to wonder if the priority shouldn't have been correctness and a fully working compiler that can handle e.g. packed unions.
  - puffoflogic 4y ago
    > Zig can easily be more correct than unsafe code in Rust. Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language. Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)
    - josephcsible 4y ago
      When exactly would that call X? Can you post or link to a whole program where it does?
      - puffoflogic 4y ago
        It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code. More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097
mtlynch 4y ago
I admittedly don't follow Rust or Zig very closely, but I think Kelley's comment is about the communities supporting the languages, not the languages themselves. The sense I get from reading a few Twitter threads is that members of the Zig community feel that the Rust community disagrees so strongly with some of Zig's design decisions that the Rust folks suggest that the world would be better without Zig.
lossolo 4y ago
Have you seen comments in Zig threads on HN for the past 2 weeks? For example https://news.ycombinator.com/item?id=32752383 https://news.ycombinator.com/item?id=32752383 Maybe this has something to do with this line from former Rust team member: > I don't see much room for a new language that isn't memory-safe in 2022.
- fulafel 4y ago
  Worth noting that this same idea has been widely held over decades by proponents of safer languages, long before Rust as well.
afking 4y ago
Relevant tweet: >A massive step backwards for the industry. :( https://twitter.com/pcwalton/status/1568306598795431936?s=46&t=OCidhdHuxbUrIkxRja0o1g https://twitter.com/pcwalton/status/1568306598795431936?s=46... :(
notacoward 4y ago
Rust the language isn't causing a problem, but certain members of the Rust community (cited elsewhere in this thread) don't seem to be "letting Zig exist" as Andrew Kelley puts it. One can only be bullied so many times before hitting back.
- hu3 4y ago
  Yep. pcwalton, a proeminent rust user who is mentioned in that twitter thread, made this reply to me yesterday: https://news.ycombinator.com/item?id=32782656 https://news.ycombinator.com/item?id=32782656 > It's perfectly reasonable to take the position that it's deeply problematic for a language aiming for wide use in 2022 to not be memory safe. There's no requirement that you "focus on tradeoffs", especially since real people get hurt by memory safety problems. And my message was already about someone else calling Zig users irresponsible. Talk about toxicity.
  - notacoward 4y ago
    pcwalton's problem is that he doesn't distinguish between different levels of memory safety. It might be "deeply problematic" for a language aiming for wide use in 2022 not to be make some significant efforts toward memory safety, but it doesn't have to be Rust levels. Rust itself isn't 100% memory safe, because a lot of code has to be marked "unsafe" even when it actually is safe and then it might contain other bugs completely unrelated to the reason for the marking and those might go undetected. Similarly, languages like Java and Python are even more memory-safe than Rust, but programs written in them are hardly bug-free either. If you eliminate enough memory-safety bugs, then other classes start to dominate and should also be addressed. Rust is beyond this point, but to get there it diverted resources from addressing other kinds of bugs and has also made some severe usability/productivity tradeoffs. Zig might or might not be at that point, but it certainly promises to get there and to do so without the same drawbacks. Ultimately the question is which language lets you write more bug-free code per month. A reasonable argument could be made that it's Rust and a reasonable argument could be made that it's Zig. Only time will tell, but only if both continue to exist and evolve, which pcwalton and others seem unwilling to let happen. What's "deeply problematic" is their belief that Rust's goals and approaches represent The One Right Way and no others can be allowed to exist.
ksec 4y ago
>Zig lang developer is saying "Let us exists" If you follow Zig and Rust closely on HN you may have more sympathy as to why they think that.

somethingor 4y ago

Some potential context: https://news.ycombinator.com/item?id=32781696 https://news.ycombinator.com/item?id=32781696

j-pb 4y ago

The rust philosophy is very correctness oriented and safety focused. This, combined with a general frustration with how broken software engineering is as a whole, has led to the mindset in part of the rust community that using anything less than very rigorous type checking is unprofessional and dangerous (think Therac-25, https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25). Zig is in a sense the antithesis to that statement, in that it eschews complex tools like a sophisticated type system, in favour of simplicity and programmer enforced contracts, with the reasoning that it is easier to informally proof correctness of a simple system, than to formally proof correctness of a very complex system. The correctness of the latter often being a somewhat shallow property that is still able to miss the intended semantics (think memory vs logic bugs). The closest analogy in programming language communities is probably clojure vs scala or haskell. In fact there is an interesting paper on code quality, where clojure compared quite favourably to statically typed languages, despite it's dynamic nature. https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

zozbot234 4y ago
Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. The Rust devs are still working on giving a full semantics for the 'unsafe' superset of the language, and this currently involves quite a few pitfalls that just don't exist elsewhere in the same way. (And btw, unsafe code cannot be ignored altogether since it comes up naturally in any interaction with outside, non-Rust code. Additionally, idiomatically "safe" APIs can sometimes introduce restrictions that leave some performance gains on the table compared to well-written unsafe interfaces.)
- j-pb 4y ago
  Yes I wholeheartedly agree, rust is definitely overpromising in that department. The language has grown too large too quickly imho, and having the compiler as a formally verifying aide when the foundations/axioms aren't defined yet certainly leaves a bad aftertaste for me. In a sense rust hasn't managed to reach it's de Bruijn criterion yet, see https://lawrencecpaulson.github.io/2022/01/05/LCF.html https://lawrencecpaulson.github.io/2022/01/05/LCF.html However, the very same can be said for zig. Given that it is such a simple language, development has focused on a many interesting things including incredible performance, but one has to wonder if the priority shouldn't have been correctness and a fully working compiler that can handle e.g. packed unions.
- puffoflogic 4y ago
  > Zig can easily be more correct than unsafe code in Rust. Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language. Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)
  - josephcsible 4y ago
    When exactly would that call X? Can you post or link to a whole program where it does?
    - puffoflogic 4y ago
      It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code. More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097

mtlynch 4y ago

I admittedly don't follow Rust or Zig very closely, but I think Kelley's comment is about the communities supporting the languages, not the languages themselves. The sense I get from reading a few Twitter threads is that members of the Zig community feel that the Rust community disagrees so strongly with some of Zig's design decisions that the Rust folks suggest that the world would be better without Zig.

lossolo 4y ago

Have you seen comments in Zig threads on HN for the past 2 weeks? For example https://news.ycombinator.com/item?id=32752383 https://news.ycombinator.com/item?id=32752383 Maybe this has something to do with this line from former Rust team member: > I don't see much room for a new language that isn't memory-safe in 2022.

fulafel 4y ago
Worth noting that this same idea has been widely held over decades by proponents of safer languages, long before Rust as well.

afking 4y ago

Relevant tweet: >A massive step backwards for the industry. :( https://twitter.com/pcwalton/status/1568306598795431936?s=46&t=OCidhdHuxbUrIkxRja0o1g https://twitter.com/pcwalton/status/1568306598795431936?s=46... :(

notacoward 4y ago

Rust the language isn't causing a problem, but certain members of the Rust community (cited elsewhere in this thread) don't seem to be "letting Zig exist" as Andrew Kelley puts it. One can only be bullied so many times before hitting back.

hu3 4y ago
Yep. pcwalton, a proeminent rust user who is mentioned in that twitter thread, made this reply to me yesterday: https://news.ycombinator.com/item?id=32782656 https://news.ycombinator.com/item?id=32782656 > It's perfectly reasonable to take the position that it's deeply problematic for a language aiming for wide use in 2022 to not be memory safe. There's no requirement that you "focus on tradeoffs", especially since real people get hurt by memory safety problems. And my message was already about someone else calling Zig users irresponsible. Talk about toxicity.
- notacoward 4y ago
  pcwalton's problem is that he doesn't distinguish between different levels of memory safety. It might be "deeply problematic" for a language aiming for wide use in 2022 not to be make some significant efforts toward memory safety, but it doesn't have to be Rust levels. Rust itself isn't 100% memory safe, because a lot of code has to be marked "unsafe" even when it actually is safe and then it might contain other bugs completely unrelated to the reason for the marking and those might go undetected. Similarly, languages like Java and Python are even more memory-safe than Rust, but programs written in them are hardly bug-free either. If you eliminate enough memory-safety bugs, then other classes start to dominate and should also be addressed. Rust is beyond this point, but to get there it diverted resources from addressing other kinds of bugs and has also made some severe usability/productivity tradeoffs. Zig might or might not be at that point, but it certainly promises to get there and to do so without the same drawbacks. Ultimately the question is which language lets you write more bug-free code per month. A reasonable argument could be made that it's Rust and a reasonable argument could be made that it's Zig. Only time will tell, but only if both continue to exist and evolve, which pcwalton and others seem unwilling to let happen. What's "deeply problematic" is their belief that Rust's goals and approaches represent The One Right Way and no others can be allowed to exist.

ksec 4y ago

>Zig lang developer is saying "Let us exists" If you follow Zig and Rust closely on HN you may have more sympathy as to why they think that.