Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rue: Higher level than Rust, lower level than Go

rue-lang.dev

Post reply on HN
Print view View original

131–140 of 274 posts

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

#131

Post by steveklabnik »

onlyrealcuzzo wrote: post #119
steveklabnik wrote: post #4

Earlier quoted context omitted.

I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.

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

Neat! Good luck, that sounds very cool. I have no idea what if anything I'm going to do about liveliness.

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

#134

Post by steveklabnik »

Panzerschrek wrote: post #95

I am surprised that a language with nothing than a couple of promises gets so much attention. Why exactly?

I've been a member of this community for a long time.

People also like hearing about new languages.

I agree that it's not really ready for this much attention just yet, but that's the way of the world. We'll see how it goes.

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

#135

Post by steveklabnik »

int_19h wrote: post #105
steveklabnik wrote: post #10

Earlier quoted context omitted.

I only have basic constant folding yet in terms of optimizations, but I'm very aware of TCO. I haven't decided if I want to require an annotation to guarantee it like Rust is going to.

Please require some form of annotation like an explicit `tailcall` operator or something similar. TCO wrecks havoc on actionable backtraces, so it should be opt-in rather than opt-out.

I am very sympathetic to this, for sure.

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

#136

Post by steveklabnik »

Panzerschrek wrote: post #94

How does it achieve memory safety?

Right now? By not even having heap allocation (though I'll be sending in the first PR for that soon.)

Eventually: through not having references, thanks to mutable value semantics. Also linear types.

But that's just ideas right now. It'll get there.

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

#137

Post by steveklabnik »

gethly wrote: post #99

This is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how much garbage there is. As someone that writes in Go, I can't stand semicolons and other crap that just pollutes the code and wastes time and space to write for absolutely no good reason whatsoever. And as this compares itself with Go, I just cannot but laugh wh…

I respect your preferences! I like punctuation.

Even though I have a Perl tattoo, it'll never get like that, though.

(Semicolon rules, for now at least, will be the same as Rust)

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

#138

Post by exceptione »

gethly wrote: post #123
imbnwa wrote: post #100

Earlier quoted context omitted.

What would be better?

Remove all of that noise. Take this: fn fib(n: i32) -> i32 {} The (n: i32) can be just (n i32), because there is no benefit to adding the colon there. The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax. So you end up with simple and clean fn fib(n i32) i32 {} And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years wit…

In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here:

  fn fib(n i32) i32 {}
But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them.

Personally, I would like a language that pushes the programmer to write the types as part of a doc comment.

Also think about returning lambda's. Should it look like this?

  fn foo(n i32) (i32 i32) {}
Of course the IDE could help by showing the typographic arrows and other delineations, but as plaintext this is completely unreadable.

  > And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason.
You still have to think about stuff like currying. You either delimit the line, or you use significant white space.

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

#139

Post by mrkeen »

Ar-Curunir wrote: post #124
mrkeen wrote: post #116

Earlier quoted context omitted.

Supporting recursion only to a depth of 1000 (or whatever) is equivalent to supporting loops of up to 1000 iterations. If I put out a language that crashed after 1000 iterations of a loop, I'd welcome the rudeness.

Plenty of languages, including very serious ones like C and Rust, have bounded recursion depth.

Then let me rephrase:

If every iteration of a while-loop cost you a whole stack frame, then I'd be very rude about that language.

This works, btw:

  #include 

  long calc_sum(int n, long acc) {
    return n == 0
      ? acc
      : calc_sum(n-1, acc+n);
  }

  int main(void) {
    int iters = 2000000;
    printf("Sum 1...%d = %ld\n", iters, calc_sum(iters, 0));
    return 0;
  }

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

#140

Post by Imustaskforhelp »

onlyrealcuzzo wrote: post #119
steveklabnik wrote: post #4

Earlier quoted context omitted.

I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.

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

can you share the link, sounds fascinating language to follow its development as well and good luck on this project!
Post reply on HN