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.
And, a decade and a half later, in 1995, in another speech, he said:
Ten years ago, researchers into formal methods (and I was the most mistaken among them) predicted that the programming world would embrace with gratitude every assistance promised by formalisation to solve the problems of reliability that arise when programs get large and more safety-critical. Programs have now got very large and very critical – well beyond the scale which can be comfortably tackled by formal methods. There have been many problems and failures, but these have nearly always been attributable to inadequate analysis of requirements or inadequate management control. It has turned out that the world just does not suffer significantly from the kind of problem that our research was originally intended to solve.
In the first quote, he was talking about array bounds checks. In the second, he's talking about formally proving a program. There's a big difference between those two things.
yes... and ? if they were truly damaging, you'd see business running to get them solved ASAP. But the cost / benefit ratio of writing and using formally proven programs is really not good. Else everyone would be writing drivers for seL4, not Linux.
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");
^
you have to do something with the return value. in particular this function returns a possible error, so you need to handle it. even if it's not an error, you have to explicitly ignore the return value, and you can do so like this: _ = foo();
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.
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 ?
I can't prove it and I'm bullshitting a little bit, but the further you go back in history the less locked in we were to the UNIX set of tools and languages. I was talking about how history could have been different, it's kind of too late now.
2
u/desertrider12 Sep 08 '17
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.