DLF September 2023 Planning Update

[Mike Shah]

On Tuesday, 14 November 2023 at 21:13:34 UTC, monkyyy wrote:
> On Tuesday, 14 November 2023 at 08:18:20 UTC, Mike Parker wrote:
>> ## The future of D
>> Robert had been itching to talk about our long-term plans for 
>> D. I think most of us understood that he was talking in terms 
>> of language features, but in this session, he explained that's 
>> not what he meant. D started as a successor to C and C++, but 
>> he doesn't see the language that way. He sees it as the best 
>> parts of C, Haskell, and Python. Others may see it 
>> differently. So how do we define the language going forward? 
>> What role do we want it to play? Are we mostly concerned with 
>> C-style stuff where every bit counts? Do we see D as a great 
>> tool for one-off scripts that would normally be written in 
>> something like Python?
>
>
> D is not and has never been a c replacement language, your not 
> Zig, there's a very real dependency on gc(and no @nogc/betterc 
> doesn't change that, you have first-class dynamic arrays based 
> on the gc) theres a grand total of 3 platforms where d is 
> stable and it will never be the portable asm of C; no embedded, 
> no gnu, no unix, and no credible aspirations to change that.
>
> D *is* a c++ replacement, c++ isn't very good at its job, and 
> while I dont know how somehow aa managed to convince walter to 
> merge in lots of quality of life stuff for the template hell. 
> Please focus on making the template hell, survivable and either 
> take it upon yourself to make the stl or enable its conditions.
>
> D isn't haskell, sumtypes aren't even a first-class abstraction 
> I simply don't know what someone could've said that made that 
> on the table.
>
> ~~python sucks and is irrelevant ~~

>Do we see D as a great tool for one-off scripts that would 
>normally be written in something like Python?

D has replaced every single file Python script that I use. Fast 
build times (DMD), multiple programming paradigms, and 
concurrency support are huge wins for D over languages like 
Python.

The major advantage with D (over Python) is building/maintaining 
scalable applications (i.e. more than one file, but several 
thousand or hundred thousand lines of code).  Talking to several 
engineers over that past few years in a few big tech companies -- 
they have spent a significant amount of time rewriting their code 
from Python to C++ because of issues with Python (performance and 
dynamic typing being culprits in Python). Too bad they did not 
start with D to avoid a rewrite! :)

>>What do we want the first experience with D to be like?

>>A person trying out D, who writes a one-file simple application 
>>using phobos does not care that a lib abandoned in 2018 still 
>>compiles. So why should they be the ones paying the penalty?

I just want to echo Steve's sentiment, that it should be easy for 
new (and old) D users to start up a project without worrying 
about editions. Reducing friction is incredibly important for 
adoption and usage. If the library writer specifies the 'edition' 
within their own module and it's totally encapsulated, that seems 
fine -- I think that is what I understand from the editions 
proposal (and if they don't specify the edition, it defaults to 
whatever the compilers default edition is).

I'd be curious to hear what folks working on tooling (IDE, 
linters, etc.) concerns are with editions. Having more tooling 
support is the main request I hear from students (Again, maybe 
this is already answered with DMD as a library in progress).