101–110 of 247 posts
TLDR: Zig bad (like C), Rust good. Not surprised to see an article like this from a core Rust member after two positive articles for Zig on HN frontpage. Gotta keep that strong hold on HN!
Still not convinced that memory semantics are critical in the vast majority of domains. Incredibly fast speeds can be achieved with simple GC and RC for short-running programs, and programs with sustained runtimes can rely on generational GC. These methods have the advantage of nearly eliminating the need for memory semantics, leaving only business logic behind. The best example might be Nim, which drastically reduce…
I completely agree with what you're saying here and wonder every day why Nim hasn't taken over the world. People seem not to realize that Nim not only has a "pluggable" gc system (so you can pick the gc that makes sense for your use case), but also allows you to turn the gc off . As in, no gc (which is exactly what you need in certain very narrow situations).
It's not Nims fault, but is still a point of friction
I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…
> ...and want to control exactly where when and how memory is allocated... Isn't this the whole point and the reason why manual memory management is still a thing - and actually getting more important with the ever widening CPU/memory latency gap? There simply is no silver bullet for memory management, you can either have high performance or automatic memory management, but not both. (vastly simplified of course - bu…
That has not been the case in the vast majority of applications I've written across a number of domains using garbage collected languages.
Yes, there is runtime overhead to GC. But for many many programs, the cost of the overhead is acceptable and you can spend all of your time worrying about the application domain and not worrying about allocation.
I tried zig after reading so many HN articles and I am not impressed. You have to remember to free after each allocation. The language is supposed to be simple, yet there exist try, catch, defer, errdefer. Rust enums make defining errors so simple with arbitrary payload. Using data structures in rust is much nicer. I think unless you have some precise needs about memory allocation, and want to control exactly where w…
This is a good comment that I hope can help other readers manage their expectations. Zig is verbose and low-level and, to like it, you have to appreciate simplicity and what it means to have control over tiny details. If you don't like either thing, then Zig will not bring anything particularly interesting to the table for you.
Earlier quoted context omitted.
> I think unless you have some precise needs about memory allocation, and want to control exactly where when and how memory is allocated, it is hard to argue in favour of Zig. I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. That said, I suspect that while they could have written TigerBeetle in Rust (no_std does not assume the existence of an allocator)…
> I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and software keeps getting more bloated and shittier. It is difficult to believe there isn't a correlation.
The really awesome news is that for those of us who still develop software whose requirements mandate this kind of control - better tools like Zig (and Rust) are making things easier but without requiring things like a GC.
Does Rust or Zig's malloc allocate on stack? Those millennials.
This title is almost perfectly designed to do well on HN, but it's definitely worth reading in it's entirety. Some highlights for me: - The author sees Rust and Zig in different niches. When Rust was created it didn't need to specialise because there were no languages like Rust. It was free to be a general purpose language targeting multiple domains. But that's not the case for Zig. He sees Zig shining at writing sys…
> He sees Zig shining at writing systems software that requires low level control. Honestly don't see why we would need to specialize this use case to a different language altogether when Rust already has `unsafe`.
Earlier quoted context omitted.
> Still not convinced that memory semantics are critical in the vast majority of domains. This is okay. Zig is not targeting the vast majority of domains. It targets the low-level, performance-critical domain that C occupies. It would be a great language to write a compiler/interpreter for a higher-level language that has the bells and whistles that you want.
It's still bizarre though that Rust is capturing such ridiculous mindshare. I suspect it has a lot to do with web developers being plugged into Mozilla, and Mozilla spending quite a lot on Rust development and marketing. And Zig may be being roped into it. It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probabl…
I don't think it's that bizarre. The two big headline features that bring Rust such popularity are: #1 "70% of bugs are memory-safety bugs" [1] and Rust can help solve those, and #2 C/C++ have a couple of package manager solutions - none of which have critical mass and Rust "comes with" cargo.
Those two make me really eager to continue experimenting with Rust.
> It seems to be a temporary low-level programming zeitgeist driven by YouTube and Reddit recommendation algorithms to an audience that has never done it and probably never will.
This is some weird gatekeep-y kinda thing. Most of us didn't start out with low-level programming. Wouldn't it have been odd and frustrating for someone to tell your younger self that you have "never written C and probably never will"?
> When we call malloc, we just hope that we have enough stack space for it, we almost never check.
malloc allocates on heap, not stack.
>> When we call malloc, we just hope that we have enough stack space for it, we almost never check. Does Rust or Zig's malloc allocate on stack? Those millennials.