Live data from Hacker News

Zig: The Modern Alternative to C

infoworld.com

21–30 of 181 posts

Re: Zig: The Modern Alternative to C

#21
post #10

Earlier quoted context omitted.

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.

It would be hard for a replacement with the purpose of modernizing a way of working to be idiomatic at the same time. It would be an explicit attempt to update what is idiomatic, and of course not be the same as what was before.

It's actually a rather interesting idea, if I had the time for a C-focused side project that sounds really fun! :)

Re: Zig: The Modern Alternative to C

#22
post #10

Earlier quoted context omitted.

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.

Their standard libraries are built around the notion, but I would argue that putting allocation in their respective stdlibs instead of a part of the language makes it possible to be flexible if needed. There are non-trivial and semi-popular C programs that do not use the C stdlib at all.

I agree that the culture is different and that is significant, but I do not see it in the notion of the language itself (without its stdlib).

Also what is idiomatic for Zig does change as it is not a mature language. Though the allocator passing is expected to remain. Odin did an interesting thing and the allocator is put in a 'context' which is an actual part of the language.

Re: Zig: The Modern Alternative to C

#23
post #19

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…

> No objects, just structs

C doesn't have 'objects' either, just structs.

In Zig you can add functions to structs though, and you have UFCS syntax sugar, both together is pretty close to class methods ;)

Those sentinel terminated arrays are a killer feature for C API interop, since you don't need to allocate separate C strings on the stack or heap just for passing string literals into the C API (Zig string literals are such sentinel-terminated arrays, so they are both slices and zero-terminated for C string compatibility). I really wish Rust would use the same idea, it would simplify creating C API wrappers a lot.

One of my favourite features of Zig is actually the arbitrary width integers, C23 is getting those too though.

...and in general Zig is fixing all the 'sloppy parts' of C, for instance it's very rigorous about not allowing implicit conversions which would lose data (e.g. trying to assign an u8 to an i8 is an error, u7 to i8 is allowed though, because no data would be lost).

PS: also how could I forget about the comptime features, this is for instance an area which is ignored by many other attempts of creating a better C, but one of the core features of Zig.

Re: Zig: The Modern Alternative to C

#24
post #19

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…

> No objects, just structs C doesn't have 'objects' either, just structs. In Zig you can add functions to structs though, and you have UFCS syntax sugar, both together is pretty close to class methods ;) Those sentinel terminated arrays are a killer feature for C API interop, since you don't need to allocate separate C strings on the stack or heap just for passing string literals into the C API (Zig string literals a…

I think one of the author's problems is that he conflates C and C++ and it seems they do not have a knowledge around either. This quote also supports this:

> There is no malloc keyword like in C/C++.

Re: Zig: The Modern Alternative to C

#25

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…

C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.

Re: Zig: The Modern Alternative to C

#26
Of all the new languages I find zig most interesting because it claims to not need build systems (not sure if I have that right?), it focuses on c library compatibility, and most importantly it aims to be a small language.

I’d like to love rust but it’s so big I just don’t have time to learn it all. It’s a pity rust is so damn big. Anyhow zig looks like a great alternative even if it lacks the safety of rust.

Re: Zig: The Modern Alternative to C

#27

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…

C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.

  > C-style for loops can almost always be replaced with iterators in a more concise manner.
Not if you want to optimise for performance.

A simple example: I search through a list of n items to find item m, iterators typically don't let you break out of the iteration.

Zig is the only contender I've seen where the for loop looks iterator-like, but also supports break/continue.

Re: Zig: The Modern Alternative to C

#28

Earlier quoted context omitted.

C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.

> C-style for loops can almost always be replaced with iterators in a more concise manner. Not if you want to optimise for performance. A simple example: I search through a list of n items to find item m, iterators typically don't let you break out of the iteration. Zig is the only contender I've seen where the for loop looks iterator-like, but also supports break/continue.

> A simple example: I search through a list of n items to find item m, iterators typically don't let you break out of the iteration.

That'd be a pretty crappy iterator implementation, short-circuiting is basically what iterators are all about (how else would you handle infinite iterators?). For example, in Rust, it's simply Iterator::find(): https://doc.rust-lang.org/std/iter/trait.Iterator.html#metho...

for loops in Rust are basically just syntax sugar for a while loop taking an element of the iterator each iteration, you can use break/continue as normal.

Re: Zig: The Modern Alternative to C

#29

Earlier quoted context omitted.

C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.

> C-style for loops can almost always be replaced with iterators in a more concise manner. Not if you want to optimise for performance. A simple example: I search through a list of n items to find item m, iterators typically don't let you break out of the iteration. Zig is the only contender I've seen where the for loop looks iterator-like, but also supports break/continue.

Some languages support early return(break) and labeled return (continue) in lambdas. Although good languages have lazy iterators or optimizing compilers. One would use iterator.takeWhile(x => x is not m) in your case, or filter, and skip in other cases. Better languages even allow you to yield return and write your own lazy iterator transformations.

Re: Zig: The Modern Alternative to C

#30

Of all the new languages I find zig most interesting because it claims to not need build systems (not sure if I have that right?), it focuses on c library compatibility, and most importantly it aims to be a small language. I’d like to love rust but it’s so big I just don’t have time to learn it all. It’s a pity rust is so damn big. Anyhow zig looks like a great alternative even if it lacks the safety of rust.

> because it claims to not need build systems

Zig has a build system, but it's integrated into the compiler and stdlib (e.g. there's usually a 'build.zig' file in the project root which is regular Zig code using 'build system' modules from stdlib, this build.zig is then transparently compiled and run to 'perform the build').

(it's interesting that nothing of this is so special to Zig that other compilers - even C compilers - couldn't use the same approach)

Post reply on HN