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

81–90 of 193 posts

Re: Zig 0.11

#81

Post by grumpyprole »

0xfedbee wrote: post #60
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.

[flagged]

You might think that, if you live in a small world. I want memory safety, but I am otherwise not a big fan of Rust. Rust tries to be too high-level like C++, making it opaque where allocations are happening. For a low-level systems language, with embedded proofs, I quite like ATS, but Vale is also promising and more like Zig.

Re: Zig 0.11

#82

Post by pjmlp »

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

No, however it may require that like with other kinds of dangerous chemicals, or hazourds goods, their use must follow strict requirements, like they already have to for high integrity computing.

Re: Zig 0.11

#83

Post by flohofwoe »

wodenokoto wrote: post #75

I enjoy seeing an update or discussion of things like D, Zig, Nim (and a few others I probably forgot) but I honestly can't keep track of where they are in relation to C/C++, C#/Objective-C, and Rust. Is there are chart or a "are we xxxx yet" page one can reference?

IMHO this is still the most important page to get an idea what the current state of Zig is and how it changed over time:

https://ziglang.org/documentation/0.11.0/

Re: Zig 0.11

#84

Post by Borborygymus »

dakom wrote: post #71
BaculumMeumEst wrote: post #41

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

Agreed, it's absurd. Jail time for writing javascript otoh...

I guffawed, and I'm not afraid to admit it.

Re: Zig 0.11

#85

Post by flohofwoe »

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.

Zig enforces much more correctness than C or C++, which also results in much more memory safety, it's just not as extremist as Rust.

Re: Zig 0.11

#86

Post by AndyKelley »

quic5 wrote: post #30
whiterock wrote: post #26

It‘s a shame macOS Arm is deprecated :(

I don't believe there ever was support for macOS on 32-bit ARM.

I believe iPhone 5c was the last of the 32-bit ARM Apple devices. I guess technically that's iOS rather than macOS but as far as Zig is concerned, it's all Darwin.

Re: Zig 0.11

#87

Post by flohofwoe »

iraqmtpizza wrote: post #61
Cloudef wrote: 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).

I thought Go tried to be better C

Why should there only be one "better C"? Go has a very different philosophy than Zig, but both can be considered a "better C".

Re: Zig 0.11

#90

Post by pjmlp »

BaculumMeumEst wrote: post #66
grumpyprole wrote: post #48

Earlier quoted context omitted.

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.

Funny that you mention that, EU does sponsor Rust development.

"Logical Foundations for the Future of Safe Systems Programming"

https://cordis.europa.eu/project/id/683289

As for US,

https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI...

"NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible. Some examples of memory safe languages are C#, Go, Java, Ruby™, and Swift®. Memory safe languages provide differing degrees of memory usage protections, so available code hardening defenses, such as compiler options, tool analysis, and operating system configurations, should be used for their protections as well. By using memory safe languages and available code hardening defenses, many memory vulnerabilities can be prevented, mitigated, or made very difficult for cyber actors to exploit."

Post reply on HN