4 ms·

> 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

> 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?
- strcat 4y ago
  Android is heavily adopting Rust. They rewrote the Bluetooth stack, hardware keystore HAL, etc. in Rust and new components like virtualization are heavily using it. This is also behind the effort to get official Rust support in the Linux kernel. Android defines a stable kernel ABI for Linux LTS branches for GKIs (Generic Kernel Images). For example, 6th generation Pixels use the 5.10 LTS branch via a 5.10 GKI which can be updated independent of the device-specific kernel drivers. 7th generation Pixels will use the 5.15 LTS branch / GKIs and 6th generation ones have an experimental 5.15 LTS branch. They want to work towards having the SoC drivers and device drivers written against this stable API/ABI almost entirely written in Rust even if mainline Linux is slow to adopt it.

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?

strcat 4y ago
Android is heavily adopting Rust. They rewrote the Bluetooth stack, hardware keystore HAL, etc. in Rust and new components like virtualization are heavily using it. This is also behind the effort to get official Rust support in the Linux kernel. Android defines a stable kernel ABI for Linux LTS branches for GKIs (Generic Kernel Images). For example, 6th generation Pixels use the 5.10 LTS branch via a 5.10 GKI which can be updated independent of the device-specific kernel drivers. 7th generation Pixels will use the 5.15 LTS branch / GKIs and 6th generation ones have an experimental 5.15 LTS branch. They want to work towards having the SoC drivers and device drivers written against this stable API/ABI almost entirely written in Rust even if mainline Linux is slow to adopt it.