Live data from Hacker News

Zig 0.11

ziglang.org

61–70 of 193 posts

Re: Zig 0.11

#61
post #17
post #5

What are the use cases for zig? The website says general purpose and tool chain but people who have used it, what it excels at?

As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).

I thought Go tried to be better C

Re: Zig 0.11

#62
post #17

Earlier quoted context omitted.

As someone who used C as main language, I've switched to zig. It's the only language that tries to be "better C", and not another C++. Comptime being like Nim where it's not entirely own language is also plus. I'd say it excels at general purpose system programming, and especially if you need to work with memory in detailed way (rust makes this very annoying and hard).

What advantages does Zig have over C?

Just to name one: compile time code execution. It eliminates the need for a separate macro language and provides Zig zero cost generic types.

Not to mention memory leak detection, crazy fast compilation times, slices and a built in C compiler so your code can seamlessly integrate with an existing C code base (seriously no wrapper needed).

Zig is really really awesome. The only thing holding it back from mass adoption right now is that it's not finished yet, and that shows in the minimal documentation. That said, if you're comfortable tinkering, it's completely capable of production uses (and is already used in production in various companies).

Re: Zig 0.11

#63
post #47

Earlier quoted context omitted.

Aarch64 is supported (M series chips) if that’s what you’re worried about.

No, I actually have a bunch of older Macs I keep running for certain experiments.

Those would be Intel not Arm, no?

Re: Zig 0.11

#64
post #52

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

At some level you need languages that are not “memory safe”. Memory safety comes with a cost. Either you pay for a GC runtime (Java) or for reference counting (Swift) or by not being able to express a correct program (Rust). There are plenty of use cases where none of these tradeoffs are feasible. To add, Zig comes with its own story around memory safety. Not at the static type system level and it’s not as comprehens…

"Express a correct program" that might end up being incorrect due to programmer's fault.

The difference is, you can use unsafe blocks/fns in Rust, in which case it becomes equivalent to C expressiveness-wise; but you can also do the opposite and forbid(unsafe_code) altogether.

Re: Zig 0.11

#65
post #7

Anybody here who is using zig on daily basis?

I took a year off, and one of the things I did was learn Zig. I've built a number of libraries, including one of the currently more popular HTTP server libraries (https://github.com/karlseguin/http.zig).

A number of my libraries are used for https://www.aolium.com/ which I decided to write for myself.

I try to write a bit every day with the benefit that I can "waste" time digging into things or exploring likely-to-fail paths.

Re: Zig 0.11

#66

Earlier quoted context omitted.

the united states government is not going to outlaw the use of memory unsafe languages. that is an absurd idea. nothing in your links suggests they would even consider it. "moving the culture of software development" to memory safe language does not mean "we want to put you in jail for writing C".

Where did you get the idea that jails are involved? Governments are clearly forming a position, if they fund new projects, they are quite likely to enforce that position. That's a significant market already.

they can enforce that position by funding projects that are written in languages that they believe are memory safe. they do not need, or want, to legislate that.

Re: Zig 0.11

#67

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

What would happen with existing codebases, sometimes built upon 2 decades of C or C++? Will the we "rewrite everything in Rust" ? lol

AI will probably find all bugs or re-write all the software in minutes soon enough.

Re: Zig 0.11

#68
post #51

Earlier quoted context omitted.

>My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. This is an oxymoron :) The strictness and borrow checker are part of the power and modernity of Rust. But even apart from that, Rust has automatic value-based destructors (destructor follows the value as it's moved across scopes and is only called in the final scope), whereas Zig only has scope-based d…

> Rust's const-eval is very constrained and has been WIP for ages Having strong backwards compatibility does that to the language, alternative is arguably worse (see Python 2 vs 3).

Yes, and I don't want a backward-incompatible Rust 2.0 either, but the slowness of stabilizing ! (named for when it's going to be stabilized), specialization, TAIT, const-eval, Vec::drain_filter, *Map::raw_entry, ... is annoying. Also the lack of TAIT currently causes actual inefficiency when it comes to async traits, because currently async trait methods have to return allocated virtualized futures instead of concrete types. Same for Map::raw_entry, without which you have to either do two lookups (`.get()` + `.entry()`) or always create an owned key even if the entry already exists (`.entry(key.to_owned())`).

Re: Zig 0.11

#69
post #47

Earlier quoted context omitted.

Aarch64 is supported (M series chips) if that’s what you’re worried about.

No, I actually have a bunch of older Macs I keep running for certain experiments.

Older mac are intel based not arm. M1 is the first arm based chip

Re: Zig 0.11

#70

Zig is not memory safe and therefore at risk, just like C/C++, of future government legislation that outlaws the use of memory unsafe languages for some or all projects. The risk of such legislation is not insignificant: https://www.itpro.com/development/programming-languages/3694... Personally I do not see the point of building an entirely new language and ecosystem that does not fully address this issue.

I'm sure the federal government's advocacy will aid Rust adoption massively. I mean, look at how Ada's adoption skyrocketed when it received DoD's stamp of approval.
Post reply on HN