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

71–80 of 193 posts

Re: Zig 0.11

#71

Post by dakom »

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

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

Re: Zig 0.11

#72

Post by bsder »

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?

Zig has a decent chance of being an actual embedded device (ie. no operating system) programming language.

In my opinion, Zig seems likely to grow the necessary bits to be good at embedded while Rust is unlikely to figure out how to shrug off the clanky bits that make it a poor fit for embedded devices.

However, I'm a personal believer that the future is polyglot. We're just at the beginning of shrugging off the C ABI that has been preventing useful interoperability for decades.

Once that happens, I can use Rust for the parts that Rust is good for and Zig for the parts that Zig is good for.

Re: Zig 0.11

#73

Post by samwillis »

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

I suspect some of this comes down to how larger donations are made. For Python they have often had people working at companies donating time on their employers books to the development of it.

GVR for example works for Microsoft and has worked at Dropbox and other places, but spends much of his time on Python. So he isn't listed as an employee of the foundation, but at times is full time.

If a company donates employee time they have more influence on the project than donating cash to pay for development.

The fact that Zig had the cash donation to do it this way is brilliant, and probably a better model.

Re: Zig 0.11

#74

Post by tauoverpi »

msavara wrote: post #7

Anybody here who is using zig on daily basis?

I'm slowly writing a game with it in my own time and previously worked on an in-memory cache for smart metering full-time. It's been nice to play with and my goto language for prototyping since arond 0.5.0.

Re: Zig 0.11

#75

Post by wodenokoto »

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?

Re: Zig 0.11

#76

Post by ObscureScience »

grumpyprole wrote: post #42
quic5 wrote: post #38

Earlier quoted context omitted.

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.

As Zig promises "not hidden allocation", I assume you can build your allocator in Rust and then use it for all memory allocation in Zig.

Re: Zig 0.11

#77

Post by anonymoushn »

Arnavion wrote: post #21
armchairhacker wrote: post #13

Earlier quoted context omitted.

My understanding is that Zig has all of the power and modernity of Rust, without the strictness and borrow checker. Unlike Rust, it also has powerful compile-time evaluation and custom allocators, and probably more improvements I'm not familiar with (in Rust you can effectively emulate custom allocators, but you have to rewrite every allocating structure to use them; or you can use nightly, but most third-party libra…

>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 has properly composable Option/Result monads, whereas Zig has special-cased ! and ? which don't compose (no Option of Option or Result of Result)

?!!??u32 is a perfectly cromulent type in Zig.

Re: Zig 0.11

#78

Post by cztomsik »

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?

1. It's typically at least as fast as C, unlike C++/Rust

2. You can do type introspection (and switching) during compile-time, and it's not just some stupid TokenStream transformer, you really have type information available, you can do if/else on the presence of methods, etc.

3. There are no generics, but your functions can accept anytype, which is still type-safe. See https://github.com/ziglang/zig/blob/9c05810be60756e07bd7fee0... and note the return type is "computed" from the type of the input.

4. Types are first-class values (during comptime), so any function can take or return a new type, this is how you get generic types, without (syntax/checking) support for generics.

5. You can easily call anything which does not allocate in these comptime blocks.

6. There's @compileError which you can use for custom type assertions -> therefore, you have programmable type-system.

7. It's super-easy to call C from Zig.

8. This is subjective: You don't feel bad about using pointers. Linked data structures are fine.

Re: Zig 0.11

#79

Post by Klonoar »

dgb23 wrote: post #52
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.

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…

...that's like, completely ignoring the escape hatch in Rust of unsafe {}.

You're not limited by anything there, period.

Re: Zig 0.11

#80

Post by bsder »

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

I retort that almost all of the concurrent data structures are obnoxious to represent in Rust.

A lock-free ConcurrentHashMap, for example, is by no means a straightforward data structure in a non-GC language. Even if you somehow dodge Rust's pedantry, you still have to figure out who owns what, who pays for what and when they pay for it--and there are multiple valid choices!

Non-GC allocation/deallocation in concurrent data structures probably still qualifies as a solid CS problem.

(And, before you point me to your favorite crate for ConcurrentHashMap, please check it's guarantees when one process needs to iterate across keys while another process simultaneously is inserting/deleting elements. You will be shocked at how many of them need to pull a lock--so much for lock-free.)

Post reply on HN