More like "mostly known from stating absolutely ridiculous claims", though I heard they went back on most of them and now are more realistic - but also much less interesting.
I always thought of Go as low level and Rust as high level. Go has a lot of verbosity as a "better C" with GC. Rust has low level control but many functional inspired abstractions. Just try writing iteration or error handling in either one to see.
Agree with Go being basically C with string support and garbage collection. Which makes it a good language. I think rust feels more like a c++ replacement. Especially syntactically. But each person will say something different. If people can create new languages and there's a need then they will. Not to say it's a good or bad thing but eventually it would be good to level up properly. Maybe AI does that.
All are high level as long as they don't expose CPU capabilities, even ISO C is high level, unless we count in language extensions that are compiler specific, and any language can have compiler extensions.
I think it is precisely why Rust is gold - you can pick the abstraction level you work at. I used it a lot when simulating quantum physics - on one hand, needed to implement low-level numerical operations with custom data structures (to squeeze as much performance as possible), on the other - be able to write and debug it easily.
It is similar to PyTorch (which I also like), where you can add two tensors by hand, or have your whole network as a single nn.Module.
One, objective definition is simply that everything that is not an assembly is a high-level language - but that is quite a useless def. The other is about how "deeply" you can control the execution, e.g. you have direct control of when and what gets allocated, or some control over vectorization, etc.
Here Rust is obviously as low-level as C, if not more so (both have total control over allocations, but still leaves calling conventions and such up to the compiler), while go is significantly higher (the same level as C#, slightly lower than Java - managed language with a GC and value types).
The other often mistaken spectrum is expressivity, which is not directly related to low/high levelness. E.g. both Rust and Scala are very expressive languages, but one is low, the other is high level. C and Go both have low expressivity, and one is low the other is high level.
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.
Interesting, for me the "between Rust and Go" would be a nice fit for Swift or Zig. I've always quite liked the language design of Swift, it's bad that it didn't really take off that much
I think with Swift 6 Apple really took it in a wrong direction. Even coding agents can’t wrap their mind around some of the “safety” features (not to mention the now bloated syntax). If anything, Swift would go down as a “good example why language design shouldn’t happen by committee in yearly iterations”.
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 that supports classes, virtual methods, etc. but I guess I’ll keep waiting.
I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust.
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.
This is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how much garbage there is. As someone that writes in Go, I can't stand semicolons and other crap that just pollutes the code and wastes time and space to write for absolutely no good reason whatsoever. And as this compares itself with Go, I just cannot but laugh when I see ";", "->" or ":" in the example. At least the semicolon seems optional. But still, it's an instant nope for me.
Okay, right now it's basically Pascal as it was described in Revised Report, only even more restricted. Which is... fine, I guess, you can still write a whole OS with something like that (without using pointers/addresses) as Per-Brinch Hansen demonstrated but it's... an acquired taste.
Are the actual references/pointers coming in the future?
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.
44 comments
[ 3.5 ms ] story [ 65.2 ms ] thread> 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?
https://gchandbook.org/
It is similar to PyTorch (which I also like), where you can add two tensors by hand, or have your whole network as a single nn.Module.
One, objective definition is simply that everything that is not an assembly is a high-level language - but that is quite a useless def. The other is about how "deeply" you can control the execution, e.g. you have direct control of when and what gets allocated, or some control over vectorization, etc.
Here Rust is obviously as low-level as C, if not more so (both have total control over allocations, but still leaves calling conventions and such up to the compiler), while go is significantly higher (the same level as C#, slightly lower than Java - managed language with a GC and value types).
The other often mistaken spectrum is expressivity, which is not directly related to low/high levelness. E.g. both Rust and Scala are very expressive languages, but one is low, the other is high level. C and Go both have low expressivity, and one is low the other is high level.
This answer is imo a very must have read about the topic of expressivity: https://langdev.stackexchange.com/a/2016
[0] https://hylo-lang.org
[0] https://rue-lang.dev/blog/hello-world/
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.
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.
Are the actual references/pointers coming in the future?
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.