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

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

41–50 of 183 posts

Re: Zig and the design choices within

#41

Post by pizza234 »

guywithahat wrote: post #33
deepriverfish wrote: post #30

It's interesting to see how popular Zig is becoming, I thought it would get overshadowed by Rust and it would go nowhere.

It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's…

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle

It is correct that the hype is past its peak, however, the TIOBE trend (if one wants to use that) is actually steadily increasing.

> There is still some development in linux

"Some development" is a miscarachterization - the official addition to the Linux kernel itself is a very big deal, and its adoption is increasing and will continue to do so.

I think that Rust has found its niche in safe low-level programming, and it will slowly have an increasingly dominant role in (although the ceiling of this area is certainly limited in the global landscape).

Re: Zig and the design choices within

#42

Post by pyrolistical »

tayo42 wrote: post #32
torben-friis wrote: post #4

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjo…

With all the hn hype around zig I ended up going through the docs and some example code and felt the same way. I'm not totally sure where this fits into my tool box of languages.

When I first heard about zig, I sat down and read the entire doc from start to end. It was so refreshing and was an instant fan

Re: Zig and the design choices within

#43

Post by pizza234 »

pron wrote: post #28
torben-friis wrote: post #4

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjo…

Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age. I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Ru…

> Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 in either list

Uh? Number 2 in CWE is an out-of-bounds write, and the same vulnerability is number 1 in the KEV list.

Re: Zig and the design choices within

#44

Post by pron »

refulgentis wrote: post #37
pron wrote: post #34

This treatment of memory safety is becoming almost a cargo cult at this point. If this were a binary issue, then clearly Rust wouldn't cut it because it is quite common in Rust (much more so than in, say, Java) to rely on unsafe code. So if you think Rust is good at memory safety, that means that you must believe that some level of unsafety is acceptable. The only question is how much, and what you're willing to pay…

There's no magic wand that can make memory safety unimportant, even doing other important things.

I agree! Memory safety is important because it's the cause of some of the top vulnerabilities, which is precisely why it's great that both Rust's level of memory safety (which is not absolute) and Zig's level of memory safety (also not absolute), both eliminate those top weaknesses!

But once you've taken care of the top weaknesses, it becomes harder to justify putting more effort into eliminating some weaknesses that could go into reducing more common/dangerous ones. If vulnerabilities are the justification, it definitely makes more sense to reduce, say, #4 on the list than #7.

Re: Zig and the design choices within

#45

Post by pron »

pizza234 wrote: post #43
pron wrote: post #28

Earlier quoted context omitted.

Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age. I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Ru…

> Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 in either list Uh? Number 2 in CWE is an out-of-bounds write, and the same vulnerability is number 1 in the KEV list.

That falls into "spatial" memory safety, which Zig also provides. Rust's ownership and lifetime - the core of its design - go into eliminating use-after-free, aka "temporal" memory safety.

Re: Zig and the design choices within

#46

Post by pyrolistical »

refulgentis wrote: post #39
pyrolistical wrote: post #12

The authors section on comptime makes me believe they have not used zig anything non trivial. I don’t think comptime as just some macro system. It is closer to a reflection system. I use comptime to access types. You can create specialized paths depending on type. Also imo generics are “first class” in zig. Comptime is first class and thus generics are too.

> X is first class and thus Y [implemented in terms of X] is too. Is everything first class, then?

I would argue C preprocessor macros are not first class. They are optional.

This anything implements with macros are not first class

Re: Zig and the design choices within

#47

Post by TinkersW »

The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data..

I don't really think much of Zig myself for other reasons, but comptime seems like a good design.

Re: Zig and the design choices within

#48

Post by metaltyphoon »

guywithahat wrote: post #33
deepriverfish wrote: post #30

It's interesting to see how popular Zig is becoming, I thought it would get overshadowed by Rust and it would go nowhere.

It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's…

> It's interesting how much Rust has slowed down

Rust has a SDK from the 3 big cloud providers, Rust IS mainstream.

Re: Zig and the design choices within

#49

Post by James_K »

rvrb wrote: post #29
brabel wrote: post #24

Earlier quoted context omitted.

> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And tho…

Zig is a tool that helps professionals prevent those mistakes. "Memory safe languages" are tools that prevent professionals from making those mistakes. It's a subtle but important difference. Zig attempts to leave some humanity to the developer. When someone says they are incapable of earning or deserving that, I feel sad.

Creating a language which is difficult to use and dangerous is not “lending humanity to the developer”. Humans make mistakes, and a language that doesn't account for this is ignoring the humanity of its users.

Re: Zig and the design choices within

#50

Post by metaltyphoon »

kristoff_it wrote: post #17
torben-friis wrote: post #4

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjo…

Some people like Zig because it makes it easier to learn how to program the machine sitting in front of them. It's better at that than Rust because it's less abstracted, and it's better at that than C because you don't have to worry all the toolchain nonsense / weird conventions / weak type system of the C ecosystem. As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly comp…

> As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha...

Nitpicking? Let’s show an example on creating an interface in Zig to see all complicated tricks.

Post reply on HN