News for hackers. Stuff that matters.
Re:Rust in Linux kernel is just a beginning by throwaway17_17 on Tuesday October 25, 2022 @09:19PM (#33338497)
My take on this is a little different than the comments previous. I tend to side with your position over the default position the GC is workable as a languages base assumption. I think the problem really is an expressiveness issue. In a language conceptualized to have memory managed either manually or GC’d and that said choice should be easily made (i.e. it should not take much work to designate some code path as utilizing a GC’d strategy), but I would say for implementation and performance you would give up being able to easily abstract over the memory strategy.

tr;dl — I’d really prefer the option to determine when I’d like GC, as opposed to dodging the collector to avoid performance hits, hot code can default to manual. Probably not a realistic ask, but it could work.

Re:Rust in Linux kernel is just a beginning by Ygg2 on Wednesday October 26, 2022 @11:32AM (#33345275)
> I’d really prefer the option to determine when I’d like GC, as opposed to dodging the collector to avoid performance hits

Fair enough. If SS14 used D maybe they wouldn't have these problems.

D and early Rust (pre 0.2, like alpha alpha) had that. Problem is you split your community in two. You get a version of "What GC-color is your function/lib?".

It's a tradeoff for some domains - allow no GC bypass you're going to run into nigh insurmountable performance cliff.

Allow GC as opt-in and you run into issue of splitting your APIs in two.