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

281–290 of 429 posts

Re: Zig, the Small Language

#281

Post by pcwalton »

pron wrote: post #272
pcwalton wrote: post #174

Earlier quoted context omitted.

> Zig has full spatial memory safety, which is already a huge improvement over C. I don't believe this is true. Zig has pointers to unknown numbers of items, which don't seem bounds checked: https://ziglang.org/documentation/master/#Pointers They prefer slices idiomatically, but that's not "full spatial memory safety". C also prefers you to pass the length of every array whenever you pass a pointer to it, in that cor…

> 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 unions. Just now I found another: sentinel-terminated pointers, since you could delete the sentinel.

It feels a bit like these arguments are going like "Zig is spatially memory safe!" "Well, what about X?" "OK, other than X, Zig is spatially memory safe!" "What about Y?" "OK, other than X and Y, Zig is spatially memory safe!" At this point the burden of proof isn't on me anymore.

It's obvious that full spatial memory safety just isn't a design goal of Zig. It seems like Zig's goal is simply to add tools, like slices, that reduce memory errors. Which is the same goal that, for example, the C++ STL has. It's a great goal, but it shouldn't be confused with Rust's goal.

> [1]: Even disregarding the hard question over which of Zig or Rust make it easier to write correct programs, which could go either way; that sound memory safety is a better path to correctness than a balance of less soundness combined with simplicity is your opinion

It's my opinion in the same sense that it's my opinion that wearing seatbelts results in fewer deaths on the road. The idea that memory-safe programming languages improves real-world safety is backed up by decades of experience. Anyone arguing otherwise has a massive burden of proof. And the arguments I've seen by people arguing that you don't need temporal memory safety are weak. The idea that a simple language that doesn't have ironclad safety guarantees reduces errors over a more complex language with those guarantees sounds nice in theory, but it hasn't actually turned out that way in practice.

Re: Zig, the Small Language

#282

Post by zozbot234 »

mwcampbell wrote: post #280
pcwalton wrote: post #151

Earlier quoted context omitted.

> Third: There are a lot of cases where the cost of memory safety just isn't that high, and Zig's mitigations are more than sufficient. But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. C++ makes sense when you already have a lot of C++ code, but if you're talking about new code, I don't see a lot of room for a language without memory safety.

> But then why not just use a GC'd language? It isn't 1995 anymore; most apps are written in GC'd languages. I mostly agree with you, and I'm enthusiastically using Rust. But I'd love to be able to develop new software, with modern developer conveniences, that could run on a 1995 computer. Assuming that implies a 32-bit OS, that seems plausible with Rust, albeit not with std (but alloc should be fine). Maybe I'll pla…

Rust has already been made to compile stuff for 1995 systems, if only as an experiment: https://seri.tools/blog/announcing-rust9x/ / https://news.ycombinator.com/item?id=31112273

Re: Zig, the Small Language

#283

Post by thegeekpirate »

llimllib wrote: post #36
masklinn wrote: post #22

Earlier quoted context omitted.

> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, b…

This really irritated me when I started working with go, but it stopped bothering me and now I even mostly like it. The missing error checks are annoying, but if you have appropriate editor config it is hard to miss them: https://cdn.billmill.org/static/newsyctmp/warning.png Basically writing go without `staticcheck`[1] is not recommended. If you do have it set up, it's pretty easy to avoid simple errors like that. I…

Use golangci-lint (https://golangci-lint.run, https://github.com/golangci/golangci-lint) which combines all of the best lints (including staticcheck).

Re: Zig, the Small Language

#284

Post by Akronymus »

TakeBlaster16 wrote: post #65
masklinn wrote: post #22

Earlier quoted context omitted.

> I do understand the reasoning (they don't want people committing poor quality code) Not that this lint actually achieves that, or even prevents real errors. Go has the same, and it's so simplistic as to only be annoying. For instance not sure whether this fails in Zig but Go will allow this: v1, err := Foo() if err != nil { return nil, err } v2, err := Bar(v1) return v2, nil Error of second call is never checked, b…

Zig seems to behave similarly. This compiles: export fn x() i32 { var a: i32 = 1; // okay a = 2; return a; } This does not: export fn x() i32 { var a: i32 = 1; // unused variable var a2: i32 = 2; return a2; } > Not that this lint actually achieves that, or even prevents real errors. I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

> I have to agree. If there's one thing I've learned over the years, it's that you can't prevent bad code by enforcing lint errors.

A lot of simple cases can be handled with linting rules, BUT that, IMO requires a few additional things. Namely, being expression based, rather than statement based, and enforcing something like a hindley milner type system.

Re: Zig, the Small Language

#285

Post by lopatin »

kristoff_it wrote: post #221
lopatin wrote: post #195

Earlier quoted context omitted.

A dogmatic one, by the sounds of it.

Well if one never stops to think about its potential merits, it can surely only be perceived as dogmatic. One thing is evaluating a choice in its full context and not liking it, another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.

> you might want to take a moment to ponder the fact

> Well if one never stops to think about its potential merits

Listing some of those merits may be more productive than insisting people aren't thinking about it hard enough

Re: Zig, the Small Language

#286

Post by bobbylarrybobby »

flumpcakes wrote: post #196
azakai wrote: post #149

Earlier quoted context omitted.

"Not much safer" isn't fair. Zig has full spatial memory safety, which is already a huge improvement over C. The Zig type system and how idiomatic code looks also prevent various safety risks. Also, Zig panics on integer overflow, avoiding various other dangers. Zig does lack a general solution for temporal memory safety. That is a downside. But it can still have that safety in ReleaseSafe mode, at least - for exampl…

I scratch my head when people think Rust is the "the answer". Zig has different trade offs to Rust and in some areas is safer . It is also a much smaller language , and hopefully won't need language lawyers to debate endlessly best practices. A gentle reminder to people that even "safe" Rust code can still crash. We always need to be vigilant and take our time to actually think about what we are doing and not just on…

Can you explain the areas in which Zig is safer than Rust?

I'm under the impression that crashes are considered perfectly safe because they don't lead to memory unsafety. They're inconvenient, but eliminating them is more or less impossible: if you don't want stack overflows, you have to ban recursion; if you don't want integer overflow, you have to ban addition or insert checks for overflow; etc.

Re: Zig, the Small Language

#287

Post by ptato »

kitkat_new wrote: post #267
ptato wrote: post #176

Earlier quoted context omitted.

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.

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.

Re: Zig, the Small Language

#288

Post by LAC-Tech »

ArrayBoundCheck wrote: post #271
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…

That was my problem with it. That and being mildly annoyed the creator hates tabs

Thankfully the tabs thing is not meant to be permanent.

Re: Zig, the Small Language

#289

Post by LAC-Tech »

sph wrote: post #139
ptato wrote: post #55

Earlier quoted context omitted.

There's a lot of people in the community that feel this way as well but tolerate it. I think it's a certainty that whenever zig 1.0 arrives it will immediately be forked to turn the unused errors into warnings, at least for debug mode. Another situation where I think the compiler is too eager with errors: unreachable code. A bare `@panic("")` won't compile, but you can "turn off" the error by doing `if (true) @panic(…

IIRC there's already a Zig fork that turns that abomination off. I remember seeing it mentioned in that upstream issue OP mentioned.

Do you remember the name or have a link?

Re: Zig, the Small Language

#290

Post by LAC-Tech »

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.

Post reply on HN