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

161–170 of 247 posts

Re: Zig and Rust

#161

Post by connicpu »

kaba0 wrote: post #117
connicpu wrote: post #72

Earlier quoted context omitted.

There's the third option, which is what Rust and C++ do by default, where types have destructors that are run when the value goes out of scope, but also have mechanisms to be activated manually at a precise moment if you know what you're doing and have specific needs.

This is by definition manual memory management.

I would argue RAII is still a type of automatic memory management, but it has the determinism and ability to reason about what's going on the same way fully manual management does.

Re: Zig and Rust

#162

Post by kristoff_it »

gpderetta wrote: post #145
haberman wrote: post #96

Earlier quoted context omitted.

RAII is not a silver bullet. RAII wants to have neat recursive ownership and cleanup of everything, which is undoubtedly a nice model, but sometimes in low-level code you have to choose between nice recursive ownership and performance. For example, Protocol Buffers are trees of objects. Originally they were simple and had recursively-owned, heap-allocated nodes. But it turns out that traversing and deleting a big gra…

There is no incompatibility between RAII and arenas. RAII doesn't require heap allocation.

That's not really the point. If you're using an arena it means that you plan to reset it at some point and erase in bulk everything that was stored on it all at once. This is the opposite of letting the destructor of every object run.

Re: Zig and Rust

#163

Post by estebank »

throwawaymaths wrote: post #45
lucasyvas wrote: post #15

Earlier quoted context omitted.

Not the parent, but Zig being much easier to use unsafely is not a good thing IMO. Rust tries to pave a path for all types of developers to eventually learn how to write performant code safely in a way that integrates cleanly. This is a much more practical need for the programming community at this time. I have to agree with the parent - I was interested in looking at Zig eventually, but after reading this I am not.…

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?

Re: Zig and Rust

#164

Post by kaba0 »

netbioserror wrote: post #160
kaba0 wrote: post #152

Earlier quoted context omitted.

Rust is the first low-level language that actually solves a fundamental problem of low-level programming. I don’t see why is it surprising that it gains weight. Zig, while I appreciate many of its design goals and definitely has some novel ideas, is “just” a better C.

I think your comment can actually help me clarify what I meant. My perception is that there is a rift between what domains Rust is targeting versus what audience is actually hyped about Rust. When I look to the C++ world and the embedded/realtime systems industry, what I see is lots of discussion about Carbon and herb Sutter's CppFront. I don't see as much Rust discussion. When I look to the JavaScript/webdev/fullsta…

There is definitely a hype among programmers who are familiar only with higher level languages, but I think the actual core audience is the (ex-)C/C++ community. I am definitely not some integral part of the Rust community, so my experience there is limited, but based on discussions in for example their subreddit, it is definitely not made up of beginners who are just learning what a pointer is.

There are beginners, but I see mostly veteran embedded/systems programmers with very good understanding of both low-level systems and the advantages/disadvantages of C++ for example, making up for very technical and interesting comments.

Re: Zig and Rust

#165

Post by za3faran »

_0w8t wrote: post #137
kaba0 wrote: post #116

Earlier quoted context omitted.

> There simply is no silver bullet for memory management, you can either have high performance or automatic memory management That’s only true for workloads where you can optimize the memory layout/allocations. This may not be true in general, where you will end up implementing a shitty GC that will definitely perform worse than a properly written one. Also, the cost of a proper GC is heavily overblown in my opinion.…

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.

What kind of workload does the server run?

Re: Zig and Rust

#166

Post by _0w8t »

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.

The problem with GC is that when it does give problems, there are no good choices. One either spends time trying to tune available knobs to hide the problem or rewrite application to try to reuse objects etc. turning the initial nice architecture into spaghetti mess.

I very much prefer for this reason reference counting. Yes, time can be wasted fighting leaks through cycles, one still have avalanches of releases problems, the performance can be bad with certain usage patterns. But solving these problems is at least local and does not required rewriting the whole application.

Re: Zig and Rust

#167

Post by _0w8t »

za3faran wrote: post #165
_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.

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.

Re: Zig and Rust

#168

Post by connicpu »

kristoff_it wrote: post #162
gpderetta wrote: post #145

Earlier quoted context omitted.

There is no incompatibility between RAII and arenas. RAII doesn't require heap allocation.

That's not really the point. If you're using an arena it means that you plan to reset it at some point and erase in bulk everything that was stored on it all at once. This is the opposite of letting the destructor of every object run.

Not every object in an RAII language needs a destructor, e.g. objects that don't manage their own memory because they came from an arena

Re: Zig and Rust

#169

Post by Yoric »

kaba0 wrote: post #151
Yoric wrote: post #56

Earlier quoted context omitted.

Frankly, my reason for using Rust is not memory semantics (I'd be happy for most applications with a Gc), it's the type system. I could be writing in Haskell for an even more powerful type system, of course, (especially now that Haskell has gained linear types) but the language never took hold outside of academia.

Well, “never took hold” is relatively. It is and will likely always be a niche language, but one with a quite big audience and ecosystem. There are people happily using different languages that are much smaller, they just happen to occupy a less academic niche — e.g. I’m guessing but you probably don’t have such feelings against D, when it might very well be smaller than Haskell.

To clarify, I have actually coded a bit in Haskell and I have actually released open-source code in SML/NJ, a commercial application in OCaml and worked (as a very minor contributor) on industrial code in Coq.

But if I have to start a new industrial project, I will most likely use Rust, because it is easier to hire and because there is lots of momentum in the Rust ecosystem, which means that there are crates for just about everything.

Re: Zig and Rust

#170

Post by lenkite »

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,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."

Compare that with a similar issue in simdjson (written in C++), where people are complaining about parsing 4GB documents into a tree !!! https://github.com/simdjson/simdjson/issues/128. serde-json has trouble moving a bullock-cart while simdjson is moving a container ship.

I don't like some parts of Zig - I think not having RAII in the language is a terrible mistake. But I do love that anything and everything that can be allocated needs to be passed an allocator. I do think they could have introduced an allocation context for RAII cleanups though instead of forcing the programmer to manually coding defer base cleanups - this is a major source of errors even for advanced programmers.

Post reply on HN