Live data from Hacker News

Zig: A new direction for low-level programming?

bitshifters.cc

41–50 of 110 posts

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

#41
post #20

> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const. This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn t…

This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.

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.

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

#42
post #32
post #29

Earlier quoted context omitted.

Not using a variable is the same as flying out your car window? It's more like the cashier smacks a peanut out of your hand saying you'll get fat.

Even when compiling in Debug mode! Where the analogy is closer to a friend who's applying for a cashier job asking you to role play being a customer so they could practice, and then spitting in your face when you go "Hey, Joe! I'll take these" because "No real life customer would do that! Start over."

> Even when compiling in Debug mode! closer to a friend asking you to role play being a customer so they could practice, and then spitting in your face saying "No customer would do that! Start over."

Thanks for the hearty laugh :D

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

#43
post #20

> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const. This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn t…

Urgh this frustrates me so much.

The worst part is, the recommended way to avoid these compilation problems is to add:

    _ = my_unused_variable;
to your code. Some IDE extensions even do this automatically. But if you do that, it permanently suppresses all compiler feedback that my variable is unused! Its basically the worst of all worlds:

- I can't easily prototype, or test code as I go because I keep stubbing my toe on irrelevant unused variables. And these are compilation errors, not warnings.

- In order to test my code, I need to go and fix all the unused variable errors (either automatically or manually). But once I've done that, they're essentially suppressed forever. Now I don't even get warnings, and I'm at risk of shipping code with unused variables. Now I need to manually scan my code, looking for times when _ = x was only added as a placeholder. Will I forget some? You bet.

So I end up in a situation where its both less convenient than other languages (I have to do more work to test my code). AND I'm more likely to ship bad code - since by the time I'm done, half my unused variable warnings have been manually suppressed and I can't find out where they are.

This obviously works for some people. Maybe some people never try running their code as they go. But its just horrible for me. It breaks my workflow and risks me shipping worse code. And it provides no actual benefit in return.

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

#44
post #19

Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement. Having to know the full set of Zig sources in advance due to error types, and the s…

You can't have monomorphization or the old async feature if you need to be able to convert individual files to C.

You can do it in multiple passes (analysis/dumping IR followed by code generation, with dep files to connect them). It's what Rust does internally with rmeta files.

Mine is not necessarily a criticism of Zig, mind. It's a criticism of what is needed from a C replacement.

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

#45
post #31

Earlier quoted context omitted.

> My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. Didn't Rust do the same thing? We only call efforts wasteful until they become mainstream, then in retrospect we call it excitement driven prudence. Anyway,…

Rust is a bit different, more like a C++ replacement and heavily focused on so-called memory safety, but with IMO many bad design decisions, while I consider Zig/Jai/Odin as merely "meh" I think that Rust is bad.

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.

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

#46
post #31

Earlier quoted context omitted.

> My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. Didn't Rust do the same thing? We only call efforts wasteful until they become mainstream, then in retrospect we call it excitement driven prudence. Anyway,…

Rust is a bit different, more like a C++ replacement and heavily focused on so-called memory safety, but with IMO many bad design decisions, while I consider Zig/Jai/Odin as merely "meh" I think that Rust is bad.

What about Rust's memory safety story justifies the "so-called" qualifier?

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

#47
post #41

Earlier quoted context omitted.

This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.

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.

It also protects innocent bystanders from being forced to see your horrifyingly mangled body tossed on the ground in front of them in what could otherwise have either been a crash with no injuries, minimized injuries, or at least contained injuries. Do you still think that law is overstep, if so why? Genuine question, I have no horse in this race and am on the fence myself.

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

#48
post #38
post #19

Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement. Having to know the full set of Zig sources in advance due to error types, and the s…

Replacing C != coexisting seamlessly. Exposing an idiomatic C interface by default would handcuff Zig’s own design. > Having to know the full set of Zig sources in advance due to error types You can just catch all of the errors and translate them back into errno or whatever homegrown scheme your c project is using. - - - Does the zig compiler not support generating .o’s without a build.zig? I like the zig build syste…

> Does the zig compiler not support generating .o’s without a build.zig?

Of course it does, all the build system does is orchestrate invocations to the other basic zig subcommands (`build-exe`, `build-lib`, `build-obj`, etc). You can invoke `zig build-obj` and get an object file in whatever flavor you prefer.

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

#49
post #43
post #20

> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const. This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn t…

Urgh this frustrates me so much. The worst part is, the recommended way to avoid these compilation problems is to add: _ = my_unused_variable; to your code. Some IDE extensions even do this automatically. But if you do that, it permanently suppresses all compiler feedback that my variable is unused! Its basically the worst of all worlds: - I can't easily prototype, or test code as I go because I keep stubbing my toe…

> (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)?

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

#50

C is not going anywhere. Neither are C++, Java, and JS (less sure about TS). One reason is that we've built most of the foundations of modern software already in these languages. New apps pop up all the time but they all rely on ffmpeg, etc. The only way for a new language like Zig to cement itself is to build foundational software that other programs depend on. I don't think even Rust is moving in that direction (lo…

A language doesn't need to be used in foundational software to be relevant or useful. Go isn't built in the OS either, but its still used by lots of developers to write useful software.

This might be controversial, but I think its fine for small languages to exist, with small followings. Nobody will ever make a browser in Haskell, but its still a work of art. Nobody uses Elm, but React wouldn't exist without it. And so on. Rust is useful on its own. But its also already inspired the C++ language committee to start talking about memory safety a lot more seriously. Thats a big deal!

I'm delighted that languages like Zig exist. If for no other reason than to show that if you're dedicated enough, a lone hobbyist can still invent a language and make it good. (I wish that were still true for web browsers.)

Post reply on HN