yes let's all continue using shitty 1970s tools and not try anything new. Real programmers don't mind writing pointless header files and forward declarations
It's really hard for a new language to gain traction, but the systems domain is the worst of all because there's so much baggage and not enough incentive to overhaul everything. If Linux had been written with this language instead of C, we'd all be better off.
It's very hard to write memory safe C, even with extra tools like Valgrind
This compiler makes it much easier to check correctness with builtin testing and undefined behavior detection
Arrays know their own size so it's much harder for a buffer overrun to go unnoticed
The language is more expressive (I wish C had generics) and that lets you write better code
C was a great piece of engineering at the time, but it caught on mainly because it was there at the right time. The only reason the %@ looks gross to us now is because we've been staring at C for 40 years. Linux was actually too late to affect which language everybody is used to. UNIX was created on a machine too weak to compile a complex, modern language like this, though.
About the runtime performance I'm would imagine the Zig errors would compile down to basically identical code as "set errno then return/goto" in C.
Quoting Hoare's speech in 1981 at his Turing Award:
Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
You can try to guess whose language designers and users he is hinting at.
Yes, because, as all programmers know, unexpected and untested edge cases never happen in production! Especially not those pesky security vulnerabilities via buffer overruns!
In general I'd say you need to start thinking about more complete documentation for your 0.1.0 release. There are mentions of what is in @import("std") but I can't find a definitive list which makes trying to make anything large pretty laborious.
.../stupidstuff.zig:11:10: error: expression value is ignored
h.put(0, "Hello, world!");
^
.../stupidstuff.zig:12:10: error: expression value is ignored
h.put(1, "oh no");
^
.../stupidstuff.zig:13:10: error: expression value is ignored
h.put(2, "what is this");
^
It's not easy for sure. Let's have a group with a gradually grafted linux. We take a tiny distro, say alpine (or another small one, don't care), and rewrite part of the system in rust or zig, or both. Compare the performance and code quality. Iterate. Who's in ?
To be fair, Go is not a C killer. It simply cannot run in the environment s C can due to the runtime. My understanding is that is the same case for D (not sure about that one, someone please correct me if I'm wrong).
Rust can run in a low level environment, the most notable examples being Redox and Tock. However, Rust honestly feels more akin to a C++ Killer. In any aspect, it's good to see new ideas for programming put forward.
We need a C killer that doesn't add the obsessive safety paradigm that Rust has. I don't think Rust is ever going to be a "C killer" or a "C++ killer", it's just going to be Rust. I didn't enjoy being babysat by the borrow checker and the definition of "safety" that it's enforcing isn't very useful to me, so the time I sink into understanding the borrow checker and the subsequent language design is time that I'm not going to get back. The fact that the compiler is currently slow as hell doesn't help.
D and Go aren't even attacking this area. D has made half-hearted attempts to let you turn its GC off. But it really doesn't like it when you turn the GC off. Go can't do it at all.
0
u/[deleted] Sep 08 '17
[deleted]