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

61–70 of 274 posts

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

#61

Post by scuff3d »

steveklabnik wrote: post #35
lifis wrote: post #34

All the Rue code in the manual seems to also be valid Rust code, except for the @-prefixed intrinsics

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?

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

#62

Post by AdieuToLogic »

steveklabnik wrote: post #14
killingtime74 wrote: post #7

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

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

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

#63

Post by UltraSane »

wswin wrote: post #40
josephg wrote: post #36

Earlier quoted context omitted.

Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript.…

Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.

async seems sensible for anything subject to internet latency.

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

#64

Post by jrjrjfhgggg »

wswin wrote: post #40
josephg wrote: post #36

Earlier quoted context omitted.

Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript.…

Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.

Disagree, having dealt with +40k LoC rust projects, bottow checker is not an issue.

Async is an irritation but not the end of the world ... You can write non asynchronous code I have done it ... Honestly I am coming around on async after years of not liking it... I wish we didn't have function colouring but yeah ... Here we are....

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

#65

Post by ksec »

steveklabnik wrote: post #14
killingtime74 wrote: post #7

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

Is this a simplified / distilled version of Rust ? Or Subset of Rust with some changes ?

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

#66

Post by neonsunset »

behindsight wrote: post #50
vips7L wrote: post #48

Earlier quoted context omitted.

Checkout Borgo: https://github.com/borgo-lang/borgo I also find that D is good between language. You can do high level or low level whenever you need it. You can also do some inbetween systems programming in C# if you don’t care about a VM or msft.

> You can also do some inbetween systems programming in C# if you don’t care about a VM or msft. C# Native AOT gets rid of the JIT and gives you a pretty good perf+memory profile compared to the past. It's mostly the stigma of .NET Framework legacy systems that put people off, but modern C# projects are a breeze.

FWIW JIT is rarely an issue, and enables strong optimizations not available in AOT (it has its own, but JIT is overall much better for throughput). RyuJIT can do the same speculative optimizations OpenJDK Hotspot does except the language has fewer abstractions which are cheaper and access to low-level programming which allows it to have much different performance profile.

NativeAOT's primary goal is reducing memory footprint, binary size, making "run many methods once or rarely" much faster (CLI and GUI applications, serverless functions) and also shipping to targets where JIT is not allowed or undesirable. It can also be used to ship native dynamically or statically (the latter is tricky) linked libraries.

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

#69

Post by xpe »

amluto wrote: post #57
reactordev wrote: post #55

I write a lot of go. I tried to write a lot of rust but fell into lifetime traps. I really want to leave C++ but I just can’t without something that’s also object oriented. Not a dig at functional, it’s just my big codebases are logically defined as objects and systems that don’t lend itself to just being a struct or an interface. Inheritance is why I’m stuck in C++ land. I would love to have something like rust but…

As a long time C++ user, I’m curious why you like inheritance and virtual methods so much. I maintain a medium sized, old-ish C++ code base. It uses classes and inheritance and virtual methods and even some multiple inheritance. I despise this stuff. Single Inheritance is great until you discover that you have a thing that doesn’t slot nicely into the hierarchy or when you realize that you want to decompose an interf…

Ah, yes, multiple inheritance in C++: where order matters but sanity does not

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

#70

Post by xpe »

dullcrisp wrote: post #49
norir wrote: post #8

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.

Plus we all know that fibs = 1 : 1 : zipWith (+) fibs (tail fibs) is the only serious Fibonacci implementation.

Who thunk of that one?
Post reply on HN