Live data from Hacker News

Zig: The Modern Alternative to C

infoworld.com

41–50 of 181 posts

Re: Zig: The Modern Alternative to C

#41
post #36

Earlier quoted context omitted.

No, it's 'code transform' async-await as is fashionable these days, but with the advantage that it's 'color blind' (the compiler will do the async transform or not based on the caller's expectation). See: https://kristoff.it/blog/zig-colorblind-async-await/

That's really cool. I'm wondering though how Zig handles massive concurrency? Is there some possibility to have greenthreading?

Unsure what "massive concurrency means". As far as I'm aware zig offers no special primitives for threading (other than tools in a standard library to start/stop threads and such). Async/await/suspend/resume are features used for concurrency (yielding on a single thread).

You then use those primitives to implement parallelism however you want. Just like you'd do in C. Or, ykno, someone makes a library that does green threads the way you want using those primitives.

Re: Zig: The Modern Alternative to C

#42
I think the official Zig website already does a good enough job at expressing what the the language has to offer, to the extent C devs can read a couple of pages and know whether or not they vibe with the language. The only thing it's missing is quoted praise from its users.

https://ziglang.org/learn/overview/

https://ziglang.org/learn/why_zig_rust_d_cpp/

Re: Zig: The Modern Alternative to C

#43

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.

Is there any language that won’t allow breaking out from an iteration? I can only imagine some FL language where the default loop construct would disallow that, but even there it is quite common to just return early syntactic sugar.

Re: Zig: The Modern Alternative to C

#44
post #7

After using zig for a few projects, it's amazing how it feels similar to C when coding.

The feeling to micromanage every details instead of focusing on the actual business logic?

Isn’t that the whole point of a low-level language? No sane person would be writing CRUD apps in Zig, the same way no one does it in C.

Your video card driver on the other hand doesn’t have too much “business logic”, but really cares about all those pesky details.

Re: Zig: The Modern Alternative to C

#45
post #39
post #13

Earlier quoted context omitted.

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 st…

I would be interested in hearing more about your point. TCL is an elegant scripting language, very LISP-y, where most data structures are lists of strings. Go on the other hand is more like a modern mix of C and Pascal with GC and lots of convenient libraries, and which builds statically. The performance of TCL and Go are also a world apart.

Go is a worse Java 1.1. The only remotely interesting part is virtual threads.

Re: Zig: The Modern Alternative to C

#46
Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.

Re: Zig: The Modern Alternative to C

#47

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.

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

I'm curious as to which language you worked with that didn't allow this.

Re: Zig: The Modern Alternative to C

#48
post #46

Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.

I'm waiting for the first fork that will do away with that "feature".

Re: Zig: The Modern Alternative to C

#49
"that could one day replace C"

I don't understand why would anybody say that, it's seems such a simple concept to me that nothing ever will replace C. Think about just the Linux kernel, nothing else. Nobody will and can rewrite every part of it that a C compiler will not be needed.

Re: Zig: The Modern Alternative to C

#50
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 really wish Rust would use the same idea, it would simplify creating C API wrappers a lot.

Zero terminated strings suck, you need to do allocation everywhere to work with them, or else you must in-place mutate the strings in hard to reason about ways and they can't fully represent arbitrary text. So I definitely wouldn't want Rust's &str string references to have either behaviour.

If what you do is interact closely with C wrappers, Rust of course provides a type for this: std::ffi::CString and that's fine, but it is a miserable structure to use for actual string work.

Post reply on HN