Zig is the new HN clickbait, taking over Rust's spot. That's a good sign for the language, honestly
I totally get it's nicer than C, I love it too, but it's completely irresponsible to push a language without a memory safety story, in 2022, this hard.
From that relatively obvious conclusion it devolves into tedious nerdsnipes. Yes there are edge cases.
It is very much not the consensus that memory safety is a requirement for any modern language. Asserting that it should be a requirement is an extreme position.
Assuming that my argument has "fallen apart", or that you have "dunked" seems quite absurd given that you've taken an extreme position which many serious practitioners and academics would disagree with.
Rust is still very much an experiment in terms of systems programming. It has a tiny overall "market share" in terms of use in large production projects compared to C/C++ and it remains to be seen whether the particular set of tradeoffs chosen by the language will lead to long term sustainable success.
Zig takes another approach and is also a worthy experiment.
I'm not diminishing the success of Rust. It's been proven it can be used for serious projects.
It's a bit of a reach to argue it's proven to be the best choice for all system programming use-cases going forward.
It's especially frustrating because you've received a ton of charity and time from strangers, we understand 110% what you're thinking (I wish it was true! I've had an inordinate amount of work for 18 months now because it isn't) but you can't seem to wrap your mind around the idea that there isn't some niche where Zig is perfect and unassailable or the only alternative is rust. I don't think you have much experience in multiple languages, it's actually fairly easy to get something as fast in JS _as in C_.
It's possible in some cases that you can implement something in JavaScript which is competitive with a systems programming language, thanks to all the incredible optimization work which has gone into JavaScript engines, but the performance ceiling of a language like JS is much much lower than that of system programming languages. For instance, if you are optimizing for memory cache performance C or Rust or Zig are going to have tools which just don't exist in JS. There's a reason that HPC - one of the computing fields where profitability literally depends on speed - is all implemented in C and C++.
And not that it matters but I've got plenty of experience with languages. I've been doing software engineering professionally for over a decade, and I've shipped professional projects in probably a half dozen languages or more including C, Rust, and Javascript. I've also done my fair share of programming in the systems domain, including computer graphics and games. I've also implemented programming languages of my own.
> you can't seem to wrap your mind around the idea that there isn't some niche where Zig is perfect and unassailable or the only alternative is rust.
I never said Zig fits a perfect niche. I said the theory of the language is valid, and it's a worthwhile contribution to the field. Zig, like all other languages, is an experiment. It's actually quite an interesting one with different goals than a lot of the other popular languages out there, and which is very appealing for the systems programming domain. I'm arguing against the idea that Zig is "irresponsible", which is an extreme position.
I keep bringing up rust because of you guys insistence that Rust is a counter-example to the idea that a new systems programming language not necessarily be memory safe. For instance this comment:
> We can't ignore the fact that Rust has shown that memory safety is not incompatible with low-level semantics.
Seems to imply that Rust's existence unto itself is proof that every new systems programming language must be memory safe.
C is the current standards bearer for systems programming. Everyone is trying to invent a "better C". Go and Nim are trying to do it with garbage collection. Rust is trying to do it with the borrow checker. Zim is trying to do it with ruthless simplicity and explicitness.
All of these are experiments, and all of them are valid. 20 years from now we'll know a lot more about what works and what doesn't from each of these experiments, but it's too early to conclude that now.
No, Zig is simply not memory safe. That's a property of a programming language that has a definition. Zig does not meet that definition.
> I find it funny that fans of a language of a not-so-young-age that is struggling to find relevance and capture even 1% of the market are treating it as such an inevitability that it's irresponsible to talk about anything else.
Leaving aside your weird description of a language powering software that serves billions of users as "struggling to find relevance", most software in 2022 is written in languages that are memory safe. Zig is quite the outlier here. It would in fact be very reasonable to survey the landscape of popular languages today and come to the conclusion that memory safety is an inevitability.
> It's also detached from reality, as much of the software we all depend on is being written, in 2022, in languages without sound memory safety guarantees.
Virtually all of that software is being developed in C or C++. The most compelling reason to use those languages is that they have a huge install base and a huge amount of code already written in them. This says nothing about whether a brand-new language should be memory safe.
> There are various approaches being tried for how we should write low-level programs in the future, but there is no consensus yet on the best one.
No, there actually is PL consensus that all new languages should be memory-safe, maybe aside from very low-level specialized languages, which Zig is not trying to be--Zig is trying to be a general purpose language.
I didn't claim that it is. I said it has a good memory safety story, i.e. mechanisms that soundly guarantee some kinds of memory safety, plus a design that helps write correct programs. Correctness in general, and memory safety in particular, are very central concerns in Zig's design, it's just that its story isn't one of sound guarantees across the board but, rather, some balanced mix of approaches -- some based on soundness, others based on facilitating comprehension and easier testing.
> Most software in 2022 is written in languages that are memory safe. Zig is quite the outlier here.
No, Zig is a low-level language, and the vast majority of low-level programs in 2022 are written in languages whose memory-safety story is worse than Zig's.
> This says nothing about whether a brand-new language should be memory safe.
That's right. We don't yet have an answer to that question, because we don't yet have sufficient experience with low-level languages that do have sound memory safety guarantees. I mean, it sure is better to have more guarantees if they come for free, but there's no such option in front of us just yet.
> No, there actually is PL consensus that all new languages should be memory-safe
No, there really isn't one when it comes to low-level languages (and the interest in Zig is proof that there is no consensus that it shouldn't exist). Rust is a low level language with sound memory safety guarantees, which comes at a price that makes it unappealing for some, and so various other approaches are being tried as well.
You can't insist there's consensus when clearly there are people who disagree with you. That's the definition of a lack of consensus. I also think it is premature, to say the least, to declare an approach that is currently still far from proving a success as the only way.
Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. It's not spacially memory safe: extern unions, sentinel-terminated pointers, and multi-element pointers break it. At best, we think there's probably some subset of Zig that you could define that is spacially memory safe. (This isn't a particularly interesting property because it's trivially true for any language, by the way: C without pointers and without arrays is a subset of C that's memory safe, for instance, and also uninteresting.)
> No, Zig is a low-level language, and the vast majority of low-level programs in 2022 are written in languages whose memory-safety story is worse than Zig's.
Zig claims to be a general-purpose language, not just a low-level one. From [1]: "Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software."
> I mean, it sure is better to have more guarantees if they come for free, but there's no such option in front of us just yet.
It's better to have more guarantees if the benefit of the guarantees outweighs the cost, not if there is no cost. For example, for many apps, the benefit of memory safety outweighs the cost of a garbage collector.
> You can't insist there's consensus when clearly there are people who disagree with you. That's the definition of a lack of consensus.
Consensus doesn't mean that nobody disagrees. It means that the opposite position is a fringe view.
It does.
> It's not spacially memory safe: extern unions, sentinel-terminated pointers, and multi-element pointers break it.
We've been through that. Those are syntactically delineated unsafe features for C/hardware interop. Rust has them, too.
> This isn't a particularly interesting property because it's trivially true for any language
That's right, but Zig is much closer to Rust than to C in that regard. It has clearly marked unsafe features for C or hardware interop, which aren't used in other situations and could be mechanically excluded -- just as in Rust.
> Zig claims to be a general-purpose language, not just a low-level one.
Surely you agree it's also a low-level language?
> It's better to have more guarantees if the benefit of the guarantees outweighs the cost, not if there is no cost.
Yep, and we don't know if we're there in low level languages. So far it seems that some people find the cost of Rust acceptable and others do not. In other words, there's no consensus on what the acceptable cost is.
> It means that the opposite position is a fringe view.
So disagreeing that the only right design is that of a language that's struggling to get 1% of the market is a fringe view? That's like a Haskeller declaring that it is a fringe view to disagree that non-strict pure functional programming is the only right way to write programs. I think that Odin and JAI, two other low level languages in development, also don't go down the full memory-safety soundness path. Seems to me to be quite far from a fringe view.
If people aren't buying what Rust is selling -- regardless of how strongly some feel about the justice of its approach -- I think that those of us who care about correctness must explore alternatives, and Zig is certainly a fascinating alternative. It might well be the case that neither Rust nor Zig succeed in the market, but even in that case, both can certainly serve as inspiration for the languages that follow.
And again we're assuming that the ones we went over in the previous thread are all there is. I found some more: @intToPtr, @bitCast, @alignCast. Some of those @ functions are spatially-memory-safe, and some are not: the differences are not clearly called out.
(I'm going to charitably assume that taking a pointer to an element in a dynamically-allocated array, and then shortening that array and dereferencing that pointer, is a temporal memory safety violation rather than a spatial one.)
> That's right, but Zig is much closer to Rust than to C in that regard. It has clearly marked unsafe features for C interop.
How are they clearly marked, when they're neither relegated to a separate section of the documentation nor behind a switch? As far as I can tell, the person who has gone through the most effort to isolate the spatial memory safe subset of Zig is me, in these HN threads.
> So disagreeing that the design of a language that's struggling to get 1% of the market is the only right way is a fringe view now?
Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now.
No one is assuming that. Like Rust, Zig has a set of unsafe operations that are well known to Zig programmers.
> How are they clearly marked, when they're neither relegated to a separate section of the documentation nor behind a switch?
They are syntactically distinct from the safe features, and they might be hidden behind a switch when there's demand for such a feature.
> As far as I can tell, the person who has gone through the most effort to isolate the spatial memory safe subset of Zig is me, in these HN threads.
So not only is disagreeing with you a fringe opinion, you're now the most knowledgeable on Zig's safety, a subject that is of great interest to Zig programmers? Those who spend the two days required to learn Zig know which operations are unsafe.
> Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now.
Haskell and Erlang are also "serving billions of users" in the same way. The fact is that at an age where almost all programming languages (Python might be the sole exception) were in the ballpark of their all-time peak popularity, only a tiny portion of developers choose Rust. Like Zig, Rust is a language whose future success is uncertain.
Look, not everyone would like Zig, not everyone would like Rust, and for all we know it's quite possible that the main difference between the two approaches is that they appeal to different people. But trying to make Rust's design appear inevitable or uniquely legitimate for low-level languages when that language is doing poorly, or claiming to speak on behalf of a consensus where there clearly isn't one and several other languages targeting the same domain prefer a very different approach, make you sound detached from reality.
I find it a questionable choice to design a new complex language when complex languages tend to do poorly in the market, or to attempt a language for low-level programming that tries to appear high level on the page after C++'s lacklustre success with that approach, but I recognise that not everyone has the same taste as me, and I wouldn't call my opinions a consensus.
Which language and which project is this referring to?
This is an extremely strange argument. How much market share do you think C has in 2022?
You seem to massively underappreciate the dominance of the web and the hegemony of languages like JavaScript and PHP. System languages are a very tiny niche and there's much less changes there than in other domains.
Rust has obviously way less than 1% market share but it's still extremely successful in the niche it's targeting. (And btw, we're talking about the only niche that still hasn't embraced memory safety, mainly because there was no acceptable tools for that meeting their requirements)
Extremely successful? It's not even mediocre. A more realistic description of its current position in its niche domain might be "still hanging in there", "not yet completely written off" or "not out of the race but waiting for a miracle."
Rust is barely at 5% of the low-level market. Its performance in its target domain is so abysmal at over seven years old that some who'd want to try it don't because its future looks so uncertain. For comparison, almost every programming language reached or at least neared its all-time peak popularity around age 10. Even if things improve we're looking at a peak of 20% of its target niche before the novelty wears off and other languages join the fray. It needs to double its market share in the next couple of years not to be "extremely successful" but just to stay relevant.
This is an extremely vague claim with so many caveats that it doesn't end up meaning anything yet if you state it confidently you might fool idiots into thinking you said something consequential.
It'd be great if there was all the real competition you seem imagine for Rust, but we don't see that. What we see are people pretending that it doesn't matter if they produce crap software using unsafe languages, but their customers are starting to notice.
As to "crap software", most of application software these days -- crappy or excellent -- is written in safe languages, and nearly all low-level code is written in unsafe languages, including some of the world's most dependable software, from avionics to OSes. We can say with close to certainty that we can do better than C, but we can also say that full soundness (Idris) is not the answer, so the sweet spot is obviously somewhere in the middle. But we really don't know where exactly -- except that it's not at either end -- or even how wide the sweet spot is (or maybe there are multiple ones, which could be either universally equivalent or dependent on some variables).
There's more we don't know about software correctness than what we know -- it's extremely complicated and affected by factors ranging from formal languages and complexity theory to management, economics, psychology, and social psychology -- but we believe noe that the ideas of the 1970s of full soundness being the only path have proven wrong (including an acknowledgment even by Tony Hoare [1]), and, indeed, Rust doesn't adopt soundness fully, and relies on testing, code reviews and other unsound processes as the main means for correctness, like virtually all mainstream programming languages.
Anyone who cares about correctness (like me -- https://pron.github.io) knows to be very skeptical of any claims for absolute answers, let alone simple ones, on that extremely complex subject.
@pron I was with you before: I think pcwaltons' take on zig is ... Err, unduly negative to the point of rudeness and closed minded — and kinda paints a clear picture for why we're seeing all of the defensiveness in twitter from andrewkelly and the zig folks.
But — I think you're coming into it similarly here against Rust. Unnecessarily rude, antagonistic, and on technical points: closed minded.
@pcwalton The zig team feels they've made good pragmatic choices around memory safety? Cool. Leave a few reasons why it's different from/and why rust took another approach and your take. Dope.
@pron The Rust folk are happy and proud of the inroads they've made in adoption. Dope. Sure, there's different ways to slice the numbers and you feel what? They've taken unearned pride in their work?
I'm a fan of all of your work, but man. This thread has been disheartening.
Not at all. I think Rust is a groundbreaking and influential language. Regardless of its success in market, it is a great and lasting contribution to programming language design.
I am, however, triggered by misleading claims about software correctness -- a subject I care deeply about -- which recently tend to come from the Rust community (replacing Haskell), and then annoyed further by claims of inevitability that I find hard to reconcile with the data. Sorry, but I am human :)
The Rust team is rightfully proud of their achievements, in language design, documentation, and also in offering those of us who are interested in software correctness another novel approach to consider.
The idea it's either "Rust or Zig" allows the poorly considered logical jump to Zig. I wouldn't use Rust because it's annoying too, but I also wouldn't choose Zig because I consider part of my professional responsibility to be using...literally any language that has memory safety.
If you think it's your responsibility to use only memory-safe languages, then if you had to do low-level programming, you'd have few option, and those options have their own downsides. That's just the reality of low level programming in 2022 -- it can often only be done in non-memory-safe languages. I actually do quite a bit of low-level programming, and I consider it my professional responsibility to strive to do that in a language that is explicit and simple; there are no languages, to my knowledge, that meet my requirement and are also memory-safe, so I must compromise on something because I live in the real world.
That isn't true. You want to use a language that is more "explicit and simple". That's your prerogative, even if I disagree with it. But you do have a choice, and you are explicitly choosing to reject memory safety.
Asking as Rustecean.
Instead of focusing on tradeoffs they chose to call others irresponsible.
However, what I've seen in the discourse of several programmers that claim to prefer Zig is the assumption that Rust is "not really that big of a deal". There's a constant minimization of the advancements both the ownership system and the safety approach provide, and a lack of recognition for the fact that the language is a "game changer" in the industry.
Overall, this looks a lot like rationalization of an emotional choice, which for me is much more close to religious zealotry.
I think you have inadvertently worded this in a way that silently confirms what the parent poster was saying. But more generally, while I can't speak for the entirety of the Zig community, the people involved with Zig directly tend to be aware of Rust's strengths. The problem is that one of the reasons why Zig exists (and is having some level of success) is because some people just don't want to deal with abstraction-heavy code. Some people value simplicity over a complex language with a memory-safe subset.
And the value of simplicity is not just a matter of aesthetics. Simplicity is a defense against bugs, because memory safety is not the end goal, correctness is.
To quote Douglas Crockford: "If you say it hardly happens, it means it happens".