Hacker News Reader

Comment by drnick1 | Hacker News Reader

What's the point of doing this in "Zig" instead of C, the traditional choice for this kind of thing?

Because you can is a pretty traditional reason.

Zig is supposed to be an improvement upon C, so doing C things with it seems reasonable.

Kind of neat that there's no need for a separate assembly file although there is inline assembly. Might get better (or worse) syntax support for separate assembly files? But it doesn't make a big difference until there's more features that need it (interrupts, threads/processes and maintaining their stacks, syscalls, starting other processors, etc)

bitpacked structs, good enums, arbitrary sized integers, optionals + non-nullable pointers, fast compiler, zig fmt, unit testing, ability to use standard library and the rest of the third-party ecosystem on freestanding, std.ArrayList, std.AutoArrayHashMap, std.MultiArrayList, std.crypto, more productive type system, comptime, SIMD, slices, labeled switch continue, error handling, custom panic handler, stack traces on freestanding, error return traces, zero bit types, the build system, package management, aligned pointers, untagged union safety, multi-object for loops, inline switch cases, semantically guaranteed inline functions, inline loops

I guess one of good reasons is easy cross-compilation.

But also, I can see some amount of weird hooray optimism in this project, like: totally confusing claim that the thing is bare metal when it's still being run under an emulator; also, calling it a kernel is a huge overstatement

Because Zig is the future, Rust has clearly failed and C is simply obsolete in 2026. The rest doesn't even matter.

Zig is essentially a substantially improved and enhanced C, both in character and intent. There is a lot to recommend it for applications where you might otherwise use C.

Fun?

Not allowed.

In this case, better tooling and consistency. E.g. the small block of inline assembly would already be trouble for some C compilers.

because Zig is simply a better C, often faster (normally at least as fast), but with way more safety guarantees or at least things preventing the vast majority of traditional C footguns from happening

Zig is not faster than C.

Would you say its always slower, or always faster?

The optimization work happens in the LLVM backend, so in most cases (and using the same optimization and target settings - which is an important detail, because by default Zig uses more aggressive optimization options than Clang), similar Zig and C code translates to the exact same machine code (when using Clang to build the C code).

The same should be true for any compiled language sitting on top of LLVM btw, not just C vs Zig.

No. I will continue my crusade against blanket statements about performance.

Gee, good thing I didn't make a blanket statement and qualified it by saying "often", which is true, my contrarian dude. https://tigerbeetle.com wouldn't have chosen it unless they found it faster than C- and there's a significant quantity of money riding on that decision, so it likely wasn't done lightly at all.

The rest, you can google yourself, but in short, sorry to tell you that it is sometimes faster. Often, sometimes, some portion of the time.

No. It is a blanket statement that is never true. A programming language has no inherent speed. Your appeal to authority argument is rejected.

That's what I was getting at in my response. Once you add the qualifiers that were originally implied, its obvious that this is not an objective discussion to be had.

With default build settings it actually might be, because Zig's release mode builds with the equivalent of `-march=native` by default ;)

(disclaimer: not sure if that's actually still the case, last I checked in detail was probably 2 years ago).

Also Zig always builds the entire project as a single compilation unit, which allows more optimization options because the compiler sees all function bodies. The closest equivalent in the C world is LTO, but this is usually also not enabled by default.

What's the point writing another kernel in C ???

Considering that we are talking about experimental toys which have lower odds of seeing production than of you winning a national lottery jackpot, the point of writing it in C would be the same as the point of writing it in anything else - IOW, the kernel is the objective, not the language used to write it.

Yeah, but even if I'm doing something for fun I do want to be a bit unique with it. Anyone who's interested enough in osdev to build something for baremetal has at least attempted a unix-like kernel in C

If you read yourself you'll realize your answer i highly toxic, quiet honestly completely irrelevant, discouraging other people from doing what they like. I would get rid of people with your attitude, you are the kind of problem I don't want to have to deal with and more than that, I don't want to have juniors have to deal with you. Please realize that you had your chance and you played it. Nobody ow you an explanation if you can't even get basics up.

What in the sweet chili dipping sauce did I walk into?

drnick1 says why "Zig" not C? [I took the quotation marks as dismissive of Zig, but I could be misreading that]

6r17 says why do it in C?

lelanthran says the language is mostly irrelevant, it's a fun experiment.

6r17 blows off the handle and starts calling people toxic and being really unpleasant.

Nothing in this comment chain seems to justify even 1/10th of the vitriol espoused.

"Considering that we are talking about experimental toys which have lower odds of seeing production than of you winning a national lottery jackpot"

If you think that quote above is at all proportionate or justifies your toxicity, we have nothing else to discuss.

because zig is lower level than c

Reply on news.ycombinator.com