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

Zig: The Modern Alternative to C

infoworld.com

Post reply on HN
Print view View original

11–20 of 181 posts

Re: Zig: The Modern Alternative to C

#11

Post by flohofwoe »

sgt wrote: post #5

Is it a good alternative to Go? How is interoperability?

The Zig compiler is also a (clang compatible) C/C++/ObjC compiler, the Zig toolchain comes with C and C++ runtime headers and libraries, C headers (but not C++ or ObjC headers) can be directly imported into Zig code. Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?).

Whether it's going to become a good alternative for Go will depend mainly on the stdlib I think. What's clear is that the Zig stdlib will be much richer than C's or C++'s, but whether it will be a good match for Go's stdlib for backend work remains to be seen.

Re: Zig: The Modern Alternative to C

#12

Post by david2ndaccount »

I don’t know why these new languages have to have their own special takes on loops without giving us the classic C99 version of the three-clause-for-loop. Even JavaScript has it. If they want to improve on it, then allow us to declare variables of different types in the first clause. Yes, using the C-style loop to iterate over a container sucks, but that is an argument for also having a for-each loop. There are lots of low level algorithms that are just better to express with the three-clause-for-loop.

Re: Zig: The Modern Alternative to C

#13

Post by hawski »

sgt wrote: post #5

Is it a good alternative to Go? How is interoperability?

It is not an alternative to Go same as C++ or Rust is not really an alternative to Go. They are on a different level, but can do the same job. Though I could argue that Tcl could be an alternative to Go, I think many would not agree.

Zig has manual memory management, doesn't have much of a runtime (no CSP out of the box) and above all is not mature yet (breaking changes do happen). As of now it has one of the best stories for interfacing with C as it can directly use C headers.

Re: Zig: The Modern Alternative to C

#15

Post by cztomsik »

hawski wrote: post #10
loeg wrote: post #8

Earlier quoted context omitted.

The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.

Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.

You could, but it's not idiomatic in C. Zig is basically built around this.

Re: Zig: The Modern Alternative to C

#18

Post by jenadine »

loeg wrote: post #8
potro wrote: post #6

A quote from the article: > A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library. I guess it is all you need to know about the article quality.

The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.

So you have coloured functions? The red that can allocate, and the blue that cannot?

Re: Zig: The Modern Alternative to C

#19

Post by Animats »

That article is about control flow and syntax, which isn't a big problem. What matters is data. So what does Zig have that C doesn't?

- Arrays and slices. A slice is a pointer and a length. There's subscript checking on slices. You'd expect that the preferred operation would be to take a slice from a slice, but the documentation does not mention that option. This may be a documentation error. There is a ".." operator for specifying bounds within a slice, but the examples given only show it being used to extract a fixed-length array. Slices are important. They let you do most of the things done with pointer arithmetic in C, usually badly.

- No objects, just structs. Structs are available in "packed" mode (no filler bits), something rarely seen since Pascal. There are discriminated variant types (Rust calls those enums) and undiscriminated variants (like C unions.)

- Strings are unchecked UTF-8, which is probably OK.

- "Sentinel terminated arrays" are a generalization of null-terminated strings. Strange, but perhaps harmless. The "char *argv[]" array in C main programs is a null-terminated array of null-terminated strings. You don't really need "argc". That's one of the last remnants of that idea, and it doesn't seem worth reviving.

It's reasonable enough, but it's maybe the fifth try at a better C.

[1] https://ziglang.org/documentation/0.10.1/#Slices

Re: Zig: The Modern Alternative to C

#20

Post by aserafini »

flohofwoe wrote: post #11
sgt wrote: post #5

Is it a good alternative to Go? How is interoperability?

The Zig compiler is also a (clang compatible) C/C++/ObjC compiler, the Zig toolchain comes with C and C++ runtime headers and libraries, C headers (but not C++ or ObjC headers) can be directly imported into Zig code. Don't know how many of those checkboxes Go ticks (I think it can at least import C headers?). Whether it's going to become a good alternative for Go will depend mainly on the stdlib I think. What's clear…

I expect the stdlib will not be quite as tailored for general backend work as Go’s, but I envisage we’ll ultimately see a rich and vibrant package ecosystem with all those bases covered.
Post reply on HN