D Language Foundation Monthly Meeting Summary for December 2022

[ryuukk_]

On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
> Robert spoke up then to suggest deprecating @property and 
> releasing a tool that removes it from a code base. Then we 
> should apply that tool to create pull requests for all dub 
> packages using @property, and then in a future release, we kill 
> it. Anyone affected by the removal can then run the tool on 
> their own code. He added that we should do this with any 
> feature we decide to remove. This is the modern way of software 
> development: you don't just break someone's code, you break 
> their code and give them a tool to fix it.

I agree with that 100%, perhaps the feature should be built in 
into DUB, it can already detect the compilers and its version, so 
it can do all the heavy lifting already


> Compile times keep getting slower. Why doesn't an LSP 
> implementation come with DMD? Why don't we have a compiler 
> daemon? Why aren't his build times sub one second?

All my projects  fully recompile in around 1s, i am sad when i 
see libraries that tank the compile speed to multiple seconds..

I ended up writing my own runtime and my own std, this is why i 
advocate for language enhancements rather than putting more 
template soup into the std

And i agree even more on the language server, Jan did an amazing 
work with serve-d, but it highlights 2 problems:

- slow to compile, wich makes contributing a pain
- DCD is basically too basic, doesn't even support most D 
features including templates



>  SumType is really awesome, and we should really do something 
> with it.


I agree, SumType is a great piece of library, it should be 
promoted as a language feature

> The first involved dub's settings file, settings.json. As he 
> put it, have you ever seen a program that asked you to write 
> its settings using JSON? There had been some favorable 
> responses to the idea of moving to YAML from some core 
> contributors a few years back. It just needed someone to do it. 
> He asked if we were okay with the move. Átila said we probably 
> shouldn't keep JSON, but wondered if YAML was the best choice. 
> What about TOML? This sparked a minor bikeshedding discussion, 
> but there was no major opposition to Mathias's plan. (He has 
> since opened a draft PR. Sönke Ludwig wants to see a broader 
> discussion of this before finalizing it, so I expect Mathias 
> will ask for community feedback at some point.)

I agree, json is not a good file format, it doesn't even support 
comments and is annoying to parse

A simple ini file would be 10x better already, no need 
complicated parsers like YAML or TML



> Robert thinks Rust has won that game. We're the second person 
> to the moon. Put @safe on top, disallow taking addresses of the 
> stack, don't allow returning ref, and don't allow pointer 
> arithmetic. That's as safe as we need to be. D's niche is on 
> top of Rust and under TypeScript. That's where we need to be. 
> That may not be the most popular opinion in the group, but he 
> was alone in his room and no one could hurt him. He thinks C++ 
> has been sinking, but it's probably going to keep sinking until 
> he's dead and will never sink completely, but Rust will take 
> that over. Rust is also taking over some of the web world 
> because it compiles easily to web assembly.


I DISAGREE fully, Rust has not won "that game", there is a 
similar negative sentiment about rust, "too complicated", "too 
hard", "bad syntax", "slow to compile", etc

The future will be many languages, each being best at certain 
domains, we seen it with the rise of Go, doing what it do best 
with the cli/web/server/containers and nothing else

WASM? C/C++ won the game, Abobe is the perfect example, it's not 
simple hello world Rust people are doing, it's full commercial 
projects https://web.dev/ps-on-the-web/

Same with games