* 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, reference-counted, and shared by reference; primitives are copied the same as Rust. - Again, no low level programming.
Calling this rust flavored (or even a systems programming language) seems a bit bold.
It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.
Google called Go a "systems language". I agree its not the right term, but people do use it to describe a language used in infrastructure software like Docker or Kubernetes.
To me it makes a lot of sense as a starting point. The world does not need another Rust since we have a perfectly good one. People who like Rust's type system but don't care to think about ownership when writing application code, and who appreciate the language asyncing all the things invisibly have plenty to like here.
I do agree though any serious language MUST have an FFI capability, and macros or at least some form metaprogramming of seem like tablestakes. Green threads are not impressive if they are not preemptive. But its not describing itself as finished, its 0.19. Rust looked completely different at that stage in its development - I think it still had green threads itself at that point.
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.
It doesn’t have a garbage collector, it uses reference counting with a cycle detector. So, no GC pauses. It should be suitable for hard real time systems.
My impression was that Gossamer has good Rust FFI rather than basic C FFI, sharing struct layout etc. I may play around with Gossamer and see how it really does performance wise…
The syntax similarities help make for a more painless two language approach.
If you are interested in Gossamer, you may also be interested in Lis, which is Rust flavored and compiles to go: https://github.com/ivov/lisette
From their readme:
Safe and expressive:
- Hindley-Milner type system
- Algebraic data types, pattern matching
- Expression-oriented, immutable by default
- Rust-like syntax plus |> operator and try blocks
- Go-style interfaces, channels, goroutines
Quietly practical:
- Interop with Go ecosystem (WIP)
- Linter, formatter, 250+ diagnostics
- Fast incremental compiler, readable Go
- LSP for VSCode, Neovim, Zed, Helix, GoLand
I would also like to toss my project into the ring, which also allows mixing most real-world Rust & Go packages together, on runtime & syntax compatible level. https://github.com/deepai-org/omnivm
Pardon the sloppy readme - it actually does work :)
I can't figure out the point of having both go and spawn. `spawn` seems to be an ordinary thread spawning mechanism, generating a handle that you can join with (but not cancel? can't find that for certain, it's not actually in the tour but is in the SPEC.md). `go` inherits all the problems of go routines. You can't join with it, you can't cancel it, you have to build other infrastructure on top of it to achieve those effects. As neat as golang was 17 years ago when it came out, this was and still is a major weakness of the language which has resulted in the community developing conventions (now standardized in the go standard library and particular usage patterns) around how to deal with it. I don't get why you'd half fix it (by introducing spawn) but then leave it in anyways. Just let the handle from spawn be ignored and you remove that particular footgun (it becomes a choice to ignore it, which still causes problems but at least the programmer chose to shoot towards their own foot).
Somewhat with you on this. I got slightly excited for a brief moment, but then the site starts to scream "an LLM threw this together super quickly" which doesn't spark joy at all.
I then started digging into the code examples and quickly determined that nothing about this project is for me, even as a fan of Rust and some of its influences it has on recent languages. That web routing example is absolutely gross to my eye, for example.
Different strokes for different folks - my own thoughts on language design (I'm hacking on one in private over the past several years, maybe one day it'll be shareable) would probably make some folks have a similar reaction, despite taking a wildly different approach than here. But it does suck to see Yet Another Vibe Looking Site hosting a language that feels like Yet Another Flavor Of Similar Stuff. Really looking forward to a language that wildly shakes things up in a usable way, and has a lot of care put into the DX... this one did not check that box for me.
Looks like we may be going to go back to the geocities days of primitive websites. I use still use hugo to generate my personal site automatically from markdown upon PR approval.
This post reminded me of Swift– a modern high-performance language that uses automatic reference counting. Its got a REPL and compiles via LLVM. It does trade goroutines for something with a little more safety built in.
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.
> 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.
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.
Not necessarily Java-flavored, but internally vs externally focused, yes. More difficult FFI assuming that is the exception not the rule, and that the language itself takes precedence. Write barriers are also not a given if using segmented heaps. Many ways to do this and no single right way. Memory allocation scheme isn't something that is just bolted on, but needs to be aligned to the rest of the language. For example, Java needs such fast allocations and good GC because it does almost no inline allocation whatsoever, so without the best GC on the planet, it would be a lot slower than it is. Contrast this with Go, which has a solid amount of inline allocations, and hence, can get by with a much slower allocator (~3-4x slower by my measurements) and a more basic mark-sweep allocator since the memory pressure is solidly less.
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?
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.
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.
I feel I have to insist that to control latency one has to first eliminate any intrinsic source of it (a GC) and only then deal with what's left (using arena/pool allocators and such) in the face of even soft realtime requirement (which imo should be the default unless utterly impossible).
This is comparable to what you say about coloring, like, if say java had _both_ GC and zig-like allocator api, so one could have fine control over what is happening. Unfortunately it does not, and the idea of not putting all eggs in one basket is somehow unthinkable.
@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?
The lock-free architecture that bypasses the allocator on the hot path is called `alloca`. Many mainstream compilers, and nearly every language that is not C, seemingly haven't properly supported it for years.
Please don't twist. alloca is in fact a limited arena/pool allocator and as such for some small sizes it is latency-free. It is also there in C. It does not have anything to do with GCs.
You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling.
This is false.
One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false.
There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
> 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.
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.
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.
It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.
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?
I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses:
- infrastructure development like Docker and Kubernetes
- general utilities programming like grep, terminal emulators, compilers, etc
- performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers
and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology.
I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.
What are you describing as a frame update? I am trying to be as generous as possible to your comment and thereby assuming there is a disconnect between my understanding of ‘frame update’ and yours. Genuinely curious, because that term as I am familiar with it means the entire time allotted to generating and rendering a single frame for display. If that’s what you meant, you are asserting that a ‘modern game’ is typically running at 333 fps. I am typically using the term ‘modern game’ to describe newly releasing AAA games nearly all of which struggle on many hardware configurations to achieve a steady 60 fps (which is 16 ms per frame).
e-sport competitive games target either 128Hz or 320Hz update frequency. Two rules of thumb: first if you want to actually get 60Hz every frame (e.g. on a console where 1st party validation cares about this more), then you attempt 120Hz so jitter only brings you down to 60Hz. Second, a bit more than half of your time is spent doing other things. So the amount of time you actually have to spend on world-update and/or render logic is only about half of your allocated time to start with. That's two independent factors of two there. I would have targeted 90Hz to start with, which gets you to about 3ms of actual time per frame.
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.
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.
It's only 2 months old. Clearly vibe coded. Still, kind of crazy what you can vibe code now.
Also the actual language design seems quite nice. I'd love something like this that was embeddable (and not vibe coded). There are basically no good easily embeddable languages. Everyone used Lua but it sucks.
But, maybe this is a terminology issue conflating an embeddable language with a language used for embedded programming. I think this is one of those CS issues prevalent for non-native English speakers (especially when those devs are relying on translations of text without LLM style semantic analysis of the source).
The first refers to the shipping of a language interpreter within the executable of a program, where that interpreter then processes “scripts”, data files, high level non-programmer editable object attributes or behaviors, etc. The most prevalent example of this is shipping a Lua interpreter inside a video game for interpreting hot reloadable asset scripts. The second usage of embedded is the implication that code is being run on a microcontroller or SoC ‘embedded’ within some other product or device.
Interesting idea, but wouldn't an embedded language normally be interpreted/runtime editable? I guess you could do it shipping a rust compiler, but it'd be big. A bit like Numba?
This is exactly the language I've been yearning for - the exact motivations and intersection of features that would be the sweet spot for me.
Kotlin without the Java baggage.
Rust but with automated memory management and without async bifurcation.
Go with a modern type system.
Swift but with green threads and a linux community.
Haskell without the hair shirt.
Elixir with a full type system and native performance.
But yes there are some flags others have mentioned, I won't repeat them. "goroutines" ?
Even on the off chance this project is not entirely vibe coded how could it ever build an ecosystem? How can any new language? All the libraries would be suspect for the same reason this repo is. The agents won't know anything about it, no one will believe it can get momentum so it won't.
Thanks - edited - I meant to say "but with a" garbage collector. I like Rust, but I don't like thinking about ownership all the time. Although when I just make Codex do it its really not that bad.
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.
Haskell does too. And it predates Go by a large margin, such that calling it goroutine is weird. And within Google, the C++ implementation fiber also predated goroutines. It really shows that this is more of a library feature rather than a language feature.
I agree with your objection to treating goroutines as the baseline implementation of fibers. However, I would disagree with categorizing the feature as a library feature vs a language level feature. In “low-level” languages (C, Rust, Zig, C++, etc) the ability and option exists for having ‘green threads’ with most of their commonly assumed characteristics be library based constructs (although see [1] for why that’s not true for threads in general ). However, almost all managed/runtime-required/scripting/“high level” languages lack the facilities to implement almost any realistic types of fibers and any FFI based implementations are going to suffer severe syntax integration issues (I am assuming somewhat on this point).
TL;DR Green threads are on a library feature for low level languages.
We are not disagreeing here. Your citation is actually not relevant: Boehm is arguing that you cannot implement threads as libraries in a language without threading. But all modern languages actually have OS native threads; the addition of green threads to this environment does not require any further changes to the compiler in addition to what has been changed to support OS threads. If anything, green threads are even easier to support than real OS threads depending on the preemption design.
Another thing is the stdlib integration of goroutines. We see this in Python where various generations of paradigms kind-of coexist. Golang built their goroutines into the heart of the stdlib which puts it IMHO in a special position.
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).
Java and Crystal are not equivalent - neither have preemptible threads. Lots of other languages have co-routines or other cooperative systems - async/await are really just variants of that.
I didn't check if Gossamer is actually preemptible.
I believe the short list of production languages with preemptible M:N schedulers are limited to:
They are not - and do not claim to be preemptive. They claim they are "not cooperative", but even that doesn't mean what anyone else thinks it means.
This paragraph is the only one containing the word "preempt" in JEP 444:
"The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads."
We were talking about n:m threading, especially with threads being blocking IO-aware, being able to automagically turning such a call to non-blocking. Java more than fits that description.
The original message you replied to said (mistakenly):
> adopt true goroutines
Goroutines are preemptive. The distinction between cooperative and non-cooperative concurrency is very significant - it is the difference between never having to think about the scheduler and always having to thinking about it when doing CPU intensive tasks.
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.
IDK what's the fuss. m:n scheduled by io is .. 2000s-era. The implementation was so obvious in like 2005, that even I patched then Python 2.6 in, so we at my then company could get rid of Twisted.
Also let you remind that M:N scheduling was the FreeBSD's pthread implementation for quite a bit too long. No, it didn't play well with MySQL at the time.
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, reference-counted, and shared by reference; primitives are copied the same as Rust. - Again, no low level programming.
Calling this rust flavored (or even a systems programming language) seems a bit bold.
It has a Rust-like syntax, enums, matching, traits, etc etc. Yes, it also loses a lot of special characteristics of Rust, but it has to be different somewhere. Moreover a lot of people like Rust as a high level language, i.e. ignoring the lower level capabilities and lifetimes, and this seems to be a direct response to that feeling.
Google called Go a "systems language". I agree its not the right term, but people do use it to describe a language used in infrastructure software like Docker or Kubernetes.
To me it makes a lot of sense as a starting point. The world does not need another Rust since we have a perfectly good one. People who like Rust's type system but don't care to think about ownership when writing application code, and who appreciate the language asyncing all the things invisibly have plenty to like here.
I do agree though any serious language MUST have an FFI capability, and macros or at least some form metaprogramming of seem like tablestakes. Green threads are not impressive if they are not preemptive. But its not describing itself as finished, its 0.19. Rust looked completely different at that stage in its development - I think it still had green threads itself at that point.
does rust have FFI, then? (aka stable ABI)
It can export a stable C ABI. Most languages can - is there any language that has a different stable ABI?
What I was talking about though, was calling into C APIs through FFI, which pretty much every language except Gossamer can do.
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.
Originally I replied here that I thought you were both missing the point (but I was wrong).
I wrote: It has a garbage collector and goroutines, so clearly it is not trying to be a systems programming language.
Then ... I saw that it does indeed pitch itself as a systems programming language. So, I guess you both are right.
If Gossamer were to drop that claim, then I'd say it looks impressive to me. I have often wanted this particular mix of language features.
It doesn’t have a garbage collector, it uses reference counting with a cycle detector. So, no GC pauses. It should be suitable for hard real time systems.
Gleam comes close if you're comfortable with functional programming: https://gleam.run/
This language reminds me of Borgo https://borgo-lang.github.io
All three points are erased by its ability to call Rust functions…
It’s not a bad approach, in that for most general programming one doesn’t need those things. Granted, macros can be convenient.
Any language with FFI support can call rust functions.
My impression was that Gossamer has good Rust FFI rather than basic C FFI, sharing struct layout etc. I may play around with Gossamer and see how it really does performance wise…
The syntax similarities help make for a more painless two language approach.
If you are interested in Gossamer, you may also be interested in Lis, which is Rust flavored and compiles to go: https://github.com/ivov/lisette
From their readme:
I would also like to toss my project into the ring, which also allows mixing most real-world Rust & Go packages together, on runtime & syntax compatible level. https://github.com/deepai-org/omnivm
Pardon the sloppy readme - it actually does work :)
You were so preoccupied with whether or not you could, you didn't stop to think if you should.
I can't figure out the point of having both go and spawn. `spawn` seems to be an ordinary thread spawning mechanism, generating a handle that you can join with (but not cancel? can't find that for certain, it's not actually in the tour but is in the SPEC.md). `go` inherits all the problems of go routines. You can't join with it, you can't cancel it, you have to build other infrastructure on top of it to achieve those effects. As neat as golang was 17 years ago when it came out, this was and still is a major weakness of the language which has resulted in the community developing conventions (now standardized in the go standard library and particular usage patterns) around how to deal with it. I don't get why you'd half fix it (by introducing spawn) but then leave it in anyways. Just let the handle from spawn be ignored and you remove that particular footgun (it becomes a choice to ignore it, which still causes problems but at least the programmer chose to shoot towards their own foot).
I'm fairly sure the code snippets aren't equal in the last python example:
```python names = sorted({name.lower() for name in users if name}) ```
vs.
```gossamer let names = users |> iter::filter(|n: String| n.len() > 0) |> iter::map(|n: String| n.to_lower()) |> iter::sort_by_key(|n: String| n.len()) ```
Python is sorting a set (unique values only), but I'm not seeing a unique or set approach for gossamer.
Also the Python sorts by string content and the Gossamer sorts by string length.
There was once a time when I'd see a page like this and think "wow, must be a great project with such a polished website".
Now, it's just a neutral or perhaps even very slightly negative signal (especially the em-dash in the very first line of the page).
Anyone able to tell me if this is a project actually worth paying attention to, or just another raindrop in the current monsoon of slop?
Somewhat with you on this. I got slightly excited for a brief moment, but then the site starts to scream "an LLM threw this together super quickly" which doesn't spark joy at all.
I then started digging into the code examples and quickly determined that nothing about this project is for me, even as a fan of Rust and some of its influences it has on recent languages. That web routing example is absolutely gross to my eye, for example.
Different strokes for different folks - my own thoughts on language design (I'm hacking on one in private over the past several years, maybe one day it'll be shareable) would probably make some folks have a similar reaction, despite taking a wildly different approach than here. But it does suck to see Yet Another Vibe Looking Site hosting a language that feels like Yet Another Flavor Of Similar Stuff. Really looking forward to a language that wildly shakes things up in a usable way, and has a lot of care put into the DX... this one did not check that box for me.
The web-routing thing is especially gross because a different example shows off pattern-matching.
The language choices demonstrate excellent taste though.
A card grid with rounded corners as the second section and a dark blue or purple theme just scream "designed by Claude".
It's decent design, but not a useful quality signal.
It's clearly vibecoded if you look at the commit history.
Looks like we may be going to go back to the geocities days of primitive websites. I use still use hugo to generate my personal site automatically from markdown upon PR approval.
you know what's even worse than slop? Zero-effort 'is this maybe slop can someone tell me' posting.
No.
A site for an entirely new programming language being slop is atrocious.
An entirely unimportant one minute comment on social media being low effort? Normal and expected and appropriate.
What on earth are you on?
This post reminded me of Swift– a modern high-performance language that uses automatic reference counting. Its got a REPL and compiles via LLVM. It does trade goroutines for something with a little more safety built in.
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.
> 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?
D uses a homegrown GC not Boehm: - https://dlang.org/spec/garbage.html - https://dlang.org/blog/2017/03/20/dont-fear-the-reaper/
> 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.
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.
Not necessarily Java-flavored, but internally vs externally focused, yes. More difficult FFI assuming that is the exception not the rule, and that the language itself takes precedence. Write barriers are also not a given if using segmented heaps. Many ways to do this and no single right way. Memory allocation scheme isn't something that is just bolted on, but needs to be aligned to the rest of the language. For example, Java needs such fast allocations and good GC because it does almost no inline allocation whatsoever, so without the best GC on the planet, it would be a lot slower than it is. Contrast this with Go, which has a solid amount of inline allocations, and hence, can get by with a much slower allocator (~3-4x slower by my measurements) and a more basic mark-sweep allocator since the memory pressure is solidly less.
The charitable explanation is the authors lack the time to rebase onto something more modern.
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?
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.
Thank you for the insightful comment.
I feel I have to insist that to control latency one has to first eliminate any intrinsic source of it (a GC) and only then deal with what's left (using arena/pool allocators and such) in the face of even soft realtime requirement (which imo should be the default unless utterly impossible).
This is comparable to what you say about coloring, like, if say java had _both_ GC and zig-like allocator api, so one could have fine control over what is happening. Unfortunately it does not, and the idea of not putting all eggs in one basket is somehow unthinkable.
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?
The lock-free architecture that bypasses the allocator on the hot path is called `alloca`. Many mainstream compilers, and nearly every language that is not C, seemingly haven't properly supported it for years.
Please don't twist. alloca is in fact a limited arena/pool allocator and as such for some small sizes it is latency-free. It is also there in C. It does not have anything to do with GCs.
You insist that offloading other allocations to a GC running on other threads somehow grants the current thread control over its own scheduling.
This is false.
One can say that you can't really control latency unless running under a RTOS and thus we shall never attempt that. This is also false.
There is no conceivable reason one should not assert absolute control upon what his own code does. GC injects uncertainity into that. This is intolerable.
[dead]
> 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 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.
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.
Cgo is cheap these days, don't worry about it.
It's barely more expensive than a direct function call but, not so you'd notice unless it's in a hot loop. At which point the lack of cross-language inlining is your real problem.
Do you know of any articles, tests, or implementation breakdowns that show this. I don’t have the personal experience to agree, but if that’s the case Inwould really like to know how the improvements were achieved.
It was somewhat slow about a decade ago - you can see
- (2015, Go 1.5) Calls cost about 170ns https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
- (2017, Go 1.8) Cgo speedup by 50% https://go.dev/doc/go1.8#cgoperf
- (2023, Go 1.21) Calls cost about 40ns https://shane.ai/posts/cgo-performance-in-go1.21/
- (2026, Go 1.26) Cgo speedup by another 30% https://go.dev/doc/go1.26#faster-cgo-calls
A current benchmark shows a Cgo function call as costing about 25 ns. https://gist.github.com/DeedleFake/2f50b02c0708484c66d182533...
You just described http://www.lisette.run
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 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?
Yes, I am. That’s why I develop on a systems programming language, and why systems programming and GC are not compatible.
I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses:
and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology.I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.
What are you describing as a frame update? I am trying to be as generous as possible to your comment and thereby assuming there is a disconnect between my understanding of ‘frame update’ and yours. Genuinely curious, because that term as I am familiar with it means the entire time allotted to generating and rendering a single frame for display. If that’s what you meant, you are asserting that a ‘modern game’ is typically running at 333 fps. I am typically using the term ‘modern game’ to describe newly releasing AAA games nearly all of which struggle on many hardware configurations to achieve a steady 60 fps (which is 16 ms per frame).
e-sport competitive games target either 128Hz or 320Hz update frequency. Two rules of thumb: first if you want to actually get 60Hz every frame (e.g. on a console where 1st party validation cares about this more), then you attempt 120Hz so jitter only brings you down to 60Hz. Second, a bit more than half of your time is spent doing other things. So the amount of time you actually have to spend on world-update and/or render logic is only about half of your allocated time to start with. That's two independent factors of two there. I would have targeted 90Hz to start with, which gets you to about 3ms of actual time per frame.
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.
Exactly. This is why Minecraft Java edition was such a disastrous flop.
They're talking about modern games running on screens with high refresh rates.
Are any of those actually pauseless like he asked for?
[flagged]
https://github.com/pizlonator/fil-c/blob/deluge/libpas/src/l...
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.
It's only 2 months old. Clearly vibe coded. Still, kind of crazy what you can vibe code now.
Also the actual language design seems quite nice. I'd love something like this that was embeddable (and not vibe coded). There are basically no good easily embeddable languages. Everyone used Lua but it sucks.
Why not embedded rust?
If this is a joke, I actually chuckled.
But, maybe this is a terminology issue conflating an embeddable language with a language used for embedded programming. I think this is one of those CS issues prevalent for non-native English speakers (especially when those devs are relying on translations of text without LLM style semantic analysis of the source).
The first refers to the shipping of a language interpreter within the executable of a program, where that interpreter then processes “scripts”, data files, high level non-programmer editable object attributes or behaviors, etc. The most prevalent example of this is shipping a Lua interpreter inside a video game for interpreting hot reloadable asset scripts. The second usage of embedded is the implication that code is being run on a microcontroller or SoC ‘embedded’ within some other product or device.
Interesting idea, but wouldn't an embedded language normally be interpreted/runtime editable? I guess you could do it shipping a rust compiler, but it'd be big. A bit like Numba?
This is exactly the language I've been yearning for - the exact motivations and intersection of features that would be the sweet spot for me.
Kotlin without the Java baggage. Rust but with automated memory management and without async bifurcation. Go with a modern type system. Swift but with green threads and a linux community. Haskell without the hair shirt. Elixir with a full type system and native performance.
But yes there are some flags others have mentioned, I won't repeat them. "goroutines" ?
Even on the off chance this project is not entirely vibe coded how could it ever build an ecosystem? How can any new language? All the libraries would be suspect for the same reason this repo is. The agents won't know anything about it, no one will believe it can get momentum so it won't.
Just a comment: Rust does not have a garbage collector
Thanks - edited - I meant to say "but with a" garbage collector. I like Rust, but I don't like thinking about ownership all the time. Although when I just make Codex do it its really not that bad.
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.
Haskell does too. And it predates Go by a large margin, such that calling it goroutine is weird. And within Google, the C++ implementation fiber also predated goroutines. It really shows that this is more of a library feature rather than a language feature.
In fairness, goroutine is far catchier than >>=<%>.
I agree with your objection to treating goroutines as the baseline implementation of fibers. However, I would disagree with categorizing the feature as a library feature vs a language level feature. In “low-level” languages (C, Rust, Zig, C++, etc) the ability and option exists for having ‘green threads’ with most of their commonly assumed characteristics be library based constructs (although see [1] for why that’s not true for threads in general ). However, almost all managed/runtime-required/scripting/“high level” languages lack the facilities to implement almost any realistic types of fibers and any FFI based implementations are going to suffer severe syntax integration issues (I am assuming somewhat on this point).
TL;DR Green threads are on a library feature for low level languages.
1 - Threads Cannot Be Implemented as Libraries (Boehm 2005), https://dl.acm.org/doi/10.1145/1064978.1065042
We are not disagreeing here. Your citation is actually not relevant: Boehm is arguing that you cannot implement threads as libraries in a language without threading. But all modern languages actually have OS native threads; the addition of green threads to this environment does not require any further changes to the compiler in addition to what has been changed to support OS threads. If anything, green threads are even easier to support than real OS threads depending on the preemption design.
Another thing is the stdlib integration of goroutines. We see this in Python where various generations of paradigms kind-of coexist. Golang built their goroutines into the heart of the stdlib which puts it IMHO in a special position.
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).
Haskell, Java
Java and Crystal are not equivalent - neither have preemptible threads. Lots of other languages have co-routines or other cooperative systems - async/await are really just variants of that.
I didn't check if Gossamer is actually preemptible.
I believe the short list of production languages with preemptible M:N schedulers are limited to:
Erlang/Elixir
Haskell
Go
Java threads including Virtual Threads (JDK 21+) are preemptive.
They are not - and do not claim to be preemptive. They claim they are "not cooperative", but even that doesn't mean what anyone else thinks it means.
This paragraph is the only one containing the word "preempt" in JEP 444:
"The scheduler does not currently implement time sharing for virtual threads. Time sharing is the forceful preemption of a thread that has consumed an allotted quantity of CPU time. While time sharing can be effective at reducing the latency of some tasks when there are a relatively small number of platform threads and CPU utilization is at 100%, it is not clear that time sharing would be as effective with a million virtual threads."
https://openjdk.org/jeps/444
How did we get to that?
We were talking about n:m threading, especially with threads being blocking IO-aware, being able to automagically turning such a call to non-blocking. Java more than fits that description.
The original message you replied to said (mistakenly):
> adopt true goroutines
Goroutines are preemptive. The distinction between cooperative and non-cooperative concurrency is very significant - it is the difference between never having to think about the scheduler and always having to thinking about it when doing CPU intensive tasks.
Does it have a REPL? That's been one of the greatest sins of Rust - designing a compiled language after 1990 that doesn't have an interactive REPL.
[flagged]
[dead]
[dead]
Sorry but the name means bitterkid in french, I can't get over it :D
https://en.wiktionary.org/wiki/gossamer#Noun
I'm french and had to think about it for a little bit.
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.
IDK what's the fuss. m:n scheduled by io is .. 2000s-era. The implementation was so obvious in like 2005, that even I patched then Python 2.6 in, so we at my then company could get rid of Twisted.
Also let you remind that M:N scheduling was the FreeBSD's pthread implementation for quite a bit too long. No, it didn't play well with MySQL at the time.