I had no idea Code Node was still going strong, I used to goto a lot of events there
DConf 2026 in London
51–60 of 71 posts
Re: DConf 2026 in London
#52Earlier quoted context omitted.
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 stan…
> 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…
> 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
``` @menu("&Query") @accelerator("Ctrl+R") void Load_Default() { query.content = readTextFile("default.txt"); variables.content = "{}"; } ```
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.
Re: DConf 2026 in London
#53Earlier quoted context omitted.
> D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC. What I meant here (I do not know the mechanism) is that I am aware that D has a GC. This means, correct me if I am wrong, that D does not use destructors (like C++) for scope exit/failure/success, though they are scoped mechanisms (RAII-like). > Come to DConf (or watch the live stream) I always follow D (even if I did not use…
Regarding web assembly, support is limited. There's been several efforts to support WebAssembly in D but they were one man efforts that never got finished and merged to the mainline D. The only support there is in the official D compiler is for the BetterC mode, which is a minimal mode with no garbage collection, no runtime and effectively no standard library. There's been some people doing some interesting projects…
> effectively no standard library
The C standard library works well with it.
Re: DConf 2026 in London
#54Earlier quoted context omitted.
What's an SF edition?
I would assume OP is asking if you would attend a DConf in San Francisco. By the way, big fan of D even though I don't get to use it much. Appreciate your work!
A San Francisco DConf would indeed be nice. We've done them in Silicon Valley before.
Re: DConf 2026 in London
#55Earlier quoted context omitted.
Going to include the common lisp condition system in the comparison?
I tried Lithp a couple times, but it never caught on with me. I wouldn't know what the best techniques for Lithp error handling would be. I can never get past the ugly syntax.
You cannot be an expert in everything, that I understand.
But the "I can never get past the ugly syntax." reason is unusually superficial from you. Understanding Lisp macros or CLOS (the very cool object system) or Conditions (which are like exceptions, but also different in a very interesting and powerful way) is totally worth enduring the syntax for a language designer.
If you find the time, give it a try! Either way: I am a big D fan, so I agree with your tastes most of the time. Thanks for your work :)
Re: DConf 2026 in London
#56What’s the status of the OpenD fork?[0] I see Adam is still active there but I’m not sure if it’s had any impact beyond losing him as an upstream contributor. [0]: https://opendlang.org/
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 t…
I didn't know 90% of that, it is heartwarming to see significant back and forth.
Re: DConf 2026 in London
#57Earlier quoted context omitted.
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 t…
I didn't know 90% of that, it is heartwarming to see significant back and forth.
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.
Re: DConf 2026 in London
#58First day seems very LLM heavy, and sounds quite odd for Phobos 3. I would like to see Phobos 3 be more betterC forward, since I have found D to be nicer than C for WASM, but you can't use most nice things. Having a default RAII vector class for betterC and a hashmap would be super nice too. Edit: Also would be nice to adopt move and copy semantics even closer to C++ and maybe need less explicit moves, and ideally le…
> Having a default RAII vector class for betterC and a hashmap would be super nice too.
You can find such @nogc collections in `dplug:core` or `nulib` packages.
> I would like to see Phobos 3 be more betterC forward.
It is, some part of it is going to be called BaseD and with a more restricted subset, without GC usage.
Re: DConf 2026 in London
#59Earlier quoted context omitted.
Or you can assume exceptions can be thrown and capture and log coming from a base class in a centralized place (and probably refine incrementally what to do with each group without dirtying all the logic inside the functions themselves). For Rust result in C++ you have optional and expected. But they have their own problems, like rewriting function signatures all the way up the stack if you notice an error was possib…
But with that design, you’re quite limited in what you can usefully do once you catch that exception.
Well, I am not sure what you mean exactly.
But it enables incremental addition of errors and you can decide later what to do exactly, so I still tend to see it as an advantage.
It is like defer the error handling and centralize later.
If you want to handle an error in place immediately, prpbably it is not an exception what you want.
But if you need it is a fatal error, I do not see any harm, since the most you will do with that exception is to unwind and log or telemetry or whatever to tracke the errors.
Re: DConf 2026 in London
#60Earlier quoted context omitted.
Ages ago in C++ there was the hope of having the standard library give more error codes and use error values instead of full exceptions. Zig has some excellent innovations in that direction, any hope of that in D? Edit: I think it was called "Herbception"s after Herb Sutter, and it really sounded like a good idea to me
Value type exceptions went nowhere, because that was yet another paper that was never turned into a proper proposal. Additionally, Khalil Estell has made an excellent work proving that the way exceptions are currently implemented is not optimal and there is plenty of room for improvement, when someone cares about their implementation. "Cutting C++ Exception Time by +90%? - Khalil Estell - CppCon 2025" https://www.you…
I created the D version of the value type exceptions proposal.
In the end, it was DOA due to compiler architecture, so that was the end of that beautiful design.
I've had to accept result types is about as good as its going to get, all that is missing to make them nice is unwrapping support in if statements. Which I too have a proposal for and implemented it. But alas politics.