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.
Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?
Rue: Higher level than Rust, lower level than Go
11–20 of 274 posts
Re: Rue: Higher level than Rust, lower level than Go
#12I 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.
Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?
Re: Rue: Higher level than Rust, lower level than Go
#13Earlier quoted context omitted.
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
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.
It's a fun project for me right now. I want to just explore compiler writing. I'm not 100% sure where it will lead, and if anyone will care or not where it ends up. But it's primarily for me.
I've described it as "higher than Rust, lower than Go" because I don't want this to be a GC'd language, but I want to focus on ergonomics and compile times. A lot of Rust's design is about being competitive with C and C++, I think by giving up that ultra-performance oriented space, I can make a language that's significantly simpler, but still plenty fast and nice to use.
We'll see.
Re: Rue: Higher level than Rust, lower level than Go
#14I 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.
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.
Re: Rue: Higher level than Rust, lower level than Go
#15I 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.
Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?
Perhaps calling it an “optimization” is misleading. Certainly it makes code faster, but more importantly it’s syntax sugar to translate recursion into loops.
Re: Rue: Higher level than Rust, lower level than Go
#16Re: Rue: Higher level than Rust, lower level than Go
#17I 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.
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.
Re: Rue: Higher level than Rust, lower level than Go
#18Earlier quoted context omitted.
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!
Re: Rue: Higher level than Rust, lower level than Go
#19Re: Rue: Higher level than Rust, lower level than Go
#20> Memory Safe > 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?
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.