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

Zig 0.11

ziglang.org

Post reply on HN
Print view View original

31–40 of 193 posts

Re: Zig 0.11

#31

Post by DeathArrow »

Cloudef wrote: post #17
tarcio wrote: 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).

What advantages does Zig have over C?

Re: Zig 0.11

#32

Post by sai_c »

whiterock wrote: post #26

It‘s a shame macOS Arm is deprecated :(

Whoa, thanks for the heads-up. I've been reading news about Zig from time to time, and planned giving it an honest try at 1.0 (whenever that may be) but it seems I'm out of luck.

Do you, by chance, know the reasoning behind this step?

Re: Zig 0.11

#33

Post by lmm »

quic5 wrote: post #28
grumpyprole wrote: post #23

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.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

Re: Zig 0.11

#34

Post by grumpyprole »

quic5 wrote: post #28
grumpyprole wrote: post #23

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.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

Memory safety is one aspect of quality yes, but is there any evidence Zig is a good fit for other quality aspects, e.g. static analysis tooling and correctness proofs? ATS is a low-level language that allows embedded proofs of correctness in the type system.

Re: Zig 0.11

#35

Post by grumpyprole »

bachback wrote: post #29
grumpyprole wrote: post #23

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.

seriously? "The National Security Agency (NSA) has recommended only using 'memory safe' languages, like C#, Go, Java, Ruby, Rust, and Swift, in order to avoid exploitable memory-based vulnerabilities."

Yes seriously. The west is getting hacked and owned on a daily basis. The NSA recommendation shows that governments are starting to identify where the problem is.

Re: Zig 0.11

#36

Post by TheFragenTaken »

quic5 wrote: post #28
grumpyprole wrote: post #23

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.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

Not to be snarky, but you argument works both ways :). What good is a medical device if it leaks sensitive data, because it had been exploited by a use-after-free?

Re: Zig 0.11

#37

Post by nevi-me »

quic5 wrote: post #28
grumpyprole wrote: post #23

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.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

It sounds like you'd be worrying about n-1 types of safety errors instead of n, which is arguably better.

Re: Zig 0.11

#38

Post by quic5 »

lmm wrote: post #33
quic5 wrote: post #28

Earlier quoted context omitted.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

There are use cases where safety beyond memory safety is required. But there are no use cases where memory unsafety is desirable, yet alone required.

That is absolutely true. But but you can write memory-bug-free code in Zig but you cannot prevent heap allocations in most of the languages listed in the article, making it outright impossible to write certain software in them.

Re: Zig 0.11

#39

Post by konsuko »

The new multi-object for loop syntax is such an improvement. Hoping for many more small QoL features like this until Zig hits 1.0.

Re: Zig 0.11

#40

Post by Ygg2 »

quic5 wrote: post #28
grumpyprole wrote: post #23

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.

That totally misses the point of quality software. What good is memory safety if you medical device crashes because of an out of memory error? What I'm trying to say: There are use cases where areas of safety are required other than memory safety.

Memory errors are much, much less likely to occur with more memory than use after free.
Post reply on HN