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.
