Worst ideas/features in programming languages?
russhy at gmail.com
Mon Oct 18 14:39:35 UTC 2021
On Monday, 18 October 2021 at 11:33:02 UTC, deadalnix wrote:
> On Monday, 18 October 2021 at 11:08:08 UTC, Ola Fosheim Grøstad
>> Well, yes, malloc is only the default, when people want speed
>> in system level programming they create their own allocators.
> It doesn't matter. These allocator need memory from the system
> and almost always use malloc do get it. Which as far as the GC
> is concerned, it the only thing that is needed. It doesn't
> matter if you malloc each object or if you malloc a large slab
> and then manage it manually.
and then you freeze all threads and must scan all allocated
pointers whenever your "gc'd malloc"'s buffer needs to grow
>In order to get to a competitive advantage, D has to decide what
>its primary use case is. >Maybe it would be better for D to
>position itself as a higher level language with some >lower
>I think also GC and malloc can be combined and improved on. You
>could probably get better >performance and less fragmentation if
>the allocation contained a hint of when it >statistically would
>be released. You could also get better performance by providing
>>information about typical allocation patterns and sizes.
>But without a clear vision of what the key use cases for the
>language is, getting a >direction on all of this is going to be
>difficult. (Much easier to make tough decision if >you have a
>clear picture of what the main use scenario is.)
you can't compete with highlevel languages and their sub 1ms
that's very depressing to focus on whether or not we should use
that is not the question we should ask, the question is: what
problem do we want to solve
ASP.net team is working hard on reducing the impact of the GC in
their library!!!! even thought they have a competitive GC, they
are making sure they don't do useless GC allocations and are
using Span/stackalloc/ValueTysk everywhere!!
Learn from them, don't be like their old-them and saying, we
should use and embrace GC everywhere
That is not how you make fast and competing software......
The smart and pragmatic approach is to give tools for people to
write efficient software
Allocators is one of them
And it doesn't change the way people code, if they want to use a
GC, they are free to do it so
But go tell an graphics engine programmer to use a GC, he'll
laugh at you
Vulkan is meant to be used with an allocator
That is the pragmatic way of designing portable and efficient
Have we lost our mind focusing on the GC? i think yes
More information about the Digitalmars-d