Hi, I'm the author of the article. Feel free to ask any questions you may have. I have to go to bed, I have work in about 4 hours, so I'll reply when I can.
Long live Holden, long live the ute!! Thanks for keeping your VZ alive
Driving with D
131–140 of 186 posts
Re: Driving with D
#132Any reasons D never caught on more? No big tech company anchor behind it?
D chose GC.
Re: Driving with D
#133> Uniform Function Call Syntax (UFCS)
> This has made my code significantly clearer. My code can accurately follow the flow of data without polluting my stack with single-use variables, nesting many function calls, or other sorts of clutter.
This is also pretty common practice in Haskell. Though Haskeller's typically have a higher tolerance for reading their code backwards. (But you don't need to. It's easy to define operators that arrange your code in the other direction.)
Re: Driving with D
#134Earlier quoted context omitted.
I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: -…
D is easy to pick up, and has three really fast compilers. It feels like a very practical language. Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway. And I really question what these situations are where you can't have g…
>And I really question what these situations are where you can't have garbage collection in 2021.
Game development, anything with a UI (GC pauses frustrate users), anything that needs high performance (scientific applications, data analysis), you name it. Ownership semantics have a side-benefit of automatic thread safety; something that is less important than memory safety (because many programs can work in one thread but almost no programs can work without allocation) but extremely valuable when needed.
Re: Driving with D
#135Earlier quoted context omitted.
> language features that require said GC A whole two features: 1. concatenating strings using the ~ operator. You can concatenate strings using malloc if you prefer. 2. closures that escape the context of the function they enclose. Instead, write a struct with fields representing the values, and make the lambda a member function of that struct. Allocate the struct instance any way you wish. The GC is a convenient fea…
Maybe something changed, but I thought array concatenation with ~, associative and dynamic arrays as well as exceptions rely on the GC as well. It's a short list, for sure, but thats not the point: Anyone looking into using D without GC will see that there are some language features that require special care. At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one alre…
> 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.
Re: Driving with D
#136Earlier quoted context omitted.
Maybe something changed, but I thought array concatenation with ~, associative and dynamic arrays as well as exceptions rely on the GC as well. It's a short list, for sure, but thats not the point: Anyone looking into using D without GC will see that there are some language features that require special care. At that point it becomes a valid question why one should learn about the pitfalls of GC free D, when one alre…
> 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 alre…
> That said, there is a plan to enable @nogc exceptions.
It's been implemented.
Re: Driving with D
#137Earlier quoted context omitted.
Just added C11 anonymous structs last night!
I saw, as long as the code stays clean I think we're going to be kicking ourselves this only happened now.
So far, it's shaping up nicely. I am indeed kicking myself for not doing it a while ago, but I'm a better programmer now than then, and it's going to be a better job.
Re: Driving with D
#138Earlier quoted context omitted.
The idea that Rust is suitable to replace C and D isn't is odd to me. It's really not hard to do + we (unlike some languages, not sure about rust) actually test on embedded targets via GCC.
What I meant by this is: if you are starting a project today, and have to choose between C and C++, there are certain reasons why you might choose C over C++. Those same reasons would apply for choosing C over D. They might not apply for choosing C over Rust.
Almost the only reason I would choose c over c++ for embedded would be if the c++ compiler was garbage for the platform or the team wouldn't allow it.
Re: Driving with D
#139Earlier quoted context omitted.
I used D for a while. It improves several things over C++, among them: - More powerful metaprogramming capabilities. - Better module and library system. - Nicer syntax. The problem IMO is it's just not enough to justify a total move from C++ -> D. The syntax of C++ can't really be fixed, but the other aspects can be improved without a new language. Furthermore, many of the other downsides of C++ are still present: -…
D is easy to pick up, and has three really fast compilers. It feels like a very practical language. Rust in comparison feels much less practical - glacial compile times and byzantine rules about manging memory. It may be 'safer' but that's a moot point when I find it all so unintuitive that I'm not going to be able to make anything with it anyway. And I really question what these situations are where you can't have g…
Audio plugins is one case. Dplug disables the GC because of an issue on MacOS. So far there is no workaround so we have to write @nogc code.
Re: Driving with D
#140Just - impressive.
And since this is about dlang a bit... My favorite part of D compared to cpp, was metaprogramming syntax. (i.e. NOT '') I was so sad when I got to know that the only thing that rust took from cpp, was ''.