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

Thoughts on Go vs. Rust vs. Zig

sinclairtarget.com

Post reply on HN
Print view View original

581–590 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#581

Post by bnolsen »

incompatible wrote: post #152
10000truths wrote: post #77

The reason I really like Zig is because there's finally a language that makes it easy to gracefully handle memory exhaustion at the application level. No more praying that your program isn't unceremoniously killed just for asking for more memory - all allocations are assumed fallible and failures must be handled explicitly. Stack space is not treated like magic - the compiler can reason about its maximum size by exam…

I don't know Zig. The article says "Many people seem confused about why Zig should exist if Rust does already." But I'd ask instead why does Zig exist when C does already? It's just a "better" C? But has the drawback that makes C problematic for development, manual memory management? I think you are better off using a language with a garbage collector, unless your usage really needs manual management, and then you ca…

I don't think manual memory management is c's problem. a very large number of errors i see in 'c' programs comes from the null terminated string paradigm and also mistakes from raw pointer manipulation (slices/fat pointers help a lot here).

Re: Thoughts on Go vs. Rust vs. Zig

#582

Post by bnolsen »

usrnm wrote: post #408
kachapopopow wrote: post #223

Earlier quoted context omitted.

template concept non_zero = (V != 0); template concept arithmetic = std::is_arithmetic_v ; template requires non_zero struct complicated { template using nested_alias = std::tuple ..., std::conditional_t 0 && ...), T, std::nullptr_t> >; template static constexpr auto process() { return [] (std::index_sequence ) { return nested_alias {}; }(std::make_index_sequence {}); } }; I most definitely agree.

The difference is that nobody really writes application code like that, it's a tool for writing libraries and creating abstractions. If all of the ugliness of async Rust was contained inside Tokio, I would have zero problems with it, but it just infects everything it touches

Unfortunately it makes the libraries difficult (or at least very tedious) to read. I find zig's standard library a very good reference for figuring out to do things in application space, from what I've seen it's been very clear and useful.

Re: Thoughts on Go vs. Rust vs. Zig

#583

Post by bnolsen »

throwawaymaths wrote: post #74
kachapopopow wrote: post #26

I could never get into zig purely because of the syntax and I know I am not alone, can someone explain the odd choices that were taken when creating zig? the most odd one probably being 'const expected = [_]u32{ 123, 67, 89, 99 };' and the 2nd most being the word 'try' instead of just ? the 3rd one would be the imports and `try std.fs.File.stdout().writeAll("hello world!\n");` is not really convincing either for a ba…

'const expected = [_]u32{ 123, 67, 89, 99 };' constant array with u32, and let the compiler figure out how many of em there are (i reserve the right to change it in the future)

'const expected: []const u32 = &.{ 123, 67, 89, 99 };' also works.

Re: Thoughts on Go vs. Rust vs. Zig

#584

Post by bnolsen »

Klonoar wrote: post #211
vegabook wrote: post #80

The last paragraph captures the essence that all the PL theory arguments do not. "Zig has a fun, subversive feel to it". It gives you a better tool than C to apply your amazing human skills, freely, whereas both Rust and Go are fundamentally sceptical about you.

I mean, if we're going to go there, you could take it a step further: Zig allows the programmer ego to run wild in a way that Rust and Go do not. This is perhaps somewhat natural; people like and want to be good at things . Where you fall on the trade off is up to you.

I might buy your argument except that without corporate sponsorship for zig several projects using a very young and unfinished zig exhibit world class performance and utility, apparently without herculean effort.

Re: Thoughts on Go vs. Rust vs. Zig

#585

Post by bnolsen »

intalentive wrote: post #533

>You have more control here than you have even in C: To allocate bytes, you have to call alloc() on a specific kind of allocator You can write your own allocator in C. You don't have to use malloc.

you could fully redesign libc to be modern and toss out the null terminated string concept and use fat pointers and slices. But at that point why not consider moving onto a more modern language with things like explicit type conversions, modern PEG type grammar, etc.

Re: Thoughts on Go vs. Rust vs. Zig

#586

Post by bnolsen »

the__alchemist wrote: post #17
echelon wrote: post #2

> Many people seem confused about why Zig should exist if Rust does already. It’s not just that Zig is trying to be simpler. I think this difference is the more important one. Zig wants you to excise even more object-oriented thinking from your code. I feel like Zig is for the C / C++ developers that really dislike Rust. There have been other efforts like Carbon, but this is the first that really modernizes the langu…

Same. Zig's niche is in the vein of languages that encourages using pointers for business logic. If you like this style, Rust and most other new languages aren't an option.

This confuses me. In zig null pointers are illegal, and I have yet to run into any case that should be addressed by using pointer arithmetic, that's all taken care of with slices.

Re: Thoughts on Go vs. Rust vs. Zig

#587

Post by bnolsen »

throwaway2037 wrote: post #363
yxhuvud wrote: post #362

Earlier quoted context omitted.

It'd be very interesting to see an OO language that passes around allocators like zig does. There is definitely nothing in the concept itself that stops that.

What about allocators in C++ STL (Standard Template Library)? Honestly, I have been reading & writing C++ for a squillion years, and (1) I have never used an allocator myself, and (2) never seen anyone else use it. (Granted, I have not seen a huge number of enterprise C++ code bases.)

they are very awkward to use in the current STL, they are part of the template definition. Back in the day EASTL did allocators much better but it never became a thing.

Re: Thoughts on Go vs. Rust vs. Zig

#588

Post by meepmorp »

bnolsen wrote: post #586
the__alchemist wrote: post #17

Earlier quoted context omitted.

Same. Zig's niche is in the vein of languages that encourages using pointers for business logic. If you like this style, Rust and most other new languages aren't an option.

This confuses me. In zig null pointers are illegal, and I have yet to run into any case that should be addressed by using pointer arithmetic, that's all taken care of with slices.

Seems like it's just a comment written by someone with little to no experience using zig.

Re: Thoughts on Go vs. Rust vs. Zig

#589

Post by riku_iki »

throwaway2037 wrote: post #363
yxhuvud wrote: post #362

Earlier quoted context omitted.

It'd be very interesting to see an OO language that passes around allocators like zig does. There is definitely nothing in the concept itself that stops that.

What about allocators in C++ STL (Standard Template Library)? Honestly, I have been reading & writing C++ for a squillion years, and (1) I have never used an allocator myself, and (2) never seen anyone else use it. (Granted, I have not seen a huge number of enterprise C++ code bases.)

> (1) I have never used an allocator myself, and (2) never seen anyone else use it.

arena allocators are necessity for high performance software, because heap allocations are magnitude slower.

Re: Thoughts on Go vs. Rust vs. Zig

#590

Post by riku_iki »

raggi wrote: post #215
zozbot234 wrote: post #141

Earlier quoted context omitted.

> Every adherent of managed memory languages should take it as a personal insult that people are choosing to write modern terminal emulators in Rust and Zig. How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC. A modern terminal emulator is not going to involve complex r…

> How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC. I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not. Rust does a decent job of giving you some ergonomics to get started, but it is still quite unergonomic to fix…

> I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not.

all GC have overhead, but specific allocation pattern: allocators with arena has as minimum overhead as possible, and are orders of magnitude faster because of this. Feel free to tell why this statement is wrong.

Post reply on HN