6 ms·

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 m

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

chubot 8y ago
Yeah I like a lot of what I see. The compile-time metaprogramming looks nice and it would be good if I had a project to try it out for :) Zig Programming Language Blurs the Line Between Compile-Time and Run-Time https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html 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.
- lifthrasiir 8y ago
  It should be mentioned that Zig's approach is not really generics (at least in the PL sense); one cannot determine the characteristics (or even validity) of `List(i64)` from `List(i32)`, much like that one cannot predict the behavior `f(3)` from `f(2)` for an arbitrary function `f`. This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support), is not necessarily bad---as C++ had been fine for decades---but can have some disadvantages w.r.t. compile time (yes, you heard right) or binary bloat.
  - bjz_ 8y ago
    > This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support) 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.
    - lifthrasiir 8y ago
      > I would class this more as 'duck-typed templates'. 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.
      - coldtea 8y ago
        >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 :-) 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.
vmchale 8y ago
> 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_ 8y ago
  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 8y ago
    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.
    - bjz_ 8y ago
      Oh, I must be mistaken then. So pointers are guaranteed not to be null? Can I mark pointers as nullable, and be forced to explicitly check? 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 https://ziglang.org/documentation/master/#Optionals
    - vmchale 8y ago
      > 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 8y ago
I've been using zig for the past 2 weeks in my spare time. I had so much fun writing in it that I ended up supporting Andrew on his mission and became a Patreon. 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++ ...
meheleventyone 8y ago
I’m using Zig for Advent of Code and it’s been pretty great. Feels very much a modern C and like it has a good niche having many of the ‘modern’ features I liked in Rust without the strictness.

chubot 8y ago

Yeah I like a lot of what I see. The compile-time metaprogramming looks nice and it would be good if I had a project to try it out for :) Zig Programming Language Blurs the Line Between Compile-Time and Run-Time https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html 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.

lifthrasiir 8y ago
It should be mentioned that Zig's approach is not really generics (at least in the PL sense); one cannot determine the characteristics (or even validity) of `List(i64)` from `List(i32)`, much like that one cannot predict the behavior `f(3)` from `f(2)` for an arbitrary function `f`. This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support), is not necessarily bad---as C++ had been fine for decades---but can have some disadvantages w.r.t. compile time (yes, you heard right) or binary bloat.
- bjz_ 8y ago
  > This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support) 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.
  - lifthrasiir 8y ago
    > I would class this more as 'duck-typed templates'. 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.
    - coldtea 8y ago
      >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 :-) 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.

vmchale 8y ago

> 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_ 8y ago
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 8y ago
  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.
  - bjz_ 8y ago
    Oh, I must be mistaken then. So pointers are guaranteed not to be null? Can I mark pointers as nullable, and be forced to explicitly check? 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 https://ziglang.org/documentation/master/#Optionals
  - vmchale 8y ago
    > 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 8y ago

I've been using zig for the past 2 weeks in my spare time. I had so much fun writing in it that I ended up supporting Andrew on his mission and became a Patreon. 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++ ...

meheleventyone 8y ago

I’m using Zig for Advent of Code and it’s been pretty great. Feels very much a modern C and like it has a good niche having many of the ‘modern’ features I liked in Rust without the strictness.