Live data from Hacker News

Hobby x86 kernel written with Zig

github.com

31–40 of 229 posts

Re: Hobby x86 kernel written with Zig

#31
post #11

Earlier quoted context omitted.

I found the module system for C interop, quite innovative and was surprised to see that Rust didn't even have such a thing. If you compare bindgen to this approach, bindgen just seems like double work and harder to maintain autogenerated bindings. I have seen both Zig and Swift use the module system very well despite several devs strangely saying its somewhat complicated, but when used for low-level development this…

I wrote a library for ffi (nifs) in elixir using zig, and a long term goal is for it to be easier to use zig as an intermediary for c library ffi than it is to use c. Already importing blas into elixir with it is crazy easy.

That sounds interesting. Do you have a link to a hex package or repo?

Re: Hobby x86 kernel written with Zig

#32
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 ?

Bouncing on recently featured HN thread "Hello World": https://drewdevault.com/2020/01/04/Slow.html (and the HN thread: https://news.ycombinator.com/item?id=21954886 ) According to this resource, Zig produces code that is very close to the hand written assembly for the simple use case of outputing "hello world" on the stdout. This is to be taken with a grain of salt though, as of course, caring about the assembly out…

For a language that _competes_ with C, caring about how semantics map to hardware instructions is absolutely within the domain of concern. It may not be a top priority, but if you _ignore_ it too long, you'll make uninformed high level decisions that prevent entire classes of important low level optimizations without extensive re-thinking. So just do the thinking upfront and save yourself and your community the hassle.

Re: Hobby x86 kernel written with Zig

#33
post #31

Earlier quoted context omitted.

I wrote a library for ffi (nifs) in elixir using zig, and a long term goal is for it to be easier to use zig as an intermediary for c library ffi than it is to use c. Already importing blas into elixir with it is crazy easy.

That sounds interesting. Do you have a link to a hex package or repo?

https://hexdocs.pm/zigler/Zigler.html

Re: Hobby x86 kernel written with Zig

#34
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 ?

Bouncing on recently featured HN thread "Hello World": https://drewdevault.com/2020/01/04/Slow.html (and the HN thread: https://news.ycombinator.com/item?id=21954886 ) According to this resource, Zig produces code that is very close to the hand written assembly for the simple use case of outputing "hello world" on the stdout. This is to be taken with a grain of salt though, as of course, caring about the assembly out…

Assembly output is important when you are trying to understand an exploit, or to make sure none can be produced.

Can be important for kernel stuff.

Re: Hobby x86 kernel written with Zig

#35
post #30

Earlier quoted context omitted.

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

Nim's GC is optional

Re: Hobby x86 kernel written with Zig

#36
post #30

Earlier quoted context omitted.

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

you're right, it is confusing, but it is optional: some toy kernels already work in nim , and with latest work on memory, you should be able to use most of the language for kernel development ! not the perfect language for that yet though, but i hope we should see more nim os examples

Re: Hobby x86 kernel written with Zig

#37
post #29
post #15

Earlier quoted context omitted.

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…

> I do think that using tabs for indentation simply doesn't work in practice

It has worked just fine for decades for projects with millions of lines of code.

It might not work for babby's first patch and how do I configure an IDE??

Re: Hobby x86 kernel written with Zig

#38
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…

On the other hand safe Rust code will be memory safe..

Re: Hobby x86 kernel written with Zig

#39

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…

Are you planning to write up a Tutorial about this?

Re: Hobby x86 kernel written with Zig

#40

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…

Author, if you decide to build more of this kernel any thoughts on providing live screencasts of the implementation like Andrew Kelly (Zig) and Andreas Kling (SerenityOS) on Youtube and/or Twitch. I never realized how effective it is for me to watch others go through the mental process of coding/debugging.
Post reply on HN