Earlier quoted context omitted.
Zig community really tries to match Rust one in terms of cult resemblance.
Did it occur to you that Rust and Zig might actually be very good?
Oh, they are.
Like a multitude of other languages.
Open-source Zig book
381–390 of 426 posts
Re: Open-source Zig book
#382Earlier quoted context omitted.
Zig community really tries to match Rust one in terms of cult resemblance.
People that consider other people that are excited about something "culty" are usually people that themselves are excited by absolutely nothing.
Nicely formulated, yet not less empty than the picture you try to sketch.
Re: Open-source Zig book
#383Earlier quoted context omitted.
Bar C if you're into system's programming there's no language you *need* to learn.
Partially agree on this, std lib/crates and ease of use do make a difference (this is not even the main reason to use Rust), though Rust certainly has its own headaches. (Imagine searching for someone's implementation of HashedMap on github or using dedicated packages like glib, when you get it easily at crates.io). Again this is subjective based on use cases.
Not much for authoring new code as much as reading it, it's the lingua franca.
Re: Open-source Zig book
#384I submitted this and unfortunately it is likely AI generated. The authors github history suggests it at the very least, along with seemingly misunderstanding a reference to a Zig language feature (labeled blocks - https://zig.guide/language-basics/labelled-blocks/ ) in the project issues ( https://github.com/zigbook/zigbook/issues/4 ). I’m not sure how much value is to be had here, and it’s unfortunate the author was…
Ok, but even if it's AI generated and won't be maintained or contains errors, I'm not sure that warrants it being _flagged_ on HN.
Re: Open-source Zig book
#385Earlier quoted context omitted.
I'd argue more people use Elixir over Erlang at this point. Sure its just an abstraction on top of Erlang, but people learn through Elixir nowadays, not through Erlang.
If you want to learn the actual mind changing aspects of the BEAM, clearly learning the simpler, smaller language with a more direct route to the juice is the way to go. Hence Erlang, not Elixir. I learned Elixir first back in 2015, and then learned Erlang, and have had the pleasure of using both in production. When all was said and done I really think Erlang was better, especially over a long enough time frame. As a…
>actual mind changing aspects of the BEAM
What are those aspects?
newb to this area.
Re: Open-source Zig book
#386I submitted this and unfortunately it is likely AI generated. The authors github history suggests it at the very least, along with seemingly misunderstanding a reference to a Zig language feature (labeled blocks - https://zig.guide/language-basics/labelled-blocks/ ) in the project issues ( https://github.com/zigbook/zigbook/issues/4 ). I’m not sure how much value is to be had here, and it’s unfortunate the author was…
We really are in the trenches. How is this garbage #1 on the front page of *HN* right now? Even if it was totally legitimate, the "landing page" (its design) and the headline ("Learning Zig is not just about adding a language to your resume. It is about fundamentally changing how you think about software."?????) should discredit it immediately.
When was the front page of HN that impressive anyways? It has always been latest fad and the first to comment "the right thing to say" gets rewarded with fake internet points.
Re: Open-source Zig book
#387Earlier quoted context omitted.
There is nothing new under the Sun. However, some languages manifest as good rewrites of older languages. Rust is that for C++. Zig is that for C. Rust is the small, beautiful language hiding inside of Modern C++. Ownership isn't new. It's the core tenet of RAII. Rust just pulls it out of the backwards-compatible kitchen sink and builds it into the type system. Rust is worth learning just so that you can fully experi…
I think that describing Zig as a "rewrite of C" (good or otherwise) is as helpful as describing Python as a rewrite of Fortran. Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. That makes the similarities to…
To me, the fact that Zig has spent so long in development disqualifies it as being a "rewrite of C."
To be clear, I really like Zig. But C is also a relatively simple language to both understand and implement because it doesn't have many features, and the features it does have aren't overly clever. Zig is a pretty easy language to learn, but the presence of comptime ratchets up the implementation difficulty significantly.
A true C successor might be something like Odin. I am admittedly not as tuned into the Odin language as I am Zig, but I get the impression that despite being started six months after Zig, the language is mostly fully implemented as envisioned, and most of the work is now spent polishing the compiler and building out the standard library, tooling and package ecosystem.
Re: Open-source Zig book
#388Earlier quoted context omitted.
Did it occur to you that Rust and Zig might actually be very good?
Oh, they are. Like a multitude of other languages.
There aren't a multitude of other languages that compete with Rust and Zig in the "zero cost abstraction" domain. There's like, Ada... and D sort of.
Rust and Zig aren't merely very good, they are better than the alternatives when you need a "zero cost abstraction" option.
But sure, go ahead and dismiss it as a cult if it makes you feel better. I bet you were one of the people who dismissed the iPhone as "just apple fanbois" back in the day. Won't amount to anything.
Re: Open-source Zig book
#389Earlier quoted context omitted.
> It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs. Right, this is the specific important thing that Rust does that Zig doesn't (with the caveat that Rust includes the `unsafe` mechanism - as a marked, non-default option - specifically to allow for necessary low-level memory manipulation that can't be checked for correctness by the compiler). Be…
It's not that simple though, Zig has equivalent spatial memory safety which prevents issues that are pretty consistently among (or at) the top of the list for most dangerous vulnerability classes. And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the…
> And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the properties/invariants that you have to preserve. So it comes with serious drawbacks, it's not just a quick "opt out of the safety for a bit" switch.
I think this is hard to generalize about. There are many instances where one might want to do unsafe memory operations in rust, with different correctness implications. I am suspicious that in Zig you do actually have to preserve all the same properties and invariants, and there's just nothing telling you if you did so or not or even what all of them are, so you don't know if your code is correct or not.
Re: Open-source Zig book
#390Earlier quoted context omitted.
> It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs. Right, this is the specific important thing that Rust does that Zig doesn't (with the caveat that Rust includes the `unsafe` mechanism - as a marked, non-default option - specifically to allow for necessary low-level memory manipulation that can't be checked for correctness by the compiler). Be…
Sure but there's this belief in the Rust community that it's not responsible anymore to write software that isn't memory safe on the same level as Rust. So Zig would fail that, but then you could also consider C++ unsuitable for production software - and we know it clearly is still suitable. I predict Zig will just become more and more popular (and with better, although not as complete- memory safety), and be applied…
> So Zig would fail that, but then you could also consider C++ unsuitable for production software - and we know it clearly is still suitable.
Speak for yourself, I never want to write C++ ever again in my life.
I'm not a huge fan of the language of responsibility. I don't think there should be a law banning the use of C or C++ or any other programming language on account of it being unsafe, I don't think that anyone who writes in C/C++ is inherently acting immorally, etc.
What I do think is that Rust is a better-designed language than C or C++ and offers a bunch of affordances, including but not limited to the borrow checker, unsafe mode, the type system, cargo, etc. that make it easier and more fun for programmers to use to write correct and performant software, most of the time in most cases. I think projects that are currently using C/C++ should seriously consider switching off of them to something else, and Rust is an excellent candidate but not the only candidate.
I think Zig is also almost certainly an better language than C/C++ in every respect (I hedge more here because I'm less familiar with Zig, and because it's still being developed). Not having as strong memory safety guarantees as Rust is disappointing and I expect that it will result in Zig-written software being somewhat buggier than Rust-written software over the long term. But I am not so confident that I am correct about this, or that Zig won't bring additional benefits Rust doesn't have, that I would argue that people shouldn't use Zig or work on languages like Zig.