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

181–190 of 247 posts

Re: Zig and Rust

#181

Post by kaba0 »

childintime wrote: post #67

Zig appeals to the “lone genius hackers”. I'd read this as the folks that like to know all the code in their code base, as is typical for embedded or moderate size projects. Folks that do not need (and resent) the abstractions made for every use case under the sun, which to them only ends up making the code harder to read and to comprehend. Though Rust does an admirable job, and things are much better than for OOP la…

> Chatgpt will then handily convert the project [..] to Rust

That’s more or less impossible if you mean idiomatic Rust without chock-full of unsafe blocks. Besides the (probably ironic?) overhype of ChatGPT, Rust’s lifetime-memory patterns are a strict subset of what is expressible with correct Zig/C.

Re: Zig and Rust

#182

Post by kaba0 »

anonyfox wrote: post #39

May someone chime in between that and make a quick 3-way comparison with Golang? I already know Rust and shipped nontrivial stuff, but I need something simpler that average developers can pickup quickly to produce performant+parallel code and be able to crosscompile+ship a single binary. (The last point already ruled out Crystal which has a poor crosscompilation story as well as insanely long compile times for nontri…

Go is absolutely nothing like Rust, Zig, C; it is arguably closer to JS than those. I really dislike how it is camouflaged as a low-level language.

Re: Zig and Rust

#183

Post by skribanto »

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…

try = ? in rust. catch = match in rust. Zig does have its own general match statement, and the reason it needs a catch is because errors in Zig aren't actually ADT's, but it's not that much more complex.

And you're really going to argue that defer,errdefer is more complex than RAII?

Re: Zig and Rust

#184

Post by Ygg2 »

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 don't think serde-json has a limit on size. But under some usages it will allocate extra. For example see: https://github.com/serde-rs/json/issues/160#issuecomment-841... 2.4 GB file can be read and parsed with serde.

Re: Zig and Rust

#185

Post by Patrickmi »

_0w8t wrote: post #167
za3faran wrote: post #165

Earlier quoted context omitted.

What kind of workload does the server run?

It serves as a proxy or manager for other components. It is IO bound. As such Go should be an ideal language for it. But GC kicking in a wrong moment still brings troubles.

So Go GC just need a api that pauses GC when it wants to run

Re: Zig and Rust

#186

Post by Patrickmi »

kaba0 wrote: post #155
_0w8t wrote: post #137

Earlier quoted context omitted.

GC is not a solved problem and can be costly. We clearly see in a production server written in Go spikes in latency and memory usage. So most likely for the next server-type application we will use Rust. Then there are benchmarks where Nginx is faster than Caddy by factor of 3.

Go doesn’t really have a good GC for what it’s worth. And of course there will always be domains where the tradeoffs of a GC doesn’t worth it, but those are very very rare.

[dead]

Re: Zig and Rust

#187

Post by herbstein »

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…

> Comment from that issue: "For example, ElasticSearch returns a 8,683KB document, I deser it into Value and the next RAM reading gives me delta of 98,484KB of RAM use. That's more than 10x the original size."

I think this is misleading. `serde_json` is designed to parse JSON documents directly into your user-defined structs. Thus the raw `Value` type isn't optimized for direct manipulation.

That said, what do you expect? The `Value` enum has the `Value::Array` variant that contains a `Vec`, which is 24 bytes in itself. One for the heap pointer, one for the length, and one for the capacity. Because of alignment requirements the enum discriminant must thus also be aligned at the 8-byte boundary. This gives us a 32-byte type.

It is possible to reduce the variant to 16 bytes by making the value type `Box` instead. Ignoring the `Value::Object` variant for a second, that would make `Value` a 24-byte type. However, you've now also made the type immutable. It's a tradeoff. 8 bytes for mutable values.

Again, do remember that deserializing into `Value`s is _not_ the primary path when working with JSON through `serde_json`.

Re: Zig and Rust

#188

Post by lenkite »

herbstein wrote: post #187
lenkite wrote: post #170

Earlier quoted context omitted.

"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…

> Comment from that issue: "For example, ElasticSearch returns a 8,683KB document, I deser it into Value and the next RAM reading gives me delta of 98,484KB of RAM use. That's more than 10x the original size." I think this is misleading. `serde_json` is designed to parse JSON documents directly into your user-defined structs. Thus the raw `Value` type isn't optimized for direct manipulation. That said, what do you ex…

Yes, I fully understand how enum variants are implemented under the hood. My point was in response to the enthusiastic use of enum variants which generally causes excessive memory to be consumed for even moderate inputs. Folks are surprised by this and then re-write their code to avoid enum variants or use pointer tagging.

Enum variants should come with a STRICT warning in the Rust book and Rust reference that their real-world use should be incorporated very carefully. Most proponents of Rust tend to never mention their costs or caveats. They are most certainly NOT a zero-cost abstraction and tend to trip up lots of programmers.

"Thus the raw `Value` type isn't optimized for direct manipulation."

Maybe this statement this should be explicitly mentioned in the documentation: DO NOT USE `serde_json::value::Value` for moderate or large sized JSON inputs in production! Stack overflow answers merrily recommend the use of `Value` to a get a piece of data out.

Re: Zig and Rust

#189

Post by [deleted] »

Ygg2 wrote: post #184
lenkite wrote: post #170

Earlier quoted context omitted.

"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 don't think serde-json has a limit on size. But under some usages it will allocate extra. For example see: https://github.com/serde-rs/json/issues/160#issuecomment-841... 2.4 GB file can be read and parsed with serde.

[deleted]

Re: Zig and Rust

#190

Post by shakow »

netbioserror wrote: post #98
klyrs wrote: post #69

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…

That's a very limited perspective.

I have worked in HPC, Cryptography and Genetics, and Rust is sailing full speed in all these domains -- which are as remote as may be from WebDev & Mozilla.

Post reply on HN