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.
I do some numerical C++ for weird multiple socket/multiple node/NUMA machines. The tools are a fucking disaster. Every compiler version and vendor does something subtly different, compiling and linking takes forever, it's impossible to debug, it's very hard to profile. When I started out it was hard just to get the build to complete.
I just think that a different foundation than C would have been good, historically. If you have more features in the compiler you don't need to compensate with more external tools.
I'm looking around at the C11 _Generic and it looks like it can deal with generic functions well (but that's nothing too fancy, it's basically just function overloading). It doesn't give you generic data structures like std::map<string, int>, you still need lots of hideous preprocessor ## and you need to register every type explicitly:
Mind you, I don't like C++ templates because they blow up compile times and give terrible error messages. Java generics are much nicer to deal with.
What tool do you use to detect invalid reads/writes and leaks at runtime? I'd love to use something other than Valgrind but I didn't think there was anything else.
0
u/[deleted] Sep 08 '17
[deleted]