Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hobby x86 kernel written with Zig

github.com

Post reply on HN
Print view View original

101–110 of 229 posts

Re: Hobby x86 kernel written with Zig

#101

Post by gw »

pron wrote: post #95
mratsim wrote: post #93

Earlier quoted context omitted.

I don't agree. For many domains, being able to implement a domain-specific language with a set of expressive rules for the domain is an incredible productivity boost and also prevents many mistakes because you cannot represent them. Not being able to manipulate the AST means that you are restricted on the embedded DSLs that you can provide. And embedded DSLs encompasses code generation for: - state machines - parsing…

The question is, as always, at what cost? Low-level languages (aka "systems programming" languages) already suffer from various constraints that increase their accidental complexity. Is it really necessary to complicate those particular languages further to support embedded DSLs? I don't think there's a universal right or wrong answer here, but there is certainly a big question.

Ironically, the lack of macros leads to an explosion of ad-hoc, extra-language DSLs. Look at rules engines, for example. In Drools (java), you have to write rules with a special language, DRL. Meanwhile in Clara (clojure) you write your rules in clojure. Macros simplify languages, they don't complicate them.

Re: Hobby x86 kernel written with Zig

#102

Post by pcwalton »

pron wrote: post #44
simias wrote: 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…

I wouldn't call Zig's comptime "C++-style." Unlike Rust, there's very little in Zig that is borrowed from C++. Zig's error reporting and comptime makes it easy to write arbitrary compile-time checks, so Zig uses a single construct and keyword, comptime, to replace all special instances of partial evaluation: generics, concepts/traits, value templates, macros and constexprs. The main difference between Zig and Rust is…

> There is also the difference in their approach to safety, but that's a complicated subject that ultimately boils down to an empirical question -- which approach is safer? -- which we don't have the requisite data to answer.

We do have the requisite data to answer whether preventing use-after-free is better than not preventing it.

You can argue (not successfully, in my opinion) that it's not worth the loss in productivity to prevent UAF and other memory safety issues, but it's impossible to argue that not trying to prevent UAF is somehow safer.

Re: Hobby x86 kernel written with Zig

#103

Post by pron »

gw wrote: post #97
pron wrote: post #86

Earlier quoted context omitted.

Well, it is intentionally weaker than macros (and I agree with Zig's designer that that's a very good thing, though it is a matter of taste), but it does replace many of the cases where in Rust you'd have to use macros (or the preprocessor in C/C++). So it replaces macros everywhere where it deems their usage reasonable.

It is a legit design choice, but it does detract from your comment about language complexity. Not having AST macros inherently adds complexity to a language by requiring features to be built into the compiler rather than be implemented as libraries.

Those are different kinds of complexity. You're talking about the effort required by the implementor of the compiler. I'm talking about the effort required by the programmer using the language.

Re: Hobby x86 kernel written with Zig

#104

Post by jackhalford »

anon767 wrote: post #39
jackhalford wrote: post #4

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?

I'm more on the reading end of tutorials right now. If I come up with something original that doesn't have an osdev page I'll contribute to the wiki.

Re: Hobby x86 kernel written with Zig

#105

Post by [deleted] »

jackhalford wrote: post #81
rehemiau wrote: post #5

Earlier quoted context omitted.

Looks awesome! Planning to do a similar thing in Jai once it comes out

I don't follow JAI but maybe Jonathan Blow should try zig, it's a great fit for game development and I remember him mentioning that he wants a language that is fun to write in.

[deleted]

Re: Hobby x86 kernel written with Zig

#106

Post by hippyhippo »

jackhalford wrote: post #81
rehemiau wrote: post #5

Earlier quoted context omitted.

Looks awesome! Planning to do a similar thing in Jai once it comes out

I don't follow JAI but maybe Jonathan Blow should try zig, it's a great fit for game development and I remember him mentioning that he wants a language that is fun to write in.

zig is following pretty much different path from jai afaik. zig prefers everything explicit and is very verbose whereas jai has many implicit things and also has macros or something similar. Anyways, more will be seen when it is released.

Re: Hobby x86 kernel written with Zig

#107

Post by gw »

pron wrote: post #103
gw wrote: post #97

Earlier quoted context omitted.

It is a legit design choice, but it does detract from your comment about language complexity. Not having AST macros inherently adds complexity to a language by requiring features to be built into the compiler rather than be implemented as libraries.

Those are different kinds of complexity. You're talking about the effort required by the implementor of the compiler. I'm talking about the effort required by the programmer using the language.

Then you aren't talking about complexity (an objective quality), you are talking about difficulty to read (a subjective quality relative to the reader). There is no doubt that macros can make a given piece of code harder to read, if the reader is unfamiliar with the macro being used. Complexity describes how intertwined different pieces of something are internally, which has nothing to do with a given vantage point.

Re: Hobby x86 kernel written with Zig

#108

Post by pron »

gw wrote: post #107
pron wrote: post #103

Earlier quoted context omitted.

Those are different kinds of complexity. You're talking about the effort required by the implementor of the compiler. I'm talking about the effort required by the programmer using the language.

Then you aren't talking about complexity (an objective quality), you are talking about difficulty to read (a subjective quality relative to the reader). There is no doubt that macros can make a given piece of code harder to read, if the reader is unfamiliar with the macro being used. Complexity describes how intertwined different pieces of something are internally, which has nothing to do with a given vantage point.

No, that's just how Rich Hickey describes complexity; it's hardly a universal definition. For example, in computer science, the complexity of a task is often a measure of the effort, in time or memory, required to perform it.

Re: Hobby x86 kernel written with Zig

#109

Post by Touche »

mratsim wrote: post #84
Touche wrote: post #46

Earlier quoted context omitted.

Are you saying that the GC is optional? If you don't use it how do you allocate/free memory?

You call malloc/free, or if working with GPU cudaMalloc/free. You can write your own memory pool or object pools, you can use destructors, and even implement your own reference counting scheme. This is what I use for my own multithreading runtime in Nim and the memory subsystem makes it faster and more robust than any runtime (including OpenMP and Intel TBB) that I've been benchmarking against, see memory subsystem d…

Does the standard library use malloc/free or does it depend on the GC? This is the part that's puzzling to me, if the stdlib depends on GC then it's harder to say that GC is optional. Technically optional but not super practical.

Re: Hobby x86 kernel written with Zig

#110

Post by pron »

pcwalton wrote: post #102
pron wrote: post #44

Earlier quoted context omitted.

I wouldn't call Zig's comptime "C++-style." Unlike Rust, there's very little in Zig that is borrowed from C++. Zig's error reporting and comptime makes it easy to write arbitrary compile-time checks, so Zig uses a single construct and keyword, comptime, to replace all special instances of partial evaluation: generics, concepts/traits, value templates, macros and constexprs. The main difference between Zig and Rust is…

> There is also the difference in their approach to safety, but that's a complicated subject that ultimately boils down to an empirical question -- which approach is safer? -- which we don't have the requisite data to answer. We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. You can argue (not successfully, in my opinion) that it's not worth the loss in produc…

> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it.

I expect Zig will prevent use-after-free. It will be sound for safe code and unsound for unsafe code (by turning this on only in debug mode for testing).

> but it's impossible to argue that not trying to prevent UAF is somehow safer.

First, see above. Second, it is not only possible but even reasonable to argue that not trying to completely eliminate a certain error is very much safer. The reason is that soundness has a non-trivial cost which can very often be traded for an unsound reduction in a larger class of bugs. As an example, instead of soundly eliminating bugs of kind A, reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer.

There has been little evidence to settle whether sound elimination of bugs results in more correctness than unsound reduction of bugs or vice-versa, and it's a subject of debate in software correctness research.

Post reply on HN