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

Zig: programming language designed for robustness optimality and clarity [video]

youtube.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: Zig: programming language designed for robustness optimality and clarity [video]

#21

Post by mschwaig »

Yoric wrote: post #20
espeed wrote: post #3

Earlier quoted context omitted.

> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org [2] https://github.com/ziglang/zig

I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?

Rust has lifetimes and ownership as language concepts so that you have to be explicit about who owns a resource, for example memory, but it does not give you a lot of control about what to do when an allocation fails.

Zig is designed so that you can still peogrammatically deal with a failing allocation, as does well-written C, but it does not have a ownership system like Rust.

Re: Zig: programming language designed for robustness optimality and clarity [video]

#22

Post by whyever »

Yoric wrote: post #19
MaxBarraclough wrote: post #16

Earlier quoted context omitted.

Do nullable types and maybe types add much over checked dereferences (a la Java)? I imagine they might be good for performance (fewer checks), but does it really help with correctness/convenience/elegance/readability/etc?

In my experience from Rust & co, yep, this improves correctness a lot. Elegance, not so much.

I think some of the combinators can be elegant. E.g. `Option::map`.

Re: Zig: programming language designed for robustness optimality and clarity [video]

#23

Post by tiehuis »

Yoric wrote: post #18

I have read quickly through the tutorial, and this looks interesting. Objectives are similar to Rust, with a few twists. A few differences that I can see: - At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. - Zig's `comptime` is quite intriguing. In particular, types are (compile-time) values and can be introspecte…

To elaborate on a few of your remarks/questions.

> At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C.

A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here.

> I don't see traits in Zig.

Nothing of the sort just yet although it is an open question [1]. Currently std uses function pointers a lot for interface-like code, and relies on some minimal boilerplate to be done by the implementor.

See the interface for a memory allocator here [2]. An implementation of an allocator is given here [3] and needs to get the parent pointer (field) in order to provide the implementation.

It isn't too bad once you are familiar with the pattern, but it's also not ideal, and I would like to see this improved.

> I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig.

You would use a memory allocator as mentioned above and use the `create` and `destroy` functions for a single item, or `alloc` and `free` for an array of items. Memory allocation/deallocation doesn't exist at the language level.

> I don't see anything on concurrency in Zig's documentation.

There are coroutines built in to the language [4]. This is fairly recent and there isn't much documentation just yet unfortunately. Preliminary thread support is in the stdlib. I know Andrew wants to write an async web-server example set up multiplexing coroutines onto a thread-pool, as an example.

> Zig supports varargs, Rust doesn't (yet).

It's likely that varargs are instead replaced with tuples as a comptime tuple (length-variable) conveys the same information. I believe this fixes a few other quirks around varargs (such as using not being able to use varargs functions at comptime).

[1] https://github.com/ziglang/zig/issues/130

[2] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842...

[3] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842...

[4] https://github.com/ziglang/zig/blob/15302e84a45a04cfe94a8842...

Re: Zig: programming language designed for robustness optimality and clarity [video]

#24

Post by espeed »

Yoric wrote: post #20
espeed wrote: post #3

Earlier quoted context omitted.

> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org [2] https://github.com/ziglang/zig

I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?

There was a HN discussion ~4 months ago that touched on some of this:

"Unsafe Zig Is Safer Than Unsafe Rust" https://news.ycombinator.com/item?id=16226235

Also see this previous thread on Rust's stdlib OutOfMemory errors:

"Containers should provide some way to not panic on failed allocations" https://github.com/rust-lang/rust/issues/29802

Re: Zig: programming language designed for robustness optimality and clarity [video]

#25

Post by espeed »

tom_mellior wrote: post #17
espeed wrote: post #3

Earlier quoted context omitted.

> I wonder if zig will ever pursue some sort of memory safety. That's exactly what Zig is designed for [1]. Andrew Kelley (andrewrk) discusses this in the talk. Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought. And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. [1] http://ziglang.org [2] https://github.com/ziglang/zig

> And as the SHA-256 demo tests in the talk show, Zig is as fast or faster than C. Do you know at what timestamp (roughly) this is mentioned in the video? YouTube makes it hard to quickly skip around in the video to find this. Or, better, a link to a written source? I'd be interested in what exactly is being compared. It's easy to cheat on benchmarks, especially when you aren't doing it on purpose.

Right at about the 20m mark: https://youtu.be/Z4oYSByyRak?t=20m2s

Re: Zig: programming language designed for robustness optimality and clarity [video]

#26

Post by Yoric »

tiehuis wrote: post #23
Yoric wrote: post #18

I have read quickly through the tutorial, and this looks interesting. Objectives are similar to Rust, with a few twists. A few differences that I can see: - At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. - Zig's `comptime` is quite intriguing. In particular, types are (compile-time) values and can be introspecte…

To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to acces…

> A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here.

But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` being safer: you can use it safely in Zig, but you have to actually request safety, because that's not the default behavior.

I probably should have phrased it differently, though.

And the "more powerful" is about the fact that a Rust enum can actually carry data, while it doesn't seem to be the case with Zig.

>> I don't see smart pointers in Zig, and more generally, I have no idea how to deallocate memory in Zig. > >You would use a memory allocator as mentioned above and use the `create` and `destroy` functions for a single item, or `alloc` and `free` for an array of items. Memory allocation/deallocation doesn't exist at the language level.

So, it sounds like deallocations are not checked by default, right?

> I know Andrew wants to write an async web-server example set up multiplexing coroutines onto a thread-pool, as an example.

That would be a nice example, for sure!

Re: Zig: programming language designed for robustness optimality and clarity [video]

#27

Post by Yoric »

espeed wrote: post #24
Yoric wrote: post #20

Earlier quoted context omitted.

I may be wrong, but if I read the documentation correctly, Rust looks more memory-safe than Zig. What am I missing?

There was a HN discussion ~4 months ago that touched on some of this: "Unsafe Zig Is Safer Than Unsafe Rust" https://news.ycombinator.com/item?id=16226235 Also see this previous thread on Rust's stdlib OutOfMemory errors: "Containers should provide some way to not panic on failed allocations" https://github.com/rust-lang/rust/issues/29802

> "Unsafe Zig Is Safer Than Unsafe Rust"

Yes, I've seen that blog post. Definitely a useful analysis, but it doesn't strike me as a fundamental difference, i.e. adding this check (as a warning) to rustc doesn't look too hard and wouldn't break existing code.

Also, as pointed out in the title, that's code explicitly marked as `unsafe` in Rust, so it might not be an entirely fair comparison :)

> "Containers should provide some way to not panic on failed allocations" https://github.com/rust-lang/rust/issues/29802

Definitely a problem, but it's not what people usually call "memory safety". The problem you mention is that of "fallible allocation". A typical definition of "memory safety" is that you can never get a memory access error.

Rust's behavior is indeed to panic in case of failed allocation, letting the developers catch the error at higher level. Barring any bug in rustc, that behavior is memory-safe.

Now, this behavior is quite opinionated and it turns out that it doesn't match all applications, so handling failed allocations is indeed being "bolted on as an afterthought". Just not memory safety :)

(especially since it's pretty hard to get a memory access error in Rust without deactivating safety checks, and it doesn't seem to be nearly as difficult in the current version of Zig)

Re: Zig: programming language designed for robustness optimality and clarity [video]

#28

Post by tiehuis »

Yoric wrote: post #26
tiehuis wrote: post #23

Earlier quoted context omitted.

To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to acces…

> A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here. But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` bein…

> But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` being safer: you can use it safely in Zig, but you have to actually request safety, because that's not the default behavior.

Sure. I think that's more an effect of the choice of keyword defaults here. A straight union is very uncommon and is typically solely for C interoperability.

> And the "more powerful" is about the fact that a Rust enum can actually carry data, while it doesn't seem to be the case with Zig.

A tagged union can store data as in Rust. See the examples in the documentation [1]. Admittedly Rust's pattern matching is nicer to work with here.

To summarise the concepts:

- `enum` is a straight enumeration with no payload. The backing tag type can be specified (e.g. enum(u2)).

- `union` is an unchecked sum type, similar to a c union without a tag field.

- `union(TagType)` is a sum type with a tag field, analagous to a Rust enum . A `union(enum)` is simply shorthand to infer the underlying TagType.

> So, it sounds like deallocations are not checked by default, right?

If referring to if objects are guaranteed to be deallocated when out of scope then no, this isn't checked. There are a few active issues regarding some improvements to resource management but it probably won't result in any automatic RAII-like functionality. This is a manual step using defer right now.

[1] https://ziglang.org/documentation/master/#union

Re: Zig: programming language designed for robustness optimality and clarity [video]

#29

Post by [deleted] »

Yoric wrote: post #26
tiehuis wrote: post #23

Earlier quoted context omitted.

To elaborate on a few of your remarks/questions. > At first glance, Rust's `enum` looks safer and more powerful than Zig's `union` + `enum`, while Zig's `union` + `enum` appears more interoperable with C. A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to acces…

> A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here. But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` bein…

[deleted]

Re: Zig: programming language designed for robustness optimality and clarity [video]

#30

Post by Yoric »

tiehuis wrote: post #28
Yoric wrote: post #26

Earlier quoted context omitted.

> A `union(TagType)` in Zig is a tagged union and has safety checks on all accesses in debug mode. It is directly comparable to a Rust enum. Any differences are probably more down to the ways you are expected to access them and Rust's stronger pattern matching probably helps some here. But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` bein…

> But if I understand correctly, out-of-the-box, Zig's `union` doesn't get a tag type, right? That's what I meant by Rust's `enum` being safer: you can use it safely in Zig, but you have to actually request safety, because that's not the default behavior. Sure. I think that's more an effect of the choice of keyword defaults here. A straight union is very uncommon and is typically solely for C interoperability. > And…

> Sure. I think that's more an effect of the choice of keyword defaults here. A straight union is very uncommon and is typically solely for C interoperability.

Fair enough. That's why Rust also has a `union` keyword, which is always `unsafe`.

> A tagged union can store data as in Rust. See the examples in the documentation [1]. Admittedly Rust's pattern matching is nicer to work with here.

Ah, right, it could be any struct instead of being a bool or integer. I missed that.

> If referring to if objects are guaranteed to be deallocated when out of scope then no, this isn't checked.

I was wondering about that and double-deallocations.

> There are a few active issues regarding some improvements to resource management but it probably won't result in any automatic RAII-like functionality.

Out of curiosity, what kind of improvements?

Post reply on HN