Permalink
Reply
This meeting took place on October 22nd at 13:00 UTC. Apologies for the delayed summary.
This was a quarterly meeting, meaning there were two parts. The first was focused on industry reps and contributors using D in production; the second was the monthly D Language Foundation meeting. If you are using D in production and would like to participate in our quarterly meetings, please let me know.
The meeting lasted three hours. The following people attended:
Industry Reps
Iain Buclaw for GDC
Martin Kinkelin for LDC
Mario Kröplin for Funkwerk
Mathias Lang for BPF Korea
Robert Schadek for Symmetry Investments
Joseph Wakeling for Frequenz
Contributors
Petar Kirov
Vladimir Panteleev
Steven Schveighoffer
D Language Foundation
Andrei Alexandrescu
Walter Bright
Ali Çehreli
Max Haughton
Átila Neves
Razvan Nitu
Frequenz
Joseph had no issues to report, but he brought up his concerns about the state of D in relation to Rust. This led to a discussion that touched on the excitement of things happening in the Rust space (new projects, particularly in the field of Data Science), the availability of libraries in the Rust ecosystem (in many cases, it's easier to get a new project going in Rust than in D), and marketing (he knows programmers who are highly enthused by Rust's offerings and unenthusiastic about the potential of D by comparison).
This led to a recurring discussion throughout the meeting about marketing, branding, and the availability of libraries. Some salient points were raised throughout:
- Word of mouth is a powerful form of marketing, and languages with solid tooling support (IDEs that almost write the code for you) and a large library ecosystem (like Go's "lego style" programming, where much of what you need for modern programming has already been written) have a lot more to talk about. We have a great language to talk about, but we're missing the other stuff.
- We may be appealing to the kind of programmer who is happy with Emacs and has no problem writing the support libraries they need, but that sort of programmer is not the future of programming.
- We don't need to be a better C, because no one wants to write new code in C. We need to just be better.
- HN/Reddit/Etc have a constant stream of "I wrote X in Rust" articles. We need more people who are using D to write about/talk about what they are doing so that others can see it.
- The biggest languages have a story. (Java: write once run anywhere, the language of the internet; Rust: memory safety without a GC; Go: goroutines). What is D's story? It's not one big thing, but a lot of little things, and that's not a strong story.
- Branding. We need to determine what we are as a brand and should consider hiring a branding expert.
Funkwerk
Mario said Funkwerk wants to create containers that can accept arbitrary types, and that includes accepting immutable and const types without the containers, in turn, becoming immutable/const. Unfortunately, they could not use the Phobos Rebindable for this, as it doesn't wrap structs. Mathis Beer worked on a solution, and Mario asked him to submit it to the forums for feeback. It received very little. And they aren't happy with it as it's a "very tricky, very ugly" solution that relies on compiler behavior. Should they continue to use it and risk it breaking if the compiler is changed? Átila said he would look at their code.
A second issue was regarding a Funkwerk PR to dfmt that adds a single_indent option to dfmt for continuation lines since dfmt only supported double indent continuations, something that was rejected for the D Style Guide. The PR got held up waiting for feedback from Brian Schott, and a later request to merge it anyway received no response. Most of the people present at the meeting have merge rights to dfmt and agreed it should be merged, and Razvan did so.
Symmetry Investments
Robert said he has no major issues with his current project. He did circle back to the libraries/marketing discussion, and I summarized his remarks above. Other than that, he is happy using D every day.
He also said he has continued working on "dud" as his Fridays project at Symmetry. He is currently working on dependency resolution, based on the work done in dub. He intends to do a talk about dud and its dependency resolution at the next real-world DConf. He mentioned that in adding parsing support for JSON/SDLang dub recipes, he found several SDLang recipes that have unexpected syntax. Finally, though he expects to keep a legacy dub-like system, where the user types dud and the project builds and runs, he would like to connect to Átila's reggae for anything more complex.
BPFKorea
Mathias reports that his company was hit by Issue #21929 two or three months ago, in code written by someone experienced with D. They would love a solution for it.
A few months ago, they were also hit by a bug in -preview=dtorfields that was triggered in vibe.d and reported in Issue #21989 after Sönke Ludwig tracked it down. A PR for this issue by MoonlightSentinel is currently stalled, but the preview switch was enabled by default in 2.098.0. BPFKorea was forced to disable the feature with -revert=dtorfields.
They also have some exception-related bugs on Alpine Linux, but the stack traces on Alpine don't work yet. He has done some work on getting them working but has not had time to finish it. He is hoping to fix that when he is able.
LDC
Martin reported that LDC's DLL support is working well and has been used successfully at Symmetry.
Iain
Over the last quarter, Iain has submitted patches to GCC for bootstrapping the D compiler and is waiting on approval. Once he has that, he'll be able to delete the current C++ front end and libraries and add in the master versions of dmd (the d front end), druntime, and phobos. With that, GDC will be at the latest version of D.
Iain has been working with Walter on Import C. A recent PR from Walter adding support for va_start and va_end now enables them to cleanly compile a preprocessed zlib to object code. Iain will soon be testing the output against zlib's test suite to see if there are any hidden run-time bugs in ImportC. They've selected zlib as a test target because it is compiled in Phobos with DMC, so it would be great to get it compiling with DMD instead.
He also brought up our aging server infrastructure, including digitalmars.com, dlang.org, the auto tester, and more, which has been a topic of discussion in past meetings. This led to a discussion about the auto tester (e.g., what is it covering that our other CI solutions are not, how switching to a monorepo would benefit the auto tester, how can we avoid unnecessary builds, etc.), our CI services, and the state of the current auto tester server stack.
(A couple of related notes.
I participated in a non-foundation meeting yesterday with Vladimir, Petar, Mathias, Max, and Razvan as a preliminary discussion of what it would take to merge some of the core repositories into a single repo. This resulted in a plan to put together a proposal and bring it to a monthly Foundation meeting, tentatively targeting our November meeting.
I am attending a foundation meeting later today with someone who has volunteered to advise us on bringing our server infrastructure under Foundation management and multiple admins. This meeting is intended to provide our adviser with a clear picture of the existing servers and our goals so that he can formulate some suggestions and bring them to one of our future monthly meetings.)
Vladimir
Vladimir's open-source btdu project has been picking up recently among users of the btrfs file system. A problem he's encountered is one of packaging and distribution. For example, on Debian: DMD isn't packaged in the official distro, GDC has an old front end, and the LDC packages are outdated. This has led to a poor experience for new users of his software, who often decide to use something else. This led to a discussion about how to get D compiler packages into more distros. Most distros do not allow people to just start submitting packages without first establishing trust in some form. The best approach will likely be to sponsor someone who already has access.
He also discussed some plans he has for some changes to DustMite that he hopes will introduce D to more people. I will say no more about that for now and leave it to Vladimir to make the announcement when he is ready.
Petar
Petar is the CTO of a small startup using D in a limited capacity. He brought up two minor issues they have encountered. The first: -chackaction=context causes linker errors in release builds. For now, they are fine using the switch only in unit test builds. The second: they could not find an easy way to customize the visualization of DateTime in vibe.d, but they were able to work around it. He feels that though the project is small it was a success story for its use case.
Petar is the only active maintainer of DLang Tour but is not happy with its current state. He has ideas on how to improve it but has not been able to make the time for it. He would be happy to guide anyone who would like to volunteer to do some work on it and will resume work on it himself when he has more time. If anyone is interested please let us know in this thread. I will make a more visible effort to recruit someone later. One of the things he would like to do is use DLang Tour to make all of the examples in Ali's book runnable.
Finally, Petar believes the tools that Hackerpilot (Brian Schott) developed (dcd, dfmt, dsymbol, etc.) are extremely useful, but it can be annoying to contribute to them while they are in separate repositories. Sometimes, I change in one requires a change in another. He would like to see them all merged into a single repository.
Steven
Steve is teaching programming to some kids. He was originally using JavaScript, then Lua and Roblox, and now D and raylib-d (of which he has since become the maintainer). This has shown him that most of our existing D resources are targeted at people who already know how to program. We have very few resources geared toward teaching D to people who do not know how to program. Related to that, it's difficult to teach the kids how to interpret error messages. This would be much easier if compiler error messages and Phobos/DRuntime error messages were improved. For example, a RangeError on an invalid array index should report what the number was that caused the problem; failed asserts should report the offending expression; etc. This would be useful to everyone, not just beginners.
The fate of -preview=in
-preview=in came up briefly at a previous meeting, in the context of a larger discussion, as a mistake that should be killed. Given that it was implemented by Mathias Lang, we decided to bring him into a future meeting to present his case for keeping the feature around and ultimately moving it out of preview.
Mathias provided a bit of background on the feature. in used to mean scope const, but then DIP 1000 came along, and in was changed to just const. Then later, a preview switch was introduced to make in mean scope const again. Mathias felt that in by itself was not very useful, so he saw an opportunity to improve it based on a use case in BPFKorea's codebase. So he changed its behavior, behind -preview=in, such that in means const scope ref, with the addition that the compiler is free to optimize to pass by value when it can (e.g., small POD structs) and it accepts rvalue references. The big objection raised in past discussions was aliasing. Mathias feels that is a more general problem, is a rare problem, and @live is supposed to help with that. BPFKorea has been using the feature in production for over a year, and in that time it has only caused a single bug, which came down to the fact that they weren't using preview=dip1000, so scope wasn't being enforced. Their code is sensitive about how things get copied around, and they have had memory corruption in the past. -preview=in solved that problem. He then mentioned some ideas he had to make it more useful, which led to some discussion that isn't relevant to this summary.
This was a long discussion that took up a full hour.
Martin, Petar, and Ali voiced strong support for the feature. Some of their arguments in favor:
- it avoids the situation in templated code with an
in refparameter where you have, e.g., anintbeing passed by reference; the compiler can optimize this to pass theintby value. - you don't have to concern yourself with deciding whether to pass a
constparameter by reference or by value; the compiler will do for you the best thing on the current platform. - this eliminates the need for multiple function overloads and/or
static ifblocks to do manually what this does for you, which simplifies the language (and is something easier to understand). - it eliminates the need for
-preview=rvaluerefparams(and the DIP on which that feature is based) and does not allow rvalues to be mutated.
Átila and Walter had strong reservations. Their two major objections:
- (Átila) if
-preview=rvaluerefparamsis broken, or the DIP is wrong, we should fix it. - (Walter) the issue with
-preview=inand aliasing isn't that it can happen, it's that it can sometimes happen and sometimes not depending on if the compiler optimizes to pass by value, and that can vary from platform to platform; this is a major inconsistency in that the behavior is unpredictable; that aliasing is rare makes this a more pernicious problem that can silently introduce memory corruption.
When reading the above, you will probably think of things to say for or against specific arguments. I'm willing to bet that it was already said in this meeting. They drilled down deep into the weeds and raised several points and counterpoints related to the above arguments and other, more minor arguments. In the end, they found their way to an agreement on how to proceed.
-preview=in will not be killed. It needs to be changed such that:
inalways meansconst scope ref; the compiler will not attempt to pass by value based on platform-specific heuristics.inwill accept rvalue references.- the compiler can in the future optimize to pass by value to
inwith more appropriate heuristics (e.g., it can prove there is no aliasing).
The next meeting
Phew! That was a longer summary than I expected to write. Our next meeting is a normal monthly meeting (no industry reps) and will take place on Friday, November 26th, at 14:00 UTC (the American clocks will be moved back an hour before then, so we have to move from 13:00 to 14:00 UTC so that we can keep it at 06:00 PST for Walter and Ali).
It looks like the primary agenda item for the next meeting will be a discussion on merging the druntime repository into the dmd repository. If you have anything you'd like us to discuss, or would like to discuss with us, please let me know and I'll tell you if I can squeeze you in.
