4 ms·

I've been a financial backer of Zig for several months now, and plan to continue, because Andrew and the other contributers are pushing language design in direc

I've been a financial backer of Zig for several months now, and plan to continue, because Andrew and the other contributers are pushing language design in directions that no other language is. That being said, Zig's comptime is not a proper replacement for typeclasses/traits. Zig can do both comptime duck typing and vtable-based dispatch, but it cannot do proper bounded polymorphism type checking. It always fully evaluates types before type checking them. This might make it difficult (or impossible?) to provide type checking error messages of similar quality to Rust. I'm not sure if there are any other practical consequences for realistic programs, though. I suspect there might be issues around interface stability gaurantees, though I can't quite put my finger on why.

pron 6y ago
Right, they are only approximately comparable, but the important thing to remember is that features of formalisms are never goals in themselves, but rather means to various ends. The goal is never "to have interfaces/typeclasses/traits" but to be able to specify an algorithm that works for a variety of data structures with shared properties. Moreover, I think it would be a mistake for Zig library authors to try and replicate styles used in other languages. Zig provides sufficient mechanisms for expressing programs, and it will develop its own style. There will be elements that are analogous to those in other lanugages, but not identical. Having said that, I do support a proposal for specifying a type at the parameter declaration with some type -> bool function. I like this quote by Leslie Lamport about comparing formalisms (he talks about specification languages rather than programming languages, but the sentiment is the same): > Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to specifications written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express specifications written in another formalism, but to specify some aspects of some class of computer systems. Specifications of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to specify actual systems, are useless.

pron 6y ago

Right, they are only approximately comparable, but the important thing to remember is that features of formalisms are never goals in themselves, but rather means to various ends. The goal is never "to have interfaces/typeclasses/traits" but to be able to specify an algorithm that works for a variety of data structures with shared properties. Moreover, I think it would be a mistake for Zig library authors to try and replicate styles used in other languages. Zig provides sufficient mechanisms for expressing programs, and it will develop its own style. There will be elements that are analogous to those in other lanugages, but not identical. Having said that, I do support a proposal for specifying a type at the parameter declaration with some type -> bool function. I like this quote by Leslie Lamport about comparing formalisms (he talks about specification languages rather than programming languages, but the sentiment is the same): > Comparisons between radically different formalisms tend to cause a great deal of confusion. Proponents of formalism A often claim that formalism B is inadequate because concepts that are fundamental to specifications written with A cannot be expressed with B. Such arguments are misleading. The purpose of a formalism is not to express specifications written in another formalism, but to specify some aspects of some class of computer systems. Specifications of the same system written with two different formalisms are likely to be formally incomparable… Arguments that compare formalisms directly, without considering how those formalisms are used to specify actual systems, are useless.