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

161–170 of 193 posts

Re: Zig 0.11

#161

Post by kubkon »

bmacho wrote: post #132
kristoff_it wrote: post #124

Earlier quoted context omitted.

> People choosing Zig to anything choose their users to throw away their devices. Apple is asking you to throw away your devices, not Zig. Getting proper CI coverage for supported versions of the OS is already pretty expensive and doing the same for unsupported systems is entirely unfeasible at this moment. Don't buy Apple if you don't want to throw away functioning hardware.

Yeah, sure. It is still a bummer when people that try actively to underpin the whole world tell you 'fuck you'. Having 'we support proprietary systems until their makers support it' as a hard rule is unnecessary and harsh. It is a simple rule, but I don't think it is good. Why not choose the supported systems on individual merits, e.g. on usage statistics? I think for example the Linux kernel does that. edit: I just…

Hi, kubkon here, the author of Zig's MachO linker. I just wanted to explain our reasoning here a little bit. As you have hopefully noticed in the release notes, there are 5 core team members that are paid either full- or part-time for their work on Zig. That's not an awful lot, and as you can see in our latest roadmap for 0.12 release, we have quite a few challenging components to develop including functioning linkers for the most common platforms, and not only macOS/Apple. This makes it really tricky to justify spending a considerable amount of time trying to support an OS that was officially dropped by a vendor such as macOS/x86, or watchOS/arm32 (FYI, as a fun fact, arm32 is considered private as opposed to public by Apple according to comments and conditional includes in Apple's libc headers). That said, after 1.0/stable release of Zig, I would love to spend more time into adding backwards support for old Apple platforms in the MachO linker and Zig as a whole.

Re: Zig 0.11

#162

Post by flohofwoe »

JohnDeHope wrote: post #160
flohofwoe wrote: post #87

Earlier quoted context omitted.

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

Possibly the thing that makes C be C is that there is only one C. It is the single lingua franca of "one notch up from assembly". I would argue any language that wants to be a better C has to accept the challenge of being available on any platform, existing or future, any architecture, suitable for any bare metal use case, and it has to want to be the single obvious go-to choice. That's what it means to step into the…

In general I agree, but a couple of IMHOs:

> that there is only one C

IMHO one of C's strong points is the ubiquity of non-standard compiler extensions, C with Clang extensions is much more "powerful" than standard C, personally I see C as a collection of closely related languages with a common standardized core, and you can basically pick and choose how portabel (between compilers) you want to be versus using compiler-specific extensions for low level optimization work (and in a twisted way, Zig is also a very remote member of that language family because it integrates so well with C).

> "one notch up from assembly"

C is actually a high-level language, it's only low-level when compared to other high-level languages, but much closer to those than to assembly. Arguably Zig is in some places even lower-level than C because it's stricter where C has more "wiggle room" (for instance when it comes to implicit type conversions where Zig is extremely strict).

> being available on any platform, existing or future, any architecture, suitable for any bare metal use case

Zig has a pretty good shot at that requirement, it has a good bootstrapping story, and for the worst case it has (or will have) a C and LLVM (bitcode) backend.

For me personnally, Zig will most likely never completely replace C, but instead will augment it. I expect that most of my projects will be a mix of C, C++, ObjC and Zig (and Zig makes it easy to integrate all those languages into a single project).

Re: Zig 0.11

#163

Post by packetlost »

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 never understood this take. You shouldn't be heap allocating each node in your linked list anyways. It's trivial to convert the pointer fields to indexes and have each nodes live in a `Vec` unless you need it to be intrusive. You'll get better performance anyways because you're not doing a pointer deref and blowing your TLB up every time you traverse the list.

Re: Zig 0.11

#164

Post by packetlost »

DeathArrow wrote: post #31
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).

What advantages does Zig have over C?

Namespaces.

Real enums, modules, etc.

A compile-time execution system (effectively replaces the preprocessor/macro system).

Syntax that is easier to `grep -r` for without complex regex.

Tests are a first-class citizen.

Safer type system.

Really, just a bunch of things that should've been added to C 20 years ago.

Re: Zig 0.11

#165

Post by CyberDildonics »

ArtixFox wrote: post #100
grumpyprole wrote: post #81

Earlier quoted context omitted.

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.

The way zig is designed, I think it will be fairly easy to embed Ada's Spark like proof system in it.

Why do you think that?

Re: Zig 0.11

#166

Post by binary132 »

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?

“Whatever you would use C for but better” roughly

I’m not really convinced because in Andrew’s livestreams he’s actively uncovered significant stdlib bugs that he is aware of and tables for later.

Hopefully those will all be gone by 1.0, but I doubt it. For now, I cannot consider it a viable alternative to anything for production software. I do hope it will be some day, because it’s a nice language, even if it has a few syntactic warts :)

that said... I feel safer choosing C89 or C99 for certain things due to its extremely wide availability and longevity.

It’s great for it to have competitors, but C and C++ are more like standards and less like one tool with a handful of people working on it.

Re: Zig 0.11

#167

Post by binary132 »

armchairhacker wrote: post #13
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?

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…

I think Rust and Zig are very different in principals and shouldn’t really be compared. It’s almost like comparing C and Ada.

Re: Zig 0.11

#168

Post by binary132 »

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

Go is about as much like C as Java is.

Re: Zig 0.11

#169

Post by pjmlp »

DrBazza wrote: post #103
bachback wrote: post #29

Earlier quoted context omitted.

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

log4shell enters the chat. https://en.wikipedia.org/wiki/Log4Shell

Yes, it belongs to the remaining 30% of exploits, when we remove the 70% ones caused by memory corruption.

Re: Zig 0.11

#170

Post by tempZigInterest »

jedisct1 wrote: post #128
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?

For WebAssembly, Zig really excels. It's very memory efficient, everything compiles of the box to WebAssembly (freestanding or wasi), the resulting code is compact and fast, and it can take advantage of the latest WebAssembly extensions (threads, SIMD, ...) without any code changes. If you are using a webassembly-powered cloud service and not using Zig to write your functions, you are wasting money. Seriously. Unsurp…

If you don't mind, since you have experience targetting WASM with both Rust & Zig, what advantages does Zig have over Rust in this particular use case?

Are the memory safety guarantees that Rust offers over Zig not as important or critical when targeting WASM?

I've been interested in checking out Zig for a while now.

Post reply on HN