[yoan9224]

The positioning is interesting - claiming Rust's performance with Go's simplicity is basically every new systems language's promise since 2015. The key differentiator seems to be "zero-cost exceptions" which I assume means compile-time Result types without runtime unwinding overhead? That's compelling if true, since Rust's Result ergonomics can get verbose in deeply nested error chains.

But the real test is compile times and cognitive overhead. Rust's borrow checker is theoretically elegant but practically brutal when you're learning or debugging. If Rue can achieve memory safety without lifetime annotations everywhere, that's genuinely valuable. However, I'm skeptical - you can't eliminate tradeoffs, only move them around. If there's no borrow checker, what prevents use-after-free? If there's garbage collection, why claim "lower level than Go"?

The other critical factor is ecosystem maturity. Rust's pain is partially justified by its incredible crate ecosystem - tokio, serde, axum, etc. A new language needs either (1) seamless C FFI to bootstrap libraries, (2) a killer feature so valuable that people rewrite everything, or (3) 5+ years for the ecosystem to develop. Which path is Rue taking?

I'd love to see real-world benchmarks on: compile time for a 50k line project, memory usage of a long-running web server compared to Rust/Go, and cold start latency for CLI tools. Those metrics matter more than theoretical performance claims. The "fun to write" claim is subjective but important - if it's genuinely more ergonomic than Rust without sacrificing performance, that could attract the "Python developers wanting systems programming" demographic.

[steveklabnik]

I’m explicitly not claiming Rust’s performance. Rust will always be ahead here. I’m giving up some of that performance for other things.

I do agree that those benchmarks are important. Once I have enough language features to make such a thing meaningful, I’ll be tracking them.

Where did I write that it’s fun to write?

[whimsicalism]

Your style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes.

e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.

[Hemospectrum]

Rather than downvoting you, I will speak up to say I don't see what you're seeing. Spaces around hyphens, yeah, sure, but LLMs prefer em dashes, and even that is unreliable, because it's borrowed from habits that real humans have had for many years.

For me, the more important indicator is the content. I see reports of personal experience, and thoughts that are not completely explained (because the reader is expected to draw the rest of the owl). I don't see smugly over-the-top piles of adjectives filling in for an inability to make critiques of any substance. I don't see wacky asides amounting to argumentum ad lapidem, accomplishing nothing beyond insulting readers who disagree with a baseless assertion.

I think it's likely you have drawn a false positive.

[dkdcio]

A) you cannot tell B) you have said nothing productive toward discussion, you’ve just accused someone of using a tool (that you don’t know if they used)

I’d prefer actual criticism of the content. (I cannot downvote and would not if I could)