Thoughts on versioning
Robert burner Schadek
rburners at gmail.com
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.
More information about the Digitalmars-d
mailing list