3 ms·

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

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".

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".