> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot.
> I am personally a proponent of a good macro system.
Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawbacks, but code generation is still a thing.
> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work.
Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten.
But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And those mistakes can have catastrophic consequences. Professionals should go for tools that help them prevent those mistakes, right??
> But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent.
That's true but it's deeper than that -- no matter how much time goes by, there will always be people new to the language, and they will always make newbie mistakes if the language allows them to. So "just be an expert and don't write shoddy code" doesn't scale, no matter how hard you personally try.
It's not that subtle, the thing that we knew doesn't work still doesn't work.
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.
Creating a language which is difficult to use and dangerous is not “lending humanity to the developer”. Humans make mistakes, and a language that doesn't account for this is ignoring the humanity of its users.
Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult". Software is dangerous. Memory safety is one of a million ways it can be dangerous. A compiler barfing when it thinks you are doing something unsafe with pointers is one approach to dealing with one of the ways that code can be dangerous to execute.
Zig does not ignore that particular danger, it just takes a different approach to dealing with it than some other modern languages. An approach that, I believe, leaves the developer with a little more humanity by allowing them the benefit of the doubt that they know what they are doing.
Everyone that has not built a systems language, or has not built a real application with both Zig and a memory safe language, that is reacting emotionally to what I've said should put a lot of consideration into whether they are cargo culting or using critical thought. Consider that we still do not yet know what is best, and shutting down attempts to explore different ideas with things like "creating [and using] this language is ignoring the humanity of the end user" is, well.. dumb.
>Zig is famously simple to pick up and write with, so I don't know what you mean by "difficult".
It's easy to get in a car and put your foot on the pedal, but usage entails not crashing.
>Memory safety is one of a million ways it can be dangerous.
We have the statistics on this. It is 7 out of 10 ways it is dangerous, going by proportion of CVEs, so it's likely higher in less well tested software. Your estimation was off by 5 orders of magnitude.
>leaves the developer with a little more humanity
I could care less if the developer is afforded humanity. I want to write software and I want a programming language that helps me to do that. Whatever humanity I'm sacrificing by writing in memory safe languages is more than made up for by the comparative ease of not having to worry about memory safety.
>reacting emotionally
You are reacting emotionally. You are judging programming languages by their emotional value rather than their features. “Humanity” is not a measurable feature. 70% fewer CVEs is a measurable feature.
I have never heard anyone calling Zig "famously simple" before. In fact, people tend to say it has quite the learning curve.
Of course, caveats apply: it is certainly simple compared to some languages, but certainly not compared to others. "Famously simple" seems to indicate it is one of the simplest languages to learn, which seems wrong unless there are some serious qualifications to that statement?
C, C++, Rust, Zig. Rust and C++ have an infamous learning curve. If you know anything about using any systems language other than Zig, Zig is incredibly simple to pick up, like C. Unlike C, it pushes you toward making less mistakes.
If you don't know anything about using a systems language, Zig makes it easier for the people who do to review your code and make sure you didn't mess it up. It does this with very intentional design that makes it easier to understand the full impact of code quickly, reducing the cost of review, making review practical to catch the issues. It also has many other fail safes to catch these problems before they ever reach a production release.
So, yeah, it's totally depending on where you are coming from -- but Zig is not a tool built for a web developer who doesn't know anything about memory to go and ship an application within their first week. It does make it easier for that person to learn the ropes at a steady pace.
Meanwhile, everyone complaining that Zig is not memory safe doesn't seem to care that applications written in Zig do not have the vulnerabilities that memory safety solves on the scale that C does[0].
If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.
If you have, you probably understand there is a niche that Zig fits in and that it isn't surprising it exists to fill it. Like all things in our industry, there is a cost/benefit analysis required for choosing the tools you build with.
No one reasonable has claimed that memory safe languages should not exist, but there is a maddening number of people being disrespectful toward those who think there are other ways of addressing the same problems.
If you are comparing Zig to Rust and C++, which are very well known to be difficult to learn, then that is not really saying anything about the ease of learning it. Compare it to Swift, D or Odin. Is it "incredibly simple" compared to those languages as well?
Similarly, one can claim that pretty much anything compiles "incredibly fast" if one compares with Rust, C++ and Swift.
But comparing to worst in class doesn't actually say anything.
One note about this:
> If you have not written a real application in Zig and evaluated it for vulnerabilities, but are claiming that creating Zig was irresponsible, and using it is too; you are cargo culting.
I don't know what this has to do with my comments at all, but I want to point out that you are using "cargo culting" wrong. This describes imitating practices of something successful, thinking that by this imitation, success will follow as well.
> No one reasonable has claimed that memory safe languages should not exist,
Again, I have not talked anything about whether memory safe languages should or should not exist. You are confusing me with someone else.
Marketing speak, that looks to be trying to put Zig over languages like Golang, Vlang, etc... which are well known for their simplicity and readability. The false hype arguably creates confusion, that Zig can be "all things to all people", when it's not.
> But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
Which part of expertise is rejecting the fact that safety through professional mind tricks in lieu of better underlying language design is unattainable?
> But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
This made me think about Rust borrow checker: given the amount of people struggling with it, I would think the number of experts is much lower than I would initially assume.
> But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
Seconded. I've really come to loathe tech that is constantly trying to "help me" unprompted and do things I didn't ask/want it to do or burying settings/configurations if not obfuscating them away entirely and acting as if it's doing me a favor by removing features in the name of "simplicity" or some shit. And let's not forget built-in obsolescence moonlighting with privacy-disrespecting dark patterns masquerading together as "Smart Devices."
>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work.
... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.
The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requires less competence than other forms of thinking about a program, then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more.
Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young. Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and that one had the advantage of Apple pushing it as the main language for iOS development, Rust never had that kind of marketing and corporate support.
It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.
Typescript is a tool more than a language, so that's not fair at all.
And the rest of those basically had no competition in their domain when they started 30+ years ago. Rust now has to grow next to 30 years of those languages maturing, and convince people to abandon all existing community resources - whereas those languages did not.
Having a low adoption rate is normal in this day and age. Go is kind of an anomaly caused by it's backing by Google.
But it doesn't help that Rust is also in the native space, whose devs are especially stubborn, and is a difficult language with painful syntax.
> And the rest of those basically had no competition in their domain when they started 30+ years ago.
That's not true, as anyone who was programming back then (like me) knows. Java had serious competition from VB, Delphi, and a host of other "RAD" languages as they were called back then (and not long before, the language that the magazines were touting as "the future" was Smalltalk). All of them were heavily marketed. C++, of course, had to compete against an established incumbent, C, and another strong contender, Ada (Ada, BTW, was about as popular in 1990, when it was 10 years old, as Rust is today, although bigger, more important software projects were being written in Ada in 1990 than are being written in Rust today). Python and Ruby both were both competing with the very powerful incumbent, Perl. PHP, of course, had Java to compete with, as did C#. Some of these languages had strong backers, but some started out as very small operations (Python, C++, PHP), and some languages with very strong backers did poorly (Delphi, FoxPro).
Again, I have no idea if Rust will ever really take off, but its adoption at this advanced age, despite no lack of marketing, would be extraordinarily low for a language that becomes very popular.
> But it doesn't help that Rust is also in the native space, whose devs are especially stubborn
Perhaps, but Fortran, C, and C++, were all in this space and they all spread rather quickly. Microsoft, a company with a fondness for complicated languages, chose to write significant portions of their flagship OS in C++ when the language was only five years old.
It's true that the market share of low-level languages has been shrinking for several decades now and continues to shrink, but also isn't really a good news for a language that for at least a decade has been trying to get a significant share of that shrinking market, and has been having a hard time at that.
> and is a difficult language with painful syntax.
Yes, but this, too, isn't a point in favour of betting on Rust's future success. Other difficult or complex languages indeed had a harder time getting much adoption in their first decade, but things also didn't pick up for them in their second decade.
The latest bloomer of the bunch is Python, but if Rust ever becomes very popular (even as popular as C++ is today), it would need to break Python's record. That's not impossible, but it would be highly unusual. Low adoption in the first decade has virtually always been a predictor of low adoption down the line, too.
I'm curious, do you have figures for this? I was not around when C or C++ were 10, but I was when python was and as a long time python user I would say that the pycommunity was much smaller at 10 then the rust community at 10. So my gut feeling is that your statement is false at least wrt python, but I'm happy to change my mind if you have sound data.
Edit: just to add some more anecdotal evidence from my memory of languages I used: java community was pretty bigger than rust at 10. Go's was much smaller than rust at 10. I'd be happy to check my beliefs against actual data :)
I wasn't programming yet when C was 10 years old, but I was when C++ was 10 years old (1995), and its adoption was an order of magnitude higher than Rust's is today.
I agree that of all popular languages, Python is the latest bloomer, but while it became popular for applications and data processing rather late, it was used a lot for scripting well before then.
> Go's was much smaller than rust at 10
Go turned 10 (if we want to count from 1.0) only 3 years ago, and Go's adoption in 2022 was much bigger than Rust's today.
I don’t have a dog in this race but I was also around at that time and one reason is there was far less choice in 1995 about where you would go from C. C++ was also a vastly simpler language back then (no templates, no exceptions, barely a few hundred command line options). So I am not sure what its adoption then can teach us about language adoption now.
I don't think it's true there was far less choice in 1995. Around that time (a few years later) I was working on a project that was half Ada half C++, and there were a few more exotic choices around. Aside from those, and C, there were still projects in the company back then written in Fortran and even in Jovial. At university, I learnt Esterel for formally-verified embedded software. And that's not even touching on the higher level space, where VB, Delphi, some Smalltalk, and a large selection of other "RAD tools" were being used (my first summer job was on what today would be called an ERP system written in a language called Business Basic). At university, the language I was taught at intro to compsi was Scheme (that was also the embedded-scrpting language we used at work). We were also taught ML and a bit of Haskell.
It's true that not many languages that seemed a reasonable choice at the time survived to this day as reasonable choices.
I dunno, I think you're trying to split hairs if top 20 isn't "very popular".
But I don't think the comparison you're trying to make works, because then isn't now.
In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better. As in, you need to offer the entire feature set of the old tool plus something else compelling enough to overcome the network effects (ecosystem + years of experience + job prospects) of the prior environment.
So when C++ came on the scene, they had to compete against ~20 years of accumulated legacy systems and language history. Rust had to compete with 50 years of legacy systems and language history.
Moreover, developer expectations are a lot different today. Back then, C++ was what, a compiler and some docs? Python was an interpreter and some docs? Maybe an IRC channel? Today, it's not enough to reach 1.0, you also have to deliver a package manager, robust 3rd party library ecosystem, language server tooling, a robust community with support for new devs, etc. So timescales for language development are getting longer than they were back then.
Also, I don't know why you've chosen "very popular" as a metric. Very popular isn't something a language needs to be, it just needs to be big enough to sustain a community. Being top 20 within 10 years is certainly in that realm. You can see that other language communities have existed for longer and are much smaller. And anyway, the entire developer population today is much larger than it was back then; you can have a small percentage of all developers but still large enough to be robust. I don't know the math, maybe someone can figure it out, but I wouldn't be surprised if 1% of developers today is inflation adjusted to like 10%-20% of developers in 1996. So Rust is probably as big as it needs to be to sustain itself, it doesn't have to be a "very popular" language if that means being in the top 5 or whatever the threshold is.
> In general, in order to convince someone to leave their current tools, you have to not only be better but a lot better.
I agree.
> So when C++ came on the scene, they had to compete against ~20 years of accumulated legacy systems and language history. Rust had to compete with 50 years of legacy systems and language history.
Ok, but Go and TypeScript are pretty much the same age, and when Java came out, it took over much of C++'s market very quickly.
I agree Rust has some clear benefits over C++, but it also has intrinsic challenges that go well beyond mere industry momentum (and other languages have shown that momentum is very much defeatable).
> Moreover, developer expectations are a lot different today.
But there are more programmers today, and many more people worked on Rust than on C++ in its early years. And besides, Rust has had all those things you mentioned for quite some time, and C++ still doesn't have some of them.
> Also, I don't know why you've chosen "very popular" as a metric. Very popular isn't something a language needs to be, it just needs to be big enough to sustain a community.
I agree it doesn't need to be very popular to survive. But popularity is a measure of the actual benefit a language brings or, at least, lack of popularity is a measure of lack of sufficient benefit, because software is a competitive business. So claims that Rust is some huge game-changer don't really square with its rate of adoption.
> I agree it doesn't need to be very popular to survive. But...
I think that's the end of it then, yeah? We've established it's popular enough (you set a lower bound at Haskell, which has been around for 35 years, has an active and vibrant community, and is still used in industry), we agree it doesn't need to be more popular, so then this threshold of "very popular" you invented (which I guess is the top 10) is arbitrary and therefore not relevent.
> Ok, but Go and TypeScript are pretty much the same age, and when Java came out, it took over much of C++'s market very quickly.
These two languages were created and pushed by two of the largest corporations on the planet. Typescript is basically Javascript++, and it came at a time when Javascript was to a large degree the only language for the browser. So they had: 1) one of the largest corporations in the world backing it with effectively unlimited money as part of a larger campaign to win web developer mindshare 2) a large developer base of people who already spoke the language 3) guaranteed job opportunities (at least at Microsoft, so more quickly followed) for people who invested in it. Microsoft was also instrumental in defining the platform on which Typescript ran, so they had that benefit as well. That's one way to achieve success for a language, but it requires only offering a very small delta in features; Typescript could only do what it did by being Javascript + types.
Likewise with Go, they bootstrapped that community with Googlers. Bootstrapping a community is way harder than bootstrapping a language, so having a built-in community is quite an advantage. People wanted to learn Go just to have it on their resume, because they heard it would help them land a job there. Plenty of my students took that route. Google threw their weight around where they could for Go, even going as far as to steal the name right out from another language developer and telling him to pound sand when he complained about it.
I mean, Google could afford to hire Robert Griesemer, Rob Pike, AND Ken Thompson to create Go; whereas Rust came from the side project of a lowly Mozilla software engineer. We're looking at two very different levels of investment in these respective languages.
This seems to me like cherry picking. You're taking the best-case scenarios and then comparing it to something not like that at all. When it pales in comparison, you conclude it's not sufficient. But here's the thing: if we want programming as a field to evolve, not every new language can be ExistingLang++. Some languages are going to have to take big swings, and they're not going to be as popular as the easy road (big swings mean big divisions and polarized views; Javascript + types is an easy and agreeable idea). That doesn't mean they aren't just as if not more beneficial to programming languages as a field.
> But there are more programmers today, and many more people worked on Rust than on C++ in its early years.
Yes, and that completely muddles your point, which is why these comparisons don't make sense. It's like comparing the success of a new NFL team to teams from 50 years ago. Yeah they're ostensibly playing the same game but in many important ways they're actually not.
So at best in order to make the claim you're trying to make, you'd have to normalize the data from then and now. You haven't done that so you can't say Rust hasn't achieved arbitrary threshold of popularity after 10 years and therefore... I'm not exactly sure what your conclusion is actually. Therefore it won't survive? Therefore it's not all people make it out to be? I don't know, you're not being clear.
> But popularity is a measure of the actual benefit a language brings or, at least, lack of popularity is a measure of lack of sufficient benefit
If you're going to make this claim you've gotta back it up with some data. "popular", "actual benefit", "sufficient benefit" are all fuzzy words that mean one thing in your head but mean something different in everyone else. Many people live long enough to understand "popular" and "best" are not often synonymous.
> So claims that Rust is some huge game-changer don't really square with its rate of adoption.
Did anyone make that claim here? Rust is programming language like any other, and at best it's an incremental improvement over current languages, just like all of the top new languages of the last 50 years. The closest thing to a "game changer" I've seen is LLM vibe coding, but otherwise the game in Rust is the same as it's always been: 1) press keyboard buttons to write code in text buffer, 2) compile, 3) dodge bugs, 4) goto 1. Rust makes the first and second parts marginally worse, while making the third part marginally better. It doesn't change the game, but it makes it more fun to play (IMO).
> These two languages were created and pushed by two of the largest corporations on the planet.
I don't think Rust lacks in hype and marketing. It doesn't buy ads in print magazines, but no language does anymore (that's exactly how VB, Delphi, FoxPro, Visual C++, and Java were marketed). And don't forget that while being well-known is necessary for success, it's far from sufficient.
There's also the matter that large corporations may let certain star personalities work on vanity projects, they tend not to invest too heavily in projects they think are unlikely to succeed. In other words, even corporations can't market their path to success, at least not for long. That's why they try to market the things they already believe have a chance of success. Sun acquired technologies developed for Smalltalk and diverted them to Java because they believed Java had a better chance of success.
> This seems to me like cherry picking
Quite the opposite, I think. I can't find a single example of a language with Rust's adoption at age 10 that ended up very popular.
> whereas Rust came from the side project of a lowly Mozilla software engineer
So did C++.
> If you're going to make this claim you've gotta back it up with some data.
I'm backing it up with the market and the idea that in a highly competitive market, any technology that carries a significant competitive advantage in shorter time-to-market or in better reputation etc. should be picked up - at least if it is well-known. It's the claim that a technology gives its adopter a competitive advantage and yet doesn't spread as quickly as previous similar technologies that requires explanation.
> Did anyone make that claim here?
This whole debate is over whether Rust has some "superabled" and unique bottom-line-affecting capabilities compared to Zig.
> Rust is programming language like any other, and at best it's an incremental improvement over current languages
If you see Rust as one avenue for incremental improvement over C++, then we're in complete agreement :)
I have received 3 transmissions from you so far, and you have yet to define "success" or "popularity", nor have you specified the threshold between "popular" and "very popular", despite having agreed with me that these things are not important for languages. Moreover, you haven't brought any figures to bear in supporting your claims. I think if we are going to continue this discussion, you have to substantiate your position -- otherwise I don't think you've said anything here that I haven't already responded to.
A specific definition of "popular" doesn't matter. What we can say is that Rust's market share at age 10 is lower than that of Fortran, COBOL, C, C++, VB, Python, JS, Java, C#, PHP, Ruby, TS, Kotlin, and Go at that age, but it's bigger than that of ML, Haskell, Erlang, and Clojure at that age. I don't know if I can compare its market share to that of Ada at that age. I'm nearly certain that much larger (and definitely more important) programs were written in Ada circa 1990 than are being written in Rust today, but it's hard for me to compare the number of programs.
Let's remember: Dancin' Duke Java Applets distributed with Netscape's web browser.
"Sun is giving away Java and HotJava free, in a fast-track attempt to make it a standard before Micro-soft begins shipping a similar product"
Zig began development ten years after Rust. If we were counting from the beginning of the development rather than 1.0 (as I did above), then Rust is about to turn 20.
> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.
What are we measuring? Lines of code? Number of programmers employed? Number of new applications started?
Rust is in: Linux, Windows, Azure, all over AWS, Amazon's Prime video, Cloudflare's proxy, Firefox, Python's `cryptography` package, Zed editor. This is just the sample I know of.
> What are we measuring? Lines of code? Number of programmers employed? Number of new applications started?
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.
As in, why not use a language with much stronger formal verification? Because people have tried it and failed.
Like you said, Rust is hard, it already feels at the limit of what people can handle.
But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.
> But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while
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.
Sure, that makes sense. I agree this is all very subjective, given we don't have the benefit of hindsight for what Zig can accomplish yet.
I think where we disagree is that you believe Zig is as safe as Rust (by making it easier to make other things safer). I don't believe so (my first impression of Zig was Bun repeatedly segfaulting), and I'm just sad that people are choosing the easy route and going for more insecure software, when it finally looked like we made such great progress, with a language people can actually use. I agree with simpler, but there's so many other things that can be changed or removed from Rust, and still leave in lifetimes, or something similar.
> I think where we disagree is that you believe Zig is as safe as Rust
Quite the opposite. Rust is definitely safer in the simple sense that it guarantees more memory safety. But that's very different from saying that Zig is closer to C than to Rust (Zig's memory safety is much closer to Rust's than to C's), and it also doesn't mean that it's easier to write more correct/secure software in Rust (because there are just too many factors).
> and I'm just sad that people are choosing the easy route and going for more insecure software
The jump from "segfaulting" to "insecure" is unjustified, as not all causes of segfaults map to equally exploitable vulnerabilities. Java programs, for example, segfault much less than Rust programs. Does that mean Rust programs are significantly less secure?
> Zig's memory safety is much closer to Rust's than to C's
This is arguable. Zig's issues with memory safety are not limited to such things as use-after-free ("temporal" memory safety in a rather obvious sense). Without something very much like Rust's borrow checker and affine types, you can't feasibly prevent a program from inadvertently e.g. stashing a pointer somewhwere to an inner feld of a tagged union, and reusing that pointer later even though the union itself may have mutated to a different tag, which results in undetected type punning and potentially wild pointers. The issue of iterators to a collection being invalidated by mutation is quite similar in spirit, and again has nothing to do with the heap per se. Rust prevents these issues across the board. The fact that it also manages to prevent temporal memory unsafety altogether is simply a bonus that essentially comes "for free" given the borrow checking approach.
That's not arguable. Because if we say that memory safety is important because it prevents some common and dangerous vulnerabilities, then Zig clearly prevents the most dangerous of those, while C doesn't.
> you can't prevent a program from inadvertently...
Now you're naming more problems that aren't as high on the list as the ones Zig does prevent (and C doesn't). It's true that type confusion is also rather high on the list, but Zig clearly reduces type confusion much more than C does.
Nobody denies that Rust prevents more issues than Zig via sound guarantees - albeit at what I think is a significant cost, and we can argue, subjectively, over whether those issues are worth that cost or not - but Zig's guarantees are still closer to Rust's than to C's if eliminating very common/dangerous vulnerabilities is what we're judging by.
The underlying issue is that Zig turns out to have no feasible safe subset, just like C - unless you go as far as to declare things like using tagged unions in combination with pointers "unsafe" which is both insanely restrictive and hard to check programmatically. People might complain about having to fight the borrow checker, but they'd complain a whole lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"
> The underlying issue is that Zig turns out to have no feasible safe subset
It does have a safe subset with respect to spatial memory safety, which is the more important kind of memory safety if what we judge by is dangerous vulnerabilities.
> People might complain about having to fight the borrow checker, but they would complain a lot more if the standard approach to safety-subsetting a language was just bounds-checked array access plus "you can write FORTRAN in any language!"
I don't know how you can say that this is an objectively-supported claim given Rust's poor adoption at its age.
Rust's real superpower is its tooling. Cargo handles package management, building, testing, documentation, and publishing. The compiler's errors explain what went wrong and where it happened. Installing the toolchain with rustup is quick and painless, even on Windows. I can't know that it's best in class, but it's certainly the best I've used.
I can see another language having a more expressive type system, I've come up against the limitations of Rust's type system more than once, but the tradeoff isn't worth it if I have to go 20 years back in time in terms of tooling.
Rust is much older than Zig, though, and there's nothing stopping Zig (or any future language that doesn't adopt Rust's precise set of guarantees) from having the same, or possibly better. Given Zig's immaturity, I certainly wouldn't use it for any serious production software today.
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.
I hadn't heard of ATS before, and I think that I mistook your using it as an example of "more isn't always better" and thought you were suggesting it as an actual alternative.
I'm looking for the next thing I want to learn, and have been leaning towards logic programming and theorem provers, so you inadvertently piqued my interest.
Sure, just keep in mind that various formal verification tools vary greatly in their usability, even theorem provers. I.e. the experience with ATS will be quite different from Lean, which will be quite different from TLA+.
> ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.
How much adoption should we expect Rust to have at this point, and how does it compare to other languages? I certainly don't have the impression that Rust has relatively low adoption in a general sense, although I'm also a fan of the language and make a point of being in programming communities that are interested in Rust too.
> then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more.
Of course it's subjective, but I think there is a perception of perceived benefit over effort. Zig gives much perceived benefit over low effort. Rust gives much perceived benefit over more effort. Even more effort for ATS. But the benefit is relative: nobody cares to create totally bug-free software when the software is not critical at all. In addition, most programmers think that solving bugs is part of the job more than preventing them. Solving segfaults is often easier than thinking about formal systems, so the perceived benefit is higher in Zig than ATS - at least for programmers that know C, pointers and the like. Note how the majority of programmers don't deal with memory allocations at all: they use JavaScript and Python, memory is managed. For them, solving memory bugs is not something that makes sense, so the effort of dealing with memory is enough to renounce that freedom altogether. Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics.
> Rust is a very good middle ground: it's a complex language, but there's lot of room for improving its ergonomics.
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.
> I am personally a proponent of a good macro system.
Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawbacks, but code generation is still a thing.
> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work.
Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.