Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rue: Higher level than Rust, lower level than Go

rue-lang.dev

Post reply on HN
Print view View original

181–190 of 274 posts

Re: Rue: Higher level than Rust, lower level than Go

#181

Post by 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.

Re: Rue: Higher level than Rust, lower level than Go

#182

Post by aw1621107 »

freakynit wrote: post #118
aw1621107 wrote: post #93

Earlier quoted context omitted.

> Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The devel…

"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree. Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 It is also accompanied with a demo video (pretty convincing in case you would like to…

> Im more interested to know the points in relation to autofree.

As sibling said, autofree is still stated to use a GC, which obviously disqualifies it from "memory safety without GC".

> Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419

I did see that! Unfortunately it doesn't really move the needle on anything I said earlier. It describes manual memory management as an alternative to the GC when using autofree (which obviously isn't conducive to reliable memory safety barring additional guardrails not described in the post) and arenas are only mentioned, not discussed in any real detail.

> It is also accompanied with a demo video (pretty convincing in case you would like to watch).

Keep in mind the context of this conversation: whether V offers memory safety without GC or manual memory management. Strictly speaking, a demonstration that autofree works in one case is not sufficient to show V is memory safe without GC/manual memory management, as said capability is a property over all programs that can be written in a language. As a result, thoroughly describing how V supposedly achieves memory safety without a GC/manual memory management would be far more convincing than showing/claiming it works in specific cases.

As an example of what I'm trying to say, consider a similar video but with a leak/crash-free editor written in C. I doubt anyone would consider that video convincing proof that C is a memory-safe language; at most, it shows that memory-safe programs can be written in C, which is a very different claim.

Re: Rue: Higher level than Rust, lower level than Go

#183

Post by chuckadams »

stouset wrote: post #9
norir wrote: post #8

I wince every time I see naive recursive fibonacci as a code example. It is a major turnoff because it hints at a lack of experience with tail call optimization, which I consider a must have for a serious language.

Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?

When you have recursive data structures, it's nice when the algorithms have the same shape. TCO is also handy when you're writing fancy control flow operations and implement them with continuation-passing style.

Re: Rue: Higher level than Rust, lower level than Go

#185

Post by culebron21 »

I couldn't figure out the main points, besides the "between Rust & Go" slogan. I've worked both with Rust and Go, and I like Rust more, but there are several pain points:

* macro abuse. E.g. bitshift storing like in C needs a bunch of #[...] derive_macros. Clap also uses them too much, because a CLI parameter is more complex than a struct field. IDK what's a sane approach to fixing this, maybe like in Jai, or Zig? No idea.

* Rust's async causes lots of pain and side effects, Golang's channels seem better way and don't make colored functions

* Rust lacks Python's generators, which make very elegant code (although, hard to debug). I think if it gets implemented, it will have effects like async, where you can't keep a lock over an await statement.

Zig's way is just do things in the middle and be verbose. Sadly, its ecosystem is still small.

I'd like to see something attacking these problems.

Re: Rue: Higher level than Rust, lower level than Go

#186

Post by chuckadams »

amluto wrote: post #57
reactordev wrote: post #55

I write a lot of go. I tried to write a lot of rust but fell into lifetime traps. I really want to leave C++ but I just can’t without something that’s also object oriented. Not a dig at functional, it’s just my big codebases are logically defined as objects and systems that don’t lend itself to just being a struct or an interface. Inheritance is why I’m stuck in C++ land. I would love to have something like rust but…

As a long time C++ user, I’m curious why you like inheritance and virtual methods so much. I maintain a medium sized, old-ish C++ code base. It uses classes and inheritance and virtual methods and even some multiple inheritance. I despise this stuff. Single Inheritance is great until you discover that you have a thing that doesn’t slot nicely into the hierarchy or when you realize that you want to decompose an interf…

Protected and private inheritance are C++'s equivalent to traits, and they don't suffer from the usual issues of multiple inheritance. As for type classes, check out concepts. By no means am I trying to sell C++, I don't touch it myself, but it doesn't leave you completely adrift in those seas.

Re: Rue: Higher level than Rust, lower level than Go

#187

Post by scuff3d »

reactordev wrote: post #172
scuff3d wrote: post #169

Earlier quoted context omitted.

You can use a struct that the other structs have as a field. The trait can then operate on that struct. I'm not trying to convince you to use Rust. If you prefer C++ have at it. I was just trying to point out that most patterns in C++ have a fairly close analogy in Rust, just with different tradeoffs.

Yeah go has embedded structs. It’s ugly and allows one to address the fields on the parent and it exposes the struct (with the same fields) so it’s kind of a head scratcher. To be honest, it’s been 3 years since I looked at rust and I might try again. I still prefer inheritance because some things just are-a thing. I also love ECS and components and see traits as that. I just wish I could store local state in those.

You can store state in the struct and then define a method in the trait to return the struct. Then all your default methods can use the "getter" to access the struct and it's state. The only thing you have to do is embed the struct and implement that one "getter" method to return it. I don't think it's much more boilerplate then utilizing inheritance.

Fyrox, a game engine written in Rust, uses an ECS and several object oriented patterns in their design. Might be a good reference if your interested. The rust book also has a section on OOP patterns in Rust.

I think it's Fyrox anyway. I remember the creator of a Rust game engine talking about it in an interview on Developer Voices. It could have been Bevy I guess, but I don't think so.

Re: Rue: Higher level than Rust, lower level than Go

#188

Post by whimsicalism »

yoan9224 wrote: post #181

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

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.

Re: Rue: Higher level than Rust, lower level than Go

#189

Post by pjmlp »

andsoitis wrote: post #2

> Memory Safe > No garbage collector, no manual memory management. A work in progress, though. I couldn't find an explanation in the docs or elsewhere how Rue approaches this. If not GC, is it via: a) ARC b) Ownership (ala Rust) c) some other way?

ARC is GC, chapter 5.

https://gchandbook.org/

Re: Rue: Higher level than Rust, lower level than Go

#190

Post by pjmlp »

waldrews wrote: post #67

What the world needs is a more expressive language than Go, that interops with Go's compilation model and libraries.

Nah, we already have that in D, C#, and who knows maybe one day Java finally gets Valhala, or one can use Kotlin or Scala in the meantime.
Post reply on HN