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

271–280 of 429 posts

Re: Zig, the Small Language

#271

Post by ArrayBoundCheck »

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

Re: Zig, the Small Language

#272

Post by pron »

pcwalton wrote: post #174
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…

> 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 new language in 2022 that is obviously too complex to see wide adoption." If a language becomes popular then obviously there's room for it, and if it doesn't, then the question is moot. Maybe what you mean is that you don't think Zig would ever become popular -- and you may well be right -- but you work on a language that is subject to similar scepticism and doubt.

Both Rust and Zig have some huge challenges to overcome if either one of them is to have "room", and I wouldn't bet on their chances, but it's good to have some widely different approaches and see which, if any of them, turns out to have "much room".

[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, and few would claim that Rust's flavour of safety doesn't come at a cost.

Re: Zig, the Small Language

#273

Post by errantmind »

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…

I commented on the github issue a while back as I was frustrated with this.

I originally looked forward to splitting my projects between Zig and Rust depending on the project parameters, but because of this one seemingly small issue I will never use Zig.

That's ok, I respect them having the right to do what they want with their language but it is a little sad because I liked pretty much everything else about Zig.

Re: Zig, the Small Language

#274

Post by pcwalton »

cztomsik wrote: post #204
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…

had the same problem, if you're just prototyping, it's easy to silence that with _ = someVar you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.

> you get used to it after some time - much better than for example rust, where you have to figure out all the lifetimes, muts and generic traits before.

They aren't comparable. Everything you mentioned in Rust is necessary for typechecking. Unused variable lints aren't necessary for anything.

Re: Zig, the Small Language

#275

Post by ShredKazoo »

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…

>in some areas is safer

What areas specifically?

Re: Zig, the Small Language

#276

Post by pcwalton »

cztomsik wrote: post #198
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.

for native addons for GC'd languages you probably don't want to introduce another GC, rust is not well-suited for interfacing with FFI, C++ is a bit heavyweight but okish I guess and C is totally unsafe, Zig is just right.

> rust is not well-suited for interfacing with FFI

That's a surprising comment, given the massive deployments of hybrid Rust/C++ apps at huge scale that exist!

Does Zig have any equivalent to cxx for interfacing with C++ code?

Re: Zig, the Small Language

#277

Post by mwcampbell »

cztomsik wrote: post #198
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.

for native addons for GC'd languages you probably don't want to introduce another GC, rust is not well-suited for interfacing with FFI, C++ is a bit heavyweight but okish I guess and C is totally unsafe, Zig is just right.

> rust is not well-suited for interfacing with FFI

How so? Packages like neon [1] and rustler [2] suggest otherwise. I'm using both of those in a real product (I'm using neon directly, to write native modules for an Electron app; on the back-end, I depend on an Elixir package that uses rustler).

[1]: https://github.com/neon-bindings/neon

[2]: https://github.com/rusterlium/rustler

Re: Zig, the Small Language

#278

Post by pron »

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/

I don't agree at all about "not much safer" and Zig differs from C in so many ways -- including but not limited to safety -- but regardless, memory safety comes at a price, language safety is not an end (that would be program correctness) but just one of many means to that end, there is no consensus at all over what is the most effective way to reach that end, and there are other things people care about as well. So your very question is the wrong one. You're both setting an absolute priority as well as the best way to achieve it when there's no consensus over either one of these.

Put another way, the answer to your question is because even if program correctness were the only value that matters to anyone who does low level programming (and it isn't), there's no agreement sound memory safety in the language -- at least the way Rust does it -- is the best way to achieve correctness. Put yet another way, the answer is: for the same reason people would want to use a language with memory safety -- because they think it helps them achieve their goals better.

Re: Zig, the Small Language

#279

Post by dfawcus »

WalterBright wrote: post #44
wyldfire wrote: post #14

Earlier quoted context omitted.

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.

D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types. Not allowing the overloading of…

Well, there is always the limited form of arithmetic overloading which Ken Thompson added to his compiler:

https://marc.info/?l=9fans&m=111559034637840&w=2

Re: Zig, the Small Language

#280

Post by mwcampbell »

pcwalton wrote: post #151
verdagon wrote: post #121

Earlier quoted context omitted.

I think there's three reasons one might use Zig instead of Rust. These are just opinions, and I would love yall's thoughts. First: there's only a certain amount of effort that one is willing to put into accomplishing one's goals, effort that will be spent on learning tools and building a project. It's not unlimited. If I just want to make a game where a character walks around the world, and I only have 20 or so hours…

> 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 play with that for a side project sometime.

Post reply on HN