Hacker News Reader

Comment by steveklabnik | Hacker News Reader

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.

View on HN

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!

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 :)

> 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]:

  No garbage collector, no manual memory management. A work 
  in progress, though.

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.

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

Fascinating.

I look forward to seeing where you go with Rue over time.

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.

Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?

No direct plans. For the immediate future, only the runtime is allowed to call into C.

If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.

FWIW, I really like the way C# has approached this need... most usage is exposed via attribute declaration/declaration DllImport for P/Invoke. Contrasted with say JNI in Java or even the Go syntax. The only thing that might be a significant improvement would be an array/vector of lookup names for the library on the system given how specific versions are often tagged in Linux vs Windows.

> because there are multiple valid ways of interpreting i

There are quantitative ways of describing it, at least on a relative level. "High abstraction" means that interfaces have more possible valid implementations (whether or not the constraints are formally described in the language, or informally in the documentation) than "low abstraction": https://news.ycombinator.com/item?id=46354267

You couldn't get the rue-lang.org domain? There are rust-lang.org, scala-lang.org, so rue-lang.org sounds better than .dev.

I'd love to see how Rue solves/avoids the problems that Rust's borrow checker tries to solves. You should put it on the 1st page, I think.

Already taken.

I'll put more about that there once it's implemented :)

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 :)

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 :)

Simplified as in easier to use, or simplified as in less language features? I'm all for the former, while the latter is also worth considering (but hard to get right, as all the people who consider Go a "primitive" language show)...

Since that seems to be the (frankly bs) slogan that almost entirely makes up the languages lading page, I expect it's really going to hurt the language and/or make it all about useless posturing.

That said, I'm an embedded dev, so the "level" idea is very tangible. And Rust is also very exciting for that reason and Rue might be as well. I should have a look, though it might not be on the way to be targeting bare metal soon. :)

I don't mind if a sentence I threw up for a side project "hurts the language" at this stage, this is a project primarily for me.

You should use Rust for embedded, I doubt Rue will ever be good for it.

Reply on news.ycombinator.com