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

61–70 of 73 posts

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

#61

Post by white-flame »

janvidar wrote: post #59
white-flame wrote: post #58

His distinction with hidden memory allocations vs perfect software fails even in his C boolean example. Calling a C function takes up stack space. That's a hidden memory allocation which can exhaust just like heap does. But it's even worse because stack allocation failures don't have a place that return a nice clean NULL like malloc does. It's pretty strong to still call this case "perfect software" under his definit…

Right, he answers a question about this. His plan seems to be to pre-calculate the stack space required at compile time using static callgraph analysis. This is not yet implemented.

Yes, but I'm talking about his assertion about that C example earlier in the talk, not about Zig. It's pretty fundamental to his arguments.

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

#62

Post by [deleted] »

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…

[deleted]

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

#63

Post by qop »

steveklabnik wrote: post #44
mschwaig wrote: post #21

Earlier quoted context omitted.

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.

Rust’s standard library types do not give you that control. The language doesn’t know abou allocation, and you can build whatever you want on top of it.

#-#-# for Steve only

"you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance.

I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in.

The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do.

You're influential in the rust microcosm, why not communicate this? Why not build a campaign directly from the utility rust is actually presenting and not the pseudo-philosophical utility that mozilla erroneously assigns to rust? For a team that hacks bits and registers all day, I'm shocked how far rust evangelism has deviated from just the simple truth of the code.

I wanted to share this with you privately, but I couldn't find you on any platform I feel comfortable using, and for some reason the best tech news aggregator in the world still doesn't do privmsg yet, so I hope I can ask you to take the perspective if what I'm trying to communicate here and not the "why you talking so loud?!" perspective.

I see these little rust-isms where a defect or some aspect of rust is manipulated in a way as to empower it rather than illustrate the technical reality of it.

Rust not having the ability to deal with failed allocation is or will be a show stopper for somebody, somewhere, eventually. It should be portrayed as such (or fixed and loudly announced) rather than saying, "oh, build whatever you want on top of that behavior" as if it's some brilliant idea.

Disclaimer: I'm not a rust contributor.

Disdisclaimer: there's love in my heart for rust but the marketing is reaching counterintelligence levels of euphemism and misdirextion and I'm confident that you have the influence and awareness to begin to fix this in the rustverse

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

#64

Post by dbaupp »

qop wrote: post #63
steveklabnik wrote: post #44

Earlier quoted context omitted.

Rust’s standard library types do not give you that control. The language doesn’t know abou allocation, and you can build whatever you want on top of it.

#-#-# for Steve only "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. The hubris of the rust team empowers…

> "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance.

It most definitely is not. "It" in "on top of it" refers to the language itself and the "core" subset of "std", which designed to cater for situations without any OS-level allocation at all, not the "std"s library's handling of OOM.

Given that Rust can work without allocation, it can work with custom allocation-failure handling too: as a minimal proof, start with core only (no std) and create custom Box and Vec types (this probably isn't the best path, but it shows it is possible).

> I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in.

> The hubris of the rust team empowers projects like zig, which are clearly communicating what their offering can and cannot do.

The Rust team is good at clearly communicating the boundaries of Rust. Others may misinterpret that/be over-enthusiastic, but they're often called out (even by members of the Rust team) when it is noticed.

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

#65

Post by espeed »

Yoric wrote: post #27
espeed wrote: post #24

Earlier quoted context omitted.

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

> i.e. adding this check (as a warning) to rustc doesn't look too hard and wouldn't break existing code.

One point of distinction: Zig does not have compile-time warnings, only errors. Simplicity by design. Either it will complie or it won't. Removing the uncertainty here means less greyarea, no space for edgecases in between.

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

#66

Post by qop »

Yoric wrote: post #39
Yoric wrote: post #36

Earlier quoted context omitted.

I was referring to espeed's "Zig is similar to Rust, but with memory safety designed into the core, not bolted on as an afterthought", which he later explained with two examples, one of which actually justifies the words "bolted on as an afterthought", but refers to local handling of fallible allocation. While local handling of fallible allocation is a desirable feature for many applications, I confirm that neither m…

> I agree that that aspect isn't relevant to what I would call memory safe. But how do you get from "espeed claimed something unreasonable" to "Rust looks more memory-safe than Zig"? Well, there are several reasons. For instance: - Rust tries very hard to prevent accidental mutations through aliases. In all the common cases and most of the uncommon ones, it works quite well. - Rust ensures that your memory can't be d…

I hate to say it, but this might be an instance where more jargon might help.

"Memory safe" can have numerous implications because there are numerous methods for attacking memory of a program. As far as we know, there's no language that handles EVERYTHING, so maybe we need to start qualifying what these languages mean. Rust landing page does this well, "no race conditions, move semantics" but then rust users will parrot "it's memory safe, it's memory safe" and they can't explain how to deal with failed allocations in rust. Not that that's necessarily a big deal, but it's just bad terminology for what is a rather complex issue.

It's almost like saying a language is "type safe". While reassuring, wtf does that actually mean? What kind of types? Is there polymorphism? Is there row types? Is there substructural typing? Type theorists generally have lots of terms to specify what flavor of types they're talking about, and that works well for them.

Rust is kind of bringing a new generation of younger hackers to systems programming and you darned kids need to get off the grass and start being more specific about memory semantics in PLT! /s but kinda serious

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

#67

Post by steveklabnik »

dbaupp wrote: post #64
qop wrote: post #63

Earlier quoted context omitted.

#-#-# for Steve only "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. I suspect rust adoption would be much more effective if it wasn't presented as a panacea-like solution (it isnt) that the entirety of computer science has always dreamed of (it hasn't) and is ready to be used to write literally everything on earth in. The hubris of the rust team empowers…

> "you can build whatever want on top of it" is a flashy way to say that "rust can't do that" in this instance. It most definitely is not. "It" in "on top of it" refers to the language itself and the "core" subset of "std", which designed to cater for situations without any OS-level allocation at all, not the "std"s library's handling of OOM. Given that Rust can work without allocation, it can work with custom alloca…

Yes, thank you. To your parent, I know you said this was for me only, but this is what I’d say.

Well, with one more addition; you can see me doing exactly what you say in this very thread: https://news.ycombinator.com/item?id=17187648

I quite often tell people that Rust is not a panacea, or to not use it if it doesn’t fit their use-case: https://www.reddit.com/r/cpp/comments/8mp7in/comment/dzr3eot

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

#68

Post by Yoric »

janvidar wrote: post #59
white-flame wrote: post #58

His distinction with hidden memory allocations vs perfect software fails even in his C boolean example. Calling a C function takes up stack space. That's a hidden memory allocation which can exhaust just like heap does. But it's even worse because stack allocation failures don't have a place that return a nice clean NULL like malloc does. It's pretty strong to still call this case "perfect software" under his definit…

Right, he answers a question about this. His plan seems to be to pre-calculate the stack space required at compile time using static callgraph analysis. This is not yet implemented.

How would that work with: 1/ recursion; 2/ calling C code; 3/ being called from C?

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

#69

Post by Yoric »

espeed wrote: post #65
Yoric wrote: post #27

Earlier quoted context omitted.

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

> i.e. adding this check (as a warning) to rustc doesn't look too hard and wouldn't break existing code. One point of distinction: Zig does not have compile-time warnings, only errors. Simplicity by design. Either it will complie or it won't. Removing the uncertainty here means less greyarea, no space for edgecases in between.

I realize that this should be an error rather than a warning. But one of the policies of Rust since 1.0 is to not break existing code, so any mechanism that detects error that were not previously detected must make it a warning, rather than an error, otherwise some existing applications and libraries would stop compiling overnight.

I generally find this a sane policy, but YMMV.

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

#70

Post by espeed »

Yoric wrote: post #69
espeed wrote: post #65

Earlier quoted context omitted.

> i.e. adding this check (as a warning) to rustc doesn't look too hard and wouldn't break existing code. One point of distinction: Zig does not have compile-time warnings, only errors. Simplicity by design. Either it will complie or it won't. Removing the uncertainty here means less greyarea, no space for edgecases in between.

I realize that this should be an error rather than a warning. But one of the policies of Rust since 1.0 is to not break existing code, so any mechanism that detects error that were not previously detected must make it a warning, rather than an error, otherwise some existing applications and libraries would stop compiling overnight. I generally find this a sane policy, but YMMV.

OT FYI: I just looked at your profile and noticed we have something in common. Your HND matches my DOB ~> 224
Post reply on HN