Rue author here, yeah I'm not the hugest fan of "low level vs high level" framing myself, because there are multiple valid ways of interpreting it. As you yourself demonstrate!
As some of the larger design decisions come into place, I'll find a better way of describing it. Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there.
How very so humble of you to not mention being one of the primary authors behind TRPL book. Steve you're a gem to the world of computing. Always considered you the J. Kenji of the Rust world. Seems like a great project let's see where it goes!
That is a very kind thing to say, I admire him quite a bit. Thank you!
> Mostly, I am not really trying to compete with C/C++/Rust on speed, but I'm not going to add a GC either. So I'm somewhere in there.
Out of curiosity, how would you compare the goals of Rue with something like D[0] or one of the ML-based languages such as OCaml[1]?
EDIT:
This is a genuine language design question regarding an imperative/OOP or declarative/FP focus and is relevant to understanding the memory management philosophy expressed[2]:
0 - https://dlang.org/1 - https://ocaml.org/
2 - https://rue-lang.dev/
Closer to an OCaml than a D, in terms of what I see as an influence. But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them.
Do you think you'll explore some of the same problem spaces as Rust? Lifetimes and async are both big pain points of Rust for me, so it'd be interesting to see a fresh approach to these problems.
I couldn't see how long-running memory is handled, is it handled similar to Rust?
I'm going to try and avoid lifetimes entirely. They're great in Rust! But I'm going to a higher level spot.
I'm totally unsure about async.
Right now there's no heap memory at all. I'll get there :) Sorta similar to Rust/Swift/Hylo... we'll see!
So if you don't have a garbage collector, and you don't have manual memory management, and you don't have lifetimes... What do you have?
The plan is something like mutable value semantics and linear types. I'm figuring it out :)
Since it's framed as 'in between' Rust and Go, is it trying to target an intersection of both languages' use-cases?
I don't think you'd want to write an operating system in Rue. I may not include an "unsafe" concept, and will probably require a runtime. So that's some areas where Rust will make more sense.
As for Go... I dunno. Go has a strong vision around concurrency, and I just don't have one yet. We'll see.
Is this a simplified / distilled version of Rust ? Or Subset of Rust with some changes ?
Some of it is like that, but some of it is going to be from other stuff too. I'm figuring it out :)
Wow didn't realise it was you who was the author. I learnt a lot about Rust from your writings.
I'm glad to have helped you :)