Thoughts on Backward Compatibility
ryuukk_
ryuukk.dev at gmail.com
Fri Feb 16 11:20:06 UTC 2024
Fast compilation, modules, compile time stuff should have been
enough for D to rule in the system language area.. but too much
distraction (Java OOP stuff), time has passed and still no way to
do better then C in some areas
And i disagree with you on Python3, breaking change didn't hurt
its adoption, it gave it a new birth, what hurt its adoption was
distro maintainers
I do lot of python these days, and it sadden me whenever i go
back to D and i can't do a simple pattern match, i have to use
the old ass verbose C style switch
Similar with returning multiple values, can't do it in D unless
you import a template everywhere and even then, using them is not
as smooth and is too verbose
It's hard to win people over these matter because everyone has
its own idea of what's needed, what's important and what is useful
At some point the leadership has to bruteforce and implement
things he thinks will be needed, important and useful
Expecting users to contribute is wrong, it's your project, we are
only using it to power our own projects
Anyways.. i don't mind breaking changes, as long as:
- it is properly documented
- the upgrade path is automated with tooling as much as possible
(i wish dmd had a: `dmd fmt` built in)
- it was done to make the language future proof
Backward compatibility should have a minimum version, otherwise
there is no way to fix past mistakes or to adapt
For me, the strengths of D:
- fast compilation
- close to C performance/control wise
- very easy access to C code / libraries, great to kickstart a
project
- compile time type introspection
- modules
- not ruled by a big corp
It however show its lack of adaptiveness, when compared to the
competition, its weaknesses:
- verbosity/repetition in the wrong areas
- no switch as expression
- no native tuple
- no tagged union
- no static array length inference
- can't have anonymous struct within structs
- C++ style of "the solution is a template in phobos"
- hard to predict what's next
More information about the Digitalmars-d
mailing list