4 ms·

So if I'm reading this correctly the Dlang syntax has non-backwards compatible changes every couple months? That's absurd, how would you even develop for that?

temp51723 3y ago
You pick a version of the compiler and stick with it until you're ready to try a newer version?
- kzrdude 3y ago
  Then you risk missing the deprecation warnings and head straight into errors.
- ubercore 3y ago
  That ignores any other libraries you use which may not make the same choice as you.
  - temp51723 3y ago
    It doesn't. You stick to the version of those libraries at work with that version of the compiler- like every other language.
    - ObscureScience 3y ago
      The difference is that most other language are backwards compatible to a fault (it's hard to have the stability cake and eat improvements)
    - ubercore 3y ago
      That's fine in a vacuum, but I feel like you'd very quickly run into the need for a security update, or some external API that changes, etc. You can't ignore all externalities, usually.
1980phipsi 3y ago
It's usually the result of deprecations that have warnings for several releases before being turned into errors. But there have been a few more deprecations lately than previously. In at least one case (disabling "alias this" for classes), I think Walter expressed some sympathy since there isn't always something obvious to do instead.
mhh__ 3y ago
It's absurd because it's not really true.
destructionator 3y ago
I have D code I wrote back in 2008 that still works fine today. That said, there are often small breakages scattered around and it can be annoying. If it is your own code, you spend the 5-10 minutes to update it (with some exceptions, the last couple months have been particularly bad, most aren't like that though). But if it is someone else's code and you have to wait for them to update it then push a new version tag, and cascade through the dependency list, that can suck. of course dependencies suck so you get what you pay for lol

temp51723 3y ago

You pick a version of the compiler and stick with it until you're ready to try a newer version?

kzrdude 3y ago
Then you risk missing the deprecation warnings and head straight into errors.
ubercore 3y ago
That ignores any other libraries you use which may not make the same choice as you.
- temp51723 3y ago
  It doesn't. You stick to the version of those libraries at work with that version of the compiler- like every other language.
  - ObscureScience 3y ago
    The difference is that most other language are backwards compatible to a fault (it's hard to have the stability cake and eat improvements)
  - ubercore 3y ago
    That's fine in a vacuum, but I feel like you'd very quickly run into the need for a security update, or some external API that changes, etc. You can't ignore all externalities, usually.

1980phipsi 3y ago

It's usually the result of deprecations that have warnings for several releases before being turned into errors. But there have been a few more deprecations lately than previously. In at least one case (disabling "alias this" for classes), I think Walter expressed some sympathy since there isn't always something obvious to do instead.

mhh__ 3y ago

It's absurd because it's not really true.

destructionator 3y ago

I have D code I wrote back in 2008 that still works fine today. That said, there are often small breakages scattered around and it can be annoying. If it is your own code, you spend the 5-10 minutes to update it (with some exceptions, the last couple months have been particularly bad, most aren't like that though). But if it is someone else's code and you have to wait for them to update it then push a new version tag, and cascade through the dependency list, that can suck. of course dependencies suck so you get what you pay for lol