D has become unbearable and it needs to stop

Chris Katko ckatko at gmail.com
Fri Jun 23 19:11:39 UTC 2023


On Monday, 19 June 2023 at 17:55:40 UTC, bachmeier wrote:
> This problem has a simple solution. Fewer compiler releases. 
> I'm all for bug fixes, but it has nothing to do with reducing 
> the frequency of compiler releases. If bug fixes are that 
> important, we'd already be doing it.

No, I don't think solution is to significantly delay features on 
a rapidly developed language. Features draw new users in, and 
keep people remembering and thinking about a new language. "I 
wonder what cool thing I can do with this new feature"

I think a simple solution is mark all non-LTS releases as "beta", 
as in "buyer beware if you use these", and have an LTS release 
every 2/3/4 years. Having to update your codebase every say, 
"four years", isn't the end of the world if you know it's coming.

If anyone is using the "beta"/"unstable" branch (or whatever you 
want to call it), it's immediately on them "You should have 
anticipated this could happen" if something breaks compatibility 
as the language evolves. At least, it's in the language users 
mind that it "could" happen and lessens the mental blow when it 
_does_ happen. A kind of consenting to instability.

I would suggest two "branches". The latest LTS, and beta. You 
want reliability plus bugfixes, use the LTS. You want new 
features, use the beta. Expecting a small community to maintain 
more than two versions is unrealistic, and a nightmare for 
library developers.

As for removing features, I don't think that's been sufficiently 
addressed. (Unless I missed the relevant discussion somehow.) 
Removing features (without so much as a press release/blog post) 
is a very dangerous precedent that forces users to think "Will my 
next used feature be removed? Should I migrate to a new more 
stable language?".


More information about the Digitalmars-d mailing list