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