Upstream has followed several of opend's innovations: we shipped interpolated expressions on day one of the fork (that was the straw that broke the camel's back) and then, after 7 years of procrastination, upstream also merged it a week later. We shipped extern(Objective-C) support, upstream backported it (and actually fixed enough bugs that I replaced my original impl with their's) a few months later. Upstream has talked about "safe by default" for over nine years. We shipped "safer by default" as a compromise (full safe by default is too much of a breaking change) a few months after forking, then a few months after we shipped it, upstream announced their own "safer by default" switch (which you have to opt into, so they kinda missed the point of "by default" but still, they followed the overall concept). For basically ever, Walter has said null checks in the language were a hard no, we implemented them and then.... guess what, a few months later, my implementation was backported (and again, a few bugs fixed so i appreciate the collaboration when we can get it) and walter decided to allow the merge. Opend shipped druntime on webassembly, looks like something similar coming to upstream. We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.
There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!
Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).
And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.
So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.
> We merged the tuple destructuring PR (that was open for years again so the author was happy to get it to land somewhere!) and upstream followed there too.
FYI that had very little to do with OpenD merging the tuple syntax - at least from my perspective - Timon may feel differently. I was the one who got the ball rolling on the DIP for it and kept pushing the process forward, and I also helped Timon and Nick get it over the finish line by fixing an ICE in the backend caused by destructuring a tuple of structs.
I've wanted first class tuple syntax in D since 2013, and when Timon mentioned not having time to do a DIP for it, I offered to help. It would've happened regardless of whether it got merged into OpenD or not.
The null check thing is actually really interesting cuz Rikki upstreamed the dmd impl but nobody's touched the ldc impl yet upstream. (I merged dmd and ldc in opend pretty early just because I had to reduce friction to make it all maintainable long term and that has indeed been a big win, I don't think either the null or objec things would have happened without streamlining the dev work like this)
My experience was the ldc impl was MUCH easier.... and optimizes much better, no surprise, but also compiled WAY slower. On dmd, the null checks barely affected compile speeds at all, but on ldc, the runtime impact isn't bad... but the compile time hit is ENORMOUS. I didn't even notice it at first, because I mostly use ldc just for cross compiles (another thing opend makes easy, `opend install xpack-win64` for example makes Windows builds just work, and it can do icons built in without third party toolchain as well, something hipreme took to upstream via his redub program that copied my implementation. he then added similar for Mac but I havent' pulled that back to opend yet, i will though) and I misdiagnosed.
Went looking for why the compile times were so much worse in opend ldc vs upstream (and btw note my definition of "so much worse" is like 3 seconds instead of 2 seconds, 50% is signifcant) and tried PGO and diffs in codegen and llvm versions...... then realized no, it is the null checks.
So the ldc implementation was easy and seems bug free (the bugs rikki fixed were in obscure corners of dmd's backend), and it optimizes well for runtime..... but wow it takes its sweet time to do that optimization. I'd appreciate someone else taking a look at that some day since there might be some better way to do it than I did (i basically copied the RangeError implementation on pointers for null check).
But I expect some day it'll come and then hopefully we'll make both of our compilers better.
we shipped druntime on emscripten on the opend side almost two years ago, supporting everything but threads and exceptions (i tested on emcc 3.1.69, i heard a later version of emscripten broke, im not sure). see my blog post from release time: https://dpldocs.info/this-week-in-arsd/Blog.Posted_2024_10_2...
there's a contributor working with both upstream and opend adding wasi support as well, and he also got exception support working, we'll probably ship that next month.
What exactly is the openD Canon D split about, and as a regular person, which one should I use? Any other details you could give, or background? I haven't followed any of that and have no clue.
I have no confidence left in the leadership of old D. This is an example: porting druntime to emscripten wasn't actually that hard to do, I did it in about a week of spare time in between kid and day job. Their solution, in so much as they pay attention to it at all, is to just point at betterC which remains half-assed for about a decade now (search my blog archives, here's one with them talking about "A betterC standard library" from December 2016 - https://arsdnet.net/this-week-in-d/2016-dec-18.html - and none of that has materialized ).
You might say if it is so easy, why not do it upstream? It takes years of political arguments and random ghosting to get anything done up there, all while constant (regression inducing) code churn breaks your PRs every other month, so you spend 3x the time rebasing than you ever spent writing the implementation before it is merged...... if it ever gets merged at all. I have several successful contributions to upstream D, it happens, but most the work done there is ignored. You might get some encouraging forum replies, but when it comes time to ship it? Crickets. Several former D contributors jumped ship for Zig many years ago, and it was a real loss for us (and real gain for them).
With the opend, I know if it works and delivers real world value, I can ship a release, dmd and ldc together, so minimal duplicated waste work.
What should you use? idk, opend is basically my pet project, provided in the hope that it will be useful, but THIS SOFTWARE IS PROVIDED `'AS IS″ AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE so your mileage may vary. Still, I maintain about a half million lines of code, some of which is quite old, so keeping some stability is important to me while moving forward with select common-sense, incremental improvements. Most D code works fine either way though, I've done web programming a long time, in the old school tradition, so words like "progressive enhancement" and "graceful degradation" are meaningful to me, even when being a compiler maintainer.
> point at betterC which remains half-assed for about a decade now (search my blog archives, here's one with them talking about "A betterC standard library" from December 2016 - https://arsdnet.net/this-week-in-d/2016-dec-18.html - and none of that has materialized ).
Oof, yeah that is definitely a pain point. Not to get too personal, but why would you continue to invest so much time in the language if upstream isn't accommodating?
Has WalterBright had any comments on this? He usually is so vocal, any hope of a remerge of the OpenD changes in to CanonD?
Anyway, I appreciate you trying to advance Dlang, I fight for it all the time at work, and usually get to do stuff in it(I am old and have privileges).
> Not to get too personal, but why would you continue to invest so much time in the language if upstream isn't accommodating?
Sunk cost fallacy lol. I got on the D train back in 2006 and of those half million lines of code I'm responsible for maintaining, about a quarter million are my own. A lot of work to make that... I have my own, from scratch: gui toolkit, terminal emulator, games, spreadsheet, web apps, shell, scriptable calculator, and more. Mostly mine but using libraries or ported third party code sometimes: music players, web browsers (one is from scratch but not terribly functional, one using chromimum libraries I'm typing this comment on right now), window manager, taskbar, the list goes on.
My whole daily work environment is made out of D code. And yeah, sure, there's alternatives, but I like mine. And a lot of it is making the apis cute. For example, I wanted to add a menu option to reset something in one of my programs last week. So I opened the code and wrote
It recompiled in about a second and a half and just like that, I can press ctrl+r to reload the defaults, or click Query -> Load Default in the menu (or alt+q and keyboard to it etc). My gui library takes care of a lot of things so I just write some functionality as-needed and use it a few seconds later.
Can I do that with Microsoft Excel? excel is a useful program too, but it takes longer to just load than it takes me to change the code, recompile, and relaunch my spreadsheet program lol.
Could I port all this stuff to other languages? Maybe. But it is less work to just maintain a stable fork of the compiler lol. (at the risk of getting flagged for being a troll again, I feel the same way about wayland... easier to maintain xorg, a program i haven't even restarted for years, than to rewrite the whole ecosystem.)
And that's the key point too, I do generally think the D language is mostly good enough as-is, so if I never committed another line of code to it, I'd still find it good enough. But it is nice if I do hit a language/compiler problem I can just fix it too.
OpenD added almost-full (you can't catch exceptions or spawn threads, so not really full, but the GC and such work fine) wasm support with like .... i think it was less than one day of work. wasm sucks though, what a miserable platform.
I had read about the split (D vs. OpenD) recently on the Dlang newsgroup.
Also, just had the thought that the split may damage Dlang's progress / prospects, for users, like the Phobos issue etc. stuff was supposed to have done.
I don't know much about those details either, I had just read a bit about it earlier, as an interested light user of the language.
No such thing happened. D has always been built on the same codebase, and the labels "D1" and "D2" are just arbitrary points on a mostly linear evolution (in fact, the tags D 1.0 and D 2.0 came only 6 months apart; 1.0 was just meant to be a long term support branch, not a different language. It was the addition of `const` that broke most code around release 2.6 but if you update those, old and new compilers generally work.
I'd say where D failed was its insistence on chasing every half-baked trend that someone comments on Hacker News. Seriously, look at this very thread, Walter is replying to thing after thing saying "D has this too!!" nevermind if it actually is valuable irl or not.
that actually wasn't its intended use; that's a side effect. The original intended use came from Effective C++ by Scott Meyers: "Prefer non-member non-friend functions to member functions.". It was meant to make that as syntactically appealing as the members.
The D parts of the compiler were released under the GPL from almost the beginning, since 2002. By 2004, a full open source compiler - what we now call gdc, officially part of gcc - was released using this GPL code. D was pretty popular in these years.
Just a personal anecdote, Walter Bright's Digital Mars C++ compiler also had the contracts (D started life almost literally as recycled code from Mr. Bright's other compilers - he wrote a native Java compiler, a Javascript 1.3 stdlib, and a C++ compiler with a bunch of extensions.... smash those together and you have the early D releases!).
Anyway, I used the DM C++ compiler originally because it was the only one I could download to the high school computers without filling out a form, and pimply-face youth me saw "DESIGN BY CONTRACT" at the top of the website and got kinda excited thinking it was a way to make some easy money coding online.
Imagine my disappointment when I saw it was just in/out/invariant/assert features. (I'm pretty sure D had just come out when I saw that, but I saw `import` instead of `#include` and dismissed it as a weenie language. Came back a couple years later and cursed my younger self for being a fool! lol)
`import` is so cool we extended it to be able to import .c files! The D compiler internally translates them to D so they can be used. When this was initially proposed, the reaction was "what's that good for?" It turned out to be incredibly useful and a huge time saver.
The concept is sort of like C++ being a superset of C and so being able to incorporate C code, except unlike C++, the C syntax can be left behind. After all, don't we get tired of:
What's the thing with the syntax? If you don't intend to use the type elsewhere don't give it a tag, if you want, you have to give it a name. (Assuming you are annoyed by the duplicate Tag)
If the user of Tag is supposed to know how the internal details:
struct Tag { ... };
if it needs to rely on the internals, but the user shouldn't care:
typedef struct { ... } Tag;
if it can be opaque (what I would default to):
typedef struct {} Tag;
I also think that is a good feature to separate specification from implementation, I like being forced to declare first what I want to implement. Funnily in your special case you wouldn't need the declaration. (But of course it's a bad idea to rely on this "feature")
Use the ascii bell character "\a" and turn off the "visual bell" or whatever options in the terminal (I hate those things) so you can actually hear it beep and find joy.
There's a lot of smaller things that haven't been pulled though, like i merged a bug fix to module naming, which was an upstream PR from like 2018, a fix on library file name generation, a regression from 2019 but has a trivial workaround, a fix to redefined reflection names which everyone finds annoying, the implementation was written in 2017, but they had endless debates about syntax and i just made an executive decision and moved on but they still bikeshed... stuff like that, they're all little things but minor annoyances every time you hit them and the fixes were easy, so just do it!
Then the two bigger things I did they have talked about but probably won't do is i made the class monitor opt-in, this is a relatively big breaking change, I had to do fixes on 8 different projects. Each one took a few minutes, so not a huge deal, but still. They talked about this in an upstream meeting but decided against taking it (for now at least).
And then I changed the default init of all built in types to zero, including char and float, and this is controversial since float init to nan has legitimate advantages, and the breakage can be subtle if you don't catch it. I was on the fence personally, it more like a 51-49 vote rather than an obvious bug fix, but it is easier to explain to newbies that int and float both init to 0. In theory, you are supposed to explicitly initialize all these all the time, but in practice we know it is different.
So I think the competitive edge is pushing them a little. And I'm not anti-collaboration; I write blogs about my implementations with the hope that they'll give a little code review and that's been semi-successful, like the upstream backporters have indeed fixed bugs in my implementations so I'm happy to share back and forth, we both win that way.