[quotemstr]

Gossamer has a cycle collector and eager reference counting. Good luck dropping the last reference to a 10,000-node graph, especially if cyclic. That means it doesn't have "pause free" memory. If you want pause freedom, go use ZGC or another modern GC on a modern VM.

I just can't take seriously this spate of languages that ignore the past 30 years of research into automatic memory management. We have multiple open-source pauseless miracles GCs right there before our eyes, yet it's the trendy thing in language design to foist memory management on users.

You don't even have to use a big VM if you want good GC. Go use MPS. Lots of options out there, even if you want to implement your own VM.

[platinumrad]

> We have multiple open-source pauseleses miracles right there before our eyes

Is this meaningfully true in a practical sense? I've been writing code with soft real-time requirements and I don't think your notion of "pauseless" suffices. And if these miracles are open-source and right before our eyes, why do languages like Crystal and D still use Boehm?

[nu11ptr]

> why do languages like Crystal and D still use Boehm?

Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system (it was designed for use in C/C++). I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (free list allocator), poor cache locality, and not precise (so you can expect memory leaks). If you are going to do a GC language you want: 1) precise 2) bump allocator 3) compacting collector 4) generations. Essentially you want to allocate fast, only touch live objects (most objects die young), compact them for locality, and only process objects each cycle of similar age. There is a huge amount of engineering that goes into a state of the art collector, but those are the basics.

[gomoboo]

D uses a homegrown GC not Boehm: - https://dlang.org/spec/garbage.html - https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/

[quotemstr]

The charitable explanation is the authors lack the time to rebase onto something more modern.

[platinumrad]

You seem to have a very low opinion of other people. If these miraculous collectors are so generally applicable, why are very smart people putting effort into things like Perseus?

[quotemstr]

Smart, honest people can have sincere and earnest disagreements. I believe the manual-memory-management people are mistaken. That's not to say they're stupid: it means I believe they're going down the wrong path, as smart people have done since time immemorial. I wish them all the best. That said, I must wonder what other innovations they reject if they insist that GC is unacceptable.

[lstodd]

We insist that GC is unacceptable only because we insist that uncontrollable latency is unacceptable.

[LoganDark]

The entire concept of a pauseless GC is that you have no uncontrollable latency. The GC can run on a background thread with zero stop-the-world.

Of course, this assumes you're in a preemptive environment with access to other threads, etc.

[smj-edison]

The one plus I'll give reference counting is it still takes the cake for interoperability with C. Which is only important if you need good interoperability, but when you do, tracing GCs don't play nice.

[iyn]

> We have multiple open-source pauseless miracles GCs right there in front of us

Can you share some links/references?

[elitepleb]

https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...

[quotemstr]

ZGC is extremely good work.

https://wiki.openjdk.org/spaces/zgc/pages/34668579/Main

> ZGC performs all expensive work concurrently, without stopping the execution of application threads for more than a millisecond. It is suitable for applications which require low latency. Pause times are independent of the heap size that is being used. ZGC works well with heap sizes from a few hundred megabytes to 16TB.

Go's GC is also very good: https://go.dev/blog/greenteagc.

V8's Orinoco is also pretty good now. It's improved a lot over the past decade and is now mostly-parallel. (A decade is about how long one of these things takes: high-performance GC is hard.)

I'm also a fan of MPS: it's a big of dark horse because it's more a GC construction kit than a ready-to-go GC, but it's fast and flexible, and I'd start with it any day over Boehm if I were making a VM from scratch.

[adastra22]

A millisecond is an eternity. It is 1/3 of the entire time allocated to a frame update in a modern game.

[treyd]

Game GCs are interesting because you know that the execution is structured like this and you know how much time you have left before you have to switch back to application code for the next frame/time step. There's interesting optimizations you can make around this and could almost completely avoid user-observable GC pauses.

[quotemstr]

Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack.

That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault:

You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right?

No? You're not doing any of these things? Then why are you worried about 1ms in GC?

[kelseyfrog]

Exactly. This is why Minecraft Java edition was such a disastrous flop.

[platinumrad]

If I were writing this language, I'd probably just compile it to Go, although that means Rust extensions would either incur cgo costs or have to be replaced with Go extensions.

[phplovesong]

You just described http://www.lisette.run

[RedComet]

Are any of those actually pauseless like he asked for?