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

Zig and Rust

matklad.github.io

Post reply on HN
Print view View original

201–210 of 247 posts

Re: Zig and Rust

#201

Post by randyrand »

netbioserror wrote: post #20

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…

There a lots of good languages to choose from with GC.

Zig would not have much unique to offer if it was a GC language, imo.

Re: Zig and Rust

#202

Post by mustache_kimono »

haberman wrote: post #80
mustache_kimono wrote: post #63

Earlier quoted context omitted.

This definition of "perfect" might be counterintuitive for those that haven't read the piece. The idea is there might some ideal memory allocation scenario that Rust doesn't do "perfectly" that you can theoretically do better in Zig, which I buy. Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. But this definition of perfection tends to ignore all the manual…

> Most particularly, my experience with arenas and defer drop is -- they aren't always perfectly easy in Rust. That is my experience also: https://blog.reverberate.org/2021/12/19/arenas-and-rust.html I was hoping the borrow checker would perfectly check arena lifetimes. And it does, but it requires that your types have lifetime parameters. That makes logical sense, but my experience attempting to actually use a type…

"Why is Rust’s 'Bump' not' Sync'?" was exactly the issue I was thinking of. Thanks for writing this. Seriously, a must read!

Re: Zig and Rust

#203

Post by linhns »

crop_rotation wrote: post #19

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…

Yep. I hardly fine a situation where Zig is the best tool to solve the problem. Guess it will fall out of favour with HN readers soon.

Re: Zig and Rust

#204

Post by throwawaymaths »

monocasa wrote: post #73
throwawaymaths wrote: post #61

Earlier quoted context omitted.

sorry, I should have been clear: I meant with a standard lib provided data structure. Thanks!

Yes, the data structures in std are parameterized over the allocator, with Global as the default allocator if not specified. https://doc.rust-lang.org/std/vec/struct.Vec.html

The point is, they are parametrized over a type, not an instance. By contrast, types in zig that are variadic by allocator are (typically) parametrized over instance.

Re: Zig and Rust

#205

Post by throwawaymaths »

monocasa wrote: post #75
throwawaymaths wrote: post #45

Earlier quoted context omitted.

the assumption with Rust is that memory safety (or, generally, resource provenance) is something that needs to exist in the type system. Zig is still young, so i would say it's not 100% certain that this shouldn't exist, for example, in a separate step, for example using static analysis. Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesys…

FWIW sel4 could have verified the C, they simply decided to verify the machine code so that they didn't have to trust that the compiler correctly complex the verified software. The issue with more broad formal method use is that it's quite a bit of work. The code to be verified has to be designed on the onset for verification, which limits design choices in interesting ways, and even then the verification code far ou…

Thank you for the clarification!

Re: Zig and Rust

#206

Post by throwawaymaths »

estebank wrote: post #163
throwawaymaths wrote: post #45

Earlier quoted context omitted.

the assumption with Rust is that memory safety (or, generally, resource provenance) is something that needs to exist in the type system. Zig is still young, so i would say it's not 100% certain that this shouldn't exist, for example, in a separate step, for example using static analysis. Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesys…

> Rust is already bumping into important cases where the typesystem is incapable of resolving things that "you might want its typesystem to track", and support for these would require breaking all of rust. I would be interested in hearing what it is you had in mind. Are you referring to the discussions around capabilities?

Yes, for example.

Another dramatic one is the whole parametrized keywords thing, though I guess it doesn't quite "break all of rust".

Re: Zig and Rust

#207

Post by pornel »

netbioserror wrote: post #192
pornel wrote: post #191

Earlier quoted context omitted.

They are not for majority of programs, but they are essential in the niches that Rust and Zig target. This is why it took so long to have a viable alternative to C and C++. Every other language decided "memory management is hard, GC is fine for 99% of programs, let's go with GC", and language after language kept disqualifying itself from the no-GC niche. From the Rust intro talk: http://venge.net/graydon/talks/intro-…

A great point. As I’ve commented before though, watching webdevs get excited for it, or “rewrite it in Rust,” or developers contort it to try and do things it shouldn’t is sort of morbid from a distance. I’m sure Darwin will work his magic and Rust will settle in the intended niche. But seeing the insane excitement levels and recruiters using Rust to attract applicants…like I said, morbid, and hard to sustain.

Rust has features besides memory safety that are generally useful — robust error handling, pattern matching, fast and powerful JSON support, nice package manager, ease of deployment, first-class WASM support, etc. Some people value these features enough to use Rust even outside of its niche. Even when performance isn't critical, it may be a nice to have.

I sometimes feel like Rust is overcompensating for its hard parts :) It's not easy to learn its memory management, but the error messages do their best to teach you!

Re: Zig and Rust

#208

Post by Klonoar »

lenkite wrote: post #170
crop_rotation wrote: post #19

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…

"Rust enums make defining errors so simple with arbitrary payload." enum variants are overused in Rust and are highly expensive in memory IMHO. One tends to run into problems like: https://github.com/serde-rs/json/issues/635 in Rust projects when used at scale. Value is an enum variant: https://docs.rs/serde_json/latest/serde_json/value/enum.Valu... Comment from that issue: "For example, ElasticSearch returns a 8,683…

I mean... if the size of `Value` is a problem, use `ijson`, the very crate that the author reporting the issue developed.

This is more or less a solved problem.

Re: Zig and Rust

#209

Post by pjmlp »

nextaccountic wrote: post #193
gpderetta wrote: post #142

Earlier quoted context omitted.

This is exactly how C++ work. union { MyObject space; }; // just a bunch of bytes MyObject * myObject = new(&space) MyObject(); // invoke the constructor myObject->~MyObject(); // invoke the destructor If you want RAII use some wrapper like Optional.

Is this syntax new(&something) a new addition? I don't remember it, but then I used to program in C++03

Placement new was already a thing in C++ARM.

Re: Zig and Rust

#210

Post by pjmlp »

Animats wrote: post #174
spacechild1 wrote: post #133

Earlier quoted context omitted.

> This separates construction, which is a typed thing, from allocation. But this is what C++ actually does! C++ ctors run after memory has been allocated (on the stack, on the heap, from a pool, etc.) Or maybe you mean something different?

The lifetime of the space can be different, but must enclose, the objects created in that space. C++ doesn't track lifetimes. Such a separation is only useful in specific situations, such as the one the original article mentions. It could be useful in avionics or industrial control, where you often avoid memory pools and have arrays of specific kinds of objects instead.

Depends on what kind of lifetimes, yes C++ doesn't do Rust like lifetimes check, at least not without help from static analysis.

However C++23 has introduced compiler aware functions to start specific lifetimes out of raw memory pools.

https://en.cppreference.com/w/cpp/language/lifetime

Post reply on HN