aldacron's comments

> array concatenation with ~, associative and dynamic arrays as well

Yes. Walter was referring to the operator itself. Strings are arrays.

> as well as exceptions

It's not exceptions themselves, but the `new` operator. It directly allocates from the GC. That said, there is a plan to enable @nogc exceptions.

> At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one already knows that about the currently used language.

People who already know another language and are happy with it have no reason to switch. Why would they? It's people who aren't completely satisfied with a given language that are going to be more open to looking at others. And so of course then it's a matter of weighing pros and cons. Do I like the syntax? Does it feel intuitive? Am I comfortable using it? Do I find the pain points blockers or minor annoyances?

There is nothing special about D in this regard. If you aren't looking for a new language, you aren't going to try it. And if you are, you either like it or you don't.

WekaIO wrote the world's fastest filesystem in D. They did it without the GC, and went so far as to write their own GC_free standard library (which they open sourced). Their CEO talked about why in this interview:

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

That said "GC-free D" is not a major selling point of the language. You will not find the maintainers recommending anyone start a D project fully GC-free unless there is a very specific use case, like that of WekaIO or the blog post author. The allocation patterns in D are different than they are in Java or C#, it's clearly defined when a collection may trigger, the @nogc attribute provides compiler enforcement for avoiding GC allocations in specific functions, a command-line switch can warn you about the same if you find @nogc too much to think about (because employing @nogc does require more consideration of your architecture), and other switches can help minimize the impact of GC.

So the tools are there for anyone who needs them. There are definitely rough edges and we are forever in need of improvement, but everything is usable and people are using D in production right now.

> Granted, this isn't optional GC, but does D really give you that? Don't you lose the entire ecosystem and stdlib with -asBetterC?

-betterC is not the only way to avoid the GC in D, just the most extreme. The original motivation for -betterC was to ease porting C code to D. Walter has used it for that to port a good bit of his old C code over. But it's also suited for the space in which the blog author is using it, and some people just prefer it. You always have access to the existing C ecosystem, but there are people writing -betterC libraries in the D ecosystem. And as more people use it, I expect that space will grow.

Funkwerk, one of the first companies to adopt D back in 2008, switched their passenger information system from Java and C++ to D. They weren't just on the look out for something different. They had a real problem to solve, tried out a few languages, and settled on D. They're still using it today (they moved from D1 to D2). And if you're riding certain rail networks in Europe, you're benefiting from it.

https://dlang.org/blog/2017/07/28/project-highlight-funkwerk...

The answer to the first question is detailed in the HOPL IV paper, 'Origins of the D Programming Language', freely available here: https://dl.acm.org/doi/abs/10.1145/3386323

Obviously I'm not Walter, but IMO, D's approach to GC does not create any tension. It's just a systems language with a GC that's there if you want to use it. You can disable it completely or only where you need to. Yes, you lose some features when you do so (like automanaged memory for dynamic array operations), but the tradeoffs are well-known and worth the loss when you need to make them. Consider WekaIO, which used D for their filesystem. No GC anywhere:

https://dlang.org/blog/2018/12/04/interview-liran-zvibel-of-...

Anyone who doesn't already have a bash environment installed on Windows isn't the target of install.sh.

Any bash environment on Windows will do. install.sh serves a specific use case for those who need it. It installs dmd in the user's home directory along with a script that enables/disables that specific version in the environment, so multiple dmd versions can be installed side-by-side, and the user can switch between versions as needed. It's a convenience script, more than anything else. More suited for people used to developing in Linux who need to work in Windows from time to time (with or without WSL) than regular Windows developers. The latter group will certainly prefer the Windows installer.

Not quite. I'm saying that in this case it doesn't matter because of the way the API is used. Is it confusing for people who don't understand D ranges? Yes, it certainly can be. It was for me when ranges first came along. But once you understand how D ranges are intended to be used, then you realize you rarely ever care what the return type is. D is not Rust, or C++, or (insert language here).

When the return type actually matters, auto should be avoided unless there's no way around it. But that's why we have "Returns:" in Ddoc. The function signature itself is not the complete documentation. I mean, you're acting like all D functions are documented to return auto. They aren't. It's used where it needs to be.

And the "Returns:" section!

D's classes and interfaces are much like Java's, so it's possible and easy to write functions that express return types like that. It's also quite restrictive for generic programming. D's metaprogramming features are much more powerful. That means a template can return different types that do not conform to a single, easily-expressed interface. The std.algorithm package is built on that concept.

In the standard library, it's primarily in the range-based functions that you see this, where the type doesn't generally need to be known. And where you do see it, the documentation will describe what the function returns more accurately than any convoluted made-up type the function signature could show you.

There's usually no reason to know the return type of any range-based function in D. It's not like auto is applied as a return type willy nilly. And anyone who understands D's ranges and how they are used should have no problem seeing a function declaration that returns auto.

It's not "littered" in the documentation for anyone who understands the basics of D's ranges. auto is the correct choice here. Range functions are lazy, meaning they are almost always used in a chain of function calls that ends in something like `.array` to get a concrete type -- an array in this case. At no point in that process do you care about the actual return type of any of those functions.

The forum post he linked to where he announced DustMite says it's inspired by Tigris Delta and lists some advantages:

https://forum.dlang.org/post/[email protected]...

> they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.

The intent isn't to turn off the GC completely (though GC-averse folks assume that it is). The `@nogc` function attribute is intended to be applied where you need it. Then you can guarantee that in that function's call stack, no language features that require the GC will be used.

The standard library has been retrofitted to eliminate use of the GC where it isn't needed and provide alternatives where possible (such as a function that takes a buffer as an argument alongside one that allocates). There may still be places where it can be trimmed down even more, but it will never be fully `@nogc` compatible.

D is meant to be used with the GC, but provides the means to avoid allocations, turn collections on/off (`GC.disable/enable`) and command line options for profiling GC usage and affecting its behavior. Anyone who wants to turn off the GC completely is going beyond the primary intended use case and is of course going to run into bumps with the standard library. Much of it is still usable, though.

See https://dlang.org/blog/the-gc-series/

Visual D is a plugin for Visual Studio, so no. Code-D is a plugin for VS Code, so it works anywhere VS Code does.

It's actually rather cheap, given the venue.

Aside from keeping the conversations going, keeping lunch on the premises makes it easier to round everyone up after and decreases the likelihood that people are disruptive by streaming in after the post-lunch talk starts. And it's pretty much expected. I would be dismayed if DConf sent me outside for lunch on my own dime.