Live data from Hacker News

Zig, the Small Language

zserge.com

181–190 of 429 posts

Re: Zig, the Small Language

#181

Earlier quoted context omitted.

"The borrow checker stops only easy memory errors" is not the impression I have of Rust, and I would love to learn more about this claim. For example, I'd love to see examples of CVEs on common rust libraries that you mention, if they are caused by safe code (ie, not using `unsafe`, which means the borrow checker is in effect).

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory

Out of the 10 top ones in that list about Rust (there's one about C code in GCC),

1. 6 are because of unsafe code.

2. 3 are because of ouf-of-memory (OOM) errors.

3. 1 is due to unsafe code in `tokio`, but I think it's fair to consider unsoundness in tokio's safe abstractions (over unsafe code) as unsoundness in "safe Rust" because the crate is so foundational, even if its third party.

Regardless, I don't think any of the above support your claim that "the borrow checker only prevents the easiest memory errors".

I imagine one could argue that OOM vulnerabilities are less likely to happen in Zig because of its emphasis on fallible and explicit allocation, but that's still not an argument for the borrow checker only preventing the easiest memory errors I think.

Re: Zig, the Small Language

#182
post #144

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/

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

The fanaticism of Rust devs makes me think it's probably massively overrated (see Node yesterday and Ruby/Rails the day before) and Go is associated with Google which gets a perhaps unfair but still unignorable knee-jerk reaction from me to avoid it.

I don't know enough about Nim to pass judgment.

Two reasons I decided to give Zig a try: The official chat channel is on IRC, instead of Discord or Slack (so the people involved care about efficiency, open standards, and avoiding trends/bandwagoning), and it has an early but promising-looking Swift UI-like cross-platform UI framework in development: https://github.com/capy-ui/capy

Re: Zig, the Small Language

#183
post #144

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/

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

Some might find Zig to have better ergonomics and some work on systems where dynamic memory allocation and concurrency are inappropriate for safety reasons anyway.

Re: Zig, the Small Language

#184

IME, general purpose "small" languages rarely stay small. Even C has accreted a lot of features. I think Python was small at some point. Pascal was small at some point, but by Delphi had become quite big. Go has just added generics. I think looking at a "smallness" for a relatively young language is likely to be misleading.

Zig is meant to stay small by design, just read all the angry comments about missing features in this very thread :^)

Re: Zig, the Small Language

#185

Earlier quoted context omitted.

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=RUST+Memory

You realize that these are notable because they're so rare, right? The vast majority of these would never even be filed as CVEs in C++. Like, consider https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4569... : "An issue was discovered in the mopa crate through 2021-06-01 for Rust. It incorrectly relies on Trait memory layout, possibly leading to future occurrences of arbitrary code execution or ASLR bypass." I…

To add to that, I think the vulnerability is actually caused by unsafe code too:

https://github.com/chris-morgan/mopa/issues/13

Re: Zig, the Small Language

#186
post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

Go look at herb sutter's guru of the week articles, and consider how many C++ programmers can actually solve them. Then consider c++ has gotten even more complex in the past 9 years since he last published a gotw.

The main problem is that every c++ programmer has their favorite little bit of complexity in the language, and that favorite bit is different for everyone. So you end up with a codebase sprinkled with the full spectrum of language complexity if you're working with a large team, meaning you need to understand all of it if you want to understand the codebase generally.

At least with complex libraries, the complexity can be safely hidden behind the API. Not so with complex languages, at least in my experience.

Re: Zig, the Small Language

#187

Earlier quoted context omitted.

https://play.rust-lang.org/?version=stable&mode=debug&editio... You can put it at the top of your file with a #! too, if you want it to apply to the whole file.

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

This would be really cool! you should open up a RFC for it.

Re: Zig, the Small Language

#188
post #144

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/

It does seem confusing to me why someone would choose Zig. If you’re looking for a low-level language, Rust is safer with a better ecosystem. If you want a high-level language, Nim binaries are smaller and the Go ecosystem is better. When is Zig the best choice?

I could see Zig thriving in a kernel, with its seamless integration with C. It would be a relatively simple upgrade to make. I still think Rust is the better choice though. Maybe the answer to your question is, if you're strictly a C developer and you want something a little nicer without too much more, then Zig might be the best choice for you.

Re: Zig, the Small Language

#189

Earlier quoted context omitted.

That was the first suggestion that Kelley posted on the issue and judging by the reactions people weren’t happy with it.

Completely unsurprisingly. "Add useless garbage to work around the stupid decisions we impose on you" is not very appreciated.

It is not useless though. There is a big difference between an unused variable and explicitly defining an unused variable.

Kelly is designing Zig to do nothing surprising or change things underneath you. Even C does things that are surprising.

If you tell the compiler "Hey, I know this is unused but I am going to write it anyway" then the compiler _can_ make decisions such as eliding the variable.

I think we do all agree that it is sensible that a variable in code that is not used should be a compiler warning (if it is an error or not is clearly debatable).

Re: Zig, the Small Language

#190
post #42

What is the appeal of small languages? If it's simplicity, it seems like complex programs would be supported by complex libraries instead of complex language features, leading to the same level of complexity but with less consistency. "Smallness" seems to be a sought after feature but I'm not sure why.

I must confess I had to suppress my knee jerk urge to downvote. It almost feels like you're asking "what's the appeal of elegance?" "What's the appeal of Chess, if you want complex gameplay just have complex rules." It almost feels alien that someone couldn't get it. Here's a simple but perhaps disappointing theory. Painting with a broad brush for a moment, there are primarily two sorts of thinkers: memorizers and lo…

I feel like your take is simply too strictly bound to your personal preferences. Small is not the same as elegant. If it sad "Zig, the Elegant Language" that would be something else. Lace and watches are elegant but complex and intricate.

A large language might be more consistent and well thought out than a smaller one. That, again, is a separate detail.

And we're talking about the main selling point of the language. Not just 'oh and its pretty small too.' Of all the things to focus on, it would not be my priority for sure.

Post reply on HN