UFCS example uses units, which looks neat, but assigns injectorWidth to a variable injectorTime, which seems wrong?
I believe width is referring to pulse width, which should be a time unit.
Bingo!
Driving with D
111–120 of 186 posts
Re: Driving with D
#112Re: Driving with D
#113Re: Driving with D
#114Re: Driving with D
#115I use D every day for own business and it's a pleasure. Nice work!
Thank you! Your post about D without its runtime is a fantastic read.
Re: Driving with D
#116Earlier 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: -…
> such as the fact that a safe subset exists, but depends on GC, @safe works perfectly fine and exactly the same in @nogc code as in GC-enabled code.
That's a bit disingenuous. Memory allocations in D require either GC or non-local unsafe code.
I'm aware that D has @live, a WIP attribute that mimics Rust semantics, but it's not remotely ready for production.
Re: Driving with D
#117Any reasons D never caught on more? No big tech company anchor behind it?
Certainly not the sole reason, but the mix of language features puts it into a weird spot: You have great control over memory layout and can easily embed assembler, which would be perfect for performance sensitive software like games. Yet "default" D comes with a garbage collector and - more importantly - language features that require said GC. If you want to go the noGC route, you have to refrain from using certain…
> 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 feature with lots of nice uses. Programming in D is not impaired by not using it.
Re: Driving with D
#118Earlier quoted context omitted.
I'm surprised you mentioned memory allocation without spotting the memory allocators in the standard library. Andrei designed the library and as far as I can tell no other language comes close when it comes to composable allocators.
I dunno why you assume that I don't know about them... Apart from that, they came pretty late, are still in experimental, and don't change the fact that only a subset of D is usable without GC. I very much like D, I really do, but I never encountered a usecase where the pros of using D outweight the cons. It sits in a very very weird spot design-wise, and while Walter and Andrei tried their best to get rid of the mos…
If you don't want to use the GC, why the concern about its implementation?
I have no idea what you mean by "proper" compile time functions. D's CTFE is excellent.
Re: Driving with D
#119Earlier quoted context omitted.
As far as I know D's original design strategy, was to be a simpler to use C++ with a GC, but with the same expressive power Over time, this proved to be a bad strategy, C++ key strength became RAII (deterministic memory management), so the GC became a failed strategy The maintainers tried to move in different directions, adding manually memory management, making the GC optional, moved D to be a C replacement, with th…
This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…
on the point of the GC being a good thing to have, this is true, but not when your main objective is to replace C++, C++ key advantage being RAII deterministic manual memory management
You cant replace C++ with GC language, even 10 years ago this should have been evident to a seasoned developers such as Walter Bright and Andrei Alexandrescu
Sometimes great developers are bad product managers
Anyway, with Rust and Go, D have no where to go, I don't think it should be fixed to appeal to a wider user base, the only good strategic move they can do today, it make it better for the current user base, they have few big users, they should focus on them and the language will fade once those users move on to something else
Re: Driving with D
#120Earlier quoted context omitted.
This isn't a very good summary of how the language evolved. D has basically always had the ability to not use the GC, it's only recently that we've taken an interest in replacing C. The GC has been written in D for a very long time, that wouldn't be the case if the language didn't allow manual memory from day 1. BetterC is a nice-to-have rather than a language dialect. Having a GC is an absolute godsend for getting c…
on the point of the GC being a good thing to have, this is true, but not when your main objective is to replace C++, C++ key advantage being RAII deterministic manual memory management You cant replace C++ with GC language, even 10 years ago this should have been evident to a seasoned developers such as Walter Bright and Andrei Alexandrescu Sometimes great developers are bad product managers Anyway, with Rust and Go,…
Then don't use the GC? Ignoring that a lot of C++ developers are practically incompetent and completely unable to separate their ideology from the actual requirements of their software (I note that not one single even anecdote has been mentioned regarding the GC in this thread), D gives you the tools to do that already. I work argue not as polished as C++, but that really doesn't matter if you set out to write a new project.
Also, if you think existing D users are going to replace D with Go I don't know what to say to you. Go and Rust are literally punchlines without a need for a joke in discussions I've had with many senior people at these companies (Mostly Go). The reasons why people use D are so utterly detached from everything that has been discussed in this thread that I don't know what to say to you. Go is a bad programming language, pure and simple, good ecosystem, awful language.