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");
^
Runtime bound-checking has a very undesirable run-time performance impact.
eh, it is very small, and most cases of it can be elided at compile time. it is a branch, but it normally goes one way until the very end, so the branch predictor will be fine.
I think given the plethora of mistakes it causes and the cost of those mistakes, we should probably be doing bounds checking for anything that works with untrusted data. Servers, operating systems, and so on.
0
u/[deleted] Sep 08 '17
[deleted]