Comment by andsoitis

Also working on a language / runtime in this space.

It transpiles to Zig, so you have native access to the entire C library.

It uses affine types (simple ownership -> transfers via GIVE/TAKES), MVCC & transactions to safely and scalably handle mutations (like databases, but it scales linearly after 32 cores, Arc and RwLock fall apart due to Cache Line Bouncing).

It limits concurrent complexity only to the spot in your code WHERE you want to mutate shared memory concurrently, not your entire codebase.

It's memory and liveness safe (Rust is only memory safe) without a garbage collector.

It's simpler than Go, too, IMO - and more predictable, no GC.

But it's nearly impossible to beat Go at its own game, and it's not zero overhead like Rust - so I'm pessimistic it's in a "sweet spot" that no one will be interested in.

Time will tell.

You might find one of my late brother's research interests relevant: https://www.cs.princeton.edu/~dpw/papers/space.pdf

Nice! I see you're one of (if not the primary) contributor!

Do you see this as a prototype language, or as something that might evolve into something production grade? What space do you see it fitting into, if so?

You've been such a huge presence in the Rust space. What lessons do you think Rue will take, and where will it depart?

I see compile times as a feature - that's certainly nice to see.

Could you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed?

What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?

Have you explored the ideas explored for the Vale language: https://vale.dev/

May be an interesting approach. That language seems very academic and slow moving at the moment though.

So linear type + mutable value would be quite close to Rust, right?

Sure, ARC is a form of very specific, constrained garbage collection.

Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.

> 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 developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.

> For developers willing to have more low-level control, memory can be managed manually with -gc none.

> Arena allocation is available via a -prealloc flag. Note: currently this mode is only suitable to speed up short lived, single-threaded, batch-like programs (like compilers).

So you have 1) a GC, 2) a GC with escape analysis (WIP), 3) manual memory management, or 4) ...Not sure? Wasn't able to easily find examples of how to use it. There's what appears to be its implementation [1], but since I'm not particularly familiar with V I don't feel particularly comfortable drawing conclusions from a brief glance through it.

In any case, none of those stand out as "memory safety without GC" to me.

[0]: https://docs.vlang.io/memory-management.html

[1]: https://github.com/vlang/v/blob/master/vlib/builtin/prealloc...

Oh, it's known. It just has an incredibly negative reputation on this site.

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.