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

61–70 of 98 posts

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

#61

Post by mappu »

platinumrad wrote: post #13
quotemstr wrote: post #8

Earlier quoted context omitted.

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…

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.

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

#62

Post by mkj »

cure_42 wrote: post #48
IshKebab wrote: post #39

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?

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?

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

#63

Post by [deleted] »

bfung wrote: post #54
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.

[deleted]

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

#64

Post by charlieflowers »

bfung wrote: post #54
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.

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.

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

#65

Post by jeremyjh »

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

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.

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

#66

Post by throwaway17_17 »

kccqzy wrote: post #20
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.

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.

1 - Threads Cannot Be Implemented as Libraries (Boehm 2005), https://dl.acm.org/doi/10.1145/1064978.1065042

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

#67

Post by throwaway17_17 »

cure_42 wrote: post #48
IshKebab wrote: post #39

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.

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

#68

Post by throwaway17_17 »

mappu wrote: post #61
platinumrad wrote: post #13

Earlier quoted context omitted.

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.

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

#69

Post by throwaway17_17 »

adastra22 wrote: post #15
quotemstr wrote: post #8

Earlier quoted context omitted.

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…

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

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

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

#70

Post by throwaway17_17 »

adastra22 wrote: post #52
quotemstr wrote: post #21

Earlier quoted context omitted.

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.

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.

Post reply on HN