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.
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 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.
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++.
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.
No, Java is still pointers to Object and dynamic dispatch under the hood. Generics didn't change this at all.
> Still can't see why C++ is closer to ML than C, since it's literally an almost compatible superset of C.
ATS is also 'literally an almost compatible superset of C'.
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)
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.
> Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years.
I am not 100% sure that I agree with these characterizations, personally, but they're both valid strategies for sure.
Could you give some concrete examples of this?
Unlike C, zig's comptime doesn't have grammar altering abilities
Don't know if that actually applies to Zig/D, but that's how I read it.
What zig offers is completely different: it allows you freely manipulate types as data, while disallowing the ability to manipulate syntax.
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.
This is one way,
http://www.lispworks.com/documentation/lw70/DV/html/delivery...
D doesn't need a successor, rather a better marketing and fixing all lose ends.
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++.
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 am on a countdown to a Rust OS ...
(An OS implemented in Rust).-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...
Appreciate the comment, on the contrary ...
Redox FTW! (Besides, microkernels, which are nice ...)
(I take it someone from the Redox team saw this and took to the downvotes tough :)
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!