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

71–80 of 183 posts

Re: Zig and the design choices within

#71

Post by api »

pizza234 wrote: post #41
guywithahat wrote: post #33

Earlier quoted context omitted.

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…

Rust has been adopted by Microsoft, Amazon, etc. It's past the hype phase and well into the "languages people use for work and complain about" phase.

I still like it -- for systems programming, that is. It's a much better C++ basically.

Re: Zig and the design choices within

#73

Post by tayo42 »

pyrolistical wrote: post #42
tayo42 wrote: post #32

Earlier quoted context omitted.

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

It doesn't seem bad, (though with some of rewrite of the std library? It doesn't seem quite ready) Im just not sure when I'll reach for it. I guess I'm comfortable enough with rust and both seem like languages that compile with llvm. Maybe if I didn't know rust it would feel like more useful.

Re: Zig and the design choices within

#75

Post by brabel »

Joker_vD wrote: post #27
brabel wrote: post #25

Earlier quoted context omitted.

That looks a lot like Common Lisp LOOP macro!

Honestly, that's been the standard form of FOR loops since Fortran and Algol-60 until C decided to spice things up.

That may be, but I was born only 40-something years ago, so I haven't had the pleasure to see that other than in Lisp.

Re: Zig and the design choices within

#77

Post by pron »

whytevuhuni wrote: post #57
pron wrote: post #53

Earlier quoted context omitted.

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> Why not ATS? As in, why not use a language with much stronger formal verification? Because people have tried it and failed. Like you said, Rust is hard, it already feels at the limit of what people can handle. But unlike ATS, many people have tried Rust and succeeded , and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.

> But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while

So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time, would be preferable to Rust.

You see, the problem is that these arguments cannot lead us to an objective preference unless we compared Rust to all other points on the spectrum, especially since Rust proponents already must accept that the best point is not on any extreme. So we know that languages that guarantee more than C but more productive than ATS are preferable. Guess what? Zig is right there, too, so that argument can't be used to prefer Rust over Zig.

Re: Zig and the design choices within

#78

Post by pron »

ModernMech wrote: post #62
pron wrote: post #53

Earlier quoted context omitted.

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> a relatively advanced age. Maybe you and I have different working definitions of "relative", but Rust hit 1.0 only 10 years ago, whereas the age of the most popular languages is 30+ years. In that sense Rust is relatively young . Indeed, Rust is the youngest language in the TIOBE top 20, and it's more popular than other languages which have been around much longer. The only language which comes close is Swift, and…

It's actually hard to find any language that has ever very popular (JS, TS, Python, Java, C++, C#, C, and you can even throw in PHP, Ruby, Go, Kotlin, and even COBOL and Fortran) that has such a low adoption rate at age 10. I'm not saying that means Rust won't buck the historical trend and achieve that, but its adoption clearly does not resemble that of any language that's ever become very popular.

Re: Zig and the design choices within

#79

Post by whytevuhuni »

pron wrote: post #77
whytevuhuni wrote: post #57

Earlier quoted context omitted.

> Why not ATS? As in, why not use a language with much stronger formal verification? Because people have tried it and failed. Like you said, Rust is hard, it already feels at the limit of what people can handle. But unlike ATS, many people have tried Rust and succeeded , and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.

> But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while So if Rust is preferable to ATS because more people are productive with it despite ATS being able to guarantee more at compile-time, then by that logic a language that more people would be productive with than with Rust, despite Rust guaranteeing more at compile time…

Sure, that makes sense. I agree this is all very subjective, given we don't have the benefit of hindsight for what Zig can accomplish yet.

I think where we disagree is that you believe Zig is as safe as Rust (by making it easier to make other things safer). I don't believe so (my first impression of Zig was Bun repeatedly segfaulting), and I'm just sad that people are choosing the easy route and going for more insecure software, when it finally looked like we made such great progress, with a language people can actually use. I agree with simpler, but there's so many other things that can be changed or removed from Rust, and still leave in lifetimes, or something similar.

Re: Zig and the design choices within

#80

Post by samdoesnothing »

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…

I think a lot of the absolutists around memory safety are just using it as a bludgeon to evangelize their preferred programming language. Otherwise, the position of "memory safety is the most important thing, but we should ignore other languages that provide stronger guarantees" is absurd.
Post reply on HN