Worst ideas/features in programming languages?

[russhy]

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 
> wrote:
>> 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 
>level features.

>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 
incremental GC

that's very depressing to focus on whether or not we should use 
the GC

that is not the question we should ask, the question is: what 
problem do we want to solve

AGAIN

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 
https://gpuopen.com/vulkan-memory-allocator/

That is the pragmatic way of designing portable and efficient 
libraries


Have we lost our mind focusing on the GC? i think yes