alt Hacker NewsI just have to add another reflection:
One thing that tends to be overlooked when discussing changes is the ecosystem effect of frequent changes.
A language that breaks frequently doesn't just impose upgrade work on apps, but also discourages the creation of long-lived libraries and tools. Anything that sits between the language and the user (linters, bindings, frameworks, teaching material, tutorials etc) has to to some degree "chase the language"
This means that the ecosystem will skew toward very actively maintained libraries and away from "write once then leave it alone" libs. And this the trade-off is reasonable during early language design, but it's worth acknowledging that it has real consequences for ecosystem growth.
One should note that other newer languages have put significant effort into minimizing this churn, precisely to allow the latter type of ecosystem to also form. So it's kind of an experiment, and it will be interesting to see which approach ends up producing the larger ecosystem over time.
Replies
Zig's worth it though. I don't care for libraries that aren't maintained anyway. If they don't maintain it, it's just bad anyway. Why do you always nag about Zig. Stop shilling your C3 here.
An example for this is the Blender addon ecosystem. Blender moves very fast, breaking API changes every few versions. Now I am not an addon developer myself, but from github issues I follow, changes are fairly often trivial to do.
Yet, someone has to do them. Ideally it is the creator of the addon, sometimes it's the users who do it, when the addon is not maintained anymore (in case of trivial changes).
It kinda works that way, but it also is some kind of gamble for the user. When you see a new addon (and a new addon developer), you can't know if they gonna stick to it or not.
If you have to pay for the addon, it's more likely they maintain it, of course. But also not a guarantee.