←back to thread

Things Zig comptime won't do

(matklad.github.io)
458 points JadedBlueEyes | 3 comments | | HN request time: 0.679s | source
Show context
no_wizard ◴[] No.43744932[source]
I like the Zig language and tooling. I do wish there was a safety mode that give the same guarantees as Rust, but it’s a huge step above C/C++. I am also extremely impressed with the Zig compiler.

Perhaps the safety is the tradeoff with the comparative ease of using the language compared to Rust, but I’d love the best of both worlds if it were possible

replies(5): >>43744960 #>>43745201 #>>43745418 #>>43745573 #>>43749228 #
ksec ◴[] No.43745418[source]
>but I’d love the best of both worlds if it were possible

I am just going to quote what pcwalton said the other day that perhaps answer your question.

>> I’d be much more excited about that promise [memory safety in Rust] if the compiler provided that safety, rather than asking the programmer to do an extraordinary amount of extra work to conform to syntactically enforced safety rules. Put the complexity in the compiler, dudes.

> That exists; it's called garbage collection.

>If you don't want the performance characteristics of garbage collection, something has to give. Either you sacrifice memory safety or you accept a more restrictive paradigm than GC'd languages give you. For some reason, programming language enthusiasts think that if you think really hard, every issue has some solution out there without any drawbacks at all just waiting to be found. But in fact, creating a system that has zero runtime overhead and unlimited aliasing with a mutable heap is as impossible as finding two even numbers whose sum is odd.

[1] https://news.ycombinator.com/item?id=43726315

replies(4): >>43745462 #>>43745760 #>>43745791 #>>43746930 #
the__alchemist ◴[] No.43745760[source]
Maybe this is a bad place to ask, but: Those experienced in manual-memory langs: What in particular do you find cumbersome about the borrow system? I've hit some annoyances like when splitting up struct fields into params where more than one is mutable, but that's the only friction point that comes to mind.

I ask because I am obvious blind to other cases - that's what I'm curious about! I generally find the &s to be a net help even without mem safety ... They make it easier to reason about structure, and when things mutate.

replies(4): >>43745891 #>>43745963 #>>43746263 #>>43747347 #
rc00 ◴[] No.43745891[source]
> What in particular do you find cumbersome about the borrow system?

The refusal to accept code that the developer knows is correct, simply because it does not fit how the borrow checker wants to see it implemented. That kind of heavy-handed and opinionated supervision is overhead to productivity. (In recent times, others have taken to saying that Rust is less "fun.")

When the purpose of writing code is to solve a problem and not engage in some pedantic or academic exercise, there are much better tools for the job. There are also times when memory safety is not a paramount concern. That makes the overhead of Rust not only unnecessary but also unwelcome.

replies(3): >>43745915 #>>43746004 #>>43747477 #
Ygg2 ◴[] No.43746004[source]
> The refusal to accept code that the developer knows is correct,

How do you know it is correct? Did you prove it with pre-condition, invariants and post-condition? Or did you assume based on prior experience.

replies(3): >>43746128 #>>43746298 #>>43749589 #
yohannesk ◴[] No.43746128[source]
Writing correct code did not start after the introduction of the rust programming language
replies(1): >>43746376 #
1. Ygg2 ◴[] No.43746376[source]
Nope, but claims of knowing to write correct code (especially C code) without borrow checker sure did spike with its introduction. Hence, my question.

How do you know you haven't been writing unsafe code for years, when C unsafe guidelines have like 200 entries[1].

[1]https://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definit... (Annex J.2 page 490)

replies(1): >>43746850 #
2. int_19h ◴[] No.43746850[source]
It's not difficult to write a provably correct implementation of doubly linked list in C, but it is very painful to do in Rust because the borrow checker really hates this kind of mutually referential objects.
replies(1): >>43749579 #
3. Ygg2 ◴[] No.43749579[source]
Hard part of writing actually provable code isn't the code. It's the proof. What are invariants of double linked list that guarantee safety?

Writing provable anything is hard because it forces you to think carefully about that. You can no longer reason by going into flow mode, letting fast and incorrect part of the brain take over.