8 ms·

Here's another example of the coolness of Zig's comptime code execution: https://github.com/ziglang/zig/commit/0808d98e10c5fea27cebf912c6296b760c2b837b https:/

by dilap 6y ago

Here's another example of the coolness of Zig's comptime code execution: https://github.com/ziglang/zig/commit/0808d98e10c5fea27cebf912c6296b760c2b837b https://github.com/ziglang/zig/commit/0808d98e10c5fea27cebf9... That's a generic container class (similar to vector in C++ or List in C#). But! With a twist! It stores structs in "column major" order in memory (e.g., if a struct had two fields A and B, then in-memory layout would be A...AB...B), and you can idiomatically and efficiently get a a slice of the values of each column. I.e., it's a datastructure that automatically applies the struct-of-arrays optimization: https://en.m.wikipedia.org/wiki/AoS_and_SoA#Structure_of_Arrays https://en.m.wikipedia.org/wiki/AoS_and_SoA#Structure_of_Arr... And the code to do it is straightforward, normal Zig. Pretty awesome stuff!

thechao 6y ago
I took one look at this and realized you could do the same thing in C++17 using the perfect-flat-reflection.
p0nce 6y ago
Same in 2016 with D https://maikklein.github.io/soa-d/ https://maikklein.github.io/soa-d/
- egeozcan 6y ago
  D is another gem (while established in its own circle, it's not mainstream, therefore a "gem") I'd suggest people to give a try. Also Nim for crazy powerful compile-time features.
  - p0nce 6y ago
    Absolutely, Nim and Zig have proper CTFE and you can parse JSON at compile-time with a normal parser code in all 3 of them IIRC.
    - dunefox 6y ago
      This all seems cool until you realise that Lisp had full compile time access to the whole language for decades.
      - deleted 6y ago
        [deleted]
      - p0nce 6y ago
        Yes. But you could see the new crop of native languages as: as close to LISP as possible without codegen in the runtime. There is this 2x gap between JIT and AOT. (EDIT: Other than that I'm not sure if any of the new kids can introspect on the content - lines of codes - of a function, like LISP would).
        pjmlp 6y ago
        Lisps support AOT compilation since several decades, image tree shaking, and actually having a compiler in the runtime allows for tooling that most languages lack.
        p0nce 6y ago
        Can you avoid having a compiler in the runtime?
        pjmlp 6y ago
        Sure, AOT compilation + tree shaking. This is one way, http://www.lispworks.com/documentation/lw70/DV/html/delivery-110.htm#95989 http://www.lispworks.com/documentation/lw70/DV/html/delivery...
        p0nce 6y ago
        So a D successor could be a LISP with mainstream syntax and UX?
- smt1 6y ago
  The problem is that all of these languages are at least partially derived from C or C++, where memory layout is inverted relative to something like Fortran (which seemed to get this right from the 1960s) when you consider most cache lines on most processors. Therefore you must either go through hoops yourself tinkering with layout in languages not built for it or add much more complexity to a optimizing compiler (like gcc or llvm). I feel Fortran got this right, and Pascal and C was where languages flipped the norm. I kind of get why they did this, because in the 80s and 90s there were so many varying architectures, the memory wall was a very real thing. Actually Simula60 (a monte carlo language), probably had the right abstraction level (everything is just a block), but this was before things like stacks, heaps, trees, and other data structures were permanently etched into people's brains. I like how Julia implemented this (but they use Fortran-like defaults, with clear inspiration from matlab, numpy, etc), with a relatively compact set of functions to do any sort of "index ordering": https://julialang.org/blog/2016/02/iteration/ https://julialang.org/blog/2016/02/iteration/ Rust is very much a child of Ocaml (with a lot of idioms form haskell) with much more control of memory than pretty much any other language (which probably makes it better for implementing complex or safety critical things like optimizing compilers or an operating system). Actually, learning any ML language is probably easier than Rust, but you'll get more fluent at a ML-like (expression based) language like Rust. For me, I felt like I understood Rust way more after looking at how rustc works and started unlearned everything I knew about C/C++.
  - Bluestein 6y ago
    > things like optimizing compilers or an operating system). I am on a countdown to a Rust OS ... (An OS implemented in Rust).-
    - andrewflnr 6y ago
      I assume you mean a widely-used one. There's a handful in development. Have you looked at Redox? :) Ed: I really don't mean this to be snarky, even though looking back it kind of sounds like it. Sometimes you just have to stop fretting about phrasing, slap a smiley on and ship the thing...
simias 6y ago
I admit that I'm a Rust fanboy so it probably wraps my view a bit, but from personal experience I don't consider unlimited compile-time code execution to be a completely good thing. Yes, it makes the language more approachable, yes it makes it easier for people who aren't familiar with the language to understand what's going on. That's nice, but that's not critically important IMO. It's nice if you want to impress people on HN, but if you use the language day-to-day you'll get over that stuff pretty quickly. On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. On the other hand languages with a more rigid structure may end up being more verbose but that leads to code that a proficient coder can unambiguously understand without having to mentally expand comptime blocks or macros. This is effectively the metaprogramming equivalent of the statically vs dynamically typed debate. Yes, dynamic code is easier to write but it can be harder to maintain and leads to worse compiler diagnostics and generally requires more unit tests to validate that it's doing the right thing. I think macros/comptime behave similarly when compared to stricter, more limited metaprograming like Rust's generics system. Rust has macros too of course, but they're a pain to write in my experience, and I'd almost argue that it's a feature. You only use them if you really have to, and after careful consideration, or at least that's how I use them.
- jiofih 6y ago
  Your points are in stark contrast to the reality of the article. The Rust code produced is the one you have to be “on your toes” with due to unnecessary complexity, while Zig, despite the compile time features, is completely straightforward to understand. Maybe a second reading is due.
  - stevenhuang 6y ago
    Agreed. Of note is that the compile time features of Zig works towards Rust's goal of zero cost abstractions as well.
- twic 6y ago
  > On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. Could you give some concrete examples of this?

by dilap 6y ago

thechao 6y ago

I took one look at this and realized you could do the same thing in C++17 using the perfect-flat-reflection.

p0nce 6y ago

Same in 2016 with D https://maikklein.github.io/soa-d/ https://maikklein.github.io/soa-d/

egeozcan 6y ago
D is another gem (while established in its own circle, it's not mainstream, therefore a "gem") I'd suggest people to give a try. Also Nim for crazy powerful compile-time features.
- p0nce 6y ago
  Absolutely, Nim and Zig have proper CTFE and you can parse JSON at compile-time with a normal parser code in all 3 of them IIRC.
  - dunefox 6y ago
    This all seems cool until you realise that Lisp had full compile time access to the whole language for decades.
    - deleted 6y ago
      [deleted]
    - p0nce 6y ago
      Yes. But you could see the new crop of native languages as: as close to LISP as possible without codegen in the runtime. There is this 2x gap between JIT and AOT. (EDIT: Other than that I'm not sure if any of the new kids can introspect on the content - lines of codes - of a function, like LISP would).
      - pjmlp 6y ago
        Lisps support AOT compilation since several decades, image tree shaking, and actually having a compiler in the runtime allows for tooling that most languages lack.
        p0nce 6y ago
        Can you avoid having a compiler in the runtime?
        pjmlp 6y ago
        Sure, AOT compilation + tree shaking. This is one way, http://www.lispworks.com/documentation/lw70/DV/html/delivery-110.htm#95989 http://www.lispworks.com/documentation/lw70/DV/html/delivery...
        p0nce 6y ago
        So a D successor could be a LISP with mainstream syntax and UX?
smt1 6y ago
The problem is that all of these languages are at least partially derived from C or C++, where memory layout is inverted relative to something like Fortran (which seemed to get this right from the 1960s) when you consider most cache lines on most processors. Therefore you must either go through hoops yourself tinkering with layout in languages not built for it or add much more complexity to a optimizing compiler (like gcc or llvm). I feel Fortran got this right, and Pascal and C was where languages flipped the norm. I kind of get why they did this, because in the 80s and 90s there were so many varying architectures, the memory wall was a very real thing. Actually Simula60 (a monte carlo language), probably had the right abstraction level (everything is just a block), but this was before things like stacks, heaps, trees, and other data structures were permanently etched into people's brains. I like how Julia implemented this (but they use Fortran-like defaults, with clear inspiration from matlab, numpy, etc), with a relatively compact set of functions to do any sort of "index ordering": https://julialang.org/blog/2016/02/iteration/ https://julialang.org/blog/2016/02/iteration/ Rust is very much a child of Ocaml (with a lot of idioms form haskell) with much more control of memory than pretty much any other language (which probably makes it better for implementing complex or safety critical things like optimizing compilers or an operating system). Actually, learning any ML language is probably easier than Rust, but you'll get more fluent at a ML-like (expression based) language like Rust. For me, I felt like I understood Rust way more after looking at how rustc works and started unlearned everything I knew about C/C++.
- Bluestein 6y ago
  > things like optimizing compilers or an operating system). I am on a countdown to a Rust OS ... (An OS implemented in Rust).-
  - andrewflnr 6y ago
    I assume you mean a widely-used one. There's a handful in development. Have you looked at Redox? :) Ed: I really don't mean this to be snarky, even though looking back it kind of sounds like it. Sometimes you just have to stop fretting about phrasing, slap a smiley on and ship the thing...

simias 6y ago

I admit that I'm a Rust fanboy so it probably wraps my view a bit, but from personal experience I don't consider unlimited compile-time code execution to be a completely good thing. Yes, it makes the language more approachable, yes it makes it easier for people who aren't familiar with the language to understand what's going on. That's nice, but that's not critically important IMO. It's nice if you want to impress people on HN, but if you use the language day-to-day you'll get over that stuff pretty quickly. On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. On the other hand languages with a more rigid structure may end up being more verbose but that leads to code that a proficient coder can unambiguously understand without having to mentally expand comptime blocks or macros. This is effectively the metaprogramming equivalent of the statically vs dynamically typed debate. Yes, dynamic code is easier to write but it can be harder to maintain and leads to worse compiler diagnostics and generally requires more unit tests to validate that it's doing the right thing. I think macros/comptime behave similarly when compared to stricter, more limited metaprograming like Rust's generics system. Rust has macros too of course, but they're a pain to write in my experience, and I'd almost argue that it's a feature. You only use them if you really have to, and after careful consideration, or at least that's how I use them.

jiofih 6y ago
Your points are in stark contrast to the reality of the article. The Rust code produced is the one you have to be “on your toes” with due to unnecessary complexity, while Zig, despite the compile time features, is completely straightforward to understand. Maybe a second reading is due.
- stevenhuang 6y ago
  Agreed. Of note is that the compile time features of Zig works towards Rust's goal of zero cost abstractions as well.
twic 6y ago
> On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. Could you give some concrete examples of this?