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

231–240 of 429 posts

Re: Zig, the Small Language

#231

Post by avgcorrection »

azakai wrote: post #149
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/

"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…

> That adds overhead, which might rule Zig out in certain areas, but not others.

It seemed back when Rust was an upstart that everyone would ride its behind about how this and that feature could add runtime overhead compared to C or C++. Especially compared to C. But now people are comparing Zig and C and are saying (indirectly) that they are fine with runtime overhead in exchange for more safety? Has a shift happened?

Re: Zig, the Small Language

#232

Post by ok_dad »

md224 wrote: post #193
ok_dad wrote: post #164

Earlier quoted context omitted.

So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...

What if the person you're replying to really, really likes Zig except for this one aspect of it?

Then they shouldn't get so mad at something that's merely annoying; it's bad for the heart and circulatory system.

Re: Zig, the Small Language

#233

Post by azakai »

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".

I don't think people say a language is unsafe if it has opt-in unsafety in controlled, non-idiomatic ways. Java, C#, Rust, etc. all have unsafe things you can do, but they are still memory-safe languages.

Specifically for Zig, I don't see a reason the compiler couldn't have an optional warning on using an unsafe pointer, so codebases can be audited for this risk, making this a controllable form of unsafety (unlike most of the unsafety in C!).

> The overhead is extremely high, because it leaks an entire 4kB page if a single allocation from that page is still alive.

In general you are right, and in a long-running process that would be the case. But consider a short-running wasm event handler: such overhead is generally not going to be significant there. So this rules out some uses cases, but not all.

> I don't see much room for a new language that isn't memory-safe in 2022.

Yeah, I agree the space for a language like Zig is limited: GC languages are the right answer for most things anyhow, as you said, and when they are not, often memory safety is crucial (like in a web browser) and I'd strongly prefer Rust over Zig there.

Still, there are use cases where Zig seems nice, like wasm event handlers that I mentioned: they're sandboxed anyhow, binaries are small, and it's nice to not have GC overhead. Zig's simplicity and fast compile times are a bonus.

Another use case are low-level things that you'd need lots of unsafe in Rust anyhow. I'm not sure if I'd prefer Rust or Zig in such a case myself. I'd prefer either over C, though.

Re: Zig, the Small Language

#234

Post by chongli »

ok_dad wrote: post #164
sph wrote: post #137

Earlier quoted context omitted.

You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a ma…

So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...

So don't use Zig?

I see this comment a lot in response to feedback: "Don't like it? Don't use it!" Every single time, it reads to me as "stop complaining!" For as many times as I've seen the comment, I haven't been able to read it any other way.

Am I being uncharitable or is it really just a clear-cut attempt to silence debate?

Re: Zig, the Small Language

#235

Post by masklinn »

flumpcakes wrote: post #224
masklinn wrote: post #219

Earlier quoted context omitted.

> It is not useless though. True, it's actively harmful. > There is a big difference between an unused variable and explicitly defining an unused variable. Which is not helpful when you're only doing it to hide a compiler error foisted upon you. > Kelly is designing Zig to do nothing surprising or change things underneath you. Refusing to compile my code because I've an unused variable is certainly surprising. > If y…

> That is the opposite of making sense. If you are actively forcing the use of a variable then the compiler removing it anyway is exactly surprising. I disagree, you are actively telling the compiler that this is dead code.

> I disagree, you are actively telling the compiler that this is dead code.

No, you would be doing that by removing the code. You are telling the compiler that this is code you want and to shut the fuck up.

Re: Zig, the Small Language

#236

Post by dirkg »

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.

Re: Zig, the Small Language

#237

Post by TakeBlaster16 »

eddyb wrote: post #207
TakeBlaster16 wrote: post #132

Earlier quoted context omitted.

Oops I didn't explain clearly. Take this code: pub fn abc() -> usize { #[allow(deprecated)] "abc".len() } I want it to complain about the "allow", because there was never any deprecated warning emitted in the first place. Maybe it would be called #[expect(deprecated)] I refactor code all the time and find these stray "allow"s that aren't doing anything anymore

> Maybe it would be called #[expect(deprecated)] Both this and the reply saying you should open an RFC worry me that it was tongue-in-cheek. Or maybe it's the obvious name choice, heh, because it literally exists with that very syntax: https://play.rust-lang.org/?version=nightly&mode=debug&editi... Not stable yet, as you can see, but all the RFC and implementation work has been done, and a stabilization report was ev…

That's hilarious, I had no idea! I'm glad I didn't embarrass myself by proposing an RFC. Thanks for the links!

Re: Zig, the Small Language

#238

Post by geodel »

chongli wrote: post #234
ok_dad wrote: post #164

Earlier quoted context omitted.

So don't use Zig? I don't get why you're so angry about something someone else likes. Just don't use it or look at it! So easy...

So don't use Zig? I see this comment a lot in response to feedback: "Don't like it? Don't use it!" Every single time, it reads to me as "stop complaining!" For as many times as I've seen the comment, I haven't been able to read it any other way. Am I being uncharitable or is it really just a clear-cut attempt to silence debate?

Well it would depend on context. For a FOSS software in domain where there are tons of other options, it is much easier to use what one likes and ignore what one doesn't. So calling it silencing the debate sounds too strong when software in question is not some controlling the world type.

On the other hand in case cloud services like those provided Google/FB/Twitter/Cloudflare etc it is much more difficult to just go with "Don't use if you don't like" because not only there are not much alternative but also because sometimes Cloud service providers act in unison. So if one is pushed out from a service they are likely to be pushed from all other services too.

Re: Zig, the Small Language

#239

Post by ok_dad »

geodel wrote: post #238
chongli wrote: post #234

Earlier quoted context omitted.

So don't use Zig? I see this comment a lot in response to feedback: "Don't like it? Don't use it!" Every single time, it reads to me as "stop complaining!" For as many times as I've seen the comment, I haven't been able to read it any other way. Am I being uncharitable or is it really just a clear-cut attempt to silence debate?

Well it would depend on context. For a FOSS software in domain where there are tons of other options, it is much easier to use what one likes and ignore what one doesn't. So calling it silencing the debate sounds too strong when software in question is not some controlling the world type. On the other hand in case cloud services like those provided Google/FB/Twitter/Cloudflare etc it is much more difficult to just go…

Yea, I was under the assumption there are literally thousands of programming languages and you can fork most of them when I replied.

I’m not usually a “just don’t use it” kind of guy, but in this case it’s valid, imo.

Post reply on HN