| > 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. |
It does, but the user doesn't see them.
There are people working on 1, 2 and 3.
> 4. backwards compatibility (heard complaints of versions breaking stuff frequently around).
We listened, and cut way back on breaking changes. Now we have editions.
> 5. interaction with C++.
C++ has gotten to the point where it would take another decade of my time to wire in ImportC++. However, if you stick with C++'s C interface when interfacing with D, you should be fine. D will also work with C++ name mangling, but all the complexity of C++ templates and such is just too much.
And thank you for the kind words! I definitely appreciate it.
> I am far and cannot attend, so I will definitely watch it.
Wonderful!