This is why I don't use D.

[RhyS]

On Wednesday, 5 September 2018 at 05:53:46 UTC, Neia Neutuladh 
wrote:
> Compare with DMD over the past year. (Just one year!) opDot was 
> deprecated, C-style array declarations were removed, opDispatch 
> works differently with `with` statements, arithmetic with 
> pointers of different types was deprecated, comma expressions 
> no longer yield a value, `delete` was deprecated, hex string 
> literals were deprecated, class allocators were deprecated, 
> certain types of postblit operators were deprecated, some 
> operations on `shared` variables were deprecated, declarations 
> in switch-case statements can't be used in other case blocks 
> anymore, `catch` statements have to declare something they 
> catch now, you can't compare values from different enum types 
> anymore...
>
> That's not all the breaking language changes in the past year. 
> And it's just one year. (I'm cheating a bit by counting both 
> deprecations and lapsed deprecation periods, but still.)
>
> D can't use semantic versioning because nearly every release 
> has breaking changes. Most of them won't affect your code in 
> particular, but once you start using a bunch of libraries, it's 
> going to be painful.

This is the same reason why D with Code-D on Windows was a total 
disaster. You install VSC+CodeD. It breaks because some 
dependency library somewhere was not updated for DMD xx.0, 
because D broke/changed something again. Contact the author, ... 
wait for a official fix for weeks.

Now install D on my work PC. Guess what, some minor update came 
out for D, install ... and it broke some libraries again. Contact 
the author again ... wait for a official fix for a few weeks.

Imagine doing this for a year and half with each time you try D 
or want to show D to some colleagues, all you had was a broken 
mess.

And it did not stop at plugins for IDEs. Code that ran good on a 
version of D, refused to work on a later because of deprecated 
features. Or sometimes, it simply crashed without a single 
warning. I can NOT rely on any external package for my code, 
because any new compiler version can break these packages ( and 
my code ).

Do people want to see how many times Vibe.D broken? Or the Mysql 
plugin. You simply get fed up and give up.

Sure, i can fix my code but the external packages are a different 
matter ( not in the mood to learn all the external code and fix 
it every time something breaks ).

And sure, people can stick to only one compiler version for X 
years but then what? You already know how fragile everything is. 
What if you run into a bug in this older package, well, the 
author will fix this bug in the latest master ( what may require 
a new compiler version ). So you run into the whole chicken or 
egg situation!

Then your forced to manually start patching the old code. If you 
can! Sometimes code get changes so much over time that 
back-patching is hard as hell. Its just insane to work like this.

WebFreak001 resorted to actually pre-compiling all the code and 
shipping it like this on the Windows platform because it was the 
only was he was able to ensure that VSC Code-D plugin actually 
kept working! I have Go plugins for IDEs that also get 
git/compiled and they all work out of the box. Each time i 
install a IDE with Go at work, laptop, in a VM or anywhere!

At the same time i have PHP code that is 10 years old, that works 
with minor updates. No need to worry about mysql and other 
extensions because they are pre-compiled and stable. Go code that 
is several years old that instantly compiles with the latest 
compiler.

Its just amateurish at best. And this issue with the code 
deprecation's, bugs, changes is only one off many issues.

Its the same reason whenever i check back on D and see BetterC or 
other "improvements", that i simply yell. "FIX YOU SYSTEMS BEFORE 
INTRODUCING MORE CRAP". Sorry for the languages but i am sure 
that plenty of other people think the same.

I and my company is not motivated to support or help out D when i 
have already put in so much wasted time in the past.

And keep those excuses how its open source and the people need to 
fix everything themselves. I see several main developers, who are 
paid full time more playing around with introducing features only 
a handful of people want. Instead of actually making the language 
stable and ensuring the entire platform runs. D in my book is NOT 
a 2.xx version but feels like a pre-beta. Like 0.xx non-stable 
API language.

You can guess what we do NOT develop in D but simply use Go and 
PHP for our work. Go for the bits that needs extra speed, PHP for 
the easy and fast development. Both are API stable, you do not 
worry much about bugs or deprecation. New features can be 
experienced without massive code breaking.

I do not worry about Go its build-in HTTP server breaking. It 
simply runs on each compile, no matter what Go version we upgrade 
to. Vibe.D on the other hand is a mess. And NOT the fault of the 
Vibe.D authors but the dependencies they depend upon. I have now 
a simple rule. You want us as a company to use your languages for 
web development. You do not have a build in and maintained HTTP 
server? No thanks. And that attitude is a direct result from the 
fun we had with D.

So take my comments however you like, D is not ready for specific 
production jobs. If you build all your code yourself, then D is 
usable. But the moment you rely on 3th party code in the D 
platform, it is unstable at best.