Thoughts on versioning

Thu Oct 28 08:50:31 UTC 2021

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 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.

Lets be bold!

Lets us call what would be D release 2.0100 "D" The semver is 
100.0.0

I have been using D2 since ~2009 and IMO it had enough breaking 
changes to call it version 100.0.0.
There is one number that describes D and its std.
When a symbol is no longer there in phobos, we increment the 
major version number.
When we add something to phobos we increment the minor number 
version number.
Here comes the somewhat tricky part, when dmd can not compile or 
a test now fails for the 50 most popular dub packages that worked 
with dmd N-1 we increment the version number.
We continue with the current release cycle, but the SemVer number 
is computed by a small script.
If we think a change warrants a major increment we can increment, 
but we can never not do an increment if we break something.
The changelog would list what broke/was removed.
Again, this can be done by a script.
The breakage testing for phobos, should not be clever, iff a 
public declaration is removed or changed it is a breaking change.
This is 2021 why is a human deciding what the version number is 
if the computer can do it.

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.

So here it goes.

### marketing

First we call D: "D the 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.

D should be the glue that makes the world go round.

### phobos/druntime

Why is https://github.com/symmetryinvestments/autowrap not in 
phobos, and why doesn't it support, WASM, python, typescript, go, 
and haskell?

If I want to call this one function out of the python std, the 
only thing in my way must be the fact that I have forgotten how 
save a file in emacs, because I'm doing it on a friends computer 
how is using emacs.

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.

I want to say, "ah you want to call a scikit function from D. No 
problem just right this line"
"But you have to call haskell first to get the data 
pre-processed, sure just at this line". No dub package required, 
just a D compiler and phobos.

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.

### dmd

Why do I have to call dmd, ldc, or gdc when I want a different 
backend to generate code. Isn't that what shared libraries are 
for?
Why can't I call dmd with --backend=llvm and compile with llvm 
instead of the dmd's backend.
Just think about this, do we really want people to understand 
that we have a D version 2.0100 with std version 2 or 3, and you 
have three compiles that support three different version of the 
language plus three different versions of the std, with all 
having different cli arguments.
No thank you, I'll just write some js and use node.js.

WASM: If I have a library or program, I need to be able to say 
--backend=XXX --outputType=WASM.
No betterC, no nogc, no excuses, it just needs to work. And 
additionally, it needs to put out a typescript file that does the 
converting of "json to D in WASM and back again" for you.
All without installing anything other than the D compiler and 
phobos.

The D compiler needs to be a file watcher daemon thing.
It is 2021 I have 64GB of memory, why is dmd still being split up 
in phases like its 1970 and all I have is a couple KB of RAM.
dmd is fast sure, but have you tried dart's or svelte's compiler.
The D compiler should be a diff compiler, were unchanged source 
is not lexed, not parsed, not semantically checked, nor ir 
generated.
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.

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.
Developers that use this forum is not our target audience.

The features of that daemon need to be so good that they drive 
the development of the lsp protocol.
So hard indeed, that all other languages have to stub out the new 
features of the protocol with assert(false, "Impossible to 
implement") for years to come.

e.g. Before the keyUp event reaches my editor, I want the 
unittest line coverage changes to appear left of the line numbers 
in the file I just saved.

Doing a "normal" dub build will not be harder with this compiler 
daemon, but doing dub build that uses all my 8 cores without 
doing work twice will be easier.
Doing a dub build for dmd/druntime/phobos in release mode, needs 
to take less than a second.

### Meta

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.

Sorry for the rant.