D Language Foundation Monthly Meeting Summary for December 2022

[H. S. Teoh]

On Sat, Jan 21, 2023 at 04:29:28AM +0000, Mike Parker via Digitalmars-d-announce wrote:
[...]
> __CTFE writeln__
> 
> Razvan next brought up [a PR to implement a `__ctfeWriteln`
> built-in](https://github.com/dlang/dmd/pull/12412). It was currently
> stalled and needed Walter's approval. Walter asked Razvan to email him
> about it. He subsequently approved it.

This may seem like a small item, but it's a landmark!!  The first PR for
this was submitted back in 2011 (https://github.com/dlang/dmd/pull/296),
superceded in in 2012 (https://github.com/dlang/dmd/pull/692), revived
in 2016 (https://github.com/dlang/dmd/pull/6101), re-attempted in 2017
(https://github.com/dlang/dmd/pull/7082), submitted in its present form
in Apr 2021 (https://github.com/dlang/dmd/pull/12412), and finally
approved in Dec 2022.  This is monumental!

OTOH, it begs the question, is there any way to improve our present
process so that relatively small features like these don't take 11 years
to get implemented?


[...]
> ### Ali
> Ali reported that he had finished the new D program at work he had
> [told us about in the November
> meeting](https://forum.dlang.org/thread/citxnklerlvqmybyoaat@forum.dlang.org).
> It had uncovered a performance issue with `std.file.dirEntries`. As
> for the program, he was happy with the end result.
> 
> He said he'd used `std.parallelism.parallel` again and speculated he's
> probably among the people who've used it most. He said it helps
> tremendously. It's very simple and everything becomes very fast.

Just wanted to chime in here to say that std.parallelism.parallel is
absolutely awesome, and I've been using it in a few of my projects for
what amounts to instant speed-up "for free".

The original design hit jackpot in making it as easy as possible to turn
a regular foreach loop into a parallel loop: just add .parallel to your
aggregate. This makes it trivial to test the performance gains of
parallelizing any given foreach loop (with independent iterations, of
course). You didn't have to invest a ton of time writing code to
instantiate task managers, task pools, create threads, manage threads,
wait for them to finish, etc.. For highly-specific performance tweaks,
you'd probably want to do all that, but for one-off quick evaluations of
whether a parallel approach is even worth it in the first place, the
design of .parallel is exactly the thing needed. Once you've confirmed
it works, you can, if needed, invest more effort into managing task
pools, etc..  If not, you haven't wasted any effort except writing
`.parallel` -- it's basically zero cost.  And for script-like helper
utilities, .parallel is just the thing you need to get the job done in
the shortest amount of time possible.  No need for anything more
elaborate.


[...]
> ### Walter
[...]
> He then said that he had noticed in discussions on HN and elsewhere a
> tectonic shift appears to be going on: C++ appears to be sinking.
> There seems to be a lot more negativity out there about it these days.
> He doesn't know how big this is, but it seems to be a major shift.
> People are realizing that there are intractable problems with C++,
> it's getting too complicated, they don't like the way code looks when
> writing C++, memory safety has come to the fore and C++ doesn't deal
> with it effectively, etc.

The inevitable is happening.  Has been happening, just on a smaller
scale.  But it will only grow.


[...]
> Robert thinks Rust has won that game. [...] Rust is also taking over
> some of the web world because it compiles easily to web assembly.

LDC already compiles to WASM.  It's a crucial first step.  But the
usability level of D in WASM is currently wayyy below what it would take
to win people over.  If we want to win this game, we need to get WASM
support to the point that you could in theory just recompile a D program
and have it work in WASM without any change.  Well, excepting, of
course, stuff that WASM fundamentally can't do.

Currently, you can compile individual functions, but you can't have
main(), you can't use Phobos, you can't use the GC, and you need to
write a lot of JS boilerplate to have your WASM D code interact with
anything outside its own little bubble.  Strictly speaking this isn't
D's problem, but that's cold comfort for anyone who wants to develop for
WASM in D.  Yeah, writing JS and HTML is part-and-parcel of targeting
WASM, but why can't we make our packaging better?  There should be a
tool for auto-generating JS wrappers, perhaps even HTML snippets, so
that a user literally can just write:

	import std;	// OK, maybe import std.wasm or something
	void main() { writeln("Hello, world!");

and get a webpage that prints that message in a browser window without
writing a single line of JS or HTML.  All the JS boilerplate and HTML
tedium should be automatically taken care of, unless the user overrides
something.

Using WASM with D should be on the level of usability of appending
.parallel to your aggregate to get a parallel foreach loop; it shouldn't
require you to write a ton of JS boilerplate and constrict your D code
to the equivalent of jumping backwards with one hand tied behind your
back.


> Walter agreed that C++ will never disappear, but he thinks it will
> fade into the background.
[...]

That I agree with.  My prediction is that C will also gradually fade
into the background and eventually be confined to small niches, but
won't entirely disappear.  Merely become irrelevant.  From my POV, C may
outlast C++ in terms of persistence before becoming irrelevant.  In
spite of all its flaws, C is overall still a cleaner language than C++
and has fewer fundamental design issues that make it unusably
frustrating.


T

-- 
Let's call it an accidental feature. -- Larry Wall