Zig and the Design Choices Within

I wouldn't say "cumbersome", but perhaps "full of warts and historical baggage".

They have some more details here: https://ziglang.org/learn/why_zig_rust_d_cpp/

I'm not saying it's not important, but we do have to consider whether it's worth the cost.

> And most of the things the things above it (other than out of bounds writes/reads which you addressed in another comment) are not something I would consider a programming language can directly affect (e.g. SQL injection, CSRF)

It actually can.

Some of our problems are novelties because before Grace Hopper basically nobody is writing software so there aren't centuries of lessons in how to do it properly - but this problem isn't like that, all the safety critical industries could tell you that "professionalism" won't prevent the mistakes and what you need is mechanism so that the mistakes cannot happen.

Let me give you an example I like from the railways, which are about twice as old. One night, signaller comes on duty and during the day a team of engineers have been doing work on "his" signal box. Still, things seem to check out and he gets to work, a train approaches, he tries to give them their whole route but their next signal seems stuck and won't "pull off" from danger - he blames the engineers of course. In accordance with regulations the train's driver phones the signaller, signaller explains that he can't release the signal but gives the driver authoriation, per standard instructions, to pass only one signal and proceed at caution (ie slowly enough to stop short of any obstruction) to the next signal. The next signal though is the same, the signaller is annoyed, blames the engineers again, same order to proceed at caution. The next signal is the same again. But, just after the driver receives their authority and passes that signal the signaller gets another call. Funny, surely they haven't reached the next signal yet? No. They're face-to-face with another train. Some junction points ("switch" if you're American) have failed, the train has been sent into another, both stopped short and nobody is injured.

The points failure had been detected. If the signaller had carefully checked his instruments they'd have told him that this failure had occurred and that is why it wasn't clear to set those danger signals off which is why, try as hard as he could, they could not be pulled off. It is mechanically impossible, not because of professionalism, or capability or any other brave words but physically impossible to kill everybody by clearing the conflicting signals in this state.

Mechanism.

So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust.

You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.

I certainly agree Rust is a much better middle ground than either C or ATS. But so is Zig. What's harder to support objectively is that Rust is a better middle ground than Zig (or vice-versa). We just don't know! They both make different tradeoffs that we can't objectively rule on.

So all I'm saying is that we're left with subjective preferences, and that's fine, because that's all we have! So let's stick to saying "I like Rust's design better" or "I like Zig's design better", and stop trying to come up with objective reasons that are just not well-founded.

At the very least, people should stop comparing Zig to C as part of an argument that claims Rust is good because it prevents the vulnerabilities associated with memory-safety violations, as Zig prevents the most dangerous of those, too.

BTW, I'm not saying Rust is bad. All I'm saying is that the attempt at proving it's objectively best by leaning on memory-safety is not really as objective as the people who make that claim seem to think it is.

They're correlated, but number of programmers employed is something that's relatively easy to measure.

> Is this low adoption?

For a language this old? Yes. That people talk so much about specific projects that use Rust only underlines that: Rust is now as old as Java was when JDK 6 came out; older than PHP was when PHP 5 came out or Facebook was launched; older than C++ was when Windows NT came out.

I still like it -- for systems programming, that is. It's a much better C++ basically.

Once that's over, people start looking at it with a more pragmatic eye - how much better is this really than what I had before. People start focusing less on the gimmicks and more on everyday usability.

For a programming language to be really popular, it needs that something that captures people's imaginations, but ultimately the stay power is determined by how useful it turns out.

Kotlin and Swift are very practical, but never had any wow features, so they never got hyped, they just quietly got more popular. Go had it with its green threads and channels, but nowadays most people seem to be not using those that much (I don't think there are a ton of instances of Go processes in prod with 10k threads), but otherwise its a solid language.

Rust - it's a solid language as well, and an improvement over C++ in some aspects like package management, but it's borrow checker and programming style is divisive.

Thing is, unlike goroutines there's no avoiding the borrow checker, so a lot of people don't really commit to Rust.

But PYPL has shown Objective-C rising to #4 in the last few months....

Rust is targeted at strategically important systems (proxies, databases, OSs, VMs, hypervisors, high-throughput servers, cryptography, browsers) and by any measure is making significant inroads into those kinds of systems in real industrial applications, and I'm to believe that Rust adoption is languishing? Am I going insane?

There is a very clear sharp line between them in that Rust has no undefined behavior outside of an unsafe block. This matters because the effects of undefined behavior -- particularly memory-corrupting undefined behavior -- are unbounded. Security issues caused by logic bugs are limited to only having local effects on the program -- a SQL injection bug can lead to the wrong SQL query being executed, a path traversal bug can lead to the wrong path being accessed, and a shell escaping bug can lead to execution of the wrong shell command. These are severe problems that can lead to data exfiltration or remote code execution, but the relationship between bug and effect is straightforward: "I'm passing user input to a shell here; this could have catastrophic consequences so I'd better review this carefully." In contrast, undefined behavior can happen anywhere in your program, and it can do anything. That is a clear and measurable difference, and emperical evidence from the last 10 years clearly indicates both that it is nigh impossible to write large C/C++ applications without both spatial and temporal memory safety vulnerabilities, and that adopting Rust measurably decreases the incidence of such vulnerabilities.

Zig is certainly an improvement over C on this front, but it is still a UB-heavy language, and that's where the sharp line is. It's hard to make emperical comparisons because Zig is so young, but the comparision between Deno and Bun in the article is a reasonably strong demonstration that Zig has not achieved a comparable level of memory safety to Rust.

> Sure, but then you might as well also consider softer effects. For example, maybe a language that's easier to review because it's more explicit, or a language that's faster to compile and is easier to test wins.

> And I agree that we should consider all these, but then we start seeing why correctness is such a complicated topic, and we could speculate just as easily that it is Zig that "clearly" wins.

This doesn't really have anything to do with my point that the CVE list does not provide evidence to dismiss temporal memory safety as irrelevant; it's more of a general statement on writing correct software. But regardless, "Zig has nullability and bounds checks" and "Rust has an affine type system, statically-checked immutability and exclusivity, language-level resource management, and no undefined behavior" are not in the same league of program correctness. Rust wasn't designed after some ideal of memory safety at the expense of clarity and correctness: the lifetime and type system came from a goal of reducing logic bugs in complex concurrent programs, and the fact that it is powerful enough to achieve memory safety without garbage collection was a happy accident. The emperical results that Rust programs have fewer memory-safety vulnerabilities demonstrate that Rust's static approach to software correctness is successful, and not just for the specific problem of memory safety, because Rust's tooling for achieving program correctness is generalizable to arbitrary application invariants. This lines up with my own experience; software I write using Rust is far easier to get right, more reliable, and easier to successfully maintain and refactor than anything else I've done.

Certainly Zig has its strong points as well -- explicitness can reduce complexity and compile times, but it also has downsides of pushing complexity into application code (thus making it harder to review and introducing more opportunities to create mistakes). A proper comparison of the two approaches is worthwhile, but just as "Rust is more memory safe" is an overly reductive generalization of the langauges' approach to software correctness, "there's a rather small difference between Rust and Zig" simply isn't true.

The point is that certain casts/type conversions can change the underlying data.

> like the int with value 3 landing in memory after calling atoi("3").

That's something else entirely. People may colloquially call this "converting a string to an integer", but what we're realling doing here is parsing a string as an integer.