Posted by ingve 12/21/2025
One huge difference is that Hylo is using LLVM, whereas I'm implementing my own backends. Another is that Hylo seems to know what they want to do with concurrency, whereas I really do not at all right now.
I think Hylo takes a lot of inspiration from Swift, whereas I take more inspiration from Rust. Swift and Rust are already very similar. So maybe Hylo and Rue will end up like this: sister languages. Or maybe they'll end up differently. I'm not sure! I'm just playing around right now.
And congrats on starting a language project, even if Just for Fun (Linux). ;)
https://frappe.io/blog/book-reviews/just-for-fun-a-book-on-l...
Both are playing around in similar spaces, both shared team members for a while, both have a take an automatic memory management that isn’t a garbage collector, both were sponsored by a primary company for a while (Swift still is, I think). There’s a lot of differences too.
Zero Cost abstractions and it's memory model is fascinating - but isn't particularly useful for the part of the tech stack I work on.
rust is cool. a lot of really cool software im finding these days is written in rust these days & i know im missing some kind of proverbial boat here. but rusts syntax breaks my brain and makes it eject completely. it's just enough to feel like it requires paradigm shifts for me, and while others are really good at hopping between many languages it's just a massive weakness of mine. i just cant quite figure out the ergonomics of rust so that it feels comfy, my brain seems to process everything through a c-lens and this is just a flaw of mine that makes me weak in software.
golang was started by some really notable brains who had lots of time in the game and a lot of well thought out philosophies of what could be done differently and why they should do it differently coming from c. there was almost a socio-economic reason for the creation of go - provide a lang that people could easily get going in and become marketable contributors that would help their career prospects. and i think it meets that mark, i was able to get my jr engineers having fun in golang in no time at all & that's panned out to be a huge capability we added to what our team can offer.
i like the objective of rue here. reviewing the specification it actually looks like something my brain doesn't have any qualms with. but i dont know what takes a language from a proposal by one guy and amplifies it into something thats widely used with a great ecosystem. other minds joining to contribute & flesh out standard libraries, foundations backing, lots of evangelism. lots of time. i won't write any of those possibilities off right now, hopefully if it does something right here there's a bright future for it. sometimes convincing people to try a new stack is like asking them to cede their windows operating system and try out linux or mac. we've watched a lot of languages come and go, we watch a lot of languages still try to punch thru their ceilings of general acceptance. unlike some i dont really have huge tribalistic convictions of winners in software, i like having options. i think it's pretty damn neat that folks are using their experiences with other languages to come up with strong-enough opinions of how a language should look and behave and then.. going out and building it.
The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup.
Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde, and monomorphized generics for basically everything). But all of this code is never checked into git (with the exception of some build.rs tools which can be configured to run as commands as well), or at least 99% of the time it's not.
This difference has impact on the developer story. In go land, you need to manually invoke the auto generator and it's easy to forget until CI reminds you. The auto generator is usually quite slow, and probably has much less caching smartness than the Rust people have figured out.
In Rust land, the auto generation can, worst case, run at every build, best case the many cache systems take care of it (cargo level, rustc level). But still, everyone who does a git pull has to re-run this, while with the auto generation one can theoretically only have the folks run it who actually made changes that changed the auto generated code, everyone else gets it via git pull.
So in Go, your IDE is ready to go immediately after git pull and doesn't have to compile a tree of hundreds of dependencies. Go IDEs and compilers are so fast, it's almost like cheating from Rust POV. Rust IDEs are not as fast at all even if everything is cached, and in the worst case you have to wait a long long time.
On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it). In Rust land, cargo creates some level of standardization.
You can always look at the auto generated Go code and understand it, while Rust's auto generated code usually is not IDE inspectable and needs special tools for access (except for the build.rs generated stuff which is usually put inside the target directory).
I wonder how a language that is designed from scratch would approach auto generation.
https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processin...
I know I don't want to have macros if I can avoid them, but I also don't forsee making code generation a-la-Go a first class thing. I'll figure it out.
Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation.
I'm sure there are projects out there with a "bunch" of it, but I don't think they are "typical".
The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.
A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc.
So its an established Google standard, which has tons of help from their CI/CD systems.
For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience. Ditto monorepos. Ditto centralized package authorities for even private modules (my least fave feature of Go).
The golang/go repo itself has various checked-in generated repo
Difference is that other languages are built for things other than network services, so protobuf is much less likely to be a necessary dependency for their codebases.
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 that supports classes, virtual methods, etc. but I guess I’ll keep waiting.
Does inheritance really matter that much?
For example: Playable could be a trait that plays a sound when you interact with it. I would need to implement func interact for each object. Piano, jukebox, doorbell, etc. With inheritance, I write it once, add it to my class, and now all instances of that object have interact. Can I add instance variables to a trait?
This saves me time and keeps Claude out of my code. Otherwise I ask Claude to implement them all, modify them all, to try to keep them all logically the same.
I also don’t want to go type soup in order to abstract this into something workable.
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.
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.
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.
I think I might be able to do it with a macro but I’m not a rust guy so I’m limited by my knowledge.
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 interface (cough, base class) into a couple of non-hierarchically related things. Multiple inheritance is an absolute mess unless you strictly use base classes with pure virtual methods and no member variables. And forcing everything into an “is a” relationship instead of a “has a” relationship can be messy sometimes.
I often wish C++ had traits / or Haskell style type classes.
How so? Maybe in a COM-like world where the user of an object needs to call a method to get an interface pointer.
I’ll grant that concepts are a massive improvement.
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.
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?
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.
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.
I was raised in a family of professional writer-editors (but now am the tech-y black sheep) which might make the cues a bit more obvious to me. The degree to which this style of writing was common prior to 2022 is vastly overstated, the tells were actually not really that common.
I’d prefer actual criticism of the content. (I cannot downvote and would not if I could)
After seeing your reply, I looked at their comment history which makes it even more obvious imo.
just as you’re annoyed by low-effort LLM posts/comments, I’m annoyed by low-effort “this sounds like it was written by ChatGPT” comments (hence my response and at least a possible explanation of downvotes)
edit: I also scrolled through, you’re absolutely right! it does look like a low-effort bot