4 ms·

can you elaborate why

lucasyvas 4y ago
Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not. They seem to have much more different philosophies than I expected, and Zig's does not resonate. The author's summary really sums it up nicely. I don't need a language that prides itself on being a bit more dangerous in exchange for some extra control.
- nindalf 4y ago
  Agree with everything you've said. > I don't need a language This, but the bigger issue is that I don't think I can be trusted with such a sharp tool. I'm just aware of my own limitations, and I think I'd better stick to safe languages.
  - xedrac 4y ago
    I don't want to need to be trusted. And I don't want to have to trust others so much. I want my tools to tell me I, or someone on my team, did something stupid.
    - fnordpiglet 4y ago
      Even better, to not be allowed to do something stupid.
- throwawaymaths 4y ago
  the assumption with Rust is that memory safety (or, generally, resource provenance) is something that needs to exist in the type system. Zig is still young, so i would say it's not 100% certain that this shouldn't exist, for example, in a separate step, for example using static analysis. Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesystem to track", and support for these would require breaking all of rust. Before you say, "static analysis is impossible" -- that's very likely generically true for C (something like Sel4 is in C but gives even stronger guarantees than rust, but IIRC it analyzes machine code). It might not necessarily be. In extremis you could in principle attach a separate file that provides rust function headers for every single function in zig, and checks resource lifetimes inside of each function. So it is not theoretically impossible, just a question of whether or not it's ergonomic and easily accessible.
  - monocasa 4y ago
    FWIW sel4 could have verified the C, they simply decided to verify the machine code so that they didn't have to trust that the compiler correctly complex the verified software. The issue with more broad formal method use is that it's quite a bit of work. The code to be verified has to be designed on the onset for verification, which limits design choices in interesting ways, and even then the verification code far outweighs the code being verified, at about 25:1.
    - throwawaymaths 4y ago
      Thank you for the clarification!
  - estebank 4y ago
    > Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesystem to track", and support for these would require breaking all of rust. I would be interested in hearing what it is you had in mind. Are you referring to the discussions around capabilities?
    - throwawaymaths 4y ago
      Yes, for example. Another dramatic one is the whole parametrized keywords thing, though I guess it doesn't quite "break all of rust".
estebank 4y ago
> - Rust is about compositional safety, its a more scalable language than Scala. > - Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool. Depending on project, experience, goals, team composition and personality, reading these two bullet points you're very likely to gravitate much more towards one or the other, and potentially feel rejection towards the other.
fnordpiglet 4y ago
Essentially the other comments capture my view. Speed and memory safety with a rigorous type and language system that disallows unsafe operations unless explicitly marked as such is worth a lot. I don’t think this means zig is worthless, and I see a lot of utility in a fast to write lower cognitive load language that offers the same speed and memory efficiency at the cost of runtime safety, but I don’t trust myself or other programmers to do a good enough job. Memory safety bugs are just so difficult to reason about most of the time that I find the compile time safety mechanisms worth whatever overhead they impose, to a point. Rust is far from reaching that point and is generally easy to develop very complex stuff very quickly. So, after reading the article (I’m more familiar with rust than zig, so it was very informative) it led me to conclude it’ll be fun to learn zig but I don’t think it’ll be useful for Serious Stuff.

Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not. They seem to have much more different philosophies than I expected, and Zig's does not resonate. The author's summary really sums it up nicely. I don't need a language that prides itself on being a bit more dangerous in exchange for some extra control.

nindalf 4y ago
Agree with everything you've said. > I don't need a language This, but the bigger issue is that I don't think I can be trusted with such a sharp tool. I'm just aware of my own limitations, and I think I'd better stick to safe languages.
- xedrac 4y ago
  I don't want to need to be trusted. And I don't want to have to trust others so much. I want my tools to tell me I, or someone on my team, did something stupid.
  - fnordpiglet 4y ago
    Even better, to not be allowed to do something stupid.
throwawaymaths 4y ago
the assumption with Rust is that memory safety (or, generally, resource provenance) is something that needs to exist in the type system. Zig is still young, so i would say it's not 100% certain that this shouldn't exist, for example, in a separate step, for example using static analysis. Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesystem to track", and support for these would require breaking all of rust. Before you say, "static analysis is impossible" -- that's very likely generically true for C (something like Sel4 is in C but gives even stronger guarantees than rust, but IIRC it analyzes machine code). It might not necessarily be. In extremis you could in principle attach a separate file that provides rust function headers for every single function in zig, and checks resource lifetimes inside of each function. So it is not theoretically impossible, just a question of whether or not it's ergonomic and easily accessible.
- monocasa 4y ago
  FWIW sel4 could have verified the C, they simply decided to verify the machine code so that they didn't have to trust that the compiler correctly complex the verified software. The issue with more broad formal method use is that it's quite a bit of work. The code to be verified has to be designed on the onset for verification, which limits design choices in interesting ways, and even then the verification code far outweighs the code being verified, at about 25:1.
  - throwawaymaths 4y ago
    Thank you for the clarification!
- estebank 4y ago
  > Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesystem to track", and support for these would require breaking all of rust. I would be interested in hearing what it is you had in mind. Are you referring to the discussions around capabilities?
  - throwawaymaths 4y ago
    Yes, for example. Another dramatic one is the whole parametrized keywords thing, though I guess it doesn't quite "break all of rust".

estebank 4y ago

> - Rust is about compositional safety, its a more scalable language than Scala. > - Zig is about perfection. It is a very sharp, dangerous, but, ultimately, more flexible tool. Depending on project, experience, goals, team composition and personality, reading these two bullet points you're very likely to gravitate much more towards one or the other, and potentially feel rejection towards the other.

fnordpiglet 4y ago

Essentially the other comments capture my view. Speed and memory safety with a rigorous type and language system that disallows unsafe operations unless explicitly marked as such is worth a lot. I don’t think this means zig is worthless, and I see a lot of utility in a fast to write lower cognitive load language that offers the same speed and memory efficiency at the cost of runtime safety, but I don’t trust myself or other programmers to do a good enough job. Memory safety bugs are just so difficult to reason about most of the time that I find the compile time safety mechanisms worth whatever overhead they impose, to a point. Rust is far from reaching that point and is generally easy to develop very complex stuff very quickly. So, after reading the article (I’m more familiar with rust than zig, so it was very informative) it led me to conclude it’ll be fun to learn zig but I don’t think it’ll be useful for Serious Stuff.