Thoughts on versioning

[SealabJaster]

On Thursday, 28 October 2021 at 08:50:31 UTC, Robert burner 
Schadek wrote:
> ...

While your ideal world is basically lala-land, you know, I kind 
of wished I lived in it.

I really appreciate this vision, but from experience of lurking 
this forum, I can tell you that, particular the older 
programmers, won't see much worth in a lot of your suggestions 
regarding the compiler changes (assuming we'd ever even have the 
manpower to make it possible in the first place).

I'm not going to spend much time going "but ackstually" and 
refute your points, since I'm going to be treating this as an "in 
a perfect world" post. So I'll mostly be sharing my own thoughts 
alongside yours.

> I think this version schema is fundamentally wrong and looks to 
> me like a quick way to the D1 standard library mess.
>
> Having/installing multiple std versions bundled with a 
> DMD/druntime release has written disaster all over it.
>
> Let me be clear, phobos needs work (breaking changes).
> I'm not denying that.

But we've become scared of the very word "breaking change", hence 
why baggage like `@property` are likely here to stay :(

> But this feels like we are scared of repeating the D1 to D2 PR 
> disaster, and do a kind of soft major version break.
> Only this way we can say: "but we didn't break the api its 
> still D2"
>
> We have DMD 2.0100 coming up.
> Just look at that silly number.
>
> When I have to explain to somebody what that number means plus 
> an additional std v2 thing, they have installed and compiled 
> the rust hello world before I'm done.

Coincidentally I was thinking about this today, but again, I 
doubt there's enough people who see any worth on fixing the 
versioning number to something a bit more... sane.

2.100 could be something special, instead of just a normal 
release with a nice, round number.

> Lets be bold!

Here we now enter lala-land.

> And then lets have a proper vision for D, and not only small 
> technical improvements.
> I understand that we can't direct people to work on things in 
> our community, but we can ask them.

I believe that's similar to how the vision documents went. 
"Here's a wishlist, please-maybe-possibly-if-you-want-to do it 
Community, best of luck and lots of love - from, the D foundation"

> First we call D: "D the best programming language"

**D** best programming language ;)

> Obviously, that is correct in IMHO, but even if people 
> disagree, they are at that point talking about D.
> We lure them in with clickbait, but than doing anything, in any 
> other language takes longer than doing it in D.

I'm kind of uncertain that'd work, but it's an interesting idea 
anyway.

> ...
>
> If I have to write more than
>
> ```D
> static import std.python;
>
> auto result = 
> std.python.thisOneFunction(a_bunch_of_complex_arguments);
> ```
>
> we have failed.
>
>
> ...
>

That's a very interesting vision... "D, the language to unite 
them all".

> phobos needs to have an event loop library included.
> golang has go routines inside the language, we at least need 
> something not much worse in phobos.
>
>
> Support for yaml, toml, ini, json-schema, etc. in phobos.
>
> When I have a json-schema, or whatever the equivalent is in 
> yaml or any of the other, I want to write 
> mixin(jsonSchemaBuild(import("path_to_schema_file.json"))
> and have classes that represent the AST of the schema and a 
> parser that turns json into those classes.
> 100% of people that see this feature will not care that it uses 
> the GC.

"But you see, does it cover `@nogc nothrow pure const inout @safe 
-betterC` all at the same time? No? Rejected!"

or

"What do you mean it needs to use the GC for more than just 
exceptions? Haven't you heard, we don't do GC anymore because 
it's scary to the C++ programmers."

> ### dmd
>
> Why do I have to call dmd, ldc, or gdc when I want a different

I understand the sentiment, but the compilers are all at 
different levels of support in terms of which version of the 
language they support.

I mean, ideally it would be nice to have a single, unified 
compiler, but I feel there's **many** obstacles in the way for 
this to actually happen.

> When I work on phobos and press CTRL-S, the unittest's for 
> phobos should start running before the keyUp event has received 
> by my editor.
> 
> Why do I have to wait for assembler to be linked when I want 
> unittest to run.
> The D compiler daemon should execute some VM IR. This is linked 
> to the --backend=XXX --outputType=SOME_VM switches from before.
>
> Also, when the compiler stores all dependencies between 
> functions and types in memory, it can also keep track of which 
> unittest dependents on what code.
> So when I change something that only has one unittest depending 
> on it, only that test should be run.
> Assuming, I didn't do anything stupid in the unittest, I would 
> expect the unittest to have finished before my editor gets the 
> keyUp event from pressing CTRL-S.

Now *this* is ambition. Unfortunately, as I said, many here 
likely don't see any value in this. (disregarding the huge amount 
of work that'd have to go into making this possible in the first 
place that *someone* would have to volunteer to champion)

> The compiler daemon, needs to support lsp perfectly.
> I know you don't need that, because you know all the functions 
> by heart and "real" programmers don't need auto complete.
> But you are wrong and they do. Just look at web crowd is doing.

I dream of the day we get a compiler-as-a-library completion 
service, so maybe things like UFCS and templated types can be 
autocompleted <3~~

As ok as code-d is, it can be a real PITA when it's only able to 
work a quarter of the time because it's completely incapable of 
handling templates in any shape or form.

Meanwhile in Go, F#, C#, Java, Python, JS, TS, even CSS... I go 
`myobj.` and get the full API + doc comments.

> Developers that use this forum is not our target audience.

^^^^^^^^^^^^^... who is our target audience exactly, because I 
couldn't actually tell you.

> Move everything to github.
> Maybe bugzilla has features github does not, but github has 
> 10^6 more users than dlang's bugzilla.
> At 10^2 we should have stop caring about features.
> The casual user that finds a bug is not going to create an 
> bugzilla account to create an issue.
>
> Let's use milestones in github to express our aims/vision for 
> the language.
> E.g. the WASM milestone would link to all the issues related to 
> WASM.
> If "average rust user" wants to know what D's story is; simply 
> look at the milestone. Easy to find, easy to contribute to.

Wasn't there some kind of initiative at some point to port the 
bugzilla issues over to Github issues? I wonder what happened 
with that.

> Sorry for the rant.

I love these kinds of "in a perfect world" posts, because at the 
very least it can spark ideas in the direction things could go.

Rants in general can be very fun and somewhat enlightening to 
read.

If only posts like this could come from those who have the power, 
time, and motivation to organise a strong, coherent, unified 
vision. And if only we had the manpower to make our strongest 
wishes come true.

A huge restructuring, a complete rebrand, an extreme focus on 
developer tooling, language integration baked into the std. Some 
possibly exciting things, but reality generally hates this sort 
of excitement, and rewards it with a coin flip.

Thank you for this post, will be exciting to see what discussion 
this sparks though I suspect it won't be as positive a response 
as I'd hope for.