
Using Zig to Provide Stack Traces on Kernel Panic for a Bare Bones OS - andreaorru
https://andrewkelley.me/post/zig-stack-traces-kernel-panic-bare-bones-os.html
======
electrograv
The more I see of the Zig language, the more I grow to appreciate its
beautiful design! Such a perfect blend (IMO; obviously personal preference
will vary) of modern language features that encourage inherent reliability and
safety of code, with low-level systems programming -- all without the language
becoming too complicated or difficult to code productively in.

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.

[1] [https://www.patreon.com/andrewrk](https://www.patreon.com/andrewrk)

~~~
vmchale
> modern language features that encourage inherent reliability and safety of
> code

It's still missing linear/affine types, no? To me that's inexcusable given the
current offering.

~~~
bjz_
I wouldn't say it's inexcusable, but I'm definitely trying to avoid any
systems language that has implicit null, and allows for data races and de-
referencing uninitialized memory from safe code. So that only really leaves
ATS and Rust, and rules out Nim, D, Zig, Jai... (for me at least).

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.

~~~
AndyKelley
Please don't spread misinformation. Zig does not have implicit null.

Also depending on how you define "dependent types" \- there are a few
competing definitions - Zig has them.

~~~
vmchale
> Also depending on how you define "dependent types" \- there are a few
> competing definitions - Zig has them.

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.

~~~
stateoff
I think Andy refers to this [1].

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());
      }
    

Output being:

    
    
      Types: Int(3) Int(4)
      Sum: 7
    

Edit: The compiler does the right thing:

[2] [https://godbolt.org/z/eLWeU2](https://godbolt.org/z/eLWeU2)

[1] [https://ziglang.org/documentation/master/#Generic-Data-
Struc...](https://ziglang.org/documentation/master/#Generic-Data-Structures)

------
wycy
I _really_ like the look of Zig syntax so far. I had wanted to use this year's
Advent of Code contest as an opportunity to learn some Zig, but I had trouble
getting the compiler compiled and working.

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.

------
ENTP
Does anyone know the pros/cons of zig vs nim?

~~~
DblPlusUngood
Well, for one thing, zig apparently has no built-in memory allocator?

~~~
AnIdiotOnTheNet
Kinda, Zig has a small selection of allocators in the standard library, but it
would be true to say that it has no "default" allocator. Idiomatic Zig code
that requires allocation accepts the allocator interface as a parameter, so
that the programmer is free to choose whatever implementation suits their
needs.

~~~
stateoff
Worth mentioning that one allocator in the std-library is wrapping malloc.

Here some more details:

[1]
[https://www.youtube.com/watch?v=WLJ_7lpBhys](https://www.youtube.com/watch?v=WLJ_7lpBhys)

~~~
ENTP
Thanks all

