Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

291–300 of 429 posts

Re: Zig, the Small Language

#291

Post by azakai »

pcwalton wrote: post #281
pron wrote: post #272

Earlier quoted context omitted.

> They prefer slices idiomatically, but that's not "full spatial memory safety" [*] is a syntactically delineated unsafe feature. Rust has the same thing. It's like saying Rust prefers safety, but doesn't enforce it because it has unsafe features; same goes for Haskell. > I don't see much room for a new language that isn't memory-safe in 2022. That statement [1] is about about as silly as "I don't see much room for a…

> Rust has the same thing. In Rust all of those features are delineated by unsafe. For one, you can disable unsafe with a compiler switch; Zig has no such equivalent feature. Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern union…

> Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel.

You're right on each of those points. But (AFAIK) all those types are explicitly there for C interop. When interfacing with C, yes, Zig will inherit much of C's unsafety. But the big picture is that

1. Idiomatic Zig should not use those things, and

2. Those things are (IIUC) mechanically-identifiable at the type level. A compiler flag could warn about them. You can check if a codebase uses them, and find out exactly where. No such thing is possible for C.

Maybe you'd prefer that an unsafe block be required to be placed around each of them, but in the end that's a matter of notation. In theory, Zig could decide to mandate such explicit unsafe blocks, but C couldn't - there isn't a useful safe subset to delineated.

I could be wrong, however. Possibly the Zig community will decide that say sentinel-terminated pointers are good to use in general (and not just for C interop). And maybe I've missed something and those types cannot be discovered mechanically for auditing purposes. If either of those is the case then I'd agree Zig lacks spatial memory safety.

(Btw, you seem downvoted atm. Not me, of course - there's probably no one else I respect more on the topic of memory safety than you! - and it's disappointing that people downvote comments just because they disagree.)

Re: Zig, the Small Language

#292

Post by pcwalton »

azakai wrote: post #291
pcwalton wrote: post #281

Earlier quoted context omitted.

> Rust has the same thing. In Rust all of those features are delineated by unsafe. For one, you can disable unsafe with a compiler switch; Zig has no such equivalent feature. Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern union…

> Moreover, we shouldn't assume that Zig pointers are the only feature that breaks spatial memory safety. It was simply the first one I found after like 2 minutes of looking through the docs. After like 5 more minutes I found another: extern unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel. You're right on each of those points. But (AFAIK) all those types are explici…

Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C++ Guidelines).

I don't see any reason why modern C++ wouldn't be just as spatially memory safe as Zig is, if we're allowed to subset the language in ways more trivial than "disable the unsafe keyword". The main thing that distinguishes Zig at that point would be that it's a simpler language. That's true. But I don't actually think that makes for safer programs, empirically speaking--otherwise, C programs would be safer than C++ programs, and they generally aren't.

Re: Zig, the Small Language

#293

Post by [deleted] »

iainmerrick wrote: post #200
vinay_ys wrote: post #11

Earlier quoted context omitted.

Yep. Exactly. We want to be able to silence the compiler for a few iterations while the code is taking shape and then cleanup all the compiler lints in later iteration. In production CI pipeline, we can have all compiler lints on. This capability is very much needed to have a fast local dev iteration where compiler can assist but not impede.

But then what if you accidentally check in that workaround? The strict compiler check would have had exactly the opposite effect from the intended one.

[deleted]

Re: Zig, the Small Language

#294

Post by littlestymaar »

ptato wrote: post #287
kitkat_new wrote: post #267

Earlier quoted context omitted.

can you give examples please?

It's been ~a year. I can't remember. It usually had to do with the dreaded self referential structures, or interfacing with c libs.

For Self referential struct, the typical answer is twofold:

- try to design your code not to need them.

- if you really need one, you can either use smart pointers (Rc & RefCell) or use unsafe and use the Pin API to be sure that you won't accidentally move your struct.

That being said, it's not easier in C (or at least, it's easier to write, but also very easy to misuse), since a memcopy will silently break your self-referential struct. Do Zig has “Copy constructors” like C++ to avoid this issue?

Re: Zig, the Small Language

#295

Post by slimsag »

dirkg wrote: post #236

I hadn't even heard of Zig till the recent news everywhere on dev blogs about bun.sh, and AFAIK it remains the biggest production project using it. I'm sure there are plenty of other languages such as Nim etc that never get similar exposure.

We're using it to build a game engine[0] competitive in spirit with unity/unreal/godot, right now it's just a really nice way to use WebGPU natively on the desktop[1] though.

[0] https://machengine.org/

[1] https://machengine.org/gpu/

Re: Zig, the Small Language

#296

Post by littlestymaar »

ptato wrote: post #176
littlestymaar wrote: post #156

Earlier quoted context omitted.

> Not fighting the borrow checker This isn't going to be appealing to Rust current users though, because “fighting the borrow checker” is a learning curve issue, you don't fight the borrow checker anymore once you've internalized its rules. > or making gratuitous copies of data to satisfy the borrow checker. You get it backward. In Rust there's less gratuitous copies, not more, because the ownership rules and the bor…

That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.

> I still fought the borrow checker after a year of using Rust.

That's interesting. How much Rust did you use during that year? And how level of proficiency did you reach?

> And I found many situations while using Rust where I either needed to clone, or use unsafe

That sounds like an uncommon trade-off. From my experience, the trade-off was usually “clone or put lifetime parameters everywhere”, which is annoying (and I really wish Rust analyzer could help with at some point, because it's pretty mechanical), but it was quite rare, because most of the time you can just move things (that is transferring ownership), unlike in C where you have either a copy or a pointer.

> or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.

This is unfortunately true. Miri helps, but there's a wide margin for improvement on that front.

Re: Zig, the Small Language

#297

Post by brundolf »

It just occurred to me, Zig could be a great learning-language for CS

When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons.

Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too many additional constraints, and has too many magical abstractions. Eg, doing manual deallocation helps you later appreciate what the borrow-checker does and why it exists

Zig is supposed to be C++ without all the pain and misery (esp around tooling). That could make it perfect for teaching people about pointers and heap allocations and working with bytes, with minimal extra pain and friction

Re: Zig, the Small Language

#298

Post by KerrAvon »

LAC-Tech wrote: post #290
TakeBlaster16 wrote: post #4

I tried Zig recently but I found the unsilenceable lints to be a huge productivity killer. I actually posted a link to the GitHub issue this morning. https://news.ycombinator.com/item?id=32751317 This makes a normal workflow with `watchexec zig test` basically impossible, since before I can even run the tests I have to spend time hunting down which variables are used/unused at the moment and (un)commenting them. And…

This 100%. I love Zig. It's built on such a better foundation than any of its competitors, old or new. I've never been happier or more productive doing systems programming. But the "no warnings" philosophy alienates developers and seriously hurts adoption. It's almost tragic that a language so impressive is going to die on this hill.

This sort of overopinionated design is part of what killed Phabricator. Let me customize the phucking thing a little bit. "No, we're doing opinionated design, and it's our rubber ducky."

Re: Zig, the Small Language

#299

Post by IIAOPSW »

avgcorrection wrote: post #259
chongli wrote: post #244

Earlier quoted context omitted.

There are plenty of people who love chess but hate opening theory. They look to variants such as chess960 to get their logician fix on. They also tend to love Go (the board game) and perhaps even Stratego (which has such a game tree that dwarfs the rest).

Chess was such a good example to use in this lame dichotomy that we are now pivoting to Bobby Fischer chess and completely different games.

Completely different in that everything is exactly the same except for minor variation to the starting position...

Re: Zig, the Small Language

#300

Post by stephc_int13 »

beltsazar wrote: post #124

Why would anyone use a new systems programming language that is not safe? Zig might be better than C in some aspects, but is it worth it to switch to Zig when you realize that it's not much safer than C? [0] [0]: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

As far as I am concerned, the alleged "memory safety" benefits of Rust do not have much more value or weight than wishful thinking, this kind of claim can only gain strength by standing the test of time.

Computer security is a real problem that must be fully addressed at every step of the design of a system, language and tooling can help, a bit, not much.

Rust is not a "safe" language. It might be -safer- than C/C++, but only time will tell if the difference is significant.

Post reply on HN