Talk on what a systems programming language needs to replace C
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.
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