On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven Schveighoffer wrote:
> 3ddemo has one commit. In February 2016. I think it would be an amazing feat indeed if a project with one version builds for more than 2 years in any language.
>
> I built it successfully with DMD 2.076 (I just picked a random old version). So it's still usable, you just have to know what version of the compiler to use. I'd say it would be nice to record which version it builds with in some way on code.dlang.org.

I think the first post is an overreaction, but now I'd like to know what is the correct line of thinking in the community:

It's normal that it's not working newer versions?

I'm not being sarcastic, because if breakage is for a good reason or in pursuit of a better language I wouldn't mind so much.

But I'd to know if breakage is considerate "normal" or "shouldn't" happen in any way, like for example in Linux user space (Even it's not 100%) or C++ world.

I'm telling this because I'm stuck with an older DMD version: 2.062, because the newer versions doesn't compiles my project.

S.

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.

On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven
>
> Schveighoffer wrote:
> > 3ddemo has one commit. In February 2016. I think it would be an amazing feat indeed if a project with one version builds for more than 2 years in any language.
> >
> > I built it successfully with DMD 2.076 (I just picked a random old version). So it's still usable, you just have to know what version of the compiler to use. I'd say it would be nice to record which version it builds with in some way on code.dlang.org.
>
> I think the first post is an overreaction, but now I'd like to know what is the correct line of thinking in the community:
>
> It's normal that it's not working newer versions?
>
> I'm not being sarcastic, because if breakage is for a good reason or in pursuit of a better language I wouldn't mind so much.
>
> But I'd to know if breakage is considerate "normal" or "shouldn't" happen in any way, like for example in Linux user space (Even it's not 100%) or C++ world.
>
> I'm telling this because I'm stuck with an older DMD version: 2.062, because the newer versions doesn't compiles my project.
>
> S.

Really, the expectation is that you're going to use a version of dmd/ldc/gdc that is at least close to current. It may make sense to stick to a particular compiler version for a while, but the longer you go without updating, the more likely it is that your code will break. 2.062 is positively ancient at this point, and depending on what your code does, it could be rather interesting to update it. I'd suggest that you try to move up through the compiler versions a few at a time rather than jumping straight to the latest, since that way, if you're using any symbols or features that were removed, you'll benefit from deprecation messages along the way, and in general, the changes required to keep code working when jumping only a few compiler releases are minimal (though it obviously depends on the code).

We do generally want to keep code compiling long term if possible, but if a change is required to improve the language or standard library, then we'll often make it. Such changes are done via the deprecation process so that they don't immediately break code, but the deprecation process for Phobos is generally about two years (it's less consistent with dmd, though if anything, it's generally longer rather than shorter). So, if you go that long without making sure that you're code compiles with the current compiler, then you could easily have code breakage. You may very well not end up being affected by any deprecations for years, depending on what you're doing, but the longer you go without moving to a newer compiler, the more likely you are to have problems. And while we try not to break code without going through the deprecation process, regressions do sometimes get in, and sometimes, fixing a bug means breaking existing code (especially if code depends on the buggy behavior for one reason or another). The kind of changes that we generally avoid are those where we can't provide a gradual transition (e.g. we'd love to get rid of auto-decoding, but no one has yet come up with a way to do it that wouldn't immediately break tons of code, so we haven't gotten rid of it).

If you're expecting to be able to write D code, not touch it for years, and then have it continue to work with the newest compiler, then you're going to be very disappointed. However, if you at least make sure that your code works with the current compiler every few releases, then it usually shouldn't take much effort to keep it working. Over time, we've gotten pickier about what we're willing to break (e.g. we won't usually change symbols names just because the current name isn't as good as we'd like, whereas 5+ years ago, we were a lot more willing to change names in order to improve Phobos), and most stuff does stay the same, but don't expect that everything is set in stone. Changes should usually be gradual enough to avoid immediately breaking code, but they do happen. So, if you want your D code to continue to work over time, I would encourage you to make sure that it works with the current compiler at least yearly.

- Jonathan M Davis

On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis wrote:
> On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via Digitalmars-d wrote:
> ...

Thanks for replying and I think I'm ok with this line of thought.

And another thing it's not just my own code, but the third-parties libraries where some were unmaintained which I think it was because the breakage with new compilers.

I think I'll try a gradual update and see how it goes.

S.

On Wednesday, September 5, 2018 9:05:29 AM MDT SashaGreat via Digitalmars-d wrote:
> On Wednesday, 5 September 2018 at 14:45:25 UTC, Jonathan M Davis
>
> wrote:
> > On Wednesday, September 5, 2018 8:18:03 AM MDT SashaGreat via
> > Digitalmars-d wrote:
> > ...
>
> Thanks for replying and I think I'm ok with this line of thought.
>
> And another thing it's not just my own code, but the third-parties libraries where some were unmaintained which I think it was because the breakage with new compilers.
>
> I think I'll try a gradual update and see how it goes.

3rd party libraries are usually the real problem if there is one. They need to be maintained, and if something happens that breaks them from one release to another, that can prevent you from upgrading until it's fixed - which may or may not be quick even if they're maintained. And if they're not maintained, well, then that's a serious problem. Now, that would be a big problem in pretty much any language, but the greater rate of change in D does make it worse than it would be in languages that change at a much more glacial pace.

- Jonathan M Davis

On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
> 3rd party libraries are usually the real problem if there is one. They need to be maintained, and if something happens that breaks them from one release to another, that can prevent you from upgrading until it's fixed - which may or may not be quick even if they're maintained. And if they're not maintained, well, then that's a serious problem. Now, that would be a big problem in pretty much any language, but the greater rate of change in D does make it worse than it would be in languages that change at a much more glacial pace.
[...]

And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).


T

-- 
In a world without fences, who needs Windows and Gates? -- Christian Surchi

On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 05, 2018 at 09:18:24AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...]
>
> > 3rd party libraries are usually the real problem if there is one. They need to be maintained, and if something happens that breaks them from one release to another, that can prevent you from upgrading until it's fixed - which may or may not be quick even if they're maintained. And if they're not maintained, well, then that's a serious problem. Now, that would be a big problem in pretty much any language, but the greater rate of change in D does make it worse than it would be in languages that change at a much more glacial pace.
>
> [...]
>
> And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).

Oh, I think that that's a good idea, and it should help with folks picking libraries to use, but it doesn't fix the fundamental problem that whoever wrote the library needs to continue to maintain it or pass it on to someone else to maintain it when they don't want to maintain it anymore, or anyone using it is going to be screwed. So, while your suggestion will definitely help with a piece of the problem, it doesn't solve the part that I was talking about.

- Jonathan M Davis

On Wednesday, 5 September 2018 at 13:27:48 UTC, Steven Schveighoffer wrote:
> 3ddemo has one commit. In February 2016. I think it would be an amazing feat indeed if a project with one version builds for more than 2 years in any language.

This problem is not about 3ddemo. I can totally relate to the OP, when I started learning D (we're talking April 2017 here) I tried many OpenGL demos and GUI libraries. I like learning by example, so I tried a lot of them on both Ubuntu and Windows. My success rate of building them was below 20%, and even if it did succeed, it often still had deprecation warnings, or linking errors when loading the required shared libraries, or glitches like messed up text rendering. I would try to fix it myself, but the error messages were not clear at all for a beginner and Googling them yielded few results.

We're not even only talking about small unmaintained projects here: at the time I tried it, Gtk-D was broken.[1] Out of frustration I carried on in C# for a while, and guess what: the first best OpenTK demo I found basically worked first try. Now I didn't give up on D, but I can totally understand that others (like OP) don't have the patience to put up with this.

While we can't force volunteers to keep their D projects up to date, we could try to give some incentive by notifying them via code.dlang.org, or give users information on what compiler / environment is required for dub packages to build. It might prevent some new users from leaving D out of frustration.

[1] https://forum.gtkd.org/groups/GtkD/thread/589/

On Wednesday, 5 September 2018 at 15:34:14 UTC, Jonathan M Davis wrote:
> but it doesn't fix the fundamental problem that whoever wrote the library needs to continue to maintain it or pass it on to someone else to maintain it when they don't want to maintain it anymore, or anyone using it is going to be screwed.

It's okay for a library to become outdated, as long as new libraries emerge. When a user finds 5 dub packages that provide a solution, and they try the first 3 and they all fail, he might get the impression it's all broken. If it was shown that only the last two build on the newest compiler, they could immediately pick that.

If it is a niche package and there's only one option which doesn't build, then it's still a problem yeah. But it would still be an improvement if maintained libraries wouldn't have to compete with broken abandoned ones in the search results.

On Wed, Sep 05, 2018 at 09:34:14AM -0600, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, September 5, 2018 9:28:38 AM MDT H. S. Teoh via Digitalmars-d wrote:
[...]
> > And that is why I think we should implement my idea of putting *all* dub packages on code.dlang.org into our CI infrastructure, and log all successes / failures to a database that can then be used to display the range of version(s) of compilers that successfully built each package on code.dlang.org. Then people can quickly see, at a glance, whether the package still works with the version of the compiler that they're using (usually the most recent release, but not always, so this information can be super useful in making decisions).
> 
> Oh, I think that that's a good idea, and it should help with folks picking libraries to use, but it doesn't fix the fundamental problem that whoever wrote the library needs to continue to maintain it or pass it on to someone else to maintain it when they don't want to maintain it anymore, or anyone using it is going to be screwed. So, while your suggestion will definitely help with a piece of the problem, it doesn't solve the part that I was talking about.
[...]

Once packages are annotated with the last working compiler version, it will be an easy next step to identify all broken packages that need maintenance.  If there's an easy fix, someone could open a PR and push it upstream, or if upstream has abandoned the project, we could fork it and apply the fix.  Either way, CI automation would help us with the initial chore of identifying such packages in the first place.

Also, if the last working compiler version is prominently displayed e.g. in the search results, it will inform people about the maintenance state of that package, which could factor in their decision to use that package or find an alternative.  It will also inform people about potential breakages before they upgrade their compiler.

It doesn't solve all the problems, but it does seem like a good initial low-hanging fruit that shouldn't be too hard to implement.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.