Thanks Atila! I'm curious about your work around reflection, care to give more details? This is one of the great strength of D, and having some API consolidation sounds awesome. Also: any opinion about runtime reflection capabilities? I love compile-time reflection as much as any other D user, but sometimes runtime reflection can do wonders if used parsimoniously.

I personally believe that it's all about _people_. How do you plan to push the community forward? After all everyone just shares their free time.

So far based on what I've observed, people in the D community is the biggest critique of it's own, even more so than any other community I've seen on the internet.

The D forum is full of shit posts thrashing D for what it is.

In a recent blog post Walter talked about adding borrowing to D. Is this planned to be implemented and if so do you see any hurdles and/or benefits in relation to your Vision?

Looking forward what new perspective you bring to the community!

I have to admit I totally latched onto the point you made about fast development time.

The interpreter+compiler approach is something I've been pining for for a little while now. I've only just begun to punch holes in my obsessive tendency to only use interpreted languages (because I hate compile waits that much), and to me having the fast-iteration times of interpreters, and _also_ -O3 when it's needed, would be the best of all the worlds; IMHO JITs are a necessary hack for dynamic/untyped(/interpreted) languages, and there are serious real-world gains to be had from having the plumbing get done that lets people jump from interpretation, over JITs, straight to optimized AOT-compiled code.

Would be quite the project though, to port a fundamentally-compiled ecosystem like D to use an interpreter. I wonder how long a realistic timeframe to "minimally practically usable" would be.

Thinking about it, Cling (https://root.cern.ch/cling, https://github.com/root-project/cling, LGPL 2.1) wires Clang's C AST into LLVM's built-in JIT (IIUC) to get a C/C++ interpreter. D has LDC, so there is already integration of the UI/NCSAOSL and understanding of how to leverage LLVM. Perhaps a workable direction (with probably a lot of domain-specific knowledge already worked out and potentially available from ROOT) could be a Cling-like s/Clang/LDC/->LLVM ?

Another thought: using an approach like the above, it might be possible to add pragmas that specify whether functions should be AOTed or JITed, and how much JIT optimization should be done. I also wonder if the LLVM JIT can be told/forced to "precompile this specific function" (effectively AOTing just that function), within the JIT hot-code-replacement framework; if this were possible you could even hot-reload running code (with per-function/per-file/etc customizable optimization levels). IMHO it may be interesting to make this functionality available, and let the community/ecosystem work through the messiness of solving things like the struct-versioning problem. Clear communication would be important to rationalize and clarify the deliberateness of such a decision, of course, and that the language [design] hadn't gone completely nuts :) due to the number of segfaults/developer burnout/etc it would probably introduce.

What happened to Andrei?

Is there any impetus in the community towards embedded development? By embedded I mean natively on microcontrollers, even if you were limited to 32 bit ARM platforms?

As a portion of our work targets micros, all of our code needs to be written in a language that supports micros so that we can share code. There is impetus to move on from C, but Rust is the first and only viable replacement candidate because of this.

The interpreter thing could work better in the current software landscape if it could be integrated in Jupyter notebooks.

Nowadays many people are migrating to Python to use machine learning in Jupyter or just to run machine learning code in Python.