> I suspect you've pulled this figure out of nowhere

Actually, out of job postings, which, however imperfect, is the best metric we have: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

The numbers are in line with older numbers (i.e. showing some growth), obtained by other people: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

> Oh yeah, I guess Objective-C peaked in 1993, Python peaked in 2001, and Java, PHP, Ruby and JavaScript peaked in 2005.

Objective-C is irrelevant (as its adoption is tied to that of another product, kind of like VBA), and with the exception of Python, pretty much yes (I said neared or reached, not reached). Other than Python, no language showed surprising growth after a decade, including C (1983) and C++ (1995).

> but it will steadily entrench itself as foundational building block of everything that surrounds you, as it has already started.

The evidence suggests otherwise, but things could change. I'm not saying Rust will never succeed, just that current performance and the historical trend don't bode well. Of course, other languages -- Zig, Odin, JAI, and those that don't exist yet -- will also enter the game, and it's not unreasonable to expect that the low-level programming world will experience a similar fragmentation to that of the applications world, where no new language is particularly dominant.

I think it is quite possible that Rust will achieve similar success in the low-level world as Go reached in the applications world. Anything beyond that is not out of the realm of possibility, but there are no current indicators to support that. Rust's adoption rate, in its target domain, is -- today -- lower than that of languages that have achieved unusual popularity in that domain or in others.

> to bash the language

I don't bash the language at all. I bash unfounded claims about it, such as those made in this discussion: that it's achieved extreme success, that all other designs are "fringe", and that it's well established as the best way to achieve correctness. None of these things are known to be true. As for the language itself, I find it too complex and reliant on implicitness for my taste, but I've said over and over that that design is certain to appeal to others. Moreover, I think Rust's "grand idea" of the borrow checker and type-checked lifetimes is nothing short of genius, although I wish it came in a simpler language.

I also don't understand people who become so attached to languages that they deny reality. Clojure is one of my favourite languages, but it's silly to deny that its adoption is low; obviously, it's not many people's cup of tea. I find TLA+ to be one the most useful tools for me, but clearly many don't. I don't understand why people who like Rust need make believe that it's doing well, inevitable, or the only reasonable choice, when the truth -- as we know it today -- is that it's none of those things, yet that shouldn't stop anyone from enjoying it, just as Clojure or TLA+'s lack of popularity has no impact on my enjoying them. Why can't people say, "I use Rust because I enjoy it, I find it convenient, useful, interesting, and beautiful?" Why the need to also make up stuff about it?

> that they spent such a significant amount of their comment activity on HN

This one gave me pause, but I think you'll find that what mostly triggers my HN comments is not so much Rust but claims related to software correctness. I've spent years on this subject, I care deeply about it, and misleading claims about it abound. It's just that recently they've been coming with great frequency from Rust folk (just as before we heard similar claims about Haskell, that triggered me just as much). Sadly, we don't know the most effective approach (or, more likely, a combination of approaches) for software correctness, and incorrect claims to the contrary drive me crazy. It is such a complex topic, with often surprising and perhaps unintuitive realisations (Tony Hoare was certainly surprised and changed his mind on some matters), and the truth is that we simply don't know whether an approach like Rust's or like Zig's lead to more correct software than the other.

> I bash unfounded claims about it, such as those made in this discussion: […] that all other designs are "fringe"

You're mischaracterizing Mr Walton's argument here: it's not “non-Rust” design which are fringe, it's “non-memory safe”, and he's arguably correct on that front: no mainstream (even in the broadest sense) language that ever came after C++ was memory-unsafe. And C++ has been progressively abandoned from every domain where its performances characteristics weren't enough of an argument. It is the consensus in PL design, whether you like it or not, and Zig is going against that 30+ years old consensus. Rust is simply the first one to seriously challenge C and C++ on their remaining domains, but memory-safe languages are ubiquitous and have been for years.

> that it's achieved extreme success

For the domain Rust is aiming at, no other languages has ever reached this level since C++, that's it. Rust hasn't taken the crown, but it's doing things that have not been done before, and it's a hell of a success for a programming language designer!

> This one gave me pause, but I think you'll find that what mostly triggers my HN comments is not so much Rust but claims related to software correctness. […] (just as before we heard similar claims about Haskell, that triggered me just as much)

I think it's mainly a thinking framework issue. You can view software defects as belonging to one of two classes: (1) design errors, and (2) programming mistakes (typos, copy-paste error, forgetting to call a mandatory function, etc.). TLA+ is a wonderful tool to make sure that your design is correct, but it's helpless against programming mistake. Respectively, the ML family of languages (and Haskell) offer really powerful tools to reduce the number of programming mistakes in shipped code (if it compiles, it has likely no programming errors) but it is completely helpless against broken design. The frequency or gravity of software defects caused by those two kinds of bugs are context dependent but they are both sources of bugs, so in a sense (even discounting memory-safety) Rust is improving software correctness by reducing the number of programming mistakes, even if does nothing (if we set memory issues aside) to reduce design errors.

There is no Rust vs TLA+ like there is Coq vs TLA+, Rust doesn't claim it can prove the high level requirements of your problem, it just claim it can prove memory-safety and thread-safety and give you a nice mistake-prone development environment. If you want design correctness, use Rust to implement the design you've validated in TLA+!

> Actually, out of job postings, which, however imperfect, is the best metric we have: https://www.devjobsscanner.com/blog/top-8-most-demanded-lang...

Ctrl-F for Rust on this page returns no results…

> Objective-C is irrelevant (as its adoption is tied to that of another product, kind of like VBA), and with the exception of Python, pretty much yes (I said neared or reached, not reached). Other than Python, no language showed surprising growth after a decade, including C (1983) and C++ (1995).

That's a surprisingly high number of wrong statements per n-gram…

As an aside, in a non-emotional discussion about a programming language, you should probably refrain yourself from insulting one of its designer. Because, yes, saying to a PL designer that his language is “struggling to find relevance” is an insult, the same way calling someone else's mom “fat and ugly”, regardless of the factual accuracy of the statement.

> and he's arguably correct on that front: no mainstream (even in the broadest sense) language that ever came after C++ was memory-unsafe.

I don't understand that logic, as we're only talking about low-level languages. Of all the low-level languages developed after C++, including D, Rust, Zig, Odin, and JAI, the majority aren't memory safe.

> It is the consensus in PL design, whether you like it or not

It clearly isn't even the majority opinion in low-level PL design, let alone the consensus.

> but it's doing things that have not been done before, and it's a hell of a success for a programming language designer!

Sure, by that metric it is a great success.

> it just claim it can prove memory-safety and thread-safety

I know, but the reason it does so is as a means to an end. The reason why anyone wants memory safety is that it eliminates certain classes of bugs that can be quite harmful. The reason why we may not want memory safety is that sometimes it can come at the cost of other bugs, overall not helping correctness. Anyway, software correctness is a complex issue, and it is not currently known whether Rust's approach or Zig's -- if either -- is more effective at achieving correctness.

> Ctrl-F for Rust on this page returns no results…

Yeah, it's an image or something, but it's there.

> you should probably refrain yourself from insulting one of its designer.

Sorry about that.

> Of all the low-level languages developed after C++, including D, Rust, Zig, Odin, and JAI, the majority aren't memory safe.

It's funny because you've included a language built around garbage collection (D), and a language that doesn't really exist yet (Jai, which is actually a placeholder name). Btw, this list (which basically contains only names we can see every once in a while on HN) shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not familiar with).

> I know, but the reason it does so is as a means to an end. The reason why anyone wants memory safety is that it eliminates certain classes of bugs that can be quite harmful. The reason why we may not want memory safety is that sometimes it can come at the cost of other bugs, overall not helping correctness. Anyway, software correctness is a complex issue, and it is not currently known whether Rust's approach or Zig's -- if either -- is more effective at achieving correctness.

The idea that Rust may cause more bugs than it avoids is backed by zero evidence. Is Rust worth it, from a engineering team perspective, given its other constraints (low number of trained practitioners, slow compilation time, or even an hypothetical productivity cost) is a fine question, especially when I see Rust being used for back-end roles where other entrenched languages are doing fine, but claiming that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy (same fallacy applied to a different context: “climate is a complex issue, maybe there's some non-anthropic cause for global warming”).

Zig doesn't particularly address “correctness”, more than any typical language: it doesn't address “design errors” more than Rust, and is arguably addressing less “programming mistakes”. There is no trade-off in correctness between those two (Rust is trading learning curve against correctness, and it might even trade productivity for correctness, but it's not trading one kind of correctness in favor of another).

One can argue that “programming mistakes” are unimportant overall, because they get ironed out easily, and that it's a matter of team experience and proficiency, and in fact in managed languages it may be true, and that would explain why functional programming never took off, but when in comes to memory management, we've had enough CVEs to show that no, programming mistakes don't get ironed out easily.

If you want to see “Zig safety story” in action, have a look at the only commercial user of the language, and go search for “segfault” in the github issues…

> shows you're really not familiar with the PL design space (which is fine actually but you should probably not be arguing about academic domains you're not familiar with).

Oh, I'm familiar enough (my job requires me to be), but I wanted to list languages people here have heard about. Also, I'm not arguing about an academic domain. Having spent just the other night at a gathering with PL researchers in the UK, some interested in Zig, I know that even if we restrict the discussion to academia alone there is absolutely no consensus over the matter. It is an empty and false assertion, plain and simple.

Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one.

> The idea that Rust may cause more bugs than it avoids is backed by zero evidence.

I never claimed that it does. I said we don't know which approach leads to more correct software, and that anyone who says we do is simply unfamiliar with the field or misleading. I explain more below.

> that “maybe Rust some unknown type of bugs we cannot be sure” is a fallacy

That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests. A complex language with a lot of implicitness, long compilation time, and possibly longer code-writing time, can slow down or hinder these two techniques. Those issues are related to why so many in software correctness research today focus on reducing soundness; soundness has a cost of slowing down very effective unsound techniques, and given that full-soundness is something most have given up on, whether the price is worth it is always a hard question with no easy answers.

> Zig doesn't particularly address “correctness”, more than any typical language...

I think it does, and Zig's designer thinks so too (in the sense that he's designing the language and it tools with correctness as a primary goal) -- I don't know if it's more than any "typical" language (working on a "typical" language myself and caring a lot about correctness, too), but certainly not to any lesser extent than Rust. In particular, there's a very strong emphasis on explicitness over explicitness (no hidden control flow, local reasoning) and there's a strong emphasis on fast compilation and good testing support (including a design that makes isolating units and testing them easier) to facilitate faster and more rigorous testing.

Those who arrive at correctness from academic PL are often unfamiliar with such reasoning, which is now increasingly more common in formal methods research where the power of unsoundness is now appreciated.

> There is no trade-off in correctness between those two

I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know.

> One can argue that “programming mistakes” ...

That's not the argument at all. Memory errors are, indeed, both tricky and dangerous, and it is important to avoid them, but not at the expense of missing other, equally tricky and equally dangerous bugs.

> If you want to see “Zig safety story” in action, have a look at the only commercial user of the language, and go search for “segfault” in the github issues…

If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.

> Also, let's not forget that Rust leans quite heavily on a garbage collector, too, albeit a rather crude one.

How do you want anyone to take any your words seriously when saying things like this… Rust has reference-counting primitives in its standard libraries, but saying in “leans heavily” on it is a “very original” take (in fact, Rust leans more on “epoch-based memory reclamation” than it does on reference counting, but even if you had that in mind, it's still quite far from “leaning heavily”).

> That's not what I meant at all. Just as an example of things that Rust's design could adversely affect to the point of adversely affecting correctness, consider two techniques that have proven extremely valuable in improving software correctness: code reviews and tests

It “could”, in the same sense that “vaccine could cause autism” or “the US could never have put men on the moon and staged the moon landing in Hollywood”

> I think it does, and Zig's designer thinks so too

Interestingly enough, you spend much, much, more time talking about it than himself…

> I gave an example above that explains why some people think there could well be. No one can claim that either Zig or Rust yield more correct software, because we really don't know.

So the gist of your argument is that we don't know because for “some reason” Rust could make testing (this is ironic when you know how much of an improvement Rust testing story is compared to most languages) and code review less practical, to a point where it would more than compensate for a class of bug that have empirically proven really really hard to avoid with conventional methods like testing, code review or runtime tooling. Wonderful.

> If you choose to eliminate bugs of class Y, you'll have none of them, and if you don't -- you will. This has no bearing at all on the question of overall correctness, which is what memory safety ultimately aims to serve. That is why there's no consensus over it.

I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good.

> It “could”, in the same sense that “vaccine could cause autism”

No. The claim "design with tradeoffs X leads to more correct programs than design with tradeoffs Y" is the one that requires evidence. The null hypothesis is that it doesn't.

> Interestingly enough, you spend much, much, more time talking about it than himself…

As I said, software correctness is my thing. When I saw Zig's brilliant, revolutionary design, I thought, wow, that's a powerful and interesting approach to software correctness. I thought pretty much the same when I saw Rust's design. My aesthetic preferences lean toward simpler languages, just as others' lean toward a more refined type system, but both of these languages make correctness a major focus of their design, they go after it in very different but equally interesting and novel ways, and it will be fascinating to learn which, if any, can achieve better correctness. However, anyone who says we already know is not telling the truth, and probably has a shaky understanding of the subject.

> So the gist of your argument is that we don't know

No. The reason we don't know is that we don't have evidence one way or another. I gave you one example as an intuition for why your hypothesis might be false.

> I was referring to this quote of yours above: “Zig has a pretty good memory safety story”. Which is empirically not so good.

You're saying it's not good because it doesn't try to completely eliminate such errors? That's called begging the question.

Now, you can say many things about me, but when talking about technical subjects I try pick my words precisely. I'll gladly keep discussing the substance of the matter -- I've devoted a lot to it and I care deeply about it (look at my blog) -- but if you're trying to poke at my words you will most likely waste both our time.

Yes, Zig has a pretty good memory safety story. It's a combination of sound spatial safety, precise pointer tracking, as well as some tools, to make catching temporal safety issues easier. It's not only a pretty good story, it's also interesting and rather novel one -- like Rust's -- only its particulars are very different. Zig's memory safety story is not perfect because the cost of perfection, Zig's philosophy believes, is too high, to the point of working against the goal of correctness.

There are two relevant open questions: If correctness is all you care about, what price should you pay for memory safety? And what if you also care about other things? I don't know the answer to these questions -- nobody does -- but we need both Zig and Rust to help us learn.

> No. The claim "design with tradeoffs X leads to more correct programs than design with tradeoffs Y" is the one that requires evidence. The null hypothesis is that it doesn't.

What's the argument here? Is it OK then to question the existence of the Apollo program because “the yanks never went to the moon” is the null hypothesis?

We've plenty of evidence that Rust offers better guarantees than C (even though with your reasoning there could be a hidden second-order effect that makes Rust actually worse than C, we cannot be sure after all, the Rust compiler is slower than C's… /s).

Now since Zig doesn't address the most prominent source of critical defects in C, the null hypothesis is that it won't be an improvement compared to C. (I actually don't think that hypothesis is true either, C is very dated and there are tons of room for small UX improvements, but getting an improvement as big as what Rust offers is a big step to climb with small improvements).

> As I said, software correctness is my thing. When I saw Zig's brilliant, revolutionary design, I thought

Yet you're like two thousand words in and you've not even begun to hint at what part of Zig designs makes it especially good for correctness compared to C.

> However, anyone who says we already know is not telling the truth, and probably has a shaky understanding of the subject.

Like with climate modeling or immunology, we're far from knowing as much as we'd like, but that doesn't mean we know nothing: for instance we know that 1) distributed systems are practically impossible to get right without tools (and TLA+ is a blessing), and we know that 2) manual memory management isn't tractable by a human without assistance. For these two problems, we have decades of empirical evidence that shows that the human brain just isn't able to do it reliably. We also know that 3) so far sanitizer and other runtime tools haven't been enough to get it right in practice.

Zig basically says that even if 2) is true, 3) will not hold for long because it will have “better tools”® than what exists for C. Hard to tell how far these tools will eventually go, but for the moment it has yet to prove anything on that front.

> You're saying it's not good because it doesn't try to completely eliminate such errors?

Yes I am, because ”eliminating completely* such errors” is the standard for every language designed after 1985 that has reached even limited use. (And we're not talking about some low-level stuff that only C or C++ could do, but about a product that competes with another written mostly in JavaScript).

By letting this kind of errors happen, it's a step back of more than 35 years ! And by “happen” or “completely eliminate” I mean “happen enough that it surfaces significantly to the user” (and resp.), I'm not arguing that it should be proven that it cannot happen (in fact, even Rust does make such a claim),but at least it should be exceptional in practice, not one of your most common issue keyword on github…

If Zig empirically had like 0.1% memory issues, then arguing that improving on any other fronts is more important would be fine (like Go not being memory safe in the presence of data race, we can agree that this isn't a significant factor in software reliability using that language and move on), but it's not what's happening. What happens is that the only commercial use of Zig so far is facing a double-digit amount of memory-related crash reported by its users. We're not talking about CVEs found by an adversary here, just Joe the user who has his software randomly crashing at startup. Correctness you said?

> Zig's memory safety story is not perfect because the cost of perfection, Zig's philosophy believes, is too high, to the point of working against the goal of correctness.

As a side note, this is a strawman, Rust doesn't aim at ”perfection” either as it's happily relying on unsafe code when needed, and Rust pragmatic solution to improving memory safety in unsafe code was Miri, a runtime sanitizer, not some kind of proof assistant or anything). There's also a runtime check for overflows or out of bounds access, not dependent types to aim at soundness perfection.

> What's the argument here?

The argument is that you don't have a hypothesis and then put the burden of proofs on others to prove that it's untrue. The justification for why science must work like this is that most associations must not be true correlations.

> We've plenty of evidence that Rust offers better guarantees than C

True, but our starting point was that neither C (let's call it 0 sound safety) nor Idris (let's call it 100 sound safety) are the best approach, i.e. we know that the most effective way is something in the middle, i.e. we already know that more soundness is sometimes better and sometimes worse.

> Now since Zig doesn't address the most prominent source of critical defects in C

No, that's your claim. Zig is as different from C as Rust is. Zig does make sound guarantees of spatial memory safety (which neither C nor C++ do), and unlike C or C++, pointers cannot be created from "thin air" with pointer arithmetic or with hidden casts such as unions, i.e. Zig has precise knowledge of what a pointer is. This makes tooling for detecting temporal memory unsafely much more powerful and precise in Zig than in either C or C++.

> Yet you're like two thousand words in and you've not even begun to hint at what part of Zig designs makes it especially good for correctness compared to C.

I hope I now did. Plus, its expressiveness is that of C++ (or Rust), not C, while being very simple (two languages are as expressive if there aren't programs in one that require more lines in the other than by a constant factor; C++ has program facilities that require exponentially more lines in C).

> but that doesn't mean we know nothing

Well, whether Rust makes it easier to write correct programs is something we don't know.

> so far sanitizer and other runtime tools haven't been enough to get it right in practice.

You're talking about sanitisers for C/C++. Zig is very different. Again -- full spatial safety, and precise pointers.

> but for the moment it has yet to prove anything on that front.

Sure, and Rust too.

> Yes I am, because ”eliminating completely* such errors” is the standard for every language designed after 1985 that has reached even limited use

That is a very bad argument. You could just as well say that the standard is not to have safety based on substructural types because that's probably too costly. I think it's funny to pretend that Rust's way to memory safety isn't very different from, say, Java's, and doesn't come at a significant cost. It obviously is, and does, and the question we don't know the answer to is: is that a better tradeoff than Zig's?

Also, the number of low-level languages designed after 1985 that have reached even limited use is too small to make any generalisation, let alone a standard, and it opens you to a far worse argument: despite the popularity of memory safety in the application space, no low-level language that has achieved significant use has been memory-safe. Don't try to build statistics on a small sample. Not only is the argument bad, but it can just as easily be turned against you.

> And by “happen” or “completely eliminate” I mean “happen enough that it surfaces significantly to the user”

This is the argument Rust is making that those who aren't so involved in software correctness find compelling, but it is nonetheless false. It goes like this: we have lots of kinds of bugs, if we can eliminate some with soundness, then that must be better! Most formal methods researchers found that argument so convincing in the 70s that they almost accepted it axiomatically. Except it turned out not to be true. Less sound approaches proved more effective overall despite not "eliminating" classes of bugs. But we don't know where the sweet spot is yet.

> Correctness you said?

I don't understand your complaint. First, I hope you're not claiming that programs written in Rust don't have very serious bugs, just as bad as segfaults. Second, you're trying to draw a trend out of tiny samples again; this never ends well. You're a step away from saying, 100% of commercial Zig programs crash, <100% commercial C programs crash, therefore it's better not to have spatial memory safety. It's like talking about a person who dies from some illness, and saying, see, that's Western medicine for you.

Anyway, my personal opinion of Rust, as someone who mostly programs in C++ is that it doesn't address the two main issues with the language -- a complex language that requires non-local reasoning, making reviews hard and slow and requiring too much thought about the language rather than the algorithm, and a slow build-test cycle that results in less testing than more "agile" languages. Zig, on the other hand, starts with those two problems, so while I have no idea whether Zig (or Rust for that matter) would ever succeed in the market and that I would ever get to use it "in production", the language that would address my biggest issues in low-level programming would look much more like Zig than like Rust.

Moreover, I think Rust made the same big mistake C++ did: trying to get a low-level language to look like a high-level one on the page (so-called "zero-cost abstractions"). I think that design philosophy has little pros and too many cons.

P.S.

In the nineties I worked on a big defence project that was written half in C++ and half in Ada. Ada was the Rust of the day, plus it had the weight of the US DoD behind it, which was no small thing. But at the time it was a much more complex language than C++, so we had to have "language lawyers", and, just as bad, its build time was much worse, that in the end we just couldn't test it as well as our more ostensibly sloppy C++ code, the result being that we gradually shifted away from Ada.

I'm not saying that the vision of the seventies of "more language; more formal soundness" is always wrong, but it's certainly isn't always right. The biggest improvement in software correctness that saved us from the total software collapse prophesied by the "formalists" of the seventies, like Dijkstra and Tony Hoare, was the advent of automated unit tests. It's been so effective that it surprised those formalists (like Hoare) as well as confounded those PL people who believed that more and better types are always better (so much so that correctness differences between languages have been very hard to find in recent years except in special circumstances, such as JS vs TypeScript). We learnt that "more language" isn't always the best answer, although sometimes it could be. We just don't know where the "best" tradeoffs are, or even if they're universal. In the past couple of decades we've also learnt more about software correctness from complexity theory, "hard" results that just weren't known to Dijkstra, and that put limits on the effectiveness of soundness. We also learnt some empirical "soft" results -- such as this one [1] -- that showed that sometimes soundness just pushes the bugs elsewhere (i.e. people write code that satisfies the language, yet manage to do this without addressing the fundamental issue, so the catastrophic bug just manifests differently).

None of that is surprising in retrospect. Bugs occur due to a lack of exhaustiveness in human reasoning (or even machine reasoning, as we now have the complexity theory to understand that), so if you're writing an algorithm whose object-lifetimes considerations are too onerous for humans, it is likely that there are other aspects of it that are equally onerous. So what is the right price to pay to prevent that algorithm failing due to use-after-free specifically?

So when a language offers to eliminate certain classes of bugs, even important classes, but possibly at the cost to both static and dynamic functional reasoning -- through reviews and tests -- it is in no position to say that it's obviously the right approach, and that's why there's no consensus that it is. Zig opts to eliminate fewer classes of bugs, up to the point that doing so is free. That's certainly an equally valid hypothesis, a-priori at least, and it will be interesting to see how things develop.

[1]: https://www.usenix.org/system/files/conference/osdi14/osdi14...

You're basically saying the same thing over and over between different posts, but here's one interesting thing:

> so if you're writing an algorithm whose object-lifetimes considerations are too onerous for humans, it is likely that there are other aspects of it that are equally onerous.

The thing is that you have lifetimes considerations in Zig too. You need to know when to free memory, so you explicitly need to reason about it, just like in Rust in the worse case (when RAII alone isn't enough) but you don't have tools to helps you know when to free and when not to (and only tools to diagnose when you've missed it) so Zig actually adds cognitive burden, not removes it. In the end you'll be reclaiming the memory at the same place (which is where the object is not used anymore and safe to free).

And you keep pointing to reviews and tests, as if rust made it harder, when in fact it makes it marginally easier than for most languages, with its built-in test framework well integrated in the entire stack, and the ability to see where mutations happen. Of course it's not revolutionary nor even unique, but on those two specific subjects in is in fact in among the best languages out there.

So you keep talking about Rust's cost, but the thing is that you can't really pinpoint what types of cost this is about (except with the hand-wavy concept of “language complexity”), and the examples you give are off.

> You need to know when to free memory, so you explicitly need to reason about it, just like in Rust

Obviously! But my point was that that reasoning isn't additive. If an algorithm is complex enough that you have to carefully reason about its object lifetime, then you might have to carefully reason about it even if you're guaranteed to get the lifetime right. Or, rather, sometimes you might, sometimes maybe not, and other times the extra burden of the language is just a chore.

> so Zig actually adds cognitive burden, not removes it

In that regard -- absolutely, in others, it reduces it. Rust's soundness obviously does some good things -- at a price. The question isn't whether those things work, but if they're worth the price. I'm not saying Rust doesn't give me value for my effort; we just don't know if it's more or less than what Zig gives us.

> but on those two specific subjects in is in fact in among the best languages out there.

Except Zig takes that to another level. Rust has some brilliant innovations -- like the borrow checker -- but Zig's entire design is a quite revolutionary, and in multiple ways. That's why I find comparisons between it and C to be so misleading. We've never seen anything like it before.

> So you keep talking about Rust's cost, but the thing is that you can't really pinpoint what types of cost this is about

I don't need to justify why Rust isn't the best approach out there; the onus is on Rust. If we knew which of Rust's approach or Zig's or maybe others altogether worked best, then we wouldn't be trying all of them. We are because we don't know.

But assumptions that soundness was the best approach proved wrong in a surprising ways in the past, and a combination of soundness and unsoundness (those "hand wavy" techniques of testing and reviews) are what proved effective. Bot Zig and Rust believe in such a combination, only in different measures. Perhaps in time we'll find out which works better, but you can't say, "fine, sometimes soundness is better and sometimes it's worse, but my mix is better than yours because it has more soundness."

Now, I'm not trying to convince you, or anyone, that Zig's approach to correctness works better than Rust's; we simply don't know. What I'm trying to get across is why both approaches are novel and interesting enough that we need to try both.

BTW, there's another axis we need to consider. The goal of software correctness from the industry's perspective is not how to write more correct software, but how to write more correct software with the programmers we have. That's why, even though it's possible that the few who can make effective use of Idris might (although maybe not) be able to produce more correct programs than others, few consider Idris as the probably solution to the problem because so few programmers would be able to put it to good use. A language that improves correctness by X around for Y programmers contributes less overall to correctness than a language that improves it by X/2 for 5Y programmers.

> Obviously! But my point was that that reasoning isn't additive

That's a very very strong claim without any supporting argument. And I'd be very surprised if it was true. (the success of the Stylo project on Firefox is a significant counter-example for instance).

> -- at a price.

once again, the abstract “price” is invoked, without any characterization… thousands of words later, we still don't know what price you're talking about…

> Except Zig takes that to another level. Rust has some brilliant innovations -- like the borrow checker -- but Zig's entire design is a quite revolutionary, and in multiple ways.

pron waves hands vigorously

You've shown a real difficulty so far to substantiate your argument with anything concrete (on the “price” of Rust, as well as on the “revolutionary” aspects of zig), though you've spent litterally thousands of words on the topic (and not just this discussion, but many before). As the French quote goes ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire viennent aisément, it makes me think you've mostly a gut feeling (Rust bad, Zig good) about this things and not a rational argument.

> I don't need to justify why Rust isn't the best approach out there; the onus is on Rust.

Nope, Rust is the state of the art, and Rust has demonstrated significant benefits over the previous state of the art. Now if Zig comes and wants to challenge it[1], fine but the burden of the proof is on Zig. Want to prove that essential oils are better than antibiotics? Go ahead, but the onus is on you.

> BTW, there's another axis we need to consider. The goal of software correctness from the industry's perspective is not how to write more correct software, but how to write more correct software with the programmers we have.

> […]

> A language that improves correctness by X around for Y programmers contributes less overall to correctness than a language that improves it by X/2 for 5Y programmers.

Yup, and that's why garbage collected languages are the clear winners of the past three decades.

But Rust is especially well-placed in that regard, because most of its users (even the early adopters) are coming from a managed-language background. And anecdotally, making low level code accessible to more developers coming from a more general-computing background is the main reason why Linus Torvalds is interested to get Rust to the kernel.

[1]: in fact this has never been an explicit goal of Zig's creator, who just want to make his programming language without bothering anyone else. He has nothing to prove, and he's never shown any willingness to take part of the kind of silly arguments, this is only the reactionary “Rust bad, need a champion to rant against Rust in online forums” crowd, who does that.

> That's a very very strong claim without any supporting argument.

I'm afraid you completely misunderstand my position. I'm merely pointing out that because we know that more soundness is not always better, the claim that Rust is more effective than Zig is not obviously true. I'm not saying it necessarily isn't. We simply don't know yet.

> the success of the Stylo project on Firefox is a significant counter-example for instance

A counter-example for what? No one is saying that Rust doesn't work well or that it doesn't offer more correctness than C++.

> You've shown a real difficulty so far to substantiate your argument with anything concrete

But I don't have any hypothesis to substantiate. I'm pointing out what we don't know.

I did give concrete examples for cases where unsoundness worked better than soundness, but because we already know that the most effective approach is not on either end, we cannot extrapolate from any specific comparison to another.

If someone wants to say language X works better for correctness than Y, they must compare X and Y, not X and Z. But I'm not making any such claim about Rust and Zig.

> Now if Zig comes and wants to challenge it[1], fine but the burden of the proof is on Zig.

No one is claiming that Zig works better than Rust, no one wants to "challenge" Rust with Zig, and no one is challenging the claim that Rust works better than C++. I want both languages to challenge the status quo.

> But Rust is especially well-placed in that regard

Of course. Rust and Zig are both well-placed in that regard, and people who care about correctness want both:

First, we don't know which, if any, works better than the other.

Second, even if one of them does work better than the other, I think it's pretty uncontroversial that they both provide better correctness than C++ (they both provide stronger guarantees, and neither is significantly more complex than C++). But because it seems that there are people who don't like Rust, and there are people who don't like Zig, software will be better served by having both.

Those who say they want Zig to not exist (like pcwalton) are not serving software correctness. I want Rust; I want Zig. We don't know what works best, neither of them is for everyone, so we need both.

> in fact this has never been an explicit goal of Zig's creator, who just want to make his programming language without bothering anyone else

Indeed. More correctness than C and C++ is, of course, one of Zig's goals; more correctness than Rust isn't. But more correctness than Zig isn't a goal of Rust, either. We want both to exist, if only because different people would prefer different languages, and both are probably improvements over the status quo. It's pcwalton who said he doesn't think Zig should exist. So let's not bother anyone else by making unsubstantiated claims about which is better, and certainly not by saying that the other shouldn't exist. Okay?

> > That's a very very strong claim without any supporting argument.

> I'm afraid you completely misunderstand my position. I'm merely pointing out that because we know that more soundness is not always better, the claim that Rust is more effective than Zig is not obviously true. I'm not saying it necessarily isn't. We simply don't know yet.

This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false. The Firefox team successfully shipping their multi-threaded CSS engine in Rust while they had failed to do so in two or three previous in C++ hints that implementing complex algorithms and at the same time having to be sure you don't mix things up with lifetime is harder than just implementing the same complex algorithm without having to think about mixing things up with lifetimes. The great shift towards Java in the 90s is also an indication of it. Taking the responsibility to manage memory manually is hard, very hard and adds a significant burden on the programmer. And this isn't “unknown”.

> and certainly not by saying that the other shouldn't exist. Okay?

Where in my comments can you find a single occurrence of this claim?

I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based as people arguing that “we don't know if vitamin D or Hydroxychloroquine are better than vaccines”. Zig doesn't have to be on par with Rust to have its right to exists, there's no point overselling with on the “correctness” argument that has never been its main stated motivation. And you, the “Java guy who doesn't like Rust” are practically the only one having this argument on HN, you should try leaving Rust and Zig alone for once.

Anyway, you've long stopped giving arguments and have been parroting the same “we don't know” over and over and over without any attempt to add anything new to the discussion, so I'm not interested in pursuing. Too bad, I won't have a single example of how Rust incurs a cost in correctness, nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness, so much virtual ink spent in vain.

> This isn't in any way related to the claim that I qualified as “very strong”: you said “But my point was that that reasoning isn't additive”, which is a very strong claim and likely to be false.

You've misunderstood. I am not trying to make a claim about how reasoning works, but to give possible explanations for why assumptions that more soundness is always better often turn out wrong, i.e. how it could work. The question of why it is that we get such "surprising" outcomes in software correctness is interesting, but we until we get an answer to it, we just know that we get surprising answers.

> I'm just arguing that at this point your reasoning of saying “we don't know which is better” is as fact-based

This doesn't make sense at all. Not knowing is the default. Until there's conclusive evidence, the fact is that we don't know.

> Too bad, I won't have a single example of how Rust incurs a cost in correctness

I don't know that it does. I gave you several examples of how it might: reading it is hard as it has implicitness and compiling it takes long making testing more burdensome. Maybe there are other reasons, maybe there are none.

Now, this is handwaving, but it's more than we need. It's okay to believe that Rust yields more correctness than Zig, the same amount, or less, but until we have empirical findings one way or the other, we don't know, even without any handwaving.

> nor how Zig's design is so brilliant it will make thinking about memory more practical than C and avoid memory management to get in the way of correctness

I explained that, too. Not only does Zig provide sound spatial memory safety -- which neither C nor C++ do -- but it also has precise pointers, i.e. you can soundly track where your pointers are, which is not the case in C/C++, where you can magically create bad pointers from good ones with pointer/array index arithmetic, or magically create pointers from non-pointers with silent casting (like unions). Zig, like Rust and GC languages has precisely tracked pointers. Good pointers can turn bad through user-after-free in Zig, but they can't be "born" bad as in C and C++.

> Where in my comments can you find a single occurrence of this claim?

Not in yours. In pcwalton. You've just tried inverting the rules of science by saying that if you assert something is true and someone else points out that it's an unsubstantiated hypothesis, the burden of proof is on them, thereby making your hypotheses true by default.

Again, I think there can be a wide consensus that both Zig and Rust provide more correctness than C or C++ because they both make stronger sound guarantees and neither is worse at reasoning or testing than C++, but the question of whether any of them is more effective at correctness than the other is unknown, and unknowable until we empirically compare the two. That something is unknown is not a claim that requires proof; until we have proof for something -- we don't know.

Here's what happened with Haskell: Some Haskellers kept insisting that Haskell yields more correctness than some other languages, and that that should be accepted as the null hypothesis until proven otherwise. Then there were a number of empirical tests that believed they'd be able to show it, and they couldn't find any large effect. So even after the empirical examination some Haskellers insisted their hypothesis should be taken as true by default, because the empirical tests weren't good enough. The result is that people who care to claim about correctness get sucked into these beliefs and not even empirical findings (or lack thereof) can shake them. That's not how we move correctness forward. Of course, Rust is not quite in the same position as Haskell because it hasn't been around the long, but it's important not to get too attached to religious beliefs that "this is the only way." Findings in software correctness frequently surprise us.

> This doesn't make sense at all. Not knowing is the default. Until there's conclusive evidence, the fact is that we don't know.

[…]

> You've just tried inverting the rules of science by saying that if you assert something is true and someone else points out that it's an unsubstantiated hypothesis, the burden of proof is on them, thereby making your hypotheses true by default.

You should definitely take epistemology classes on coursera or elsewhere, because by our definition of “knowing”, we never get to know anything.

And unfortunately this “but we cannot know it's too complex” is way too common nowadays, from climate change to pandemic management “we don't know” is a convenient fallacy. There are key things that we actually do know :

- that Rust is memory safe while Zig isn't (not even from a spacial perspective because there are escape hatches).

- that memory safety is a deep issue and tracking object lifetime by hand isn't something humans are good at, at all. (and use of Zig in the wild shows that the issue is unsurprisingly very common in Zig, as it is in C).

So, yes we cannot be sure that there aren't second orders or third orders effects that makes Rust less than optimal and compensate for this massive difference, but there exist no convincing list of such hypothetical effects that could have a significant impact in Rust's ability to build correct software (to take your examples about legibility and testing, Rust has a strong emphasis on explicitness and incremental builds are more than fast enough for efficient testing, so there's little margin for gains on these fronts).

So have clear evidences of a strong first order effect in favor of Rust, and no compelling evidences for adverse higher orders effects, that's what our current knowledge is.

That's a big difference with your Haskell example, because Haskell cannot really pinpoint a significant edge over other languages, it's more a collection of convenient little things, so the improvement is much more vulnerable to higher order effects. The same could be said if we had to compare Rust and Java for instance: I much prefer use Rust than Java because there are many things that I like but at the same time there are little things that are decisively in favor of Rust (Send and Sync trait for compile-time thread safety is nice, but really workload dependent) so I'd be very wary of saying that Rust leads to more correct code than Java.

But Zig carries a significant burden in that regard (and I believe it should really think about introducing a borrow-checker-like in its design before it's too late and compatibility with existing code makes it impossible, while eschewing the whole ML-style functional stuff that Rust has, because that part is definitely in the “nice to have but not really significant” category).

> because by our definition of “knowing”, we never get to know anything.

I was talking about the common scientific method. You can define "know" as "the vast majority of the target community is sufficiently convinced that something is true."

> and use of Zig in the wild shows that the issue is unsurprisingly very common in Zig, as it is in C

You've seen absolutely no such thing.

> So, yes we cannot be sure that there aren't second orders or third orders effects that makes Rust less than optimal and compensate for this massive difference, but there exist no convincing list of such hypothetical effects that could have a significant impact in Rust's ability to build correct software

I am not doubting Rust's ability to build correct software, just the claim that it's obviously the best approach.

> Rust has a strong emphasis on explicitness

I think you don't understand what "explicitness" means in this context, as Rust relies on more implicitness than most popular languages.

> So have clear evidences of a strong first order effect in favor of Rust, and no compelling evidences for adverse higher orders effects, that's what our current knowledge is.

Taken as is, you're once again claiming that your belief requires no evidence. Taken more charitably, what you're saying is that you believe it because it is very obvious to you. In that case, either it will be easily verified by the evidence and rather quickly, or it will be shown wrong just like previous "obvious" beliefs regarding software correctness.

What you can't do is is demand evidence from others because what's obvious to them isn't obvious to you, and at the same time claim that what's obvious to you and isn't obvious to others should be assumed true.

> because Haskell cannot really pinpoint a significant edge over other languages

I don't know if you're aware how this kind of argumentation sounds to others, but are you really comfortable making such arguments to support what is a scientific claim? Not only did Haskell supporters say the exact same thing (their edge over, say, Clojure was, of course the type system) but even after time and again we see how complex this subject is, how elaborate the interactions, you make an argument that is not much stronger than, "well, I have more money in my wallet than you, and since I can't immediately see any indication that you have more in your bank we can safely assume I'm richer than you."

> But Zig carries a significant burden in that regard

And Rust carries a significant burden, too: it hinders, in comparison, the two most effective assurance methods we have, tests and code reviews. Just as importantly, too many people find complex languages unappealing, and so the impact a language that not many people would use cannot be large.

Now, I am not trying to convince you that you're wrong, just that different things are obvious to different people, and unless something is obvious to pretty much everyone -- which clearly isn't the case here -- you cannot expect others to just accept your belief, however strongly you believe it, while demanding evidence from them for not accepting it.

The fact is that however obvious it may seem to you, other do not not seem to think that it is obvious that Rust leads to more correct software than, say, Zig. If you're trying to convince others of that, then you have to support it by their standard, not yours (of "faith alone suffices"). I would suggest not repeating arguments that are not only logically weak but have failed just recently, and prefer empirical evidence.

But hey, do what you want, and if you believe that everyone should be convinced or that perhaps everyone is already convinced -- that's fine, too. Just don't be surprised when others find such assertions of faith somewhat cultish and not a good look for programmers.

And you know what? If you think your argument is so scientifically convincing, try writing a science paper making the claim that Rust yields to better correctness than Zig.

Until then, programmers will use whatever language we find most aesthetically pleasing, enjoyable, or profitable.

It's funny to read you talking about “beliefs” and “cult” while at the same time being in such a denial:

> You've seen absolutely no such thing.

Just go ahead, grab a few popular projects in Zig (for instance Bun or the zig compiler) and their issue tracker and see how fine the situation is.

And as an epistemological conclusion to this discussion, I should note that while you use “beliefs” pejoratively, but “knowledge” is in fact nothing more than rationally founded “beliefs” that's open to perpetual questioning ;).

Here you just refuse to accept to even think about the rational arguments because they go against your beliefs, hence the reluctance to address the arguments when I've exposed them, falling back to parroting your common sense over and over.

To this day I think the top 3 popular Zig projects are Bun, as you mentioned, then River [1] and TigerBeetle [2].

[1] https://github.com/riverwm/river [2] https://github.com/tigerbeetledb/tigerbeetle

Up to you to decide how fine is the situation in those projects.