comptime and tagged unions are the 2 features i love the most about zig
I'm still not sure if i want to commit with zig, i don't enjoy its ergonomics and error messages (way too noisy, i have to constantly scroll), but whenever i want to implement tagged unions in C.. i just want to drop C and use something nicer
C/C++, Rust, D and even C#, they all don't have them, for C/C++ it's understandable, but for the other ones.. shame on you
I don’t know about the others, but Rust absolutely has tagged unions. It’s just the enum type.
edit: just checked the others. D has https://dlang.org/phobos/std_sumtype.html and C++ has std::variant. both seem a bit clunky, but usable.
Last i checked, Rust tagged union was "unsafe", what's unsafe has no place in Rust [1]
About D, a template is not Tagged Union, it's a template in a module from the standard library, it's not a language feature, it makes me less interested about that language knowing that fact, they follow the same path as C++, ``std::`` crap
A strength of a language's features is if the user can extend it with library types. Needing special syntactic and semantic sugar is a sign of expressive weakness.
(Though too much expressability can also lead to problems, like adding nitro injection to your car.)
The D std sumtype is actually super impressive after taking a longer look at it. Crazy how nice it looks to use for something that's not a language construct.
D is the king of practical metaprogramming for me. I think it stands out for compile-time metaprogramming beyond the competition.
Many ppl talk Lisp and Nim and such. They are even more powerful. But I honestly get lost with those and not with D. Idk why, maybe my familiarity with C++ helps.
If you find it easier, you can do the simpler "build a compile-time string and inject it" D-like metaprogramming in Nim with `macros.parseStmt` or `parseExpr`. And just `template` in Nim can go a long ways without all the mucking about with strings.
Nim is choice - in many dimensions. Many things that are built into languages even as flexible as D remain not hard-coded in Nim. E.g., it could be different now, but last I checked, D has hard-coded Associative Arrays. In Nim you can give any user type (e.g. B-Trees) the special syntax (no real meta-programming required..just generics). Also user-defined operators. Etc.
But, yeah - you need to be familiar with a base language whenever you do any meta-programming anywhere. Anyway, if you ever give Nim a try again, maybe `parseStmt` can be your gateway drug. ;-) (But I recommend starting with generics & template...)
I do like Nim also. The only problems are the usual ones plus one:
- IDEs ecosystem (both for D and Nim) - libraries
Additionally, Nim departs quite a bit from C/C++ to look more than Python. As nice as it looks, Nim is not Python, it has a ton more qualifiers and others. It is fast, but it departs from C/C++ a lot and there is much more than it is apparent to relearn. D's path is smoother in that sense. Also, C/C++ compatibility is a problem.
Yes, I know you could say Nim is very compatible with C. But at the end of the day is a considerable investment of extra work. If it does not work, if it works half-way even if compatible in theory. I have been there many times, I code hybrid in many occassions with scripting layers that are supposed to work, and at the end, there is extra work...
Trade offs abound in most things. D is undeniably syntactically closer to C if that is the priority. I knew people in the initial Java era who insisted their next PL had to look like C. I know others who prefer Pythonic brevity and Nim is even more brief & to the point in many ways.
Compatibility-wise, Nim can also just `emit` C/C++/Javascript (like D|Nim can just emit inline assembly) - arguably max compatibility that can even work with arbitrary non-portable backend compiler pragmas, `__int128` extensions, etc. OTOH, that also ties it to limitations of backends. Possibly relevant is https://github.com/nim-lang/c2nim & https://github.com/PMunch/futhark & the rather old/probably partly stale in both columns https://github.com/timotheecour/D_vs_nim .
There are many choices in Nim. Sometimes https://en.wikipedia.org/wiki/The_Paradox_of_Choice can be a real problem - in both software or in life - and at many, many levels. :) I am not trying to challenge your own priorities or push choices on you, but to add information others may be unaware of.