4 ms·

Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.

nine_k 4y ago
What makes Zig safer than Go, to your mind?
- valenterry 4y ago
  Features such as sum types (enums) that you can pattern match on. Or generics (well now Go got them as well, for a reason). Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path. Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.
  - pjmlp 4y ago
    No you don't, only for public types , types internal to the package can stay on the same file.
  - cesarb 4y ago
    > Think Java: for each type you have to create a new file. That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").
    - valenterry 4y ago
      Well, you still have to define them inside of another class then and have to find one that makes sense. They also have an reference to the outer class which might not be desirable. That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.
fulafel 4y ago
They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1]. Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years. [1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j
- valenterry 4y ago
  Sure, I agree - I don't think what you said contradicts my point.
- drran 4y ago
  Rust doesn't have GC, but it has very good automatic memory management. GC or memory management doesn't make programs immune to buffer overflows, which is the most common security vulnerability these days, while use-after-free is at 4th place.
  - fulafel 4y ago
    What do you mean by automatic memory management here? (I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
- bitwize 4y ago
  Modern automatic memory management techniques like RAII and ARC largely render GC obsolete.
  - pjmlp 4y ago
    Reference counting is hardly modern, and is a GC algorithm.
littlestymaar 4y ago
I'm not a fan of Go but it is memory safe (with a very minor exception[1]), Zig isn't (it will likely end up safer than C, but it will be “modern c++”-safe but not memory safe. [1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.
- fulafel 4y ago
  > this has ever been proven exploitable I agree (typo exploit!) See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-data-races.html https://blog.stalkr.net/2022/01/universal-go-exploit-using-d... (And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)
  - littlestymaar 4y ago
    Oh, I wasn't aware of the second blog post, thanks.
pjmlp 4y ago
Rust yes, Zig is hardly any better than Modula-2.
- valenterry 4y ago
  So that means Modula-2 is better than Go? :)

nine_k 4y ago

What makes Zig safer than Go, to your mind?

valenterry 4y ago
Features such as sum types (enums) that you can pattern match on. Or generics (well now Go got them as well, for a reason). Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path. Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So people often shortcut and just use "String". Now you have "String password" and "String userid" and you can swap it up and print the password by accident. Artificial example, I know, but I hope it explains what I mean in general.
- pjmlp 4y ago
  No you don't, only for public types , types internal to the package can stay on the same file.
- cesarb 4y ago
  > Think Java: for each type you have to create a new file. That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").
  - valenterry 4y ago
    Well, you still have to define them inside of another class then and have to find one that makes sense. They also have an reference to the outer class which might not be desirable. That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.

fulafel 4y ago

They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1]. Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years. [1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=31853964 https://news.ycombinator.com/item?id=31853964 https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j https://lobste.rs/s/v5y4jb/how_safe_is_zig#c_vddk9j

valenterry 4y ago
Sure, I agree - I don't think what you said contradicts my point.
drran 4y ago
Rust doesn't have GC, but it has very good automatic memory management. GC or memory management doesn't make programs immune to buffer overflows, which is the most common security vulnerability these days, while use-after-free is at 4th place.
- fulafel 4y ago
  What do you mean by automatic memory management here? (I misspoke a bit with "Rust doesn't have GC", it does have opt in basic GC in the form of ref counting, but it's not used much because a headline feature of Rust is code without GC and I guess libs with interfaces requiring GC would be considered uncool)
bitwize 4y ago
Modern automatic memory management techniques like RAII and ARC largely render GC obsolete.
- pjmlp 4y ago
  Reference counting is hardly modern, and is a GC algorithm.

littlestymaar 4y ago

I'm not a fan of Go but it is memory safe (with a very minor exception[1]), Zig isn't (it will likely end up safer than C, but it will be “modern c++”-safe but not memory safe. [1]: there can be memory safety issues in the presence of data races, but this has ever been proven exploitable, doesn't cause the compiler to completely miscompile and is very rare in practice, so it's not comparable to unsafe memory languages.

fulafel 4y ago
> this has ever been proven exploitable I agree (typo exploit!) See eg https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m... & https://blog.stalkr.net/2022/01/universal-go-exploit-using-data-races.html https://blog.stalkr.net/2022/01/universal-go-exploit-using-d... (And also people shouldn't take "nobody developed an exploit for this vulnerability yet" as any kind of strong evidence, attacks techniques always get better, never worse, over time etc - crypto algorithm people have it right when they start bracing for impact quite early after signs of a theoretical break)
- littlestymaar 4y ago
  Oh, I wasn't aware of the second blog post, thanks.

pjmlp 4y ago

Rust yes, Zig is hardly any better than Modula-2.

valenterry 4y ago
So that means Modula-2 is better than Go? :)