3 ms·
Car analogies aren't a substitute for actually writing widely-attacked software. There are systematic reasons why I'm skeptical Zig's approach will lead to bet
by pcwalton 4y ago
Car analogies aren't a substitute for actually writing widely-attacked software.
There are systematic reasons why I'm skeptical Zig's approach will lead to better results than what we see in modern C++. The worst memory safety issues from a security point of view tend to be use-after-free caused by complex, untested code patterns, where one programmer wrote, or implied, "free", without realizing that somewhere else in the millions-of-lines codebase some other part of the code, written by someone else, still had a reference to the object. Unit tests don't catch these problems because they're caused by strange patterns that the programmer didn't anticipate. That is the kind of vulnerability that is difficult to solve without either a compiler or a runtime system (GC) to help you, and I see nothing in Zig that solves it. You can, and people do, make raw pointers to other objects in Zig.
- anonymoushn 4y agoIn support of the parent who already knows all this: you don't even need to take raw pointers to have these problems! You'll usually get a slice from your allocator. Keeping any copy of that or any slice into that (e.g. a string in a struct obtained by deserializing a json document into a short-lived slab of memory) will get you use-after-frees too.
- Schroedingersat 4y agoZig is not trying to be a better C++, so I don't see how complaining that it isn't a better C++ is relevant. It's not trying to be for large, widely attacked projects. It's for things where the complexity overhead (whether resources or mental overhead) of Rust is too much, so you'd have to use C. It's not meant to make memory errors impossible, it's meant to make them much easier to avoid or find and remove than it is in C. Noone is suggesting anyone make a web browser in Zig, but it's likely useful for drivers or similar where you'd otherwise be using a lot of unsafe code, so rust's guarantees are at best a partial help, and at worst a false sense of security.
- pjmlp 4y agoThey could have used Object Pascal or Modula-2, and would get the same memory safety guarantees that Zig offers.
- Schroedingersat 4y agoAnd it makes no pretense otherwise. Why bring this up?
- pjmlp 4y agoOne would thought a C replacement in 2022 would have better hindsight regarding memory safety than what was already possible in 1978, which was actually even available in JOVIAL (1958), or ESPOL/NEWP (1961), among many other possible examples.
- Schroedingersat 4y agoGuarantee =/= capability. There are plenty of tools in the language and ecosystem for dealing with memory errors and reducing their frequency, but you're clearly not interested in a rational discussion.
- Tozen 4y agoBut isn't the position of a "Better C", already covered too, by languages such as D? And I mean literally too, with their "-betterC". There is arguably no place for Zig to go, along the "better C" route, that hasn't been covered by other languages. And languages like D and Object Pascal, are way up on the charts, so it will be a hard climb to reach them in popularity. Even the much older Nim language (which has been called a C alternative), still hasn't cracked the top 50, among language rankings. Debatably, a language's "claim to fame" (to escape niche status), can't just be about being a more complex C replacement. There has to be other things about it, that it can firmly stand on, for greater mass appeal.
- Schroedingersat 4y agoD is garbage collected and requires a runtime. Object pascal appears to be pascal with classes. Both of them have exceptions and operator overloading. Zig is smaller than object pascal or D, and closer to the metal than D, it's arguably simpler than C as it's more regular, has no hidden control flow and has no separate preprocessor. The unique things it's attempting to do are manual memory management with handrails (not dissimilar to pascal, but maybe with a few more handrails like testing allocator), error handling with better erganomics than go, rust, or unchecked exceptions (but slightly less power), and comptime which afaik is unique and is where it provides much of the power to do things like generics, many kinds of composition, or even implement a borrow checker and lifetimes as user code (with terrible erganomics and poor performance, but it's illustrative of its power). The thing it stands on for mass appeal is trivial interop with C and the zig compiler is a functional, statically linked C toolchain out of the box and is easier for a beginner to do things like cross compile on than gcc or clang msvcc or similar. Additionally it has the power and simplicity of C with fewer footguns (ie. it attempts to cover some of pascal's strengths, but on the balance I like pascal more as a teaching language). It also shares some of nim's goals like fast compilation and hot code reloading. The thing I'm personally interested in is the type system and semantics of comptime seem to have all the ingredients required for formal verification with no additions to the language, translations to a prover, or annotations (but it would require extending the compiler's abilities considerably). This is unique if true (but I will lack the skills to find out if it is true for a while yet, and the people closer to it are busy with other things). Whether it will succeed, or the comptime concept is fatally flawed in some way is as yet unknown, but it does fill out a currently empty niche as a simpler C, it is not trying to be yet another more complex C. I think its main competitor if it is successful will be go. Go is slightly higher level, arguably marginally simpler and considerably less powerful out of the box (at least last time I looked before the latest generics stuff). The last two are arguably in its favour for being a better C.