ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
74% Positive
Analyzed from 1580 words in the discussion.
Trending Topics
#language#rust#languages#https#gossamer#more#still#reference#modern#memory

Discussion (48 Comments)Read Original on HackerNews
* 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.
From their readme:
Pardon the sloppy readme - it actually does work :)
```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.
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?
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.
It's decent design, but not a useful quality signal.
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?
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
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.
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.
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?
Languages use Boehm for exactly one reason: it is easy to shim into an otherwise manual memory system. I mean no respect to its authors, but using Boehm in production is the worst of all worlds: slow allocations (regular malloc), no 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 similiar age.
Can you share some links/references?
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.
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.
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.