Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DConf 2026 in London

dconf.org

Post reply on HN
Print view View original

21–30 of 71 posts

Re: DConf 2026 in London

#21

Post by WalterBright »

vips7L wrote: post #18
WalterBright wrote: post #17

Earlier quoted context omitted.

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?

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?

Re: DConf 2026 in London

#22

Post by gregdaniels421 »

germandiago wrote: post #20
WalterBright wrote: post #10

Earlier quoted context omitted.

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 f…

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.

It has better than that, but it is a bit clunky compared with C++(just use struct instead of class). You can have proper destructors, but if you have a container you need to be more careful than in C++.

In D exceptions are the default like in C++ and you have to opt out with nothrow or extern(C) or betterC.

Really try some D code in a bigger situation it is 90% good and almost worth using over C++, but if you can't have GC it is a huge pain, but better than C.

Re: DConf 2026 in London

#23

Post by WalterBright »

germandiago wrote: post #20
WalterBright wrote: post #10

Earlier quoted context omitted.

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 f…

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC.

D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC.

> I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types.

Come to DConf (or watch the live stream) and I hope I can change your mind, or at least challenge your conclusions!

Re: DConf 2026 in London

#24

Post by gregdaniels421 »

destructionator wrote: post #19
gregdaniels421 wrote: post #15

Earlier quoted context omitted.

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

Re: DConf 2026 in London

#25

Post by WalterBright »

swyx wrote: post #13
WalterBright wrote: post #4

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.

would you ever do an SF edition? would be happy to host for you. i do a lot of conferences.

What's an SF edition?

Re: DConf 2026 in London

#27

Post by wannabe44 »

gregdaniels421 wrote: post #6
WalterBright wrote: post #4

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.

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 was the throwing values proposal. Bjarne was not satisfied with the proposal because it didn't interact well with existing exceptions code.

Re: DConf 2026 in London

#28

Post by WalterBright »

gregdaniels421 wrote: post #22
germandiago wrote: post #20

Earlier quoted context omitted.

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 f…

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC. It has better than that, but it is a bit clunky compared with C++(just use struct instead of class). You can have proper destructors, but if you have a container you need to be more careful than in C++. In D exceptions are the default like in C++ and you have to opt out with nothrow or extern(C) or betterC. Really try some D code…

I've never understood why GC would be a huge pain. It makes some things a lot easier, like Compile Time Function Execution.

Also, recently the GC implementation received a big modernization upgrade.

Re: DConf 2026 in London

#29

Post by germandiago »

WalterBright wrote: post #23
germandiago wrote: post #20

Earlier quoted context omitted.

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 f…

> I would classify D's scope exit/failure/success as RAII actually, even if D uses a GC. D's scope exit/failure/success is built on top of RAII and has nothing to do with the GC. > I would say exceptions should be the main mechanism in normal circumstances and for expected errors you csn use error/result types. Come to DConf (or watch the live stream) and I hope I can change your mind, or at least challenge your conc…

> 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 it intensively). I have extremely high respect for you as a language designer and as a technician. Your knowledge is very refined, so I never take your opinions lightly.

Probably one of the most knowledgeable persons in the industry for native language design. However, I am far and cannot attend, so I will definitely watch it.

> or at least challenge your conclusions!

No problem in challenging them. I am always open to do things better. This is just my practical experience as I implement stuff so far.

I currently think exceptions seems like a good default mechanism (apparently at least) compared to alternatives. But I also think other mechanisms have their place and can/should be used even in the same program, just for different things.

All mechanisms have trade-offs. I just talked about defaults from my POV for the kind of software I develop (mostly server-side, some client-side, and not embedded in the extremely constrained sense).

-----------------------------

One question: I tried to use D several times in my career (20 years of C++ experience here, roughly). I found it a lot of fun. I like it better than more "modern languages". I like the plasticity D provides. But I am not sure how it would work if I want to do:

   1. backend (server-side mainly, Linux is main platform, x86-64)
   2. desktop + android and iOS (being mobile more important than desktop)
   3. web assembly (even more important than mobile at this moment, could change).
   4. backwards compatibility (heard complaints of versions breaking stuff frequently around).
   5. interaction with C++.
I do like D a lot, but the problems I had before were more related to tooling (autocomplete, I use mainly Emacs but did not try for a few years) and toolchain maturity.

It would be ready for all of the above? Also, very very handy would be to wrap C++ code and C code. I saw that D had an ongoing effort for C++ compatibility better than other languages, but I am afraid it could be half-broken. Even if it is, it is documented what works and what does not work? That would help a lot.

Thanks.

Re: DConf 2026 in London

#30

Post by CapsAdmin »

WalterBright wrote: post #21
vips7L wrote: post #18

Earlier quoted context omitted.

Is it because bar is defined after foo?

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?

Lua has the same problem with local functions, and Lua was the first language I learned that I still use today. So it feels very natural for me to see local functions with no dependencies at the top, and the ones with the most dependencies at the bottom. (but you can work around this in lua with globals, forward declarations, functions in tables, etc)

So I guess I kind of prefer seeing helper functions at the top and the main logic at the bottom most of the time.

Post reply on HN