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

Zig; what I think after months of using it

strongly-typed-thoughts.net

Post reply on HN
Print view View original

171–180 of 181 posts

Re: Zig; what I think after months of using it

#171

Post by dolmen »

chrisco255 wrote: post #48
bobbylarrybobby wrote: post #36

Earlier quoted context omitted.

If you must write unsafe code, what's wrong with just dropping down to unsafe in Rust when you need to? You have all the power unsafe provides, and you have a smaller surface area to audit than if your entire codebase resides in one big unsafe block.

Unsafe Rust is problematic: https://zackoverflow.dev/writing/unsafe-rust-vs-zig See also: https://github.com/roc-lang/roc/blob/main/www/content/faq.md... Zig is not entirely unsafe. It provides quite a few compile time checks and primitives to catch memory leaks or prevent them altogether.

In related news, someone just published a PoC borrow checker for Zig:

https://news.ycombinator.com/item?id=42923829

Re: Zig; what I think after months of using it

#172

Post by throwawaymaths »

zamalek wrote: post #157
throwawaymaths wrote: post #145

Earlier quoted context omitted.

wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.

The original argument is that clr proves Zig is as safe as Rust, per your wording " all the memory safety parts." Does the incompletely POC do all the parts, or doesn't it? That is no criticism against the project itself, striving to improve memory safety in any language is an honorable goal. The cinch is that an incomplete POC doesn't prove things one way or another, the POC needs to be completed (or at least comple…

I guess the question is what level of satisfied are you.

Are you satisfied like "proof is left as an exercise for the reader" in a math textbook? Or is it like "I have proved this but it's too large to fit in the margins"?

It seems author couldn't be bothered to complete it since there's (minor) missing features in the zig compiler that need to be satisfied first to make it worthwhile?

Re: Zig; what I think after months of using it

#173

Post by [deleted] »

Ygg2 wrote: post #161
throwawaymaths wrote: post #145

Earlier quoted context omitted.

wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.

Nothing, it's the principle of the thing. I.e. when you make a challenging to evaluate statement, the burden of proof is on the one making the claim. If I say "Moon is made of millennia old cheese", the burden of proof isn't on you to go create a rocket, fly to the moon, sample it and come with conclusions, but on me, making a difficult to verify statement.

[deleted]

Re: Zig; what I think after months of using it

#174

Post by throwawaymaths »

Ygg2 wrote: post #161
throwawaymaths wrote: post #145

Earlier quoted context omitted.

wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.

Nothing, it's the principle of the thing. I.e. when you make a challenging to evaluate statement, the burden of proof is on the one making the claim. If I say "Moon is made of millennia old cheese", the burden of proof isn't on you to go create a rocket, fly to the moon, sample it and come with conclusions, but on me, making a difficult to verify statement.

the author has put a lot of unpaid I'm guessing work into this repo -- seems reasonable for the author to demand a bit of work out of any asshole taking a potshot at it.

Re: Zig; what I think after months of using it

#175

Post by zamalek »

throwawaymaths wrote: post #172
zamalek wrote: post #157

Earlier quoted context omitted.

The original argument is that clr proves Zig is as safe as Rust, per your wording " all the memory safety parts." Does the incompletely POC do all the parts, or doesn't it? That is no criticism against the project itself, striving to improve memory safety in any language is an honorable goal. The cinch is that an incomplete POC doesn't prove things one way or another, the POC needs to be completed (or at least comple…

I guess the question is what level of satisfied are you. Are you satisfied like "proof is left as an exercise for the reader" in a math textbook? Or is it like "I have proved this but it's too large to fit in the margins"? It seems author couldn't be bothered to complete it since there's (minor) missing features in the zig compiler that need to be satisfied first to make it worthwhile?

> Are you satisfied like "proof is left as an exercise for the reader" in a math textbook? Or is it like "I have proved this but it's too large to fit in the margins"?

In the first example the proof would be available elsewhere. In the second example, no. My answer is "just the facts as they exist today."

A mathematical proof holds no inherent utility. The thing it proves is what is useful. What I find useful is not suffering memory safety woes. Can I run a tool, any tool, today that will give me the same assurances that the Rust compiler (and/or Miri) does? Conjecture about the future is pointless because someone could equally go and write some static analysis tool like clr for Rust to fix all the bad parts, or fix the compiler, or the parts of clr that aren't finished might be impossible (we don't know, nobody has tried), or the heat death of the universe could come early. All still irrelevant, because I'm a user and I care exclusively about what I can currently do.

Re: Zig; what I think after months of using it

#176

Post by zozbot234 »

kprotty wrote: post #170
zozbot234 wrote: post #116

Earlier quoted context omitted.

> Rust uses references all over the place This is mostly a concern with the Rust stdlib, though. And it's in principle fixable, by writing new varieties of those stdlib functions that take raw-pointer or &UnsafeCell arguments, and delegating the "safe" varieties to those.

There's compiler-level traits like `Iterator` and `Future` which enforce references. If wanting to do intrusive pointers into them, one risks creating overlapping references: https://github.com/tokio-rs/tokio/issues/3399

References to UnsafeCell should still be safe, because the only thing you can do with an &UnsafeCell is extract a possibly-mutating raw pointer to T. (UnsafeCell is also special in that, like Cell, you can mutate through it without incurring UB.)

Re: Zig; what I think after months of using it

#177

Post by Turskarama »

adgjlsfhk1 wrote: post #78
Turskarama wrote: post #31

Earlier quoted context omitted.

I honestly don't see how anyone who has used a language with both unions and interfaces could come up with anything else that makes dynamic types better. Either way you need to fulfill the contract, but I'd much prefer to find out I failed to do that at compile time.

the place where imo static languages come up short is first class functions.

What are you talking about, the majority of functional languages have static types.

Re: Zig; what I think after months of using it

#178

Post by Validark »

edflsafoiewq wrote: post #47
ethin wrote: post #12

No idea how much the author is experienced at Zig, but my thoughts: > No typeclasses / traits This is purposeful. Zig is not trying to be some OOP/Haskell replacement. C doesn't have traits/typeclasses either. Zig prefers explicitness over implicit hacks, and typeclasses/traits are, internally, virtual classes with a vtable pointer. Zig just exposes this to you. > No encapsulation This appears to be more a documentat…

> Zig does have destructors, in a way. It's called defer and errordefer. defer ties some code to a static scope. Destructors are tied to object lifetime, which can be dynamic. For example, if you want to remove some elements from an ArrayList of, say, strings, the string's would need to be freed first. defer does not help you, but destructors would.

That's actually a great argument in favor of Zig over Rust. I assume Rust automatically writes code equivalent to this for you:

``` defer { for (list.items) |str| gpa.free(str); list.deinit(gpa); } ```

When it's spelled out like this, it becomes obvious to the reader that maybe this is the wrong allocation strategy. Maybe the whole thing should go in an Arena. Or, similarly, maybe there should be an ArrayList that holds all the character data that your string ArrayList indexes into with a u32 (or points to with pointers, if you want to update all the pointers on resize). Regardless, I'd be skeptical of code where each string has a separate lifetime even though all the lifetimes could be tied.

Rust makes classic (bad) allocation strategies automatic. Zig makes good allocation strategies more attractive than classic (bad) allocation strategies.

More succinctly: Rust makes bad code safe, Zig makes good code easy.

Re: Zig; what I think after months of using it

#179

Post by baranul »

toprerules wrote: post #61
scubbo wrote: post #10

Great write-up, thank you! I used Zig for (most of) Advent Of Code last year, and while I did get up-to-speed on it faster than I did with Rust the previous year, I think that was just Second (low-level) Language syndrome. Having experienced it, I'm glad that I did (learning how cumbersome memory management is makes me glad that every other language I've used abstracts it away!), but if I had to pick a single low-lev…

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…

Many, after doing a review of Rust, say they don't like or will stop using it. It's very premature to declare it has "won", whatever that can be said to mean. Example, ThePrimeTime[1] (famous YouTube programmer) is another stating he does not like Rust anymore, and rather use some other language.

It appears part of the controversy surrounding Rust, is that many are of the opinion that it's not worth it because of the limited use case, poor readability, complexity, long compile times, etc... and that appears to be what certain advocates of Rust are not understanding or appreciating the difference in opinions. Rust is fine for them, specifically, but not for everyone.

[1]: https://www.youtube.com/watch?v=1Di8X2vRNRE

Re: Zig; what I think after months of using it

#180

Post by baranul »

chrisco255 wrote: post #32
zamalek wrote: post #17

Earlier quoted context omitted.

This is absolutely not what the article is about. A good majority of it is spent on the myth that Zig is safer than Rust, which has nothing to do with wishing Zig was more like Rust.

Is there a myth that makes that claim? Virtually every take I've heard is that Zig is "safe enough" while giving developers more control over memory and actually, it's specifically better for cases where you must write unsafe code, as it's not possible to express all programs in safe Rust.

Various modern alternative languages can claim to be "safe enough" or safer than C, along with C interop. Nim, Dlang... In fact, the V programming language (Vlang) can make the argument of being even safer, because it has more default safety features and an optional GC (that no libraries depend on) for greater memory safety. That and it being designed to be easier to use and learn, for general-purpose programming.

The article, in its review of the Zig language, goes after its marketing history and broken promises (calling Andrew's statements fallacious and worse) for attempting to portray itself as safer than unsafe Rust, the distortions around UB (undefined behavior), etc... As a consequence of the demonstrably valid test results and being tired of unreliability, the author stopped using Zig. It should also be mentioned, that v1 Zig is nowhere in sight, so likely many years more to wait.

Post reply on HN