Worst ideas/features in programming languages?

[russhy]

On Friday, 15 October 2021 at 23:58:34 UTC, deadalnix wrote:
> On Friday, 15 October 2021 at 21:55:55 UTC, SealabJaster wrote:
>> On Friday, 15 October 2021 at 16:44:57 UTC, deadalnix wrote:
>>> Then end result in practice is that almost everything uses 
>>> the GC, and that @safe and @nogc are almost useless.
>>
>> Is there anything we can do to start addressing this, and the 
>> other woes people have brought up?
>>
>> The answer is likely no, so I foresee these same things 
>> popping up over and over and over again with no resolution 
>> since we seem to have dug ourselves into a corner.
>
> Well at some point we need to make choices about the invariant 
> we want and stick with them.
>
> Considering D's values, I'd say the solution that make sense is 
> to allocate using the GC, have an ownership system on top of it 
> that can free most things safely. You'll note that is is 
> possible to build a GC that is as fast as malloc free (for 
> instance, I was able to build a GC on top of jemalloc, and the 
> only thing I had to add is one hashmap store when allocating 
> chunk of size bigger than 4MB. this happens almost never and 
> when it does, memory allocation is usually not the problem as 
> simply filling these 4MB with literally anything is far more 
> work than the work the allocator does (to be 100% fair, this 
> doesn't work with all mallocs, a tcmalloc style structure 
> wouldn't cut it for instance, but jemalloc is notorious to be 
> one of the fastest and bestest so we are not making a big 
> concession).
>
> So using a GC instead of malloc/free is very much viable. In 
> fact, because we know if something is shared or not, I bet we 
> can do something that is even faster than traditional mallocs.
>
> So we allocate on the GC, always and use ownership on top of 
> it. Ownership should allow you to express common 
> allocation/disposition patterns, and when you can't, either you 
> leak to the GC, or you free explicitly, which is unsafe.
>
> That require repurposing @nogc as preventing leaking from the 
> ownership system to the GC rather than allocating on the GC - 
> which in itself is no problem if the allocations are freed 
> properly.
>
> There are a ton of added benefit that come attached to this if 
> done properly, like solving a ton of problems with shared.
>
> Even tricky situations such as @nogc exception become trivial 
> in that model. Consider:
>
> ```d
> void foo() {
>     // Allocate the exception using the GC. The exception is
>     // an owned(Exception), and the corresponding overload from
>     // the runtime is called.
>     // Ownership of the exception is transferred to the runtime.
>     // The ownership system didn't lose track of the exception, 
> so
>     // foo can be @nogc .
>     throw new Exception();
> }
>
> void bar() {
>     try {
>         foo();
>     } catch(Exception e) {
>         // The ownership of the Exception is transferred back 
> to the
>         // user's code. The Exception doesn't leave the catch 
> block,
>         // so it can be freed automatically without the user 
> having to
>         // do anything.
>         // In practice, that require the runtime to provide the
>         // exception handler with knowledge of the exception 
> being
>         // owned or not and a runtime check, so that, if it is 
> owned
>         // it is freed.
>         // bar can also be @nogc , because either the exception 
> is owned
>         // in which case it is freed and no leak occurred, or 
> the exception
>         // is not owned, in which case the leak happened 
> somewhere else.
>         // In that case, this somewhere else cannot be @nogc .
>     }
> }
> ```
>
> You'll note that the ownership system does not need to be as 
> rich as Rust's, because there is always the option to fallback 
> on the GC or on unsafe constructs.


What is your plan to make GC incremental? what about latency 
sensitive applications?

Can you scale the GC? servers with heaps above 1TB?

Both Java and Go can scale their GC and ensure sub 1ms collection 
without stopping the world

I hear you want to stick to the GC no matter what, did you know 
to target 60 FPS in games, one only has a budget of 16ms per frame

Languages with GC can afford one because their GC is competitive 
and they put lot of R&D in constantly improving and tuning them

I'm not saying GC is bad, i'm saying if you want someone to take 
you seriously, you have to provide serious tools so you can 
assist them whenever they need to scale their buisnesses


Look at ASP.NET team at microsoft, they all working towards 
improving the C#language so it is much less reliant on the GC

Span, value task, ref, stack alloc and bunch of other stuff they 
have planned for C# 10

D's history is C/C++, why stray away from that history?