Hacker News Reader

To add to what you're saying, Zig (and only Zig) is a plausible contender for replacing C, exactly because consuming a Zig .o file from C is roughly as simple as consuming a C .o from Zig.

So if you have a C program, and you want to dip your toes in Zig-land by writing the next library in Zig, you just can. If you chose Rust instead, you're going to have a bad time.

> If you chose Rust instead, you're going to have a bad time.

Naw.

    /* main.c */
    #include <stdio.h>
    #include <stdint.h>
    uint8_t answer();
    int main(int argc, char** argv) {
        printf("%d\n", answer());
        return 0;
    }

    // example.rs
    #[no_mangle] extern "C" fn answer() -> u8 {
        println!("The answer is:");
        42
    }

    # test.sh
    rustc --crate-type staticlib -o example.a example.rs
    gcc main.c example.a -lpthread -ldl
    ./a.out

    $ ./test.sh
    The answer is:
    42

Workflows using `cargo` instead of `rustc` are also sane and easy.

    #[no_mangle] extern "C"

All due respect to Rust, which is a fantastic language, what this line says is "here is a C function written in Rust".

You can of course do the same thing with C++ and with D, allowing all three to check the box for interoperability. And with Rust you get everything Rust offers: so you can write in the `extern "C"` dialect while getting memory-safety guarantees within the library, that's not nothing.

What Zig offers is the ability to write ordinary Zig and call that from C. That's part of what it's designed to do.

This is interoperability by design, rather than by configuration. It's simply a different thing, and considered along this singular dimension, I would assert that it's better.

I didn't, and wouldn't, say that Zig has the potential to replace Rust. I said that about C, and explained why.

> What Zig offers is the ability to write ordinary Zig and call that from C.

You say that, but Zig appears to suffer from the exact same problem you point out in my Rust code:

    export

https://ziglang.org/documentation/master/#Exporting-a-C-Libr...

Perhaps I'm mistaken. How do I directly call Zig's `std.debug.print` from C? Or Timestamp.unixEpoch as defined here? https://ziglang.org/documentation/0.7.1/#Doc-comments

There's a bunch of rust crates containing macros, binaries, and build scripts that cut down on Rust's boilerplate as well. While there are some rough edges and room for further improvement, I am far happier with Rust's C interop than I am with the C interop of most other languages. Zig might have a touch more polish, but the bit I originally quoted made Rust sound like it was a good order of magnitude worse than Zig at C interop, which I just can't agree with.

One of the very first things I did when learning Rust was write a test library and drop it into an existing C++ codebase. I've also experimented heavily with cross compiling it to pretty much anything I can get my hands on. It was a good time, not a bad one.

I found it very difficult to deal with C macros, though. That said, I have no idea how zig deals with that problem either.

Zig can handle C macros, you can see this if you use the zig translate-c option on the CLI which will convert any C code to Zig. This does make it the most usable C ffi I have used, as it means it really works with even difficult C code.

This seems like unsolvable problem - if you'd want to allow calling C macros from your new language, you would have to be C superset. So no memory/thread/... safety, weird syntax inherited from C, ...

This was one of the most redeeming things about Objective-C. It is a superset of C, and when I was working with it, I found myself writing the high-level stuff in ObjC, but with a lot of pure-C functions sprinkled in. It was really nice for working with C libraries like OpenGL, because you could find an example online and directly apply it without going through any kind of translation step. It was a really cool feature to have.

I share a similar experience with C++.

However that compatibility is also what makes Objective-C and C++ impossible to ever be fully safe, without breaking compatibility with the C subset.

Static analysis help, but only when all code is available.

It isn’t so black and white.

Nim, if you let it use C as a backend, will let you use C macros, despite being generally safe and not remotely a C superset.

Yes, the use of C macros (and any kind of ffi) is unsafe, that cannot be avoided. But it doesn’t need to be a c superset (and indeed, when you use JS as a backend, or the native LLVM backend, you get no access to C macros)

It's probably impossible in general, but you could probably deal with a bunch of common cases fairly easily (like constants)

Learning how to write memory safe code in Rust is a challenge at first, but it buys you access to an ecosystem of transitive dependencies that are (mostly) efficiently implemented and interconnected through memory safe API's. That advantage remains even if you have you have to manually define an unsafe C API for the rust code you added to your codebase.

The same is true for C++, Rust, etc.

Obviously, you can’t expect people that didn’t managed to learn these languages to know that.

But if that’s your killer Zig feature, lots of languages have it.

Maybe C "disappears" while coding, but I'd much rather it stuck around to help me out. When writing C, I have to carefully make sure that each resource has been freed/closed (but not too soon!), that I'm not mutating or holding onto anything I'm not meant to, that I've accounted for every exception that I can result from a given call, and so on. Can Zig handle some of that bookkeeping for me?

"I have to carefully make sure that each resource has been freed/closed (but not too soon!)"

You can use defer keyword to free right after allocating and it won't be called until the function/program completes. You can use debug or testing allocators to ensure no memory is left unfree'd or double free'd. The std lib has a large selection of custom allocators that you can use depending on your needs. One great one is an "Arena Allocator" which is just a linked-list of allocations that can be free'd at one time, versus tracking all these individual allocations. And if none of these allocators fit your needs, the interface to define one is pretty easy to implement. https://ziglang.org/documentation/0.7.1/#Choosing-an-Allocat...

"I'm not mutating or holding onto anything I'm not meant to"

Not really sure Zig can help you with this one. With great power comes great responsibility, or something like that.

"that I've accounted for every exception that I can result from a given call"

Zig does not have exceptions, but it does have error types which functions can return. From the function definition you usually can determine all the errors that can possibly be returned, unless the function definer use'd the catch all ! error type. Regardless, it is still much better than regular exceptions because

- you know by the function def that an error could be thrown, the compiler forces the caller to account for a possible error by "unwrapping" the return value

- an error happening just passes back a different type to the caller and in combination with the above, you can never "miss" an error https://ziglang.org/documentation/0.7.1/#Errors

Also Zig switch statements without an else ensure you handle every possible value so if you forget to handle one possible error (based on the type), it will throw a compile error. https://ziglang.org/documentation/0.7.1/#toc-Exhaustive-Swit...

The compiler infers the errors in an error set even if you don't declare it explicitly (e.g. when returning `!void`). This means that you can use a switch statement to have the compiler tell you what cases it contains.

There's also ZLS, a language server implementation for Zig that I believe can help with that (or if not today, it will in the future).

Cool trick, I did not know this, but it makes sense.

couple of weeks (days ?) back there was a post here which described the new defer mechanism (possible source of reference: https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-f...)

this can do that quite easily afaik.

Rust is a lot easier than C++, although there is an initial slightly steeper learning curve.

It's hard, coming from C because C is a small language with not many keywords. As a hobby programmer I did not know about generics and such and the differences between pointers and references.

Learning Rust kind of feels like brute-forcing my brain until it sticks. But I can't say it isn't fun and exciting!

Rust has a steeper learning curve initially but when you're over the hump you don't see mountains in the distance like you do in C++ :)

And I feel like, while Rust also has you puzzle-solve a little and jump through hoops initially, you quickly start to appreciate all the safety that gains you. And I value that a LOT. Though I have to say, Zig looks awesome. Both Rust and Zig get me really excited to code more after getting frustrated with god-awful python codebases.

I'm about to start a little fun project where it would be nice to be able to interact with C++ object files.

I was planning on using Nim but might give Zig a try also.

It looks really cool. I feel like Nim and Zig both fill a similar niche, maybe Zig aiming more towards the lower level / even embedded.

That's just my impression, not having used either in anger.

I agree on the C++ puzzle solving thing, though in a way it's almost part of the appeal!

As a Nim user, I think Nim and Zig fill quite different niches. Zig is made specifically for low-level programming with some higher-level constructs, whereas Nim is very general-purpose.

What are the flaws/weak points of Zig?

while zig's error handling is almost perfect, it's missing a way to return context w/ the error (https://github.com/ziglang/zig/issues/2647)

while the debug allocator can tell you at runtime about use-after-free or memory leaks, that's a less strong guarantee than rust or a GCed language

there are no closures; in general the code you write is lower-level than code in python, c#, rust

the language is very new

--opinions of a zig dilettante

bonus observations:

the std library code is very readable

the language overall has an excellent philosophy & design approach, and i predict it will become extremely popular

(as a single point of comparison: even after puzzling over it for a while, i still don't understand how modules work in rust; the equivalent feature in zig is immediately obvious, and in fact is the same concept as structs. how cool is that? (very cool, imo.))

> the std library code is very readable

I think that's very important feature to have for some people like me. I love Java standard library, because it's really easy to read. I regularly read its source code when I need to understand something and it's amazing how much time that could save. The only nitpick when it comes to Java is that some low-level stuff implemented in C and it's not as straightforward to jump into C implementation.

And that what turns me off from Scala and from C++. Scala collections library is horrible to read. It's immensely complicated. I get that they're solving hard problem, but I don't like it. And I hate C++ STL code (at least those that I saw), they're using obscure __identifiers__ and so on (may be there are better implementations, I saw GCC and MSVC ones).

Standard library is how language is supposed to be used. Those who learn language can just read its sources to better understand language idioms and replicate those in their code. And there's a huge difference between languages with readable standard library and languages with unreadable standard library (or even without sources at all, Apple sucks).

They use those "obscure __identifiers__" because they are reserved by the standard and thus a conforming program will not define macros with those values and break everything.

IMO a better approach would to define some way for compiler to undo all defines before standard header is included and redo those defines afterwards. Or just to stipulate that standard headers must be included before other user code.

With modules, "hiding" code like that will be possible in C++.

If only we could skip forward a decade and get mature implementations of it right now...

> I get that they're solving hard problem, but I don't like it.

this is why the world is such a sad place

Currently: initialization of multi-dimensional arrays, and partial initialization of arrays, this whole area isn't as convenient as C (yet, I hope).

Also, currently it's possible to return a pointer/slice to a stack-allocated array from a function without a warning or error resulting in a dangling pointer. But this too will hopefully be fixed (because even C compilers warn about this these days).

But I think all those points can be considered bugs / todos.

I love Zig. Occasionally I wish it had interfaces because that’s how my brain designs software components. You currently achieve the same runtime characteristics of interfaces by using a function property on a struct.

It’s a great language though and a ton of fun. It’s so easy to dive into a codebase quickly which I value as a very distracted dad. The standard lib is a joy to read too.

Can you explain what you mean when use the term interfaces? I’m just curious as to what your describing. Also, do you mean use a function property on a struct in Zig specifically to capture the operation of such an interface?

I assume interfaces refers to runtime polymorphism.

The ones I've seen are not Zig-specific, but rather attendant to any language in early stages: a small development team, very limited tooling. (To be fair though, the dev team has done an amazing job banging out good code.)

search for "design flaw" on the issue tracker

I was half expecting to find some kind of rickroll-esque joke, but there is actually a lot of really interesting discussion tucked away in that search¹. I find the open and frank discussion of problem choices to be very refreshing.

¹ https://github.com/ziglang/zig/search?q=design+flaw&type=iss...

Unlike Rust, Zig does not provide memory safety.

They have runtime checks (unlike Rust compile checks) which are at least slower, but likely still don't guarantee memory safety (did not dig deep).

If this is a language for people that didn’t managed to learn C++, D or Rust... lots of questions quite unfavorable for Zig pop up. I’d just remove that sentence.

even if the language is great, if all the ecosystem is written by people that didn’t manage to learn C++ in 25 years, I can’t really trust any library there

It’s it a running (almost) joke that nobody actually knows C++? I have not met anybody that work with the whole language and not only a subset.

Just like I bet most will fail a pub quiz using C17, C# 9, Java 15, F# 5, VB 16, Python 3.9 as base input for the question pool.