Thoughts on versioning

[harakim]

On Thursday, 28 October 2021 at 14:53:26 UTC, Adam D Ruppe wrote:
> On Thursday, 28 October 2021 at 14:30:42 UTC, Ola Fosheim 
> Grøstad wrote:
>> When programmers write code for a particular 
>> language/library/runtime/compiler they tend to make 
>> assumptions, that they probably shouldn't have.
>
> Then there's the risk things will break. So be it.
>
>> One might claim that people should not write ugly code, but 
>> most applications of scale does contain ugly code.
>
> They also have their own test procedures and the option to 
> version-lock the system if the breakage is too much. They might 
> file a bug and I'm sure upstream can consider their problems on 
> a case-by-case basis if there's no other solution.
>
> What we have now is fear leading to analysis paralysis. I say 
> just do something and if there is a problem, we'll deal with it 
> as it comes.
>
> (the truth that nobody really wants to talk about is that even 
> the most popular D libraries have just a handful of users 
> anyway. we can just work with them as needed.)

I'm going to start by saying you have always been more than 
helpful on the forum, I respect your opinions, and most of my D 
problems have historically been solved by asking you or by asking 
someone who references something you wrote. I don't have any 
claim to the direction of the D language/phobos library compared 
to you, so this is not supposed to be prescriptive, but a 
different perspective.

I think the reason the most popular D libraries have just a 
handful of users is related to the idea that the D language 
maintainers should just do something and if there is a problem, 
make affected users come to the forum and ask for help. Why 
should they do that when they can easily switch to a more stable 
language?

I posted a [post on 
reddit](https://www.reddit.com/r/d_language/comments/q74bzr/comment/hgpobuu/?utm_source=share&utm_medium=web2x&context=3) in reply to why D is not popular. I dread coming back to my projects and having to spend time to get them to recompile. I didn't include this specifically in the reddit, but the libraries are pretty bad in some cases with comments like this one, from Derelict:

>###THIS PROJECT IS NO LONGER MAINTAINED!
>
>It doesn't compile with the latest version of DMD and I will not 
>be updating it.

Why doesn't it compile? Not even the maintainer wants to find 
out, what chance do I have?

D will never be popular until this problem is solved. If D wants 
to be a niche language with few people maintaining the entire 
ecosystem, rapid change is desirable. If D wants to become 
widespread, then it has to start viewing breaking changes as 
generally unacceptable and a failure of the ecosystem. For that 
reason, I would be very hesitant about doing something to break 
libraries that use std.

Auto-decoding seems like a corner case that was used for a time, 
but isn't used much anymore except by libraries that this forum 
more or less is willing to change. If that's true then I think 
it's worth a breaking change, but I still feel like that change 
needs to be viewed as a failure and retrospected upon.

I think the compiler could be smart enough to issue an error 
about the library change if it sees a type difference of std.X.Y 
and std2.X.Y in a parameter. Maybe a hyperlink to a document that 
explains a solution, for example: "Hey that old duration type 
you're passing in? You need to pass in a new version, but the old 
version takes the new version in one of its constructors. Here's 
an example ..."
I think it could "autobox" the new object for you automatically 
and give a warning. Then this transition would be like the Java 
1.4 to Java 1.5 change (like generics, but also like 
auto-boxing). I understand that might be too much to ask or even 
not desirable. I also think it should be end-of-life'd at some 
point.

I don't know how to deal with the issue of reference equality 
tests between std and std2 types, but I don't know how often that 
comes up, to be honest.

It might be worth saving up a bunch of these breaking changes and 
coming up with a D3 that is just one breaking change of language 
and library that D can go off of, without breaking changes, for a 
long time. Perhaps it would be best to leave auto-decoding in 
until that version is ready.

Based on the discussion, it seems like there is not really a 
coherent vision and things get added here and there. That is not 
how popular languages are. Their releases are few and far between 
and they take breaking changes very seriously. People can count 
on the language and when they learn or build something, it is 
typically learned or built for good. This is not to say 
everything about the way popular languages are maintained is 
better than D. I just think the community needs to figure out a 
way to create stability. It doesn't mean we have to give up 
experimentation. Maybe there could be an experimental D++ that 
ports back the best features to D in spaced-out increments for 
the common folk. D++ would allow breaking changes and would 
always have features D doesn't.

\<feelings>
Whoever said that D's target audience is not the people on the 
forum: I feel like I'm one of the people you're talking about, I 
just happen to be on the forum sometimes. For me, D is like a 
girlfriend with a borderline personality disorder. When I get 
real excited and try to rekindle a part of our relationship (ie 
try to compile something), it feels like she doesn't give a shit 
about me and I'm going to have to work for here love. Not exactly 
marriage material. Java might be ugly and not very helpful, but I 
know where I stand with her.

I would love to be more involved in the D community and use it 
for all my projects. I'd love to come up with some libraries and 
a microservice collection and even help develop some tools. As 
things stand, I hesitate to suggest using D at work, and I will 
shy away from committing to it in my side business, until I feel 
like it is stable.
\</feelings>