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:
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.
Zig doesn't have unlimited compile-time execution and what it has is strictly weaker than Rust's macros [1]. Rather, it has one carefully designed construct that is both very simple and very expressive, and yet isn't as weird or as dangerous as macros. It is not "extreme customisation" but just the right amount to make the language both simple and expressive without extreme measures like macros. Zig accepts that macros are problematic, and shows how far you can go without them altogether. OTOH, while macros are common enough in Rust that while you may not write them yourself all the time, you do use them frequently.
I guess that there is some small truth to your allusion to the static-vs-dynamic debate, but Zig does give you errors at compile-time, and elaborate things it can check at runtime are much easier to express than in Rust. But I would say that Rust is a language in a well-known tradition, and is clearly a "cleaned up C++", while Zig is something that we haven't seen before. It is not dynamic in the same sense as dynamic languages -- you get the checks done at compile-time -- but it is not part of the familiar tradition of typed languages or even any low-level language.
I'm not a devout minimalist, but when it comes to low-level programming in particular, language simplicity is a very important feature, and before Zig it wasn't clear it was achievable at all in low-level languages without significantly compromising on expressivity and safety.
(I wanted to read your [1] reference but you seem to have forgotten to add it.)
I agree that comptime is not the same thing as Rust macros, I mostly mentioned Rust macros because I felt it was a gotcha to my argument since my criticisms of Zig's comptime could be levied at Rust's macros.
To be a little more specific in my criticism, the fact that Zig implements generics with comptime is a bit of a red flag for me. I worry, perhaps unreasonably, that it's going to lead to fragmentation in the way generics are handled in various libraries, leading to headaches and incompatibilities. It is a smart solution, but I wonder if it's a pragmatical solution.
It's definitely an interesting approach at any rate, it's great to see all this creativity in systems language. I don't want to sound too critical of Zig, it's a cool language.
> my criticisms of Zig's comptime could be levied at Rust's macros.
Except that comptime is nothing at all like macros, even though, as it turns out, it can replace enough of their use to make them unnecessary in low-level languages.
> I worry, perhaps unreasonably, that it's going to lead to fragmentation in the way generics are handled in various libraries, leading to headaches and incompatibilities.
But generics in Zig are just functions, and so the problem should be no better but no worse than any API. comptime is drastically less "crazy" or "weird" or hard to make compatible than macros, which Zig doesn't have at all.
I'd say Rust is much more like Ocaml (with very different memory management) than anything related to C++ (in fact, if you unlearn C++, or know any ML-ish language, idiomatic Rust becomes significantly easier). Ownership types are probably Rust's main difference relative to any systems language, I think the first attempt to bring it to a C-ish language is probably Verona: https://microsoft.github.io/verona/explore.html (though it's very immature)
Definitely not; what do they have in common beyond being statically typed and compiled?
Where they differ: memory safety, sum types (don't tell me std::variant is a valid replacement), move semantics, having pointers, classes, GC vs RAII, statement vs expressions... That's a lot of differences.
What do you mean 'beyond'? It's not like there are many other languages that have compile-time polymorphism. (Java, Go, C, etc., don't.)
> memory safety, sum types (don't tell me std::variant is a valid replacement), move semantics, having pointers, classes, GC vs RAII, statement vs expressions... That's a lot of differences.
ML ignores the real performance and architecture considerations, so yeah, of course it is a simpler and more 'elegant' language. As a teaching aid, yeah, I think all C++ programmers should be forced to program something in an ML-derived language.
But once you start handling the real-world edge cases and requirements you'd end up in a place very similar to C++.
> What do you mean 'beyond'? It's not like there are many other languages that have compile-time polymorphism. (Java, Go, C, etc., don't.)
Java does, it's called generics. Also D, rust, Ada, free pascal, nim, and most statically typed languages from the last 3 decades (even Go is finally getting them ). Still can't see why C++ is closer to ML than C, since it's literally an almost compatible superset of C.
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.
I don't think comparing zig's comptime with rust macros is actually that apt of a comparison. I tend to think of rust macros as syntactic sugar. Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. Top level const expressions are automatically comptime, modules are comptime structs, static polymorphism is used all over the stdlib (e.g. std.mem.eql), heck std.debug.print is written without special compiler tricks thanks to how cleanly you can use comptime in zig.
I think the idea that zig is a very sharp knife is true, but the overlap of footguns and comptime is not as big as one would think (@fieldParentPtr mistakes comes to mind, but that's sort of about it)
> Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways.
TANSTAAFL. Compile-time evaluation cannot truly "permeate" a language because most practical languages preserve a phase distinction between compile time and runtime. (This phase distinction is somewhat softened, e.g. in interpreted languages as well as in advanced PL's which include such features as dependent types). For a system programming language like Rust which relies on this clear-cut phase separation, macros and proc macros (as well as `const`-marked expressions and functions) are ultimately more elegant.
constexpr is basically making more of C++ available at compile time -- e.g. lots of C++11, 14, 17, and 20 are just allowing more of the language at compile time. Including STL, allocators, etc.
Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years.
My understanding is that Rust is going down the same path as C++. So you're going to have 2 kinds of macros AND comptime-like/constexpr-like compile time execution.
Regardless of the particular trade-offs the various languages under discussion are choosing to make, it’s exciting to me that more and more languages are adapting, exposing and using “compile time” systems
> 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.
Only thing I can think of is something blowing up when cross-compiling to a different target because there's no code in the static if branch to handle that architecture (e.g. stdlib doesn't officially support WASI). But that's not really comptime's fault per se IMHO; you can break things in similar ways in golang, for example.
Unlike C, zig's comptime doesn't have grammar altering abilities
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.
There's more to a language than just features and functionality though. Why does Clojure have adoption despite being the least powerful Lisp, created decades after Common Lisp? Its stdlib, default data structures, and even syntax make it compelling (yes, sometimes having a deliminiter other than parentheses is helpful, and no being able to define new syntax via macros is not the same thing because defaults are important). Its not bad to rehash language features that have existed for 50 years if the resulting language has other compelling qualities.
Depends on what you think the cause of the lack of adoption is. If you think it can be fixed by doubling down on existing languages, then sure. But I don't know if that's addressing the cause (because I don't know the cause).
I use Lisps all the time and love them. But I recognize that most people don't like them. At some point we have to meet people where they are, if we want to have broad impact. Ideas on their own aren't good enough, they need to be packaged up in the right way, approachable to the right people, marketed appropriately, etc. The tech itself is just a small part of what it takes for an idea to create impact.
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).
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.
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/
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++.
> 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.
How do you mean? As I understand it, the only difference in these languages in this regard is in 2D arrays, where in C, the current row is in the current cache line and in FORTRAN the current column is in the current cache line. It seems to me you are if anything slightly more likely to want to do several operations on the current row, so the C way is better. What am I missing?
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...
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_Arr...
And the code to do it is straightforward, normal Zig.
Pretty awesome stuff!