71–80 of 98 posts
Earlier quoted context omitted.
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
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.
Sorry but the name means bitterkid in french, I can't get over it :D
Earlier quoted context omitted.
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.
- (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...
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.
Exactly. This is why Minecraft Java edition was such a disastrous flop.
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.
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 typic…
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
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 wante…
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,…