Hacker News new | ask | show | jobs
by kprotty 96 days ago
I've worked on two "production" zig codebases: tigerbeetle [0] and sig [1].

These larger zig projects will stick to a tagged release (which doesn't change), and upgrade to newly tagged releases, usually a few days or months after they come out. The upgrade itself takes like a week, depending on the amount of changes to be done. These projects also tend to not use other zig dependencies.

[0]: https://github.com/tigerbeetle/tigerbeetle/pulls?q=is%3Apr+a...

[1]: https://github.com/Syndica/sig/pulls?q=is%3Apr+author%3Akpro...

1 comments

I really wanted to deep dive into zig but I'm into rust now kinda late as I'm really just started like 2024.

Have you tried rust? how does it compared to zig?

* just asking

Two different philosophical approaches with Zig and Rust.

- Zig: Let's have a simple language with as few footguns as possible and make good code easy to write. However we value explicitness and allow the developer to do anything they need to do. C interoperability is a primary feature that is always available. We have run time checks for as many areas of undetermined behaviour as we can.

- Rust: let's make the compiler the guardian of what is safe to do. Unless the developer hits the escape hatch, we will disallow behaviour to keep the developer safe. To allow the compiler to reason about safety we will have an intricate type system which will contain concepts like lifetimes and data mobility. This will get complex sometimes so we will have a macro system to hide that complexity.

Zig is a lot simpler than Rust, but I think it asks more of it's developer.

> However we value explicitness and allow the developer to do anything they need to do*

* except for having unused variables. Those are so dangerous the compiler will refuse the code every time.

They are indeed dangerous, and I think this is a pretty good example of why.

https://andrewkelley.me/post/openzfs-bug-ported-zig.html

don't know if it's still on the table, but Andrew has hinted that the unused variables error may in the future still produce an executable artefact but return an nonzero return code for the compiler. And truly fatal errors would STILL produce an executable artefact too, just one that prints "sorry this compilation had a fatal error" to stdout.
It’s hard to say that one needs unused variables.
If I comment out sections of code while debugging or iterating I don't want a compile error for some unused variable or argument. Warning. fine, but this happens to me so frequently that the idea of unused variables being an error is insane to me.
It is insane and you are completely right. This has been a part of programming for over 50 years. Unfortunately you aren't going to get anywhere with zig zealots, they just get mad when confronted with things like this that have no justification, but they don't want to admit it's a mistake.
Same for kernel drivers
Rust is a Bugatti Veyron, Zig is a McLaren F1.
as few footguns as possible

There are no destructors so all the memory ownership footguns are still there.

sure, but when I've written zig this has never been an issue for me. `defer` makes memory management really easy.

If you want to auto-generate destructors, zig has really good comptime features that can let you do that.

defer is still something you have to consciously put in every time so it destroys the value semantics that C++ has, which is the important part. You don't have to "just write defer after a string", you can just use a string.

The 'not a problem for me' is what people would say about manual memory in C too. Defer is better but it isn't as good as what is already in use.

That's disingenous, Rust tries to minimize errors, first at compile time then at runtime, even if it at some discomfort of to programer.

Zig goes for simplicity while removing a few footguns. It's more oriented towards programmer enjoyment. Keep in mind that programmers don't distinguish ease of writing code from ease of writing unforeseen errors.

Yes, I've written a few unsafe-focused crates [0], some of which have been modified & merged into the stdlib [1] [2] exposing them to the fringe edge-cases of Rust like strict provenance.

IMO, Rust is good for modeling static constraints - ideal when there's multiple teams of varying skill trying to work on the same codebase, as the contracts for components are a lot clearer. Zig is good for expressing system-level constructs efficiently: doing stuff like self-referential/intrusive data structures, cross-platform simd, and memory transformations is a lot easier in Zig than Rust.

Personally, I like Zig more.

[0] https://crates.io/users/kprotty

[1] https://github.com/rust-lang/rust/pull/95801

[2] https://github.com/rust-lang/rust/blob/a63150b9cb14896fc22f9...

Zig is a modern C,

Rust is a modern C++/OCaml

So if you enjoy C++, Rust is for you. If you enjoy C and wish it was more verbose and more modern, try Zig.

As someone who never liked writing anything C++ since 2000+ (did like it before) I cannot agree with this. C++ and Rust are not comparable in this sense at all.

One can argue Rust is what C++ wanted to be maybe. But C++ as it is now is anything but clean and clear.

See my other comment[1]

It replaces C++ for me, so I would say it's "a C++"

[1]: https://news.ycombinator.com/item?id=47334275

And in a world of only you your claim is true.
I think the comparison is fair, strictly in the sense that both Rust and C++ are designed around extensible programming via a sort of subtyping (C++ classes, Rust traits), and similar resource management patterns (ownership, RAII), where Zig and C do not have anything comparable.
My take, unfortunately, is that Zig might be a more modern C but that gives us little we don’t already have.

Rust gives us memory safety by default and some awesome ML-ish type system features among other things, which are things we didn’t already have. Memory safety and almost totally automatic memory management with no runtime are big things too.

Go, meanwhile, is like a cleaner more modern Java with less baggage. You might also compare it to Python, but compiled.

Zig gives things we really dont have yet: C + generics + good const eval + good build system + easy cross compilation + modern niceties (optionals, errors, sum types, slices, vectors, arbitrary bit packing, expression freedom).

Are there any other languages that provide this? Would genuinely consider the switch for some stuff if so.

+1 The zig toolchain is the state of the art currently.
It is kind of interesting that the Linux kernel is slowly adopting Rust, whereas Zig seems like it would be a more natural fit?

I know, timelines not matching up, etc.

Definitely not. Rust gives you a tangible benefit in terms of correctness. It's such a valuable benefit that it outweighs the burden of incorporating a new language in the kernel, with all that comes with it.

Zig offers no such thing. It would be a like-for-like replacement of an unsafe old language with an unsafe new one. May even be a better language, but that's not enough reason to overcome the burden.

actually that's not true at all. Zig offers you some more safety than C. And it also affords you a compiler architecture and stdlib that is so well designed you could probably bolt on memory safety relatively easily as a 3rd party static checker

https://github.com/ityonemo/clr

"More safety than C" is an incredibly low bar. These are hygiene features, which is great, but Rust offers a paradigm shift. It's an entirely different ballpark.
Memory safety by default in kernel sounds like a good idea :). However I don't think that C is being _replaced_ by Rust code, it's rather that more independent parts that don't need to deeply integrate with the existing C constructs can be written in a memory safe language, and IMO that's a fine tradeoff
I believe Rust is mainly being used for driver development, which seems a great fit (there's so many people of different skill levels who write Linux drivers, so this should help avoid bad driver code being exploited). It may also end up in the core systems, but it also might not fit there as well.
And “if you enjoy C++/if you enjoy C” are gross oversimplifications.
It is not about timelines. Linux Torvalds doesn't spend nights reading bunch of books with crabs on their covers rewriting random bits and pieces of the kernel in Rust. It is basically a dedicated group of people sponsored by megacorps doing the heavy lifting. If megacorps wanted Zig we could have had it in the kernel instead (Linux might have rejected it though, not sure what he thinks of it).
And Zig isn't stable yet
Comparing Rust to C++ feels strange to me.

It’s like people do it just because Zig is very comparable to C. So the more complex Rust must be like something else that is also complex, right? And C++ is complex, so…

But that is a bit nonsensical. Rust isn’t very close to C++ at all.

I wrote lots of C++ before learning Rust, and I enjoyed it. Since learning Rust, I write no more C++. I found no place in which C++ is a better fit than Rust, and so it's my "new C++".

For example, high performance servers (voltlane.net), programming languages (https://github.com/HF-Foundation, https://github.com/lionkor/mcl-rs, and one private one), webservers (beampaint.com) and lots of other domains.

Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

> found no place in which C++ is a better fit than Rust, and so it's my "new C++".

Writing the compiler toolchains that Rust depends on, industry standards like CUDA, SYSCL, Metal, Unreal or the VFX Reference Platform.

There are places a language could be a better fit, but which haven't adopted it. E.g. most languages over typescript on the backend, most systems programming languages over Java for games.
Rust uses LLVM because it's pretty great, not because you couldn't implement LLVM in Rust.

Maybe cranelift will eventually surpass LLVM, but there isn't currently much reason to push for that.

> Rust is close to C++ in that it is a systems language that allows a reasonable level of zero-cost abstractions.

That's like saying php is close to haskell because they both have garbage collection.

I found swift way more enjoyable than rust as a C++ alternative. It even has first class-ish interop now.
Seriously asking, where Go sits in this categorization?
Nowhere, or wherever C# would sit. Go is a high level managed language.
Go is modern Java, at least based on the main area of usage: server infrastructure and backend services.
Tbh Go is also really nice for various local tools where you don’t want something as complex as C++ but also don’t want to depend on the full C# runtime (or large bundles when self-contained), or the same with Java.

With Wails it’s also a low friction way to build desktop software (using the heretical web tech that people often reach for, even for this use case), though there are a few GUI frameworks as well.

Either way, self contained executables that are easy to make and during development give you a rich standard library and not too hard of a language to use go a long way!

Go is modern/faster Python.

- It was explicitly intended to "feel dynamically-typed"

- Tries to live by the zen of Python (more than Python itself!)

- Was built during the time it was fashionable to use Python for the kinds of systems it was designed for, with Google thinking at the time that they would benefit from moving their C++ systems to that model if they could avoid incurring the performance problems associated with Python. Guido Van Rossum was also employed at Google during this time. They were invested in that sort of direction.

- Often reads just like Python (when one hasn't gone deep down the rabbit hole of all the crazy Python features)

i wonder what makes go more modern than java, in terms of features.
The tooling and dependency management probably
It's also a modern C.

If you enjoy C and wish it was less verbose and more modern, try Go.

Go has a garbage collector though. This makes it unsuitable for many use cases where you could have used C or C++ in the past. Rust and Zig don't have a GC, so they are able to fill this role.

GC is a showstopper for my day job (hard realtime industrial machine control/robotics), but would also be unwanted for other use cases where worst case latency is important, such as realtime audio/video processing, games (where you don't want stutter, remember Minecraft in Java?), servers where tail latency matters a lot, etc.

> GC is a showstopper for my day job (hard realtime industrial machine control/robotics)

Which is a very niche use case to begin with, isn't it? It doesn't really contradict what the parent comment stated about Go feeling like modern C (with a boehm gc included if you will). We're using it this way and it feels just fine. I'd be happy to see parts of our C codebase rewritten in Go, but since that code is security sensitive and has already been through a number of security reviews there's little motivation to do so.

Thanks. I write some Go, and feel the same about it. I really enjoy it actually.

Maybe I'll jump to Zig as a side-gig (ha, it rhymes), but I still can't motivate myself to play with Rust. I'm happy with C++ on that regard.

Maybe gccrs will change that, IDK, yet.

Go is a language which sits perfectly where using garbage collection is no problem with ya.
C++ added OOP to C.

Rust is not object-oriented.

That makes your statement wrong.

It certainly is according to the various CS definitions of type systems.

Plenty of OOP architectures can be implemented 1:1 in Rust type system.

> Plenty of OOP architectures can be implemented 1:1

Plenty of OOP architecture can be implemented in C. That's an extremely flawed and fuzzy definition. But we've been through this before.

Yet people have to keep be reminded of it.
Yes, of course you can call objc_msgSend or equivalent in Rust just as you can in C. But you are pushing the object-oriented model into a library. It is not native to the language.
I am talking about Rust OOP language features for polymorphism, dynamic and static dispatch, encapsulation, interfaces.

Which allowed me to port 1:1 the Raytracing Weekend tutorial from the original OOP design in C++ to Rust.

Also the OOP model used by COM and WinRT ABIs, that Microsoft makes heavy use of in their Rust integration across various Windows and Office components.

Objective-C added OOP to C. C++ did not. C++ is neither an OO language nor a C superset.
If you make up your own definitions things can be anything you want and have or not have any label.
Absolutely. That's why it is best to stick to the already established definitions. Kay was quite explicit about what "object-oriented" meant when the term was uttered for the first time; including specifically calling out C++ as not being object-oriented.

And yes, we all know the rest of the story about how the C++ guys were butthurt by that callout and have been on a mission to make up their own pet definition that allows C++ to become "object-oriented" ever since. I mean, who wouldn't want to latch onto a term that was about the unique features of a failed programming language that never went anywhere?

Zig is Modula-2/Object Pascal re-packaged with a C like syntax.
Time to start zig++
Zig is what you want to write, because it gets out of the way.

Rust is what you want your colleagues to write, to enforce good practices and minimise bugs. It's also what I want my past self to have written, because that guy is always doing things that make my present life harder.

I'd rather my colleagues (and past self) write Rocq.

Rust is what you use when you'd rather spend time doing sales and marketing for Rust than building software.

zig really makes it unappealing to architecture astronaut, and rust pushes you towards it. id rather my colleagues write zig