Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

gossamer-lang.org

Post reply on HN
Print view View original

51–60 of 98 posts

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#51

Post by nu11ptr »

platinumrad wrote: post #3
quotemstr wrote: post #2

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-so…

> 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?

> 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.

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#52

Post by adastra22 »

quotemstr wrote: post #21
adastra22 wrote: post #15

Earlier quoted context omitted.

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

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 G…

Yes, I am. That’s why I develop on a systems programming language, and why systems programming and GC are not compatible.

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#53

Post by yunuskusak »

quotemstr wrote: post #8
iyn wrote: post #4

Earlier quoted context omitted.

> We have multiple open-source pauseless miracles GCs right there in front of us Can you share some links/references?

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 a…

[flagged]

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#54

Post by bfung »

reocha wrote: post #49

Three things stick out to me on https://gossamer-lang.org/docs/migration/rust/ * No user macros at all. Six fixed format! / println!-family macros expand at parse time. - Meta programming is incredibly important in rust. * (unsafe is) Forbidden at the language level. No unsafe keyword in Gossamer source. std is safe-Rust too. - No low level programming then. * No move semantics. Non-trivial values are heap-allocated,…

Totally agree, misleading.

The syntax looks like rust, but esp w/the memory management model (reference counting), it’s going to have more overhead than rust when it’s running, more like Swift or at worse, Python.

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#55

Post by yunuskusak »

LoganDark wrote: post #28
lstodd wrote: post #27

Earlier quoted context omitted.

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

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.

@LoganDark You're right, as long as there is an object graph to scan, 'uncontrollable' latency is an inherent trade-off in GC-based systems. I’ve taken a different route with a C++20 execution engine that eliminates the object graph scan entirely by using pre-allocated, static memory pools and lock-free SPSC structures. It's essentially moving from 'managing GC pauses' to 'deterministic, zero-allocation execution'. Have you ever benchmarked your systems against a lock-free architecture that bypasses the allocator on the hot path?

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#56

Post by yunuskusak »

lstodd wrote: post #27
quotemstr wrote: post #14

Earlier quoted context omitted.

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.

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

[dead]

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#57

Post by quotemstr »

lstodd wrote: post #27
quotemstr wrote: post #14

Earlier quoted context omitted.

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.

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

And we disagree on how best to gain control of latency. Some say that the way to gain control of memory management latency is to track object-level allocations locally using malloc/free-style APIs, arenas, and so on. IMHO, low tail latency achieved through this approach is fragile and often illusory: object reference graphs are often bigger than you expect, and malloc/free-style heap managers (even with thread caches) need to do global synchronization eventually. Arenas work for some cases, but often break down for complex programs. (Look at libapr!)

No, I think GC is the way to control latency of memory handling. Plenty of work on real-time GC shows that you can construct a GC such that if the mutator allocates less than X MB/second you can achieve reclaim latencies under Y ms. The nice thing about these guarantees is that they're global: it doesn't matter how you allocate. All that matters is how much you allocate. It's a metric you can measure and optimize, IMHO, more easily than you can try to bound heap-manager contention and free-SCC size.

Granted, you can come back and point out that it's hard for me to prove I don't have allocation-rate spikes just like it's hard for you to prove you don't have lumpy free()s and malloc pool contention. But IME, it's a lot easier to bound latency rates, because we have good allocation profilers and in many cases you can prove allocation caps. IMHO, it's much harder to reason about long-range interactions of threads touching heaps.

The one primitive I wish we had but (outside BEAM) don't is object coloring. In a GC system, I should be able to allocate objects from different heaps and GC them independently .This way, a can write a subroutine that I can prove locally obeys the allocation-rate rule for my latency target and doesn't do any global allocations without giving up the use of the global heap for other purposes. They'd be a bit like the explicit arenas your tribe uses. (Your child heap would count as one "object" for purposes of parent-heap retention.) You could probably adapt existing multi-pool systems like MPS and ART's GC pretty easily too.

But even absent QoL features like these, modern GC is plenty suitable for programs that need to be responsive.

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#58

Post by Zak »

I'm seeing a big red flag here for what purports to be a systems programming language: it isn't used for its own compiler. The compiler is written in Rust.

A systems programming language should be able to self-host its compiler. Writing compilers is one of the canonical systems programming tasks. Making that happen may not even be hard in the LLM and LLVM era as it's a fairly mechanical task for an LLM to execute, and you can output textual LLVM IR to bootstrap on any architecture LLVM supports.

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#59

Post by Twey »

samuell wrote: post #12

Glad to see more languages adopt true goroutines [edit: lightweight threads or fibers] with M:N scheduling. Surprised more haven't. Among compiled language I'm only aware of Go and Crystal off the top of my mind.

Green threads predate modern async/await by quite a long way. Since async/await was developed, recent languages tend to prefer the ‘principle of least surprise’ by making the yield points explicit, since they interact in important ways with the code around them, with the notable exception of Go (which is very weird considering how explicit they decided to make their error handling).

Re: Gossamer: a Rust-flavoured language with real goroutines and pause-free memory

#60

Post by mappu »

nu11ptr wrote: post #51
platinumrad wrote: post #3

Earlier quoted context omitted.

> 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?

> 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…

This is all true but is a somewhat Java-flavoured perspective i.e. generations ties you into a moving collector, which ties you into barriers and complicates FFI, which is not always the right tradeoff.

A non-fragmenting allocator goes a long way to alleviating the need for compactions too.

Post reply on HN