4 ms·
> a footgun is a surprising defect that's pointed at your foot and easy to trigger Close, but not the way I think of a footgun. A footgun is code that was writ
by solatic 8mo ago
> a footgun is a surprising defect that's pointed at your foot and easy to trigger
Close, but not the way I think of a footgun. A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. Good design makes it easy for people to do the right thing and difficult to do the wrong thing.
In Rust it is extremely easy to hit the borrow checker including for code which is otherwise safe and which you know is safe. You walk on eggshells around the borrow checker hoping that it won't fire and shoot you in the foot and force you to rewrite. It is not a runtime footgun, it is a devtime footgun.
Which, to be fair, is sometimes desired. When you have a 1m+ LOC codebase and dozens of junior engineers working on it and requirements for memory safety and low latency requirements. Fair enough trade-off in that case.
But in Zig, you can just call defer on a deinit function. Complexity is the eternal enemy, and this is just a much simpler approach. The price of that simplicity is that you need to behave like an adult, which if the codebase (hotpath optimization) is <1k LOC I think is eminently reasonable.
- vlovich123 8mo ago> A footgun is code that was written in a naive way, looks correct, submitted, and you find out after submitting it that it was erroneous. You’re contradicting yourself a bit here I think. Erroneous code generally won’t compile whereas in Zig it will happily do so. Also, Zig has plenty of foot guns (eg forgetting to call defer on a deinit but even misusing noalias or having an out of bounds result in memory corruption). IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++. It’s mildly better but it’s closer to C/C++ than being a safe language and UB is a huge ass footgun in any moderate complexity codebase.
- davemp 8mo ago> IMHO the zig footgun story with respect to UB behavior is largely unchanged relative to C/C++ The only major UB from C that zig doesn’t address is use after free afaik. How is that largely unchanged??? Just having an actual strong type system w/o the “billion dollar mistake” is a large change.
- vlovich123 8mo agoDepends how you compile it. If you’re compiling ReleaseFast/ReleaseSmall, it’s not very different from C (modulo as you said it has some language features to make it less likely you do it): * Double free * Out of bounds array access * Dereferencing null pointers * Misaligned pointer dereference * Accessing uninitialized memory * Signed integer overflow * Accessing a union field for which the active tag is something else.
- dnautics 8mo agowow, what a list! all of these are statically analyzable using a slightly hacked zig compiler and a library! https://github.com/ityonemo/clr https://github.com/ityonemo/clr (Btw: you can't null pointer dereference in zig without using the navigation operator which will panic on null; you can't misalign a pointer unless you use @alignCast which will also create a panic)
- vlovich123 8mo agoNeat. Why isn’t this in the main compiler / will it be? I’m happy to retract my statement if this becomes actually how zig compiles but it’s not a serious thing as it’s more a PoC of what’s possible today and may break later
- dnautics 8mo agoIt will never be in the main compiler, since it was written by Claude. I think that's ok. The general concept is sound and won't break (modulo names of instructions changing etc). In fact it will get better. With the new io, concurrency checks will be possible But also, there is no reason why it should have to be in the main compiler. I've architected it as a dlload plugin. It's even crazier! The output is a zig program which you must compile and run to get the final result.
- pjmlp 8mo agoI can also analyse C and C++ code for such issues, while keeping using a mature languages ecosystem.