Using Zig to Provide Stack Traces on Kernel Panic for a Bare Bones OS
andrewkelley.me
andrewkelley.me
I'm really looking forward to tinkering around in Zig, for my next hobby project(s).
P.S. In fact, I'm going to 'put my money where my mouth is' and contribute via Patreon[1]. Zig is incredibly high quality and well-designed, despite being achieved from the spare time of so few; it deserves better funding.
Zig Programming Language Blurs the Line Between Compile-Time and Run-Time
https://andrewkelley.me/post/zig-programming-language-blurs-...
Now that I think of it, I wonder if Go could take the approach of Zig for generics, or at least for containers.
Look at how they express List(i32) there. It seems like a much more Go-like approach than say what Swift or Rust do for containers and generics. Like Go, Zig seems to have no classes, only functions and structs.
It does seem like many newer languages have complicated type systems and long compile times. I think Zig has an interesting alternative approach, although I would have to use it more to really make an judgement.
Note that Haskell and Rust (and other languages) have adhoc polymorphism _with_ type system support via type classes/traits. I would class this more as 'duck-typed templates'.
> or binary bloat.
This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not. I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site.
Or parametrically polymorphic type variables!
> This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not.
I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It is still technically possible to deduplicate similar enough functions, either at the source level or at the binary level, but that is orthogonal to this issue :-)
> I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site.
You are right for the status quo of C++ templates, but I'm not sure for general cases. It might be possible to keep error information down to the instantiation site for better error messages... or not.
Regarding this bloat thing, are monomorphized functions ever generated for types/signatures that are not actually _used_ in the program?
If not, it's not really bloat, is it? It's what one would do themselves without generics, if they wanted to be able to use them with full speed.
Right, but in many cases they can be combined without much speed penalty. For example you can combine monomorphized functions when you only rely on methods that are expected to be costly and inlining has a negligible effect. With actual, not ad hoc, generics you may (hopefully) have a control over monomorphization---I think Rust's trait object is a good design for this reason.
It's not mandatory for ad-hoc polymorphism. Haskell desugars ah-hoc polymorphism to dictionary passing (although it often does inlining to reduce the overhead of this).
It's still missing linear/affine types, no? To me that's inexcusable given the current offering.
Zig certainly has some cool ideas - I definitely think that we should be making the phase distinction more flexible. I do wish however that its compile time function evaluation was built on a firmer foundation, ie. using dependent types.
Also depending on how you define "dependent types" - there are a few competing definitions - Zig has them.
Although there are differing ways to define dependent types, and they come in different varieties (dependent functions, dependent pairs/structs, very dependent types, dependent intersections, inductive types), they are all founded on a foundation of type theory. I guess if you want me to clarify, it is 'dependent types based on a well understood foundation from type theory'.
---
Edit: seems like Zig does have optional types! That is a good thing! https://ziglang.org/documentation/master/#Optionals
How is it ambiguous? Dependent type systems/algorithms can be weaker than desired, but there's no way you can say Zig has dependent types.
For example you can do:
const std = @import("std");
fn Int(comptime value: i32) type {
return struct {
pub fn value() i32 {
return value;
}
};
}
pub fn main() anyerror!void {
const int3 = Int(3);
const int4 = Int(4);
std.debug.warn("Types: {} {}\n", @typeName(int3), @typeName(int4));
std.debug.warn("Sum: {}\n", int3.value() + int4.value());
}
Types: Int(3) Int(4)
Sum: 7
[2] https://godbolt.org/z/eLWeU2
[1] https://ziglang.org/documentation/master/#Generic-Data-Struc...
I don't have a problem with GC so Nim/D are on the table. ATS is a pain in the ass but after the arrival of Rust it's pretty clear that linear/affine types can be user-friendly. There's no excuse any more.
http://smallcultfollowing.com/babysteps/blog/2018/11/01/afte...
http://smallcultfollowing.com/babysteps/blog/2018/11/10/afte...
So while Rust is much more productive than ATS or Cyclone, there is still room of improvement for that experience.
So D, Nim, C# (AOT compiled), Java (Embedded/Android Things/MicroEJ), Swift, Go are pretty much on the table as well.
Could you clarify the ambiguity you see, and how Zig has them?
It's "linear/affine types," not "linear affine types".
Also: Zig doesn't have linear or affine types. You seem to be quite confused about PL theory, which frankly does not make me any more confident in the language.
Or, the other one: lack of affine/linear types is "inexcusable", really?
As if these are so mainstream that any new language should have them? It's a new language, still in development, use it or not. Zig doesn't want to be a dumpster for trendy PL concepts. It has been designed to be a safer and friendlier C, not a simpler Haskell or Agda.
Current offering being of course Rust.
Rust isn't a "simpler Agda" either. It is a safer C/C++ – as in bare metal capable, no GC, natively compiled… and affine types is what makes the safety possible.
Calling Rust a "simpler Agda" is a bit insane. Rust simply has a sensible, current type system. Agda is full dependent types.
Exactly why the project is pointless. It doesn't offer enough beyond C for there to exist any incentive to switch. I would add that affine types are not simply a "trendy PL concept" given that Rust has used them to great effect.
In one word zig is "joy". I forget that I am actually writing a compiled language. It feels almost like python. Everything just snapped into place for me.
I encourage everyone interested to give it a try, especially if you prefer C over languages with a strong paradigm. It is very easy to pick up zig. Read the short manual, check some samples or the "std" library and you can be immediately productive.
C interop is amazing. comptime is a sample of how it should work in other languages. syntax is clean and simple. no headers, good error strategies, a (rather) helpful compiler, build system included etc.
The only downside is now it feels heavy to go back to work and hammer on C++ ...
I see now that binaries are available (maybe they always were?)--maybe it's time to put Zig to the test on these toy problems.
Here some more details: