D has become unbearable and it needs to stop

GrimMaple grimmaple95 at gmail.com
Tue Jun 13 16:57:15 UTC 2023


On Tuesday, 13 June 2023 at 15:34:28 UTC, Martyn wrote:
> Ok, now I need to use some libraries. DUB is great for this! 
> However, when I search for packages, how do I know which 
> version they support?

Actually, dub already allows specifying toolchain requirments. 
https://dub.pm/package-format-json.html#toolchain-requirements . 
But it hardly helps with solving the issue of breakage, as some 
packages may require different versions of frontend and there is 
no way to solve it. Actually, someimtes, even dub packages 
themself can break because they depend on different versions of 
the same package, but at least 3rd party is usually strong enough 
in guaranteeing compatibility within certain major version.

> Are we expecting maintainers of these libraries to keep them up 
> to date monthly? Lets be honest.. if I need to include 3 DUB 
> projects into my application then what are the chances they 
> have been tested on 2.104.0? It is highly unlikely. The next 
> question is - what version should I be using? Atleast 4 
> versions old?

I don't know what the "expectancy" is, but talking with a lot of 
D developers led me to one conclusion: everyone expects you to 
have your own standard library. And then everyone expects you to 
use as little of the language as possible. And then everyone 
expects you to write your own code anyway, because there's an 
informal agreement that "dependencies bad".

This is a chicken and egg problem, really. Is there no packages 
because nobody writes them because "dependencies bad", or are 
"dependencies bad" because every existing one just breaks?

> Now, imagine the difficulties of an application with 3 or 4 DUB 
> packages. Each library being released/updated at different 
> times and lord knows what version they were last tested on. 
> Will they all work with 2.104.0?

I don't have to _imagine_ this -- dlangui has 9 dependencies. I 
went through great lengths to extract them from dlangui project 
itself (they were initially copy-pasted into a 3rdparty folder), 
and I'm beginning to regret this. If any of the dependencies 
break, or stop updating, I'm stuck with an old compiler version 
essentially. And it's not like replacing dependencies is easy 
when they are so scarce.

> Because of potential breaking changes for each new release... 
> could I end up with ProjectA being OK but not another, while 
> experimenting with different dmd versions?

`icontheme` dependency of dlangui is exactly what you describe. 
The maintainer refused to adapt to changed `alias this` rules, 
and I will have to figure something out eventually. Possibly, 
it's another project that I will have to maintain by myself 
because of silly breakage.

> There is a reason why LTS releases exist. Look at other 
> languages. Java, .NET, C++. Look at other projects like Linux 
> or Blender. Could you imagine Blender users going by monthly 
> builds only. Blender would fall apart and fast!

I agree that _some form_ of LTS is needed, but I don't think it's 
going to happen with D. After all, it's not that the lack of LTS 
is causing issues. We could be upgrading compilers monthly 
without issue __if__ those releases provided some strong 
guarantee of _at least_ not changing something that results in 
API changes. After all, changing, eg, `std.xml` to `undead.xml` 
isn't that devastating, and doesn't affect third-party that much. 
I even stressed that D has __become__ unbearable, as in it didn't 
introduce much breakage a few years back. Though, a stable 
release would still be greatly appreciated.

> Again, if we had LTS builds, our libraries can target those 
> specifically. It also makes it easier to maintainers to plan 
> ahead for the next LTS. As my previous post suggested, the 
> version of the libraries can start with the LTS version. It 
> makes it so easy to know if your version is supported, etc.

Yes, that is the whole point of this thread. To ask for some sort 
of stability in the D ecosystem. Because, practically, there 
isn't just "the latest version", there are 10 to 20 versions of D 
in the wild at the same time, and it's impossible to deal with.




More information about the Digitalmars-d mailing list