Live data from Hacker News

Rue: Higher level than Rust, lower level than Go

rue-lang.dev

81–90 of 274 posts

Re: Rue: Higher level than Rust, lower level than Go

#81
post #78
post #51

Earlier quoted context omitted.

This hasn't been my experience at all. I still regularly use typescript. One problem I run into from time to time is "spooky action at a distance". For example, its quite common to create some object and store references to it in multiple places. After all, the object won't be changed and its often more efficient this way. But later, a design change results in me casually mutating that object, forgetting that its bei…

I wholeheartedly concur based on my experience with Rust (and other languages) over the last ~7 or so years. > If I call a function which returns an object of type T, I can safely assume the object lasts forever. It cannot be mutated by any other code (since its mine). And I'm not going to break anything else if I mutate the object myself. These are really nice properties to have when programming at scale. I rarely s…

> I rarely see this mentioned in the way that you did, and I'll try to paraphrase it in my own way: Rust restricts what you can do as a programmer. One can say it is "less powerful" than C. In exchange for giving up some power, it gives you more information

Your paraphrasing reminds me a bit of structured vs. unstructured programming (i.e., unrestricted goto). Like to what you said, structured programming is "less powerful" than unrestricted goto, but in return, it's much easier to follow and reason about a program's control flow.

At the risk of simplifying things too much, I think some other things you said make for an interesting way to sum this up - Rust does for "ownership flow"/"dataflow" what structured programming did for control flow.

Re: Rue: Higher level than Rust, lower level than Go

#82

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

> 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 managem…

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.

Re: Rue: Higher level than Rust, lower level than Go

#83
post #65

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

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

Re: Rue: Higher level than Rust, lower level than Go

#84
post #72

I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. 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,…

Yeah, this is a hard problem, and you're right that both have upsides and downsides. Metaprogramming isn't easy!

I know I don't want to have macros if I can avoid them, but I also don't forsee making code generation a-la-Go a first class thing. I'll figure it out.

Re: Rue: Higher level than Rust, lower level than Go

#85
post #61

Earlier quoted context omitted.

Yes, I started off with the idea that Rue's syntax would be a strict subset of Rust's. I may eventually diverge from this, but I like Rust's syntax overall, and I don't want to bikeshed syntax right now, I want to work on semantics + compiler internals. The core syntax of Rust is good enough right now.

Out of interest, what's the motivation? What are you hoping to do with Rue that Rust doesn't currently provide?

Primary motivation is to have a fun project. If nobody ever uses this, I'll still be happy.

I'd like fast compile times, and giving up some of Rust's lowest level and highest performance goals in exchange for it. As well as maybe ease of use.

Re: Rue: Higher level than Rust, lower level than Go

#86

Any plans for adding algebraic data types (aka rust enums)?

I landed non-generic enums this evening. I'm not 100% sure what abstraction paths I want to go down. But I see sum types as just as important as product types, for sure.

Re: Rue: Higher level than Rust, lower level than Go

#88

Earlier quoted context omitted.

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?

Re: Rue: Higher level than Rust, lower level than Go

#89

Earlier quoted context omitted.

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

Re: Rue: Higher level than Rust, lower level than Go

#90

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

Check out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.
Post reply on HN