Live data from Hacker News

Hobby x86 kernel written with Zig

github.com

21–30 of 229 posts

Re: Hobby x86 kernel written with Zig

#21

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

Many of the features of new languages are their restrictions. How would you restrict C in a new version to e.g. remove null pointers in favor of optional types?

Re: Hobby x86 kernel written with Zig

#22
post #6

Earlier quoted context omitted.

> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?

> I'm asking out of curiosity because I want to learn a "system" programming language If you mean that you don't know any right now, just learn C. This isn't web programming, where everyone is always hopping to the latest fads. C is the lingua franca, the sine qua non of systems programming. It will be a long time before that changes. The C machine model is what everyone is working with anyway. C is small, despite so…

Thank you. I sure tried C too (also C++ for gui programming), though I wouldn't say I "know" it (which to me would imply at the very least one significant real-world experience with it), I do understand why some projects try to modernize "system" programming. I just want to evaluate alternatives, but I may very well go for C in the end...

Re: Hobby x86 kernel written with Zig

#23

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

A great feature I find with Rust not being superset of an unsafe language, is that the only option for you is to write safe code (unless you explicitly opt for `unsafe`).

Compare this to merely extending a language e.g adding smart pointers - you could always (mistakenly) implicitly fall back onto bad coding practices.

Re: Hobby x86 kernel written with Zig

#24
post #6

Hi, author here! I've just finished writing the pre-emptive multitasking [0](only round robbin though, nothing fancy). I'm currently writing an ATA driver [1], the idea is to implement ext2. I used to do this in Rust but I switched to zig for maintainability and readability over Rust. It seems that with `comptime` I'm able to make a lot of things optimal. Overall I have to say kernel programming is _hard_ but very re…

> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?

The Road to Zig explains the essence of the language:

https://youtu.be/Gv2I7qTux7g

C but with the problems fixed.

Re: Hobby x86 kernel written with Zig

#25

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

You could argue that it's what these languages do, the C heritage is very strong in every one of them.

The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?

C is ancient now, its type system and its many quirks are quite far from the state of the art or language design, a modern language wouldn't have to mess with the nonsense that are, for instance, C arrays (including C++ which can't outright remove them but does everything it can to render them obsolete with std::vector and std::array).

An other big problem with C interop for newer languages is that while C itself is relatively small and easy the C preprocessor isn't. That's usually where the friction is, because if you want to maintain compatibility with C macros you have to choice but to implement the language syntax wholesale.

Re: Hobby x86 kernel written with Zig

#26

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

Multiple attempts have been done to fixing C security issues, but the community at large tends to refuse to adopt them, so the only way forward is to create other languages for the same domain.

Note that Objective-C and C++ are extensions to the C language, and both started as pre-processors that would generate C code.

Also C wasn't the first on its domain, just got lucky that UNIX got widespread adoption and then found its way outside UNIX, just like JavaScript eventually found a way outside the browser.

Re: Hobby x86 kernel written with Zig

#27

Earlier quoted context omitted.

Zig is lower level than either (it's more like C than C++: expect to manually call 'free'on allocated values). It has a lot of nice improvments over C however, like proper arrays, no null, a module system, and proper compile time evaluation (no need for the hacky preprocessor).

May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?

Existing languages can't be meaningfully improved without breaking compatibility with all existing software. Python 3 is a better language in every way but it took many years before it saw significant adoption.

Re: Hobby x86 kernel written with Zig

#28
post #6

Hi, author here! I've just finished writing the pre-emptive multitasking [0](only round robbin though, nothing fancy). I'm currently writing an ATA driver [1], the idea is to implement ext2. I used to do this in Rust but I switched to zig for maintainability and readability over Rust. It seems that with `comptime` I'm able to make a lot of things optimal. Overall I have to say kernel programming is _hard_ but very re…

> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?

In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case:

* zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it handy, this is a case where native support vs library support means a world of difference.

* zig has native support for freestanding target. I used to have to build with Xargo for cross compiling to a custom target, I also was forced to `[nostd]`, and some features I was using forced me to use nightly Rust. In zig I have a simple `build.zig` and a simple `linker.ld` script, just works.

* zig has nicer pointer handling. A lot of kernel programming is stuff that Rust considers unsafe anyway. It's not uncommon to have to write lines like `unsafe { (ptr as const u8) }` to deref a pointer in Rust, which is a pain because this kind of thing happens all of the time. Also you have to play around with mut a lot like this: `unsafe { &mut (address as mut _)`. It just felt wrong a lot of the time, where in zig you have either `const` or `var` and that's the end of it.

* zig is really fun to write! this is something that comes up often in the community, after years of C it's just very refreshing.

Some things zig is missing:

* Package manager, this is coming soon. [1]

* Missing documentation for inline assembly (I think this part is going to get overhauled, as Andrew Kelley is writing an assembler in zig atm [2]).

I don't know Nim, but I believe it has a garbage collector so it could be tricky to use for kernel programming.

[0] https://github.com/jzck/kernel-rs

[1] https://github.com/ziglang/zig/issues/943

[2] https://www.youtube.com/watch?v=iWRrkuFCYXQ

Re: Hobby x86 kernel written with Zig

#29
post #15
post #9

Earlier quoted context omitted.

I'm curious too, I'm quite familiar with Rust and never written any Zig in my life so I went digging through the source and I find the syntax remarkably similar for the most part. The only thing that stood out is that apparently you can drop the braces for single-line `if` bodies like in C whereas Rust makes them always mandatory but I'm firmly on Rust's side on this one. The part where Rust can get really messy is w…

If you want more syntax weirdness: tab characters are illegal.

I don't mind opinionated coding style (my Rust integration scripts all enforce that stock "rust clippy" doesn't return any error) and I do think that using tabs for indentation simply doesn't work in practice regardless of how great they are in theory because hardly anybody uses them correctly (including the vast majority of code editors by default). It might be strange to back it straight into the compiler but I don't mind it.

That being said it does make it even weirder to allow braceless ifs IMO, but that's bikeshedding.

Re: Hobby x86 kernel written with Zig

#30
post #6

Earlier quoted context omitted.

> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?

In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case: * zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it…

Thank you.

> I don't know Nim, but I believe it has a garbage collector so it could be tricky to use for kernel programming.

You're right. Still good for libraries though (or apps, but that may be outside of "system").

Post reply on HN