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

Zig: A new direction for low-level programming?

bitshifters.cc

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Zig: A new direction for low-level programming?

#71

Post by bonzini »

stephc_int13 wrote: post #61
cadu2 wrote: post #45

Earlier quoted context omitted.

Can you comment you some of these decisions in Rust that you feel are bad? I enjoy the language and have done quite a bit of work with it so I might be blinded/biased. I feel some warts here and there (async fns, anyone?), but overall the thing works and `cargo` is really a blessing.

Horrendous compilation time. Unnecessary complexity everywhere, basically C++ but worse.

There's a lot less complexity in Rust than C++. Compilation times are mostly due to lack of compiled code reuse, which is bad but not unsolvable.

Re: Zig: A new direction for low-level programming?

#72

Post by Icathian »

techjamie wrote: post #69
lvass wrote: post #41

Earlier quoted context omitted.

Seatbelt laws are still wrong, government has no business protecting me from myself. But even from an utilitarian perspective, compilers do have warnings and they could just have used that.

Keeping with the analogy, yes, you should always wear your seatbelt on public roads (release), but that doesn't mean I feel like I need to buckle up just to move my car while staying in my own driveway (debug).

That's reasonable. I think major restrictions that cause you to need to refactor your code when going from debug to release are a footgun and a half, but that'd at least be defensible.

Re: Zig: A new direction for low-level programming?

#73

Post by dullcrisp »

cornstalks wrote: post #52
lvass wrote: post #41

Earlier quoted context omitted.

Seatbelt laws are still wrong, government has no business protecting me from myself. But even from an utilitarian perspective, compilers do have warnings and they could just have used that.

> Seatbelt laws are still wrong, government has no business protecting me from myself. If there are multiple people in a car and some choose to wear seatbelts and some choose not to, those who are not wearing seatbelts become a danger to everyone else as their bodies become in-vehicle projectiles. Sure, I can understand the debate when it's just a single person in a car. But when a person's decision starts impacting…

Even if it’s just you, you’d be leaving your mangled corpse on a public road for other people to deal with, which is a nuisance.

Like take the car crash out of the equation and imagine some cars came with an ejector switch that launches you through the windshield at 70 mph. This would not be allowed.

Re: Zig: A new direction for low-level programming?

#74

Post by bonzini »

cranberryturkey wrote: post #65
gliptic wrote: post #13

Earlier quoted context omitted.

> Dynamic Typing: Flexible type system with runtime type checking Uhm, what does this have to do with C/Zig?

its another alternative to C

It doesn't even distinguish integer and floating point?

Re: Zig: A new direction for low-level programming?

#75

Post by kristoff_it »

dmit wrote: post #70
jmull wrote: post #64

The author hand waves away ReleaseSafe, but does not really seem to understand its usage. I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Since zig allows turning off/on safety checks on a per-block basis, you only need to pay as much of a performance cost as you want for this. Actually, this doesn't really come across as a sincere critique of…

> I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Which profile is the default for the Zig compiler itself? What about Bun? TigerBeetle was the only one of the three to use ReleaseSafe by default last I checked? (Edit: in fact, they outright ban ReleaseFast and ReleaseSmall because they care about correctness.) ZLS suggests ReleaseSafe in its…

Zig ships release fast but there's an accepted proposal (not implemented yet) to change unstable builds to be release safe.

Re: Zig: A new direction for low-level programming?

#76

Post by dmit »

kristoff_it wrote: post #75
dmit wrote: post #70

Earlier quoted context omitted.

> I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Which profile is the default for the Zig compiler itself? What about Bun? TigerBeetle was the only one of the three to use ReleaseSafe by default last I checked? (Edit: in fact, they outright ban ReleaseFast and ReleaseSmall because they care about correctness.) ZLS suggests ReleaseSafe in its…

Zig ships release fast but there's an accepted proposal (not implemented yet) to change unstable builds to be release safe.

You mean the official nightlies? I like that plan! Should boost coverage by a lot in irl projects.

Re: Zig: A new direction for low-level programming?

#77

Post by aeonik »

SoraNoTenshi wrote: post #23

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic. And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an…

Well theoretically if you compiled the whole system with Zig or Rust, you could eliminate that undefined behavior of invalid pointers right?

You'd need an OS that supports it, but it seems viable that the OS using allocators could know what happens at any given pointer.

To do it statically though, and with enough detail, I suppose it would take something like Idris with dependent types, and I'd imagine at that point it would be a pretty tough exercise.

Re: Zig: A new direction for low-level programming?

#78

Post by SoraNoTenshi »

aeonik wrote: post #77
SoraNoTenshi wrote: post #23

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic. And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an…

Well theoretically if you compiled the whole system with Zig or Rust, you could eliminate that undefined behavior of invalid pointers right? You'd need an OS that supports it, but it seems viable that the OS using allocators could know what happens at any given pointer. To do it statically though, and with enough detail, I suppose it would take something like Idris with dependent types, and I'd imagine at that point…

I think that'd require a different Datatype than a Raw pointer. Allocating heap memory is a side-effect that's not really predictable, if you take all the factors into account. However i can see a world where this may be possible because of virtual memory, but i don't know how.

Dependent Types could help, although i am unsure if it helps with raw pointers.

Re: Zig: A new direction for low-level programming?

#79

Post by SoraNoTenshi »

90s_dev wrote: post #40
SoraNoTenshi wrote: post #23

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic. And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an…

> The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it. He just pointed out to us language skimmers that it's a potential chicken egg problem, which we may not have considered. Perfect for this…

I mean reading through the article it was only considering author's present perception which is a bit too naïve in my opinion.

Out of my head, the benefits of having a `build.zig` that you learn right from the get go is, that you kind of have to dig a bit into the eco-system a bit. Also how the buildsystem works, etc. which then in return makes it muuuuch easier later on if you have a bigger project, to properly utilize the power of the buildsystem.

I can also only consider my perspective here, but I've done quite a bit of Rust now (and work with it for over a year now, full time as well), and i can tell you as much: I would be thrown into icy waters if i need to do anything with a build.rs.

Re: Zig: A new direction for low-level programming?

#80

Post by 90s_dev »

josephg wrote: post #56
90s_dev wrote: post #49

Earlier quoted context omitted.

> (I have to do more work to test my code) I feel like that's already the cultural precedence in Zig. I mean, isn't their primary way of making sure your code fully and oncely frees all memory, just writing tons of tests that thoroughly exercise your function(s)?

Sure; but when I'm working on a complex problem, I'll often run (test) my code as I go, eyeballing the input and output to make sure I'm on the right track and its doing what I expect. The less time that passes between writing code and discovering a bug, the easier it is to find and fix the bug. Its also a great way to write tests - I'm more aware of edge cases when I've just written the code being tested. The proble…

I don't disagree with anything you said, I was adding to it, and showing evidence that it seems to be a problem with Zig community's culture.

> at an experimental stage, I haven't refactored my code to make it beautiful yet. I always prefer to debug my code before refactoring it, because if my tests fail afterwards, I can isolate the bug to the refactoring process itself.

Yes, that is inherently the best way to write code. The right flow is,

1) make it work

2) make it work right

3) make it work for the right reasons

Post reply on HN