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

81–90 of 110 posts

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

#81

Post by EPWN3D »

I think the author's criticism of the named initializer requirement is emblematic of a big problem I have with most new languages. The author says that it makes things like vectors more verbose and awkward, which is true.

My counter to this is: who gives a shit? I'm not writing a vector library or a game engine; I'm writing systems code, and unnamed initializers are harder to read and expose code to subtle bugs. And for what? So that vectors look prettier?

A lot of programming language design seems to prioritize making its own standard library math functions more elegant to implement, which I find to be very irritating, and Zig is a breath of fresh air in this regard.

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

#82

Post by davemp »

GianFabien wrote: post #5

I stumbled across Zig by a reference to it as part of the Bun (JS engine) documentation. I didn't find the Zig language benefits sufficiently compelling to learn yet another opinionated language. Since much of my work is with embedded and bespoke systems, I did find the Zig cc front-end to LLVM convenient. Maybe it's because I haven't sufficiently mastered Clang for cross-compilation.

I’m using zig for embedded builds currently. All of the mcu files are still in C (arm thumb isn’t first class supported in zig) but the host software is sometimes zig. Being and to easily develop on and for any host platform is such a pleasure. I can just tell junior devs to download zig and a vscode extension and they’re off to the races.

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

#83

Post by lolinder »

Icathian wrote: post #24
90s_dev wrote: 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.

If we're going to go with the seatbelt comparison then we'd have to flesh it out a bit:

Your new car sounds an alarm non-stop if any seat belt in the car is unfastened, whether or not a seat is occupied and whether or not the car is even on. This seems kind of silly, so you raise it with the manufacturer and they say that standard procedure is to just leave all seat belts fastened all the time.

You start doing that and quickly realize that it's much harder to remember to put your seat belt on than it was in your old car, because the car doesn't warn you when you've forgotten your seat belt and when you do remember on your own you have to sit up awkwardly to unfasten it before you can get under it and fasten it around you. You point this out to some fans of the manufacturer and they act like you're the weird one for not seeing how this makes you safer.

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

#84

Post by wolvesechoes »

heresie-dabord wrote: post #53
stephc_int13 wrote: post #25

I've been closely following and evaluating the train of C replacement languages that was (I believe) started by Jonathan Blow and Jai. Zig is one of the strong contenders, but Odin is IMO following a saner path, Carbon and D should be mentioned and I think there are a few others. My initial reaction to new programming languages is naturally skeptical, but I really liked the way the designers behind those efforts appr…

> the problems they try to solve are not painful enough. The lack of safety is not painful enough? There is an entire industry (i.e. job sector, training, expertise) that evolved to try to thwart bad actors abusing unsafe languages.

But neither Zig nor Odin solve this problem. The only serious attempt is Rust.

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

#85

Post by gliptic »

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's really not. Looks like something like JS with almost identical syntax.

Also, the compiler (and what else?) isn't even implemented [1].

[1] https://github.com/profullstack/smashlang/blob/master/src/co...

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

#86

Post by ksec »

pron wrote: post #33

Because we rarely have objective measures by which to compare programming languages, there is no such thing as "ideal." Some objective measures can include code size, and it is undoubtedly true that switching from Assembly to Python often results in a super-linear reduction in code size, but we rarely see such differences anymore. When we do get some objective comparisons through empirical research -- always many yea…

>https://news.ycombinator.com/item?id=43939520

Hi pron, I am hoping you could write your thoughts on Odin.

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

#87

Post by davemp »

kristoff_it wrote: post #48
davemp wrote: post #38

Earlier quoted context omitted.

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.

So you can just extern the functions you want, handle all the errors internally, and stick it into your makefile with?

    %.o: %.zig
        zig build-obj *.zig -o *.o
Not sure I get OP’s complaint then.

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

#88

Post by bonzini »

davemp wrote: post #87
kristoff_it wrote: post #48

Earlier quoted context omitted.

> 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.

So you can just extern the functions you want, handle all the errors internally, and stick it into your makefile with? %.o: %.zig zig build-obj *.zig -o *.o Not sure I get OP’s complaint then.

Anything that produces object files is a lot harder to debug and maintain than a transpiler.

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

#89

Post by davemp »

bonzini wrote: post #88
davemp wrote: post #87

Earlier quoted context omitted.

So you can just extern the functions you want, handle all the errors internally, and stick it into your makefile with? %.o: %.zig zig build-obj *.zig -o *.o Not sure I get OP’s complaint then.

Anything that produces object files is a lot harder to debug and maintain than a transpiler.

Not sure I agree. If you’re going zig->C->obj, you’d still have to fix the zig source if you find an issue in the C level.

If you don’t want to learn or debug in a new language then you should probably just stick with C?

The goal of zig as far as I know is to make it so you can transition away from C completely. Maintaining a C target seems antithetical to breaking ties with the “C machine”.

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

#90

Post by andrewmcwatters »

pjmlp wrote: post #58
andrewmcwatters wrote: post #39

Earlier quoted context omitted.

I feel many of your sentiments, and suspect that many C successors fail, because they don't want to just look like an evolution of C in the same way C with Classes did. No one is out here building C with Safety.

WG14 could design such an evolutionary path, it has been obvious since 1980's, however they clearly aren't interested.

Yeah, it's really disappointing. I think the general attitude is to use calls to functions that are safe and to use instrumentation, which I get, but it results in these piecemeal fixes over the years.
Post reply on HN