6 ms·

DConf 2026 in London

126 points by teleforce 2mo ago

OSaMaBiNLoGiN 2mo ago
Good language.
- WalterBright 2mo ago
  Most elegant language!
gregdaniels421 2mo ago
First 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 less mess with calling __xdtor when trying to do RAII
- destructionator 2mo ago
  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_25.html 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.
  - gregdaniels421 2mo ago
    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.
    - destructionator 2mo ago
      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 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.
      - gregdaniels421 2mo ago
        > 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 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).
- p0nce 2mo ago
  > 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.
WalterBright 2mo ago
I 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.
- gregdaniels421 2mo ago
  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
  - WalterBright 2mo ago
    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 https://dlang.org/articles/exception-safe.html
    - germandiago 2mo ago
      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.
qwe----3 2mo ago
I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past
- swyx 2mo ago
  for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
  - zem 2mo ago
    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++.
    - WalterBright 2mo ago
      For example, C and C++ still cannot compile this: int foo() { return bar(); } int bar() { return 3; }
      - vips7L 2mo ago
        Is it because bar is defined after foo?
        WalterBright 2mo ago
        Yes. It has deleterious consequences. One solution is to add a forward declaration, which is the kind of busywork a language is supposed to eliminate. Another is to reverse the natural order of functions, with the implementation functions at the top and the interface of the module at the bottom. After all, do you read a website from top to bottom or bottom to top?
        2mo ago
bayesnet 2mo ago
What’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/ https://opendlang.org/
- destructionator 2mo ago
  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.
cachius 2mo ago
Cool that the low-level configuration system and settings management tool of GNOME 3 gets its own conference! https://en.wikipedia.org/wiki/Dconf https://en.wikipedia.org/wiki/Dconf
p0nce 2mo ago
Even if you don't use D, I highly recommend watching some of the talks since I find them interesting and dense in information.
nubinetwork 2mo ago
We really have a problem naming things... this is the d language conference, not the gnome dbus configuration system...
jpfromlondon 2mo ago
I had no idea Code Node was still going strong, I used to goto a lot of events there
Ferret7446 2mo ago
I came in here wondering why a config database is in London. It's quite unfortunate to name your conference after a much more popular, or at least widely used software (try searching dconf in a non personalized search engine)

126 points by teleforce 2mo ago

OSaMaBiNLoGiN 2mo ago

Good language.

WalterBright 2mo ago
Most elegant language!

gregdaniels421 2mo ago

First 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 less mess with calling __xdtor when trying to do RAII

destructionator 2mo ago
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_25.html 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.
- gregdaniels421 2mo ago
  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.
  - destructionator 2mo ago
    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 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.
    - gregdaniels421 2mo ago
      > 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 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).
p0nce 2mo ago
> 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.

WalterBright 2mo ago

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

gregdaniels421 2mo ago
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
- WalterBright 2mo ago
  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 https://dlang.org/articles/exception-safe.html
  - germandiago 2mo ago
    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.

qwe----3 2mo ago

I don't know why but dlang continues to draw me - I've really enjoyed many of the talks in the past

swyx 2mo ago
for those (like me) completely new but interested in new programming languages - can you or similar minds summarize the current appeal?
- zem 2mo ago
  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++.
  - WalterBright 2mo ago
    For example, C and C++ still cannot compile this: int foo() { return bar(); } int bar() { return 3; }
    - vips7L 2mo ago
      Is it because bar is defined after foo?
      - WalterBright 2mo ago
        Yes. It has deleterious consequences. One solution is to add a forward declaration, which is the kind of busywork a language is supposed to eliminate. Another is to reverse the natural order of functions, with the implementation functions at the top and the interface of the module at the bottom. After all, do you read a website from top to bottom or bottom to top?
        2mo ago

bayesnet 2mo ago

What’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/ https://opendlang.org/

destructionator 2mo ago
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.

cachius 2mo ago

Cool that the low-level configuration system and settings management tool of GNOME 3 gets its own conference! https://en.wikipedia.org/wiki/Dconf https://en.wikipedia.org/wiki/Dconf

p0nce 2mo ago

Even if you don't use D, I highly recommend watching some of the talks since I find them interesting and dense in information.

nubinetwork 2mo ago

We really have a problem naming things... this is the d language conference, not the gnome dbus configuration system...

jpfromlondon 2mo ago

I had no idea Code Node was still going strong, I used to goto a lot of events there

Ferret7446 2mo ago

I came in here wondering why a config database is in London. It's quite unfortunate to name your conference after a much more popular, or at least widely used software (try searching dconf in a non personalized search engine)