I wish them the best, but until they have a better story here I'm not particularly interested.

Much of the complexity in Rust vs simplicity in Go really does come down to this part of the design space.

Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a trade-off). No one really knows a sane way to do it otherwise, unless you also want to drop the general-purpose systems programming language requirement.

I'll be Very Interested if they find a new unexplored point in the design space, but at the moment I remain skeptical.

Folks like to mention Ada. In my understanding, Ada is not memory safe by contemporary definitions. So, this requires relaxing the definition. Zig goes in this direction: "let's make it as safe as possible without being an absolutist"

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.

> 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?

* 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.

[0] https://rue-lang.dev/blog/hello-world/

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.

Are the actual references/pointers coming in the future?

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.

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.

[0] https://hylo-lang.org

    fn fib(n: i32) -> i32

       let mut i = 0;