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

41–50 of 193 posts

Re: Zig 0.11

#41

Post by BaculumMeumEst »

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.

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

Re: Zig 0.11

#42

Post by grumpyprole »

quic5 wrote: post #38
lmm wrote: post #33

Earlier quoted context omitted.

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.

Sure one can write memory-bug-free code in x86 assembly too. But how can you prove it? ATS is an example of a low-level systems language where you can prove it.

Re: Zig 0.11

#43

Post by TheRoque »

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.

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

Re: Zig 0.11

#44

Post by candrewlee14 »

sai_c wrote: post #32
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?

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

Re: Zig 0.11

#45

Post by DeathArrow »

pkulak wrote: post #24
lenkite wrote: post #19

Earlier quoted context omitted.

Also none of the common knowledge around traditional data-structures and algorithms work with Rust anyways. One needs to dance like a ballerina with their hands and feet tied.

“Linked lists are hard” is not “none of the common knowledge around traditional data-structures and algorithms work”.

Ever tried to implement generic trees in Rust?

Re: Zig 0.11

#46

Post by BaculumMeumEst »

whiterock wrote: post #26

It‘s a shame macOS Arm is deprecated :(

this comment is misleading. aarch64, the architecture for apple silicon, is still fully supported. did you see "arm" with a skull next to it and assume that meant all ARM architectures became recently deprecated?

Re: Zig 0.11

#47

Post by sai_c »

candrewlee14 wrote: post #44
sai_c wrote: post #32

Earlier quoted context omitted.

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?

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.

Re: Zig 0.11

#48

Post by grumpyprole »

BaculumMeumEst wrote: post #41
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.

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.

Re: Zig 0.11

#49

Post by grumpyprole »

TheRoque wrote: post #43
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.

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

Maybe doing it for new projects is better than doing nothing?

Re: Zig 0.11

#50

Post by kristoff_it »

pid-1 wrote: post #4

> Backed by the Zig Software Foundation, the project is financially sustainable. These core team members are paid for their time: (lists five people) That's quite impressive. For comparison, Python had 2 full time paid devs in 2019 (not sure about now).

We're also pretty efficient, more than 90% of the donated money is used to pay developers (the rest goes to administrative costs, CI infrastructure, etc).
Post reply on HN