3 ms·
According to the followup a week later[0] it seems OpenD is doubling down on GC: > One of the guiding principles of this fork is to embrace the GC as a success
by badsectoracula 3y ago
According to the followup a week later[0] it seems OpenD is doubling down on GC:
> One of the guiding principles of this fork is to embrace the GC as a successful design rather than to shun and avoid it. [...] I have harshly criticized @nogc in the past as putting a disproportionate burden on library authors while being the wrong answer to what can be a perfectly fair question.
[0] https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.html https://dpldocs.info/this-week-in-d/Blog.Posted_2024_01_08.h...
- petre 3y agoThe GC works fine. Why waste energy to duplicate the functionality that requires it? Programmers who don't want the GC are already using C++ or Rust instead. The GC is one of those tools that makes programming in D productive. The lack of libraries and modern tooling is the part that ruins it. That's why you get software written in Go and Java instead of D. I'd love to use it for embedded work instead of C and C++, even in the current state. Embeded meaning 32bit MCUs running some kind of RTOS, not ARM SBCs powerful enough to run Linux. If not D, then maybe Zig. For this it needs to be able to link against and build upon existing C/C++ libraries.
- badsectoracula 3y ago> Programmers who don't want the GC are already using C++ Sure, but this was in a response about D substituting C++.
- hashmash 3y agoUnfortunately, the D garbage collector is a simple design that doesn't offer the performance and scalability of a modern collector. Someone switching over to D from Java/C#/Go might be surprised to see GC pauses reminiscent of 1998. Hopefully the maintainers of the D fork will address this.