Is Zig weird though? I find it eminently pragmatic and a lot of the interest in it comes from people migrating from popular languages like C and C++ (not that C++ isn't itself pretty weird).

Zig uses explicit allocations everywhere (if you want to allocate something you need a reference to an allocator) which is pretty unique even for low-level languages (e.g. C, Rust)

From what I’ve seen, Zig has no built-in polymorphism features (no vtables/interfaces/traits), which is _pretty_ weird for a modern language in a good way.

That is just because it is new. If it survives it will end up with everything.

It has compile time programming designed to subsume those features. So eg a generic struct becomes instead a compile time function that takes a type and returns a struct

That is a wholly other set of language features, for a different purpose, and is thus no substitute.

Practical languages accumulate features to better address a multitude of common real-world problems. Toy languages don't. Sometimes a toy language is adopted and grown to practicality. People always complain about that.

“Adding everything” is definitely not a part of Zig’s philosophy.

https://github.com/ziglang/zig/issues/130#issuecomment-70601...

> However, at this point the plan is to not add an additional dynamic dispatch language feature.

Key phrase: "at this point".

Isn't that forecasting a trend with too few data points? The field is still young and changing.

Oh, I don’t think it is a trend. I rather see it as a curious phenomenon that makes one reflect on the trade offs we usually make when using polymorphism, and whether it’s worth all the time, not only in terms of performance, but also in terms of program architecture.

Interesting. What are the program architecture tradeoffs you are suggesting?

To be honest, I have zero experience programming with Zig. But I imagine programming with Zig would lead to more literal style and fewer, simpler abstractions (no IoC, no frameworks). That might be beneficial for certain kinds of focused-scope projects.

I see. They say you can solve every problem with an other indirection, and ad hoc polymorphism is an instance of that. But there are other ways to enable composition that are seldom reached for when your language makes that easy

Every problem, except those caused by too many indirections.

Each solution uses only a few language features. Different problems call for different subsets. Not using a feature on your favorite sort of problem says nothing about its value. "Ways to enable composition" poorly supported are reached for less. Poorly supporting one of them that has proven frequently useful does not improve a language.

> too few data points?

There have been rather a lot of languages. The field is approaching 70 years old, and still changing, but clear evolutionary processes are seen repeated in hundreds of languages living and dead. The ones that don't grow are the most reliably dead.

Zig is certainly not weird in the way that something like prolog or scheme are.