Talk on what a systems programming language needs to replace C

IGotD- nise at nise.com
Sat Sep 7 19:26:55 UTC 2019


On Thursday, 5 September 2019 at 20:21:12 UTC, H. S. Teoh wrote:
> On Thu, Sep 05, 2019 at 07:33:05PM +0000, bachmeier via 
> Digitalmars-d wrote: [...]
>> It's true that Rust does appeal to the sliver of programmers 
>> that think memory management is an awesome way to spend 
>> Saturday night, but let's let Rust have those users and worry 
>> about a good experience for the rest.
>
> +1, couldn't have said it better.  Coming from a C/C++ 
> background, I'm well-versed in all-nighters spent debugging 
> memory management problems, and personally I find D's GC a 
> godsend.  I am *so* much more productive with the GC when 
> performance isn't a big issue, and even when it is, there are 
> ways to control the GC so that it stays out of the bottlenecks 
> in the code.  It isn't as though this is Java where you are 
> *forced* to use the GC, after all.  (In many cases the GC isn't 
> a problem as long as you don't trigger it inside 
> performance-sensitive inner loops.  Cutting out GC from the 
> *entire* application as a knee-jerk reaction is, IMNSHO, 
> premature optimization. Heck, even game engines these days 
> support higher-level scripting in GC'd languages -- you just 
> have to keep the GC out of the core performance sensitive code 
> and it's Good Enough(tm).)
>
>
>> > There's still room in the world for DasBetterC, so I hope 
>> > the development continues. It's great that many of the 
>> > annoying restrictions have been lifted.
>> 
>> Exactly. There's no reason to choose between D and betterC 
>> because we can have both.
>
> +1.
>
>
> T

There two situations here when it comes memory management. When 
programming near hardware or OS level stuff you often want to 
manage your memory yourself. These are often very specialized 
allocators in order to optimize the usage and fragmentation. Here 
you deal with the memory management manually anyway. The other 
side to this are applications where I don't really care about the 
memory that much, in this case GC is king and that Rust way of 
manage memory is just annoying at least for my projects. I want 
to go from A to B as easily as possible and GC is usually the 
best approach for this. Computers are supposed to work for us, 
not the other way around.

I think that D have the opportunity to provide both scenarios. 
Most of the library can be GC but there are exceptions. String 
manipulations should avoid GC as this is often done in an OS less 
or real time environment as well. IO should avoid to too, for 
performance reasons as well.

I also say, keep the GC. Remove the GC where it makes sense. 
-betterC should continue to evolve and I would actually like to 
see classes with polymorphism (both GC and manually allocated) 
with betterC as well.




More information about the Digitalmars-d mailing list