I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
DConf 2026 in London
11–20 of 71 posts
Re: DConf 2026 in London
#12First 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…
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.
so the full d story on wasm is progressing too.
Re: DConf 2026 in London
#13I haven't announced my keynote yet, but it's about various ways of handling errors and their tradeoffs. This has inspired some spirited debate in the D forums! I'm looking forward to engaging with everyone.
would you ever do an SF edition? would be happy to host for you. i do a lot of conferences.
Re: DConf 2026 in London
#14I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
it's an evolutionary (as opposed to revolutionary) language; it is in many ways a reimagining of c++ based on decades of observing the latter's flaws and weaknesses in the real world. if you're in the c or c++ ecosystem already you will likely find D a pleasant set of improvements to c++.
Re: DConf 2026 in London
#15First 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…
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 exceptio…
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.
Re: DConf 2026 in London
#16I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
I always try it every few years, but I can never figure out how to get a good ide experience. I’ve tried both VSCode and IntelliJ. I most recently tried to make it work for advent of code last year. Maybe I’m just too used to how good the IDE experience for Java is?
Re: DConf 2026 in London
#17Earlier quoted context omitted.
for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
it's an evolutionary (as opposed to revolutionary) language; it is in many ways a reimagining of c++ based on decades of observing the latter's flaws and weaknesses in the real world. if you're in the c or c++ ecosystem already you will likely find D a pleasant set of improvements to c++.
For example, C and C++ still cannot compile this:
int foo() { return bar(); }
int bar() { return 3; }Re: DConf 2026 in London
#18Earlier quoted context omitted.
it's an evolutionary (as opposed to revolutionary) language; it is in many ways a reimagining of c++ based on decades of observing the latter's flaws and weaknesses in the real world. if you're in the c or c++ ecosystem already you will likely find D a pleasant set of improvements to c++.
For example, C and C++ still cannot compile this: int foo() { return bar(); } int bar() { return 3; }
Is it because bar is defined after foo?
Re: DConf 2026 in London
#19Earlier quoted context omitted.
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 exceptio…
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.
Re: DConf 2026 in London
#20Earlier 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
It's been a while since I looked at Zig. I couldn't say anything intelligent about it without some study. I used to be a big fan of C++ exceptions, but eventually soured on it for various reasons. Here's an article partially addressing it from a while back: https://dlang.org/articles/exception-safe.html
I think there is nothing better than exceptions + RAII for error handling since exceptions cannot be ignored by accident.
I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.
Sometimes you might not need exceptions and something like std::expected or optional is better.
In my case I use expected for some network APIs since I expect failures to happen out of my control aspart of the flow of my program, but I do not see why I would not use exceptions in many other situations, such as for non-ignorsble errors. I could think of a lack of disk space or some other fatal error thst is not under the control of the program.
If you forget to handle this, the error will cascade.
Also, exceptions do not make the signature of a function change (at least not in C++, Java checked exceptions is different). This means that the plasticity for adding errors at any depth of the call stack augments without bypassing any error silently.
All in all, I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.