4 ms·

> Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. It does. > It's not spacially memory safe: extern unions, sentinel-terminate

by pron 4y ago

> Zig doesn't have mechanisms that soundly guarantee some kinds of memory safety. 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.

pcwalton 4y ago
> We've been through that. Those are syntactically delineated unsafe features for C interop. Rust has them, too. 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.
- pron 4y ago
  > And again we're assuming that the ones we went over in the previous thread are all there is. 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.
- dom96 4y ago
  > Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now. Which language and which project is this referring to?
  - 4y ago
littlestymaar 4y ago
> a language that's struggling to get 1% of the market is a fringe view 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)
- pron 4y ago
  > Rust has obviously way less than 1% market share but it's still extremely successful in the niche it's targeting 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.
  - littlestymaar 4y ago
    - pron 4y ago
      > 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-languages-in-2022/ 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/ 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.

by pron 4y ago

pcwalton 4y ago

> We've been through that. Those are syntactically delineated unsafe features for C interop. Rust has them, too. 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.

pron 4y ago
> And again we're assuming that the ones we went over in the previous thread are all there is. 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.
dom96 4y ago
> Again, "struggling to get 1% of the market" is a weird way to describe a language that's serving billions of users right now. Which language and which project is this referring to?
- 4y ago

littlestymaar 4y ago

> a language that's struggling to get 1% of the market is a fringe view 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)

pron 4y ago
> Rust has obviously way less than 1% market share but it's still extremely successful in the niche it's targeting 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.
- littlestymaar 4y ago
  - pron 4y ago
    > 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-languages-in-2022/ 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/ 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.