Re: D Language Foundation Monthly Meeting Summary for May 2023
On Tuesday, 27 June 2023 at 14:18:52 UTC, Mike Parker wrote: I still will put at least three or four weeks between the meetings and the summaries. I appreciate your summary here. This was very insightful!
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Tuesday, 27 June 2023 at 12:36:20 UTC, Sergey wrote: After that real person could verify result and make small corrections. It should significantly reduce effort and decrease time-to-market :) Yes. The next version of Davinci Resolve (which I use for video editing) will have automated transcriptions. Once it's released, I intend to start loading my meeting recordings into it and then derive my summaries from that. However, I still will write the summaries as summaries, rather than publishing the transcripts directly or otherwise quoting them verbatim. This will save me from having to go back and forth through the video, so it will certainly save time. I still will put at least three or four weeks between the meetings and the summaries. One benefit I've found in the delay is that it's an easy way for me to follow up on any actionable items. As I'm writing a summary, I can check on the status of issues, follow up with anyone who said they'd do something, etc. Then I don't have to worry about taking notes during the meeting, I can add the current status directly into the summary, and anything that's not done by the time I write it up I can stay on top of.
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote: The monthly meeting for May 2023 took place on Friday the 5th at 14:00 UTC. It lasted about an hour and a half. Hi Mike. Does anyone consider some automatization and application of modern technologies for the process of meeting summarization? Like NN that: * record the sound from the call * make sound to text (with different speakers) * make text summarization * generate report After that real person could verify result and make small corrections. It should significantly reduce effort and decrease time-to-market :)
Re: D Language Foundation Monthly Meeting Summary for May 2023
If you feel up to doing a practice talk, you're welcome to join us on BeerConf!
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote: [...] Walter brought up [Sebastiaan Koppe's presentation from last year](https://youtu.be/hJhNhIeq29U) on structured concurrency. He said he'd like to see Sebastiaan there this year for an update on the project, preferably as a follow-up presentation. He was excited about the project and felt it was a big deal in general and a big deal for D. Even if Sebastiaan decided not to move the project forward, Walter felt we should find someone to take it over. He said the ideas behind it were big and would be a nice thing for us. (We subsequently confirmed with Sebastiaan that he didn't have enough material yet for a follow-up talk). [...] For anyone interested, this is still very much alive. In fact, the lovely folks at https://github.com/NVIDIA/stdexec have validated several ideas I had for improving things, and I have been using any spare time I have left - which isn't much sadly - to incorporate these concepts. I hope to find some time to do a lighting talk.
Re: D Language Foundation Monthly Meeting Summary for May 2023
On Friday, 23 June 2023 at 14:32:51 UTC, Mike Parker wrote: The monthly meeting for May 2023 took place on Friday the 5th at 14:00 UTC. It lasted about an hour and a half. This was the last meeting before we started our new planning sessions. Nice to read on what you guys are doing! — Dmitry Olshansky CEO at Glow labs https://sponsr.ru/glow https://patreon.com/dmitry_glow_labs
D Language Foundation Monthly Meeting Summary for May 2023
The monthly meeting for May 2023 took place on Friday the 5th at 14:00 UTC. It lasted about an hour and a half. This was the last meeting before we started our new planning sessions. The following people attended: * Walter Bright * Iain Buclaw * Ali Çehreli * Martin Kinkelin * Dennis Korpel * Mathias Lang * Razvan Nitu * Mike Parker * Robert Schadek ## The summary ### Me I started with an update on DConf submissions, reporting the numbers and some of the details on who and what. At that point, we had a total of 11 submissions from 8 people. I suggested we could put a panel in one of the open slots if we needed to and asked everyone to think of some ideas. (We ended up with 39 submissions from 21 people, or 24 if you count the additional three members of the one team that submitted, and had no room at all for a panel). Next, I told everyone we had secured some [sponsorship funding from Ahrefs](https://ahrefs.com/) and noted that I planned to use it for BeerConf. I hoped to rent the same space we rented last year at The Fox, so I detailed how I was going to work out paying for it via our event planner. Last year, Funkwerk provided the funding to the DLF, Átila and Walter each paid one or more nights on their credit cards, and the DLF reimbursed them. (Unfortunately, pub hire rates this year have massively increased over last year, putting them well beyond our budget. We've fallen back to the old way of designating a hotel as the BeerConf location, this time Travelodge Central City Road. The sponsorship funding will go toward our speaker reimbursement budget.) Next, I gave an update on registrations. At that point, only one person had registered. I then talked about some email exchanges I'd had with some D shops about possible sponsorships. (Our current headcount as of June 23 is 43. I'm anticipating a final number in the neighborhood of 60-70, which would be in the same ballpark as last year.) Walter brought up [Sebastiaan Koppe's presentation from last year](https://youtu.be/hJhNhIeq29U) on structured concurrency. He said he'd like to see Sebastiaan there this year for an update on the project, preferably as a follow-up presentation. He was excited about the project and felt it was a big deal in general and a big deal for D. Even if Sebastiaan decided not to move the project forward, Walter felt we should find someone to take it over. He said the ideas behind it were big and would be a nice thing for us. (We subsequently confirmed with Sebastiaan that he didn't have enough material yet for a follow-up talk). I summed up by saying that DConf planning was on track and there were no issues so far. Later, I remembered to mention that I had Robert's GitHub to Bugzilla migration script in hand. Now it was just waiting on me to make time to test it out, so I was the blocker now rather than Robert. He warned me about a command line option I should leave off while testing. (You can read about the progress on that [in the General forum](https://forum.dlang.org/thread/pfpoeaoihsqpohumj...@forum.dlang.org) and track our progress [on our GitHub projects page](https://github.com/orgs/dlang/projects/23?pane=issue=29572916.)).) I asked about some issues that [had been migrated to the tools repository](https://github.com/dlang/tools/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) from Bugzilla. Robert said that was not from him. Mathias jumped in to say that he had done it a long time ago when he took a stab at this. He had closed all of the Bugzilla issues he'd migrated, so there would be no duplications when migrating the open ones. ### Iain Iain opened what turned into a 25-minute segment by saying that he hadn't gotten much done since the middle of March as he'd spent several long weekends on holiday. He'd released D 2.103.0 in April and 2.103.1 on May 1. He had also pushed out the first beta of 2.104.0, and it was on track for release at the end of the month ([he announced it on June 2](https://forum.dlang.org/thread/waigfuztqsqlhzouj...@forum.dlang.org)). He said that GCC 13.1 had been released on April 26. That included version 2.103 of the D frontend in GDC. Walter thanked Iain for handling the releases for us. Martin asked how long the release process takes nowadays. Iain said it depends on if he hits an issue building the Windows release. The Windows box, and *only* the Windows box, seems to hit a file system sync issue. There's a D program, `copyimports.exe`, that had replaced several make recipes to copy files during the build. Sometimes when building the releases, `make` tries to call that program before the linker has created the executable. When that happens, it aborts and Iain has to run the release process from the start again. [He had filed an issue](https://issues.dlang.org/show_bug.cgi?id=23486) for it. If everything goes smoothly, it's about a two-hour process. The biggest part of that is waiting for the builds to
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/28/2023 5:04 AM, Johan wrote: Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code? No. We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors. It's been a while, but I think the only difference is if you're taking the address of a property. Without the @property, the address of the function will be taken. With @property, the address of the return value will be taken. This will affect inference, such as `auto x = ` That will likely lead to type mismatch errors further down the line, but I can't guarantee it. The best approach I can recommend is to remove the @propertys a handful at a time, checking them into git, and running your test suite to check for any failures. This will make `git bisect` invaluable in tracking down the cause of any errors that are missed by the test suite.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 28 January 2023 at 13:04:33 UTC, Johan wrote:
Is there a document describing cases where removal of
`@property` does not lead to an error but does lead to a change
in behavior of code?
We are considering a blanket removal of 3000+ instances of
`@property`. The resulting compile errors I can fix (unless
they happen in speculative instantiations, they may be harder
to track down), but I am especially worried about changes in
behavior that do not lead to compile warnings/errors.
Given that the only thing `@property` actually does is change the
result of `typeof` in certain situations, the behavior changes
will probably be things like the following:
```d
static if (typeof(foo.bar) == T) {
// foo has a `T bar` property
} else {
// doesn't have it
}
```
Currently, if `foo` has a `@property T bar();`, this code will
take the first branch. If `@property` is removed, it will take
the second.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: Razvan noted that simplifying the language is part of our vision, and this seems like a good candidate. Walter agreed. Dennis suggested going through DRuntime and Phobos to look at all instances of `@property` and seeing if they could be removed. Walter agreed. Is there a document describing cases where removal of `@property` does not lead to an error but does lead to a change in behavior of code? We are considering a blanket removal of 3000+ instances of `@property`. The resulting compile errors I can fix (unless they happen in speculative instantiations, they may be harder to track down), but I am especially worried about changes in behavior that do not lead to compile warnings/errors. Thanks a lot, Johan
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/23/2023 11:21 PM, Siarhei Siamashka wrote: But the safety is not exactly great. It does (and always has) resolved the #1 memory safety problem - buffer overflows. If you use @safe, and the GC for allocations, it is just as memory safe as Python.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: Robert thinks Rust has won that game. We're the second person to the moon. Do you mean second to last? The safety offered by D language currently only looks good when compared to C/C++, but is worse than pretty much any of the other popular/mainstream languages. D language even did not invent memory safety, because the other safe languages existed long before it (such as Python, etc.). The strong point of D language is a convenient syntax combined with full native speed of compiled binaries. And also compilation speed for those who care about it. But the safety is not exactly great. And compatibility breaking habits are also bad. D can't realistically compete with Rust on the safety front and with C/C++ on the compatibility front. 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. I like this proposal. Will it actually happen?
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Monday, 23 January 2023 at 21:26:56 UTC, H. S. Teoh wrote:
On Mon, Jan 23, 2023 at 08:43:03PM +, Adam D Ruppe via
Digitalmars-d-announce wrote:
On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
> 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.
http://webassembly.arsdnet.net/
Paste in
import std.stdio;
void main() { writeln("hello world"); }
to the box on that page
and get
http://webassembly.arsdnet.net/usertemp
Ahahahaha... just like Adam to have already dunnit while I'm
still twiddling my fingers wondering how to go about doing it.
:-D Now all we need is to package your little page up into a
dub package or something (personally I prefer just a tarball)
and we're good to go. :-D
Webassembly is a trash target but like been there done that.
Yeah TBH after dabbling with it a little I realized just how
much it was still dependent on JS to do the heavy lifting. You
can't even pass strings across the JS/WASM boundary without
truckloads of JS boilerplate. The C-like API isn't officially
part of the WASM standard yet, and they're still trying to
figure out how GC might work. As far as I'm concerned, it's
still early adopter tech, not yet stable enough for me to
invest in.
Of course there are some caveats in what works, there have
been come contributions coming in from hipreme recently to
extend it a lil.
Nice. Can it handle WebGL yet? I betcha that'd be the second
question a newbie to D would ask after asking about WASM. :-P
T
I was going to wait a little bit on that announcement. But yes,
Hipreme Engine has already been completely ported to WASM. File
loading, rendering with my abstraction, audio playing,
image/audio decoding, input system, I've got pretty much
everything working. WASM only changed in my engine how the file
loading is handled internally. An example, It sends D delegates
to JS execute when things are complete, so, there isn't anymore a
sync API for loading files.
I have used arsd.cgi for making it easy to any D programmer host
it with dub. I have posted on Learn like yesterday how to
integrate the custom runtime with any dub project too, which is
how I'm using to build for my engine.
The list of features being supported are:
- new
- string switch
- classes (inheritance and abstract included)
- interfaces
- every array operation
- every associative array operation
- RAII
- delegates and function pointers
- assertion
- throw should work. Catching don't
- RTTI (typeid and other things that depends on it)
- All the compile time features seems to be working finely
- main() and it will run as expected.
- string utf decoding
Unsupported features:
- static this/~this (should be easy to implement though, my
engine has no need to do that, specially since it uses a lot of
DLL for Android and Xbox and static this is quite buggy for it
anyway)
- try/catch
- fibers
The problem on try/catch/fiber are the same. They need stack
unwinding and from what I've looked, this implementation needs
compiler developers to write a little of assembly to get this
working, as I have no idea on how that works, I can't implement
that.
I believe this covers like 90% the usage of one using the
druntime.
I honestly don't care about throw/catch. Specially for gamedev
which is my aim, the code doesn't need to "protect" from itself.
That being said, if one is not using Hipreme Engine and is using
a lot of standard library, this one would need to implement a lot
of it. Hipreme Engine implements a minimal phobos (as I don't
implement the entire libc) for being used. Needless to say, some
modules from phobos didn't need to adapt to WASM, so,
`std.algorithm` and `std.traits` are being used from upstream.
std.math was possible to copy/paste without too much work to do
(A matter of 5 lines I think).
I'm also using arsd.ttf to runtime create text textures, a
library which does not uses any of my modules, no bug was found
on it, so, this is mostly a matter of giving a little of effort
and everything can be done.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Mon, Jan 23, 2023 at 08:43:03PM +, Adam D Ruppe via
Digitalmars-d-announce wrote:
> On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
> > 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.
>
> http://webassembly.arsdnet.net/
>
> Paste in
> import std.stdio;
> void main() { writeln("hello world"); }
>
> to the box on that page
>
> and get
> http://webassembly.arsdnet.net/usertemp
Ahahahaha... just like Adam to have already dunnit while I'm still
twiddling my fingers wondering how to go about doing it. :-D Now all we
need is to package your little page up into a dub package or something
(personally I prefer just a tarball) and we're good to go. :-D
> Webassembly is a trash target but like been there done that.
Yeah TBH after dabbling with it a little I realized just how much it was
still dependent on JS to do the heavy lifting. You can't even pass
strings across the JS/WASM boundary without truckloads of JS
boilerplate. The C-like API isn't officially part of the WASM standard
yet, and they're still trying to figure out how GC might work. As far as
I'm concerned, it's still early adopter tech, not yet stable enough for
me to invest in.
> Of course there are some caveats in what works, there have been come
> contributions coming in from hipreme recently to extend it a lil.
Nice. Can it handle WebGL yet? I betcha that'd be the second question
a newbie to D would ask after asking about WASM. :-P
T
--
I see that you JS got Bach.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On 1/23/23 12:06, H. S. Teoh wrote:
> `.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.
Yes! :)
As a heads up to those who haven't tried it yet, there are cases that
may benefit from reducing the work unit size from its default value of 100.
Especially when it's about file processing and there are a few files
that take disproportionate amount of processing time, then the thread
that is working on the largest file(s) would be holding on to 99 others
to process them later in serial fashion. This may happen when the other
e.g. 20 threads have already finished their tasks.
So, I recommend experimenting with smaller work unit sizes; I currently
use 1 for such file processing. Something like this:
auto tp = new TaskPool(totalCPUs / 2); // Thread count
foreach (e; tp.parallel(elements, 1)) { // Work unit size
// ...
}
tp.finish(); // Don't forget
as seen here:
https://youtu.be/dRORNQIB2wA?t=1692
Ali
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Monday, 23 January 2023 at 20:06:46 UTC, H. S. Teoh wrote:
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.
http://webassembly.arsdnet.net/
Paste in
import std.stdio;
void main() { writeln("hello world"); }
to the box on that page
and get
http://webassembly.arsdnet.net/usertemp
Webassembly is a trash target but like been there done that.
Of course there are some caveats in what works, there have been
come contributions coming in from hipreme recently to extend it a
lil.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Sat, Jan 21, 2023 at 04:29:28AM +, 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/citxnklerlvqmybyo...@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
Re: D Language Foundation Monthly Meeting Summary for December 2022
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
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 11:25:37 UTC, Sergey wrote: On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek Thank you Mike and all D foundation. It was very pleasant read. I am surprised how many things and details were discussed in an hour and a half! Agreed 100%, these summaries and the transparency into the decision making are great!
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote:
As far as he understood, the only time `@property` has an
effect is when you take the address of a function it annotates.
It is when you do typeof(thing.prop), not
Walter said that `__traits` is meant to be ugly.
We should revisit this decision. I don't think it ever made
sense, and especially now with the benefit of hindsight it looks
like a clear unforced error.
Robert said that doesn't solve his problem with compile times.
He has a project that doesn't use much of Phobos, but compile
times still suffer. The compiler is slow.
I'd like to know more about this project
He had previously dug into `hasUDA` and it was scary how many
recursive expansions he found.
We should also revisit the abstractions here. The more I use
these the more I've been landing on something like what Steve
described in the dconf online. It is faster to compile, more
flexible with runtime reuse, and just generally easier to
document and use.
Then we can just let hasUDA and friends die.
That goes to the idea of caching or pre-compiling the template
so that
Please note that the compiler does cache templates right now, and
it takes gigs of memory. A lot of work would have to be done to
make this good since work not done is still better than work
unnecessarily done... and if it is cached too aggressively you
just run out of memory.
If the end result is simple, we ought to be able to discard
intermediate results, but the current implementation doesn't even
allow this!
We don't have [...] `std.html` [...] We just need someone to
write them.
Yes, if only some did that 13 years ago and has been continuously
maintaining it ever since. If only ~someone~ wrote that.
Something was causing the struct configuration to take over 10
minutes to compile.
If you did any string replacements that'd slaughter your
performance, the ctfe engine is *extremely* bad at this.
In my arsd.jni, I had a string like:
enum code = q{
PRETEND_MACRO void foo() { implementation; }
};
mixin(code.replace("PRETEND_MACRO", ""));
mixin(code.replace("PRETEND_MACRO", "static"));
Those two simple lines added 30 seconds to the compile time! Just
copy/pasting it and replacing the pretend macro ahead of time cut
95% of the build time off. It was astonishing.
You can optimize some of these with mutable buffers, avoid the
concat operator in ctfe even if it means two passes through the
data. This helps a lot.
But also just using template mixins tends to work well when you
know the proper techniques.
Re: D Language Foundation Monthly Meeting Summary for December 2022
On Saturday, 21 January 2023 at 04:29:28 UTC, Mike Parker wrote: The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek Thank you Mike and all D foundation. It was very pleasant read. I am surprised how many things and details were discussed in an hour and a half!
Re: D Language Foundation Monthly Meeting Summary for December 2022
A very big problem we have right now is that we are on pretty shaky foundations with how symbols are represented at the binary image level due to DLL's not be fully implemented in dmd. Any work for things like incremental compilation must be done with the knowledge that the foundations right now are just not there to do this reliably cross platform. I.e. is incredibly easy to run into: https://learn.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4217?view=msvc-170 I believe we are going to have to modify export (and with that removing it as a visibility modifier) quite significantly. In the C/C++ world you can use macros and compiler level defines to swap out DllImport and DllExport, or remove it all together. We can't do that. Which means we are going to need to make export a whole lot smarter if we don't want to run into these issues on Windows.
D Language Foundation Monthly Meeting Summary for December 2022
The December meeting took place on the 3rd of the month at 15:00 UTC. The following people were present: * Andrei Alexandrescu * Walter Bright * Ali Çehreli * Dennis Korpel * Mathias Lang * Átila Neves * Razvan Nitu * Mike Parker * Robert Schadek The meeting lasted around an hour and a half. ## The summary ### Dennis Dennis opened by reporting that he had begun working on a DIP to use `@default` as a means of resetting attributes. He had a question about what it should affect: should it reset all attributes (including visibility attributes like `private`), or only function attributes? The unanimous consensus was that it should only affect function attributes. He has since [submitted the DIP for Draft Review](https://github.com/dlang/DIPs/pull/236). ### Razvan __@property__ In his ongoing effort to resolve old Bugzilla issues, Razvan had encountered a number of old issues regarding `@property`. Walter and Andrei had said in the past that we shouldn't support the feature anymore, and it's often recommended that people not use it. But people do still use it. So what are we going to do about it? Should we attempt to fix these old issues? Should we deprecate `@property`? Walter suggested one possible approach is just to leave it as is. Those who see a benefit in using it can continue to do so, and those who don't can avoid it. He hadn't looked into the issues surrounding `@property` in a long time and asked if this was a viable approach. As far as he understood, the only time `@property` has an effect is when you take the address of a function it annotates. Razvan said `@property` sometimes interacts with other features in unexpected ways and the spec says nothing about what it's supposed to do. Maybe we could just add something to the spec saying it shouldn't be used. Andrei said that's not what a spec is supposed to do. A spec tells you what happens when you, e.g., move your hand like this. A spec doesn't give you advice. If we're keeping it, we should spec it out even if we then never touch it again. Guides will say whether or not to use it. But we can't just leave it hanging unspecified. Ali noted that he didn't include it in his book other than to say using it is discouraged. Razvan asked how he should handle these `@property` issues in Bugzilla. Find someone to fix them or just document the behavior? Walter said the latter. He also suggested adding a recommendation to avoid `@property` in the best practices section of the documentation. 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. Átila said that would work fine here except in cases where someone is taking the address of an `@property` function. We aren't going to be able to make a tool for that. Robert said that's true but do it anyway. The tool should tell them, "This doesn't work for this case. Sorry." He said that if we test the tool with all the D code we can find on GitHub, he'd bet beers at DConf that we'd find no more than ten instances of code that would break. After more discussion in a similar vein, Razvan said what it comes down to is that this is a broken feature and we don't know how to fix it. We need to just deprecate it. We shouldn't be keeping broken features around if we aren't going to fix them. Robert agreed. A tool to remove it from code will handle most cases, and for those people whom it doesn't help we'll have to help them migrate. There was then some discussion about whether or not `@property` is fixable. Dennis brought up the case of when the property is a callable (and linked the [docs for Adam Ruppe's `arsd.jsvar` module](http://arsd-official.dpldocs.info/arsd.jsvar.html) as an example of the problem manifesting; see Adam's comment in the example code and his notes near the bottom of the page). If we want to support this kind of type that can store callables, then we need some kind of fix. Walter said that's an ambiguity for which no one had been able to settle on a solution. Andrei said one intent of `@property` is to be a replacement for a data member. That's a good goal. Any improvement of `@property` should serve that purpose. If there's an ambiguity, it should go in favor of that. Átila thought that made sense. If there's an ambiguity, then just pretend it's a field. If there's only one set of parentheses, you call the callable. If there are no parentheses, you call the callable. Robert countered by saying we're trying to make D simpler, and `@property`
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: ### Petar One of the things Petar wants to do toward that end involves the Nix package manager. He's been using it for the past few years. There are already packages for the three D compilers, but they only target the latest stable releases. He would like to create Nix package expressions for "as old as practical" versions of the compilers. It seems we have a common goal. I'm happy to give Petar modification rights to https://github.com/dukc/oldDDerivations (the one that's linked from DMD download page) if he wants. Also if he wants to convert that to also include old LDC and GDC versions, permission granted! (Sent this privately to him last weekend but since I received no reply I assume I have wrong Email address.)
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: [...] Thank you so much for these updates! It makes a whole lot of a difference to see the progress that is being done. It turns out there is so much work both mentally and programmatically that is undertaken...
Re: D Language Foundation Monthly Meeting Summary for November 2022
Dne čt 12. 1. 2023 12:51 uživatel Mike Parker > ... > Next, Razvan reported he had been looking at a PR to implement > the `throw` attribute for functions. The problem with it was that > it potentially breaks code that uses the `getAttributes` trait > when testing for the presence of `nothrow`. Walter said that the > compiler internally should just view `throw` as the absence of > `nothrow` rather than as a separate attribute. Its only purpose > is to turn `nothrow` off, so ideally code using `getAttributes` > shouldn't need to change at all. It's not like > `@safe`/`@trusted`/`@system`, which is a tri-state. With the > binary `nothrow`/`throw` state, you only need to care if a > function is `nothrow` or not. Martin agreed. > > With that, Andrei brought up past debates about `attribute(true)` > and `attribute(false)`. Walter finds that syntax clunky. It was > easy to use `throw` to turn off `nothrow` since it's already a > keyword. Petar brought up `pure` and `@nogc`. This led to a long > discussion about attribute algebra, attribute soup, negative and > positive attributes for disabling each other, attribute > inference, circular dependencies, and tangential topics. Finally, > Dennis gave his perspective and mentioned another proposal that > had come up in the past: using the `default` keyword to establish > a default set of attributes for non-templated, unannotated > functions, which could be used to "reset" the attribute state of > any function. Walter thought that `default` to reset state is a > great idea, and that we should think about that before https://wiki.dlang.org/DIP79
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: I fell behind on my meeting summaries in the run up to DConf Online. The December summary will follow in a few days. [...] Thanks for these reports -- great to have such transparency and get updates on the work in progress. Great work everyone!
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: Andrei asked Razvan about the status of [the ProtoObject DIP](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1042.md). Razvan said that Adam Ruppe had raised some valid complaints in the DIP's pull request thread, and those were reinforced in the community review. [...] Andrei thinks it's worth making an effort to resolve any issues the proposal has. What I'd recommend doing is migrating the existing Object to match the desired capabilities. The biggest complaint people have that has no real solution in the existing language is the unconditional presence of the monitor field. I actually think you could infer this without too much of a breaking change; the presence of a `synchronized(this)` in the same module as the class definition could infer its necessity and add it to the type (this would also cover `synchronized` classes and methods, of course), but in other modules you couldn't be so sure (since they can be compiled separately). This would break anyone who uses synchronized(random_object) (which includes me btw) but the migration would be so simple (change the type) and it'd retain compatibility with old compilers so I think it'd be a minimum amount of pain. Other option is to just remove it and require everyone to use an explicit Mutex field, which also has a number of advantages, but is more invasive and means removing synchronized classes and methods as language features entirely. Among other complaints in that dip were opEquals, which is already fixed (and tbh could just be removed but i think it is fairly harmless to keep), factory which is slated for removal already, opCmp (which currently throws if you call it! so it isn't used by anything and could be simply removed), and opHash which recently was subjected to a random breaking change anyway (and a bad one that didn't achieve anything, but it shows that breakage is obviously on the table), so everything else already is being addressed in Object itself.
Re: D Language Foundation Monthly Meeting Summary for November 2022
On Thursday, 12 January 2023 at 11:47:26 UTC, Mike Parker wrote: [snip] ### Andrei Andrei asked Razvan about the status of [the ProtoObject DIP](https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1042.md). Razvan said that Adam Ruppe had raised some valid complaints in the DIP's pull request thread, and those were reinforced in the community review. Razvan and the primary author had no answer for those complaints at the time. The primary author eventually decided to move on (I have belatedly marked the DIP as "Withdrawn"). Andrei thinks it's worth making an effort to resolve any issues the proposal has. [snip] Thanks, as always. Adam's complaints on ProtoObject start here https://github.com/dlang/DIPs/pull/219#issuecomment-954740989
D Language Foundation Monthly Meeting Summary for November 2022
I fell behind on my meeting summaries in the run up to DConf Online. The December summary will follow in a few days. The November 2022 monthly meeting took place on the 4th of the month at 14:00 UTC. It lasted about two-and-a-half hours. The following were present: * Andrei Alexandrescu * Walter Bright * Iain Buclaw * Ali Çehreli * Max Haughton * Martin Kinkelen * Petar Kirov * Dennis Korpel * Razvan Nitu Átila Neves was present at the beginning but had to leave early. ## The summary ### Iain Iain started by noting that the digitalmars.com domain had gone down for about 6 hours the week before because it hadn't been renewed. He was thankful to Mathias Lang for notifying him so quickly and to Walter for being so responsive when Iain called him about it around 5:00 am PST. Walter is the one most at risk in that situation if someone else snatches up the domain, as Digital Mars is his business, but it does raise the question: why are our D pipelines failing when digitalmars.com goes down? Iain believes it's because the Digital Mars FTP site is being queried somewhere in the build scripts. It might be a good idea to have a mirror for that. Walter agreed that D services shouldn't be relying on digitalmars.com. Also the previous week, one of the build hosts in the autotester died for about 12 hours. When this happens, there's practically nothing we can do. The autotester is only building dmd and DRuntime, and is no longer running any tests. Given that it's being used for less than less, Iain proposed ripping out all the GitHub hooks for the autotester, maybe starting in January 2023. No one argued against it. He then gave us an update on the 2.101 release. At the time, the release candidate had been announced and he expected the final release to go out in the middle of November. He subsequently announced it on November 15. He then had a question for me. I had set up an admin group on Hetzner Cloud, and he wondered what it was intended for. I answered that this is where we would be setting up the services the foundation will be taking control of from the ecosystem. Iain said that out of coincidence, he and Mathias Lang had both bought bare metal servers on Hetzner to use in the BuildKite CI pipelines. This reduced individual pipelines from 1 hour per pull request to 18 minutes, making BuildKite less of an issue when a big load of changes comes through. It also means we can add more projects to our BuildKite CI. (For context, [Mathias reported in the October meeting](https://forum.dlang.org/post/jzqabfjmdwveeatpd...@forum.dlang.org) that after BuildKite had gone down a few days prior, he restructured it so that it was running from his own server. This gave us control over updating the dependencies, something we didn't have before. Unfortunately, it ended up being slower. The servers he and Iain are paying for rectify that problem. Thanks to them both!) There was then a discussion that touched on several topics. A couple of highlights: dlang.org is still with Walter's registrar, and we need to transfer it to the DLF's account; should we also transfer digitalmars.com (answer: no); in moving the downloads.dlang.org content from S3 to Backblaze, Iain realized several packages were missing, but they were present at ftp.digitalmars.com and he pulled them from there; does it matter if the main dlang.org site is hosted on Hetzner servers in Europe vs. North America (answer: probably not). ### Martin Martin let us know the next LDC release would be a bit later this time. He hadn't had much time and still needed to work out some details regarding the DMD and DRuntime repository merge. He had just started testing the 2.101.0 RC 1 against the Symmetry codebase. So far it wasn't too bad, but it was hard to tell for sure as a few dub packages needed to be updated. One benefit that was already visible was that it had uncovered some existing bugs related to copy constructors. He had also found a regression which he was going to file. Other than that, he congratulated Dennis for some nice new diagnostics regarding function inference, which means e.g., it's no longer necessary to figure out manually which line in a function causes it to be inferred as `@system` rather than `@safe`. The newest dub version had shown no regressions so far in testing on the Symmetry projects he tested. That's good progress. The new colored output is also very nice. Petar asked if Martin planned to incorporate LLVM 15 into the next release or delay to the one after. Martin said that Nicholas Wilson and someone else had already taken care of migrating to LLVM 15. According to their tests, LLVM 15 *should* be working, but there was some work to be done before Martin could run all of the tests with LLVM 15. First, he needed to update the LDC fork of LLVM to LLVM 15 for all targets. Then he needed to overcome an issue with testing vanilla LLVM via GitHub Actions, as the
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: ### D ecosystem services While we were waiting for everyone to arrive, I gave an update on the status of our plans to bring all of the ecosystem services under our control. At that point, I had received information on the resource requirements of services maintained by Vladimir Panteleev (the D forums, D wiki, and more), Jan Knepper (the main dlang.org site, the newsgroup server, the D blog), and Petar Kirov (run.dlang.io and tour.dlang.io). I also had received affirmative responses from those three to my invitation to join our next server meeting. Since that time, I have also received the same from Sönke Ludwig (code.dlang.org). Throughout February, I had received advice from different people about which name registrar we should sign up with. At the meeting, everyone agreed I should just pick one and be done with it. I have since signed up with Namecheap. Now I'm waiting for the owner of dlang.io to get back to me about handing it over to us (he brought it up in an email to me back in January). Walter has always maintained dlang.org, and he will transfer it to our new account in the future. BTW, if the foundation ever wants to take https://dla.ng off of my hands, please feel free to reach out and we could arrange something — I’d be happy to transfer the domain over. Only main thing is finding a registrar that supports the .ng domain, I’m not sure that Namecheap supports them.
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: The monthly meeting for March 2022 took place on March 4 at 15:00 UTC. The following foundation staff and contributors were present: [...] Thanks for summarizing!
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: ### D ecosystem services While we were waiting for everyone to arrive, I gave an update on the status of our plans to bring all of the ecosystem services under our control. At that point, I had received information on the resource requirements of services maintained by Vladimir Panteleev (the D forums, D wiki, and more), Jan Knepper (the main dlang.org site, the newsgroup server, the D blog), and Petar Kirov (run.dlang.io and tour.dlang.io). I also had received affirmative responses from those three to my invitation to join our next server meeting. Since that time, I have also received the same from Sönke Ludwig (code.dlang.org). The dub documentation, hosted at https://dub.pm should also be in that list. Currently there is a problem updating that site, see https://github.com/dlang/dub-docs/issues/41. -- Bastiaan.
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: One of the problems with going to DIP 1000 by default is what to do about `ref return scope` ambiguity. Walter had finally come up with a fix that was half-implemented. Some of the PRs had been merged, but others were stalled. Those stalled PRs are blocking progress on DIP 1000, and he wants to get those moving. Status update: the `ref return scope` ambiguity is fixed now ([PR 13693](https://github.com/dlang/dmd/pull/13693)), as well as the invalid [pure->scope inferrence](https://github.com/dlang/dmd/pull/12989) and [inout->return inference](https://github.com/dlang/dmd/pull/12689). Currently, most remaining open issues are related to nested functions. Atila resumed work on making dip1000 the default [by printing deprecation messages for scope errors](https://github.com/dlang/dmd/pull/12578).
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Tue, Apr 05, 2022 at 12:23:54AM +1200, rikki cattermole via Digitalmars-d-announce wrote: [...] > +1 infer everything! I agree, in principle. The ideal is 100% inference. Unfortunately, that's unlikely to be actually reachable. Nevertheless, we should definitely move in the direction of more inference vs. less. T -- Life is complex. It consists of real and imaginary parts. -- YHL
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 12:23:54 UTC, rikki cattermole wrote: +1 infer everything! Well, you *can't* infer everything, but private things I do think you can get away with since they're not allowed to be virtual. Inferring more on non-virtual things is a maybe, you still have to think about the abi mismatches there but that might work.
Re: D Language Foundation Monthly Meeting Summary for March 2022
## Razvan ### Reference counting Going through some old DRuntime pull requests, Razvan found several PRs adding reference-counted things (RCArray, RCPointer, etc) from a period when reference counting was a hot topic in the D community. The problem with reference counting in D has been the transitivity of qualifiers (e.g., you can't reference count an immutable object). Razvan remembered he had drafted [a DIP for a `__metadata` storage class](https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md). In a forum discussion on that DIP, Timon Gehr had pointed out two fundamental issues with it (anyone interested can see [the forum discussion thread](https://forum.dlang.org/post/3f1f9263-88d8-fbf7-a8c5-b3a2a5224...@erdani.org)). Ultimately Razvan's progress stalled and he never submitted the DIP. I stand by my comments about read only memory. A person can still at runtime mark memory as read only, unfortunately I don't know how you can detect this in a compiler and fail compilation because of it. My preference continues to be three new operator overloads methods for classes and structs. opRefAdd, opRefSub, opReadOnly. The first two are like destructors, they ignore const. The last tells the type (must not be const) that it is going into read only memory allowing it to know that it is no longer writable. It would be required if reference counting methods are implemented. The main difference to __mutable which was argued that it should not allow going into read only memory is that: the compiler can't detect if the user does it, but can prevent itself from doing it. That gives a very false sense of guarantee that it will not be. Where as with this approach it is clearly the responsibility of the one who put it into read only memory to call the method and for the programmer who wrote the type to have done the right thing in the methods. Giving no guarantees and hence no sense of security. ### Attribute inference on private functions Mathias thinks that inference on private functions is something everyone would want. It's something he heard Walter mention in the past. The current blocker on that is that attribute inference doesn't work for recursive functions. He thinks the solution is simple: you should assume that the function has all the attributes; if you recurse on yourself, the rest of the code will help you infer the attributes. Walter said that makes sense; the more attribute inference we can do the better. +1 infer everything! I suspect you can do some quick and cheap tests in the parser to determine if given a function scope if a given attribute such as @safe should be inferred later on. If done well, it could mean @safe by default! ## Andrei He started by arguing that reflection on built-in bitfields is "just warped". You're going to have things less than 8-bit and to which you cannot take a pointer. Any proposal for bitfields must account for that. Walter's solution of having `__traits(getMembers)` return an aggregate is only half of the story. What about the getters and setters? A library solution has those, but for the built-ins, they're compiler magic. Martin agreed (and this is his main sticking point; he brought it up in the last meeting). enum __c_bitfield; is(typeof(value.bitfield) == __c_bitfield) As long as .sizeof is the real size accounting for "empty" bits and alignment that should be a fairly safe way to go. It accounts for a single pointer and requires a special reflection mechanism to get the tuples of number of bits + names + types.
Re: D Language Foundation Monthly Meeting Summary for March 2022
On Monday, 4 April 2022 at 10:59:39 UTC, Mike Parker wrote: ### DIP 1008 and Phobos Razvan has opened these two issues for this: https://issues.dlang.org/show_bug.cgi?id=22985 https://issues.dlang.org/show_bug.cgi?id=22986
D Language Foundation Monthly Meeting Summary for March 2022
The monthly meeting for March 2022 took place on March 4 at 15:00 UTC. The following foundation staff and contributors were present: * Andrei Alexandrescu * Walter Bright * Iain Buclaw * Ali * Martin Kinkelin * Dennis Korpel * Mathias Lang * Razvan Nitu * Mike Parker This was a three-hour meeting that covered a lot of ground. I want to note that when someone makes an argument or suggestion in these meetings, they usually use a good bit of dialogue to make their case. And, more often than not, there is some amount of discussion as people reinforce the points raised. For context, and in anticipation of reader questions or inferences, I sometimes note some of the points raised when I think it's useful to do so and the points aren't too complex for a concise summary, but I'll usually leave out things people say that reinforce those points. My goal isn't to summarize everything everyone said, but just the major points and counterpoints raised. Sometimes, when I feel like I can't concisely summarize the larger context of someone's argument, or if the larger context isn't relevant, I'll just condense things down to "so-and-so suggested x". I just want to make it clear that there is always more to that "x" than just "x". ## Me ### D ecosystem services While we were waiting for everyone to arrive, I gave an update on the status of our plans to bring all of the ecosystem services under our control. At that point, I had received information on the resource requirements of services maintained by Vladimir Panteleev (the D forums, D wiki, and more), Jan Knepper (the main dlang.org site, the newsgroup server, the D blog), and Petar Kirov (run.dlang.io and tour.dlang.io). I also had received affirmative responses from those three to my invitation to join our next server meeting. Since that time, I have also received the same from Sönke Ludwig (code.dlang.org). Throughout February, I had received advice from different people about which name registrar we should sign up with. At the meeting, everyone agreed I should just pick one and be done with it. I have since signed up with Namecheap. Now I'm waiting for the owner of dlang.io to get back to me about handing it over to us (he brought it up in an email to me back in January). Walter has always maintained dlang.org, and he will transfer it to our new account in the future. ### Flipcause I informed everyone that Andrei and I had decided to terminate our Flipcause account at the end of this year. We signed up for it initially with the hope that it would be beneficial to us, but in the end, we decided the value we get from it isn't worth the annual fee (if we had a higher volume of donations, it would really be great for us because most donors there cover the transaction fees, an option PayPal doesn't offer, so it could potentially pay for itself). I'll miss the ability to set up targeted campaigns with a variety of optional features to choose from, but the annual membership fee we pay them would be better spent on server hosting. (That said, if you plan to register for DConf '22, please use [the Flipcause page we've set up for it](https://www.flipcause.com/secure/cause_pdetails/MTQ3NjEy)). For those of you making monthly donations through Flipcause, I'll contact you later this year to notify you when we're ready to shut it down. ### DConf registration rates In the middle of the meeting, I received an email from Symmetry with their proposed DConf registration rates. They asked me to get feedback from the foundation staff. Given the fortuitous timing, I interrupted the meeting to get everyone's opinion. They all gave the thumbs up. Those are the rates [you now see at dconf.org](https://dconf.org/2022/index.html#register). Walter suggested we also offer a hardship rate as we have done at past conferences. I have added information about that to the site. ## Martin Martin let us know that LDC was prepared for the next major release. He said there was one thing he was getting ready to do that he had been wanting to do for years: change the `extern(D)` calling convention to not reverse the formal parameters anymore. Until very recently, there was a coupling between DRuntime and the compiler which depended on this reverse order. This is an issue that has persistently popped up in the forums. It especially was a problem when someone was trying to fix Dwarf emission. One problem with this is that naked asm functions that take multiple parameters, and which assume parameters are in specific registers or stack slots, will break. He had to change some things in Phobos, which makes a significant diff between LDC Phobos and upstream Phobos. It will be easier if DMD can follow suit. ## Iain ### Deprecations Iain has been ending the deprecation period of things that were deprecated and forgotten about, and adding end dates for deprecated features that did not have one. He iterated a few examples, some of
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 14 January 2022 at 07:14:25 UTC, Mike Parker wrote: On Friday, 14 January 2022 at 06:12:51 UTC, Konstantin wrote: Hello, Max! Are there any news or estimates about the roadmap? I posted a note about it in a meeting summary or a blog post (can't remember where) a few weeks ago. But the short of it: in the process of revising it, I realized it needs a complete rewrite. The document we ended up with isn't what we said we wanted. The rewrite will be a high priority for me once I wrap up the DConf Online Q & A videos and get the DIP queue moving again. I'll need more input from other people, and the time that takes is never predictable, but I intend to get it published in the first quarter of this year. And for the record, it's *not* a roadmap (assuming roadmap means a step-by-step plan for language evolution). It's broader than that. The intent is to outline Walter's and Atila's current focus, their longer-term goals, and areas where contributors can direct their efforts. It's a living document that will evolve as priorities change. Thanks, Mike! I will be waiting for news!
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 14 January 2022 at 06:12:51 UTC, Konstantin wrote: Hello, Max! Are there any news or estimates about the roadmap? I posted a note about it in a meeting summary or a blog post (can't remember where) a few weeks ago. But the short of it: in the process of revising it, I realized it needs a complete rewrite. The document we ended up with isn't what we said we wanted. The rewrite will be a high priority for me once I wrap up the DConf Online Q & A videos and get the DIP queue moving again. I'll need more input from other people, and the time that takes is never predictable, but I intend to get it published in the first quarter of this year. And for the record, it's *not* a roadmap (assuming roadmap means a step-by-step plan for language evolution). It's broader than that. The intent is to outline Walter's and Atila's current focus, their longer-term goals, and areas where contributors can direct their efforts. It's a living document that will evolve as priorities change.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote: On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git) Hello, Max! Are there any news or estimates about the roadmap?
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Tuesday, 12 October 2021 at 19:21:50 UTC, Ben Jones wrote: On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) How about "from prototype to production" or something? I was reading yesterday about how both memcached and redis were originally written in scripting languages and then rewritten in C for performance. Kinda like this one
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Tuesday, 19 October 2021 at 16:17:43 UTC, Andrea Fontana wrote: On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) You mean: Just D it That's awesome! using that as my discord status now.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) You mean: Just D it
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On 01.10.21 14:32, Mike Parker wrote: Walter would like to establish a new slogan, or tagline, for D. Gettin' it Done. (Enunciated like Doom's "Rip and tear until it is done.")
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) How about "from prototype to production" or something? I was reading yesterday about how both memcached and redis were originally written in scripting languages and then rewritten in C for performance.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On 10/3/21 2:24 PM, James Blachly wrote: > Cons: Potential association with silicon valley phrase "move fast and > break things". I am going off-topic but I feel I have to make a correction there. As a person who worked and lived in Silicon Valley since 1996 (since 1994 in the greater Bay Area), I can safely claim that that phrase has never been a Silicon Valley phrase. It was used by Facebook in their less enlightened days (a business that may arguably be associated with Silicon Valley by their postal address). Ali
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Monday, 4 October 2021 at 15:44:11 UTC, Ki Rill wrote: About (1): I've written some C++ code recently. I was very happy with the code. I've read the code multiple times in search for potential bugs and errors. I decided to rewrite some of the code in D just to see the difference code-wise and performance-wise. Guess what happened? It didn't compile. I got out-of-bounds access error in D meanwhile the C++ version ran happily with no sign of any failure. That's a classic with C++ and static arrays. C++ now has the STL array which is standard now but who cares because not many know about it and there so many ways to do the same things in C++ you get lost. Also, it's ugly. In the case for D, I think D is a "sky is the limit" kind of language. D handles so many different areas, from low level to rather high level quite nicely. However, this together with one of the best metaprogramming out there, the versatility of the language is really among the highest. Now, the metaprogramming in C++ is just as powerful but not many people can handle it and they tend to avoid more complicated solutions. With D, metaprogramming is much more approachable and tasks that the programmer was unable to do in C++ can be done in D relatively easy.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Monday, 4 October 2021 at 15:44:11 UTC, Ki Rill wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] These are great news! As for the new slogan, I believe we need to put some emphasis on D's modelling power. If I come up with something decent, I'll post it. [...] Very curious what code that was.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] These are great news! As for the new slogan, I believe we need to put some emphasis on D's modelling power. If I come up with something decent, I'll post it. Meanwhile: (1) Reliable, fast. (2) Safe, not strict. (3) Smooth start, deploy. (1) - "no" unexpected surprises, improved memory safety, easy to catch bugs such as trying to index a pointer in a @safe function, out-of-bounds array write/read and similar; an almost instantaneous compilation, performance similar to that of C/C++. (2) - continuing from (1), it's @safe, but you make the final choice how far you want to go. (3) - it's "relatively" easy to start a new project in D using DUB: `dub init/add/run`. Need a library that's not available in DUB? Create a D interface to C header file and use it. There are tools that can automate this process, etc. I put "..." because it's not always the case. About (1): I've written some C++ code recently. I was very happy with the code. I've read the code multiple times in search for potential bugs and errors. I decided to rewrite some of the code in D just to see the difference code-wise and performance-wise. Guess what happened? It didn't compile. I got out-of-bounds access error in D meanwhile the C++ version ran happily with no sign of any failure.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Sunday, 3 October 2021 at 21:24:31 UTC, James Blachly wrote: Cons: Could be open to criticism that garbage collected language is not "the future," but this would likely be a tiny number of detractors. It seems like D itself is moving away from GC everywhere too.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] I don't have a slogan in mind. But it would be nice if it could capture the plasticity of the language somehow
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On 10/1/21 8:32 AM, Mike Parker wrote: Walter would like to establish a new slogan, or tagline, for D. He asked us all to think about this for a future meeting. (Ali has since solicited some good advice from a relative who is a professional marketer that has gotten us on the right track.) 1. "Move fast" Pros: More succinct than "Write fast code, fast" or whatever the old slogan was. Still captures the essence of both speed of execution and ease of writing. Potential tie-in to D-Rocket logo. Cons: Potential association with silicon valley phrase "move fast and break things". 2. "Future code" Pros: Association with the idea that we are often at the leading edge of new features which are later incorporated into other languages. May also carry the implication that D is great language for the reader to learn in the future. Potential tie-in to space and mars theme. Cons: Could be open to criticism that garbage collected language is not "the future," but this would likely be a tiny number of detractors. ... As always, if anyone has anything they'd like me to put on the meeting agenda, please let me know beforehand. I don't know for sure if we'll be able to fit anything onto this month's meeting, though. These meetings can run long if the industry reps have anything big to discuss, and we're going to have a major item on the foundation's agenda that I expect will consume most of post-industry portion of the meeting (`-preview=in`). But if you have something, I'll see what I can do. Thanks for doing these writeups as community liaison.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Saturday, 2 October 2021 at 08:48:10 UTC, Konstantin wrote: On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote: On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git) Thank you, Max! Do I understand correctly, that roadmap section will be available at https://dlang.org/foundation/index.html Most likely, but we will get it on the home page as well so it can't be missed.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote: On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git) Thank you, Max! Do I understand correctly, that roadmap section will be available at https://dlang.org/foundation/index.html
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: new slogan feature X ? D got it yesterday!
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git)
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere?
D Language Foundation Monthly Meeting Summary (September 24, 2021)
Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker (Átila Neves was on vacation in an area with limited internet access) The primary item on the agenda for this meeting was a governance proposal from Mathias Lang. Modeled on [Python's PEP 13](https://www.python.org/dev/peps/pep-0013/), the proposal was to establish a self-governing Core Team (CT) of unlimited size, and a five-member Steering Committee (SC) elected annually by the CT. The CT would take on all management and decision-making responsibilities, subject to veto by the SC. The proposal set out a basic set of procedures and responsibilities for each team, including the establishment of Working Groups within the core team to focus on specific areas (i.e., compiler development, dub, DIPs, etc.). We spent the majority of the meeting discussing the pros and cons of such a structure. Among the points discussed, a major pro and a major con stand out: formalizing governance can potentially bring more order and structure to the day-to-day management of the language and the ecosystem (pro); there's a risk of Walter and being pushed out of the decision making process (con). In the end, we agreed that some sort of formalized committee that brings more order to the ecosystem is worth pursuing, but that decisions regarding development of the language should be left in the hands of Walter and Átila. Given that membership in the monthly meetings has expanded over time, and the quarterly meetings include industry reps using D in production, we already have a skeleton of the Core Team outlined in Mathias's proposal. Mathias agreed to go back to the drawing board and draft a new proposal that is smaller in scope and better suited to the size of our community. The goal is to take what we already have and formalize a process for organizing work on priority tasks, managing resources, drafting volunteers, etc., (in other words, a team that can manage the ecosystem), while leaving language design decisions to Walter and Átila. I will assist Mathias in drawing up the proposal and we will present it at a future foundation meeting (I anticipate November). A topic that came up in course of the discussion was pull requests blocking on feedback from Walter or Átila. As a remedy, Razvan will be sending periodic updates to them with a list of PRs that require their feedback. Walter is also open to once- or twice-month-meetings with contributors to resolve pull-requests through in-person discussion. We agreed to establish a page on dlang.org that lists the core team members so there's no doubt who is involved in the management process. Walter would like to establish a new slogan, or tagline, for D. He asked us all to think about this for a future meeting. (Ali has since solicited some good advice from a relative who is a professional marketer that has gotten us on the right track.) Our next meeting will take place on October 22nd at 13:00 UTC. This will be a quarterly meeting, so the industry reps will be present. As always, if anyone has anything they'd like me to put on the meeting agenda, please let me know beforehand. I don't know for sure if we'll be able to fit anything onto this month's meeting, though. These meetings can run long if the industry reps have anything big to discuss, and we're going to have a major item on the foundation's agenda that I expect will consume most of post-industry portion of the meeting (`-preview=in`). But if you have something, I'll see what I can do.
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote: That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages. For truly high level languages garbage collection probably is the best, if you design the language semantics for it. The main issue with D is that the language semantics don't enable competitive GC advantages. I think at least D should go with ARC for shared resources. Then have a variety of options for task-local resources, including GC.
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote: On Saturday, 5 June 2021 at 09:14:52 UTC, Ola Fosheim Grøstad wrote: The current GC strategy is a dead end. No GC makes the language too much of a C++ with no real edge. D needs to offer something other languages do not, to offset the cost of learning the language complexities. I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages. Well, I advise reading "On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-Checked, Concurrent Language" http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf And watching the upcoming WWDC 2021 talk "ARC in Swift: Basics and beyond" on Friday. https://developer.apple.com/wwdc21/sessions What Cedar, Swift and Nim have in common that D lacks, are fat pointers, the compiler awareness for optimizations regarding elision of counter manipulation code, and tricks like background threads for the cycle collector or cascade deletions. It is no an accident that high performance reference counting GC is similar to tracing GC in regards to implementation complexity.
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote: I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages. Yes, this is a way forward. Walter doesn't want to add fat pointers, however he hasn't mentioned if that's part of the language or fat pointers as a library (like C++). It doesn't need to be part of the language but as a library type. Classes in D are essentially already library fat pointers. What we need is to extend this so that we have a generic fat pointer type (that can be recompiled to whatever GC type we want) that can be used for any type through out the entire code base if the programmer wishes that. Then we need refactor druntime/phobos to only use this fat pointer type. As you mentioned, in order to have better support for different GC, we can support compiler hooks (like your acyclic example) in order to give the compiler optimization hints. Whatever GC type you think is better for you, you should decide that and not forced by the D compiler and library. Basically GC X is better than Y is not an argument. What is the argument is how we can allow people to choose.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 09:14:52 UTC, Ola Fosheim Grøstad wrote: The current GC strategy is a dead end. No GC makes the language too much of a C++ with no real edge. D needs to offer something other languages do not, to offset the cost of learning the language complexities. I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages.
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote: My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases. Great, I am interested in highly interactive apps (games, sound editors, graphics editors, audio plugins, etc). Maybe we could create a focus group and collect experiences, approaches, weak spots, strong spots? Right now I think many feel left in the dark when they come with an idea for an app as there is little guidance of how to build a bigger app. I sense this by watching the learn-forum.
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 23:04:12 UTC, Norm wrote: On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote: On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote: On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject. There is also https://micropython.org/ I just skipped MicroPython, because Circuit Python seems to have more uptake even though it is based on it. It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32. This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D. Exactly, and the whole GC vs no-GC take the language nowhere in that regard.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote: On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote: On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject. There is also https://micropython.org/ It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32. This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D.
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote: Hopefully D will not stop covering these use cases. I know all the web-apps folks who wants to serve 100 requests per second will not like GC, I guess. Absolutely not, D must continue with automatic memory management and I think about everybody agree with that. The discussion is about how D can support different types of memory management and how to approach that, this is where the opinions are very different.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 09:58:23 UTC, Ola Fosheim Grøstad wrote: You mean the wait-for-everything-to-stop-scan-everything approach will remain? What is the area that D is trying to cover though? Somebody should write a memo on that. My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases. I know all the web-apps folks who wants to serve 100 requests per second will not like GC, I guess.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote: On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote: You might be surprised, but it's actually not up to you what topic fits or not. I said GC-phobia is irrational, I did not say any criticism of it is. Obviously GC is good for some things and not good at all for other things. What *is* irrational is saying it has absolutely no place at all. I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal. I agree with the description of a swiss army knife. Like if some comany/brand said they're removing the little saw, and there are many ppl who bought the knife mainly to be able to do some quick n dirty sawing, they would choose another company/brand.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 09:47:11 UTC, Imperatorn wrote: I get your point, but I still think GC will remain mainly because of the area D is trying to cover. You mean the wait-for-everything-to-stop-scan-everything approach will remain? What is the area that D is trying to cover though? Somebody should write a memo on that.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 08:51:07 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote: [...] This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :) [...] I get your point, but I still think GC will remain mainly because of the area D is trying to cover.
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote: Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, D isn't useful for teaching kids programming. Wy too complicated. Most Arduino users, who build useful stuff, use C++. But it is not a good strategy for D to become more like C++, too late. It would've been a good strategy 6 years ago to align D semantics with C++ and have full interop, but too late now. D needs a feature-set that makes it attractive for people wanting to do high profile interactive stuff, like games, graphics editors, sound editors, high performance services. With useful optional GC and easy multithreading. The current GC strategy is a dead end. No GC makes the language too much of a C++ with no real edge. D needs to offer something other languages do not, to offset the cost of learning the language complexities.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote: On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote: You might be surprised, but it's actually not up to you what topic fits or not. This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :) Obviously GC is good for some things and not good at all for other things. The problem is that the D-style GC is not a good fit for anything interactive, beyond simple applications. My impression is that most people use D for batch programs, so I guess that shapes the opinion. And that is a problem for D. A bad GC-strategy is reinforced by the remaining majority, which is a tiny fraction of the overall programming community. These days you don't really need a system level language to write batch programs. So it is not a good strategy to hold onto this specific type of stop-everything-scan-everything GC. Unless D decides to not be a system level language, but then you need a lot more convenience features and become more scripty. The inbetween position is not the top-pick for anyone looking for a solution. Not being willing to switch MM strategy means being stuck on a tiny island, too afraid of crossing the ocean to get access to the main land. My impression is that Walter would rather stay on this tiny island than take any chances. The language is being extended with incomplete experimental features, instead of going to the core of the issue and doing something with the foundation for the language. That is not going to end well. You'll end up with a patchwork.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote: D certainly has the power to do so but the question is if there is any will power in this community. Nothing has happened for almost 20 years. I guess importC will make changes even more unlikely. Absorbing C is nice, but it has the unfortunate effect of giving D some of the same disadvantages as C++.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. In the case of Phobos, in order to make as versatile as possible it shall not assume any other layer than malloc/free. I'm asking myself, even if we don't care about the cons, would that at all be possible with a ~20 years old language with a ~20 years of ecosystem evolution. How many things need to be rewritten? D certainly has the power to do so but the question is if there is any will power in this community. Nothing has happened for almost 20 years.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote: On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote: On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote: [...] As a small language, if you want to succeed.There is no way out except to be the best. Otherwise, why don't I use C++? [...] GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational. THERE IS NO GC PHOBIA, it is a nice UTILITY people don't understand what an utility is, it is meant to be used whenever you need it, NOT ALL THE TIME YOU DON'T NEED IT there must be strategies how you position yourself in the market, what other language are doing, what people are looking for in a pragmatic system language this is why it makes me furious everytime i see people wanting more GC, you are clueless, and you drive adoption down by wanting more GC i should stop write message here, nobody understand anyways, and people who make decisions for D are lost too
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote: Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. You can parametrize over all possible MM strategies making every function generic and pass the right MM into it. Beside increasing template bloat it isn't that optimal as the same code has different performance characteristic for each MM, so you need to overload over all these and even then you won't cover all the MM because there are people wanting to insert their custom MM, but the library was already written. I'm asking myself, even if we don't care about the cons, would that at all be possible with a ~20 years old language with a ~20 years of ecosystem evolution. How many things need to be rewritten?
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote: You might be surprised, but it's actually not up to you what topic fits or not. I said GC-phobia is irrational, I did not say any criticism of it is. Obviously GC is good for some things and not good at all for other things. What *is* irrational is saying it has absolutely no place at all. I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote: GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational. The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs) You might be surprised, but it's actually not up to you what topic fits or not. I said GC-phobia is irrational, I did not say any criticism of it is. Obviously GC is good for some things and not good at all for other things. What *is* irrational is saying it has absolutely no place at all.
Re: D Language Foundation Monthly Meeting Summary
On Wednesday, 2 June 2021 at 14:02:29 UTC, Mike Parker wrote: On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote: Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it? The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages. I thought v2 is what it currently is, so the next would be v3.
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote: D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it? This is not a realistic or helpful suggestion. You're proposing to get rid of current users of the language - many of whom like that there's a GC - in order to chase C++ programmers, who represent a small sliver of all programmers, who mostly wouldn't change languages anyway, and who would change to Rust if they were planning to change languages. Again, not a helpful suggestion.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 14:07:38 UTC, drug wrote: I use GC when developing an algorithm to solve my problem. After I has implemented the algorithm I can redesign it to avoid GC (if needed). It works pretty nice in my case at least. Because initially I concentrate on my domain problem and then I only deal with memory management. This separation is very helpful. Yes, if you select that strategy from the start. But think for a moment how much easier it would be if the language had ownership pointers. I also believe that careful usage of ownership pointers in combination with precise scanning could lead to much less memory being scanned. There are no language features in D that support GC-strategies. That's not a strength. They can be remedied, but it takes willpower.
Re: D Language Foundation Monthly Meeting Summary
04.06.2021 16:32, Ola Fosheim Grøstad пишет: On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote: GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational. The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs) I use GC when developing an algorithm to solve my problem. After I has implemented the algorithm I can redesign it to avoid GC (if needed). It works pretty nice in my case at least. Because initially I concentrate on my domain problem and then I only deal with memory management. This separation is very helpful. Also there is no rewriting when you switch to manual management - you just add new code, no replacing old code. Again often API is worse after switching than in case of GC.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote: On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote: GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational. The topic doesn't fit in this thread, but it isn't irrational. The most irrational issue here is that the language itself prevents precise collection, and there is no willpower to change it. If you combine task-local GC with fully precise compiler-guided scanning, then you'd have something that would work.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote: GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational. The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs)
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote: On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote: [...] As a small language, if you want to succeed.There is no way out except to be the best. Otherwise, why don't I use C++? [...] GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 11:41:49 UTC, sighoya wrote: Yet another GC vs NoGC thread :sigh: Routine determines success or failure.
Re: D Language Foundation Monthly Meeting Summary
Yet another GC vs NoGC thread :sigh:
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 00:39:41 UTC, IGotD- wrote: On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote: Zim: the grammar is ugly. Zim? Is that what they speak in Zimbabwe? Zig.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote: Zim: the grammar is ugly. Zim? Is that what they speak in Zimbabwe?
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote: OK, how do you position "d"? As a small language, if you want to succeed.There is no way out except to be the best. Otherwise, why don't I use C++? rust,go,zim.I dislike them. Rust: slow compilation, weak template function. Go: there is no template function, and the abstraction is not strong,error process,time question.spaghetti Zim: the grammar is ugly. D's advantage is template.But now the advantage over `C++20` is smaller. So `D` should have `a sense of urgency`. D's position is too vague. Don't want to gain everything,Everything is nothing. what `D` need to do is `enhancing advantages`, `discarding` disadvantages, so simple! `Template metagramming` is a big advantage, we should enhance. GC is disadvantage, we should discard it! discard `GC`,attract `C++er` ,`pythoner/scripter/learner` will all come. otherwise,who help you write the lib?
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 23:47:07 UTC, zjh wrote: The GC of D is a burden.in the speaking of AA. D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it? Yes, for Phobos v2 one of the primary goals should be to not being forced to rely on GC. Phobos should only rely on malloc/free. Phobos may be using reference counting internally as it also only relies on malloc/free.
Re: D Language Foundation Monthly Meeting Summary
OK, how do you position "d"? What kind of programmers do you want to attract? beginner?pythoner?scripter? How to attract them and why and what feature attact them? What slogan of "d", Can d occupy a bigger market? Does d still occupy the field of system programming The GC of D is a burden.in the speaking of AA. D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it?
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 22:40:50 UTC, JN wrote: On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote: On Saturday, 29 May 2021 at 00:26:54 UTC, zjh wrote: OK, how do you position "d"? What kind of programmers do you want to attract? beginner?pythoner?scripter? How to attract them and why and what feature attact them? What slogan of "d", Can d occupy a bigger market? Does d still occupy the field of system programming The GC of D is a burden.in the speaking of AA. D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it?
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote: On Saturday, 29 May 2021 at 00:26:54 UTC, zjh wrote: Good,maybe we can raise our sounding slogan "Better C++" again! There are too many talents in C++ We must attract them. Only them can make d great!Because they are library writer. They can make d great. I disagree. Attracting C++ folks doesn't seem to work. You may try to lure them with promises of nicer templates and no header files, but after a while they will complain about the garbage collector and go back to their new C++ draft standard. If you advertise yourself as Better C++, you are instantly setting yourself up for comparison and are turning away everyone who dislikes C++ in the first place. Rust doesn't advertise itself as "Safe C++", Go doesn't advertise itself as "Native Java", Zig doesn't advertise itself as "Better C".
Re: D Language Foundation Monthly Meeting Summary
On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote: Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it? The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages. Andrei has talked about it a little here in the forums, and Steve did some preliminary work a while back. Beyond that, I have no details about plans. We'll have more after the workgroup gets going.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote: For example, major long-term goals are memory safety (e.g., specific bugs, fully enabling DIP 1000 support) and Phobos v2. Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it?
Re: D Language Foundation Monthly Meeting Summary
On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote: Good,maybe we can raise our sounding slogan "Better C++" again! If I'm a marketer of `rust`, I'll say `rust` is `abnormal C++`.would you like a try? If I were a marketing person of D, I would say `d` is a `Better c++`.will you try? We can make use of the `C++` fame to make us famous. `C++` is `always` our good friend.
