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

121–130 of 274 posts

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

#121

Post by mrkeen »

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…

Weird, that's exactly how I feel reading Go:

  func (lst *List[T]) Push(v T) {
    if lst.tail == nil {
        lst.head = &element[T]{val: v}
        lst.tail = lst.head
    } else {
        lst.tail.next = &element[T]{val: v}
        lst.tail = lst.tail.next
    }
}

And this one doesn't even have the infamous error-checking.

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

#122

Post by raincole »

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.

Rust indeed gets harder with codebase size, just like other languages. But claiming it is because of borrow checker is laughable at best. Borrow checker is what keeps it reasonable because it limits the scope of how one memory allocation can affect the rest of your code.

If anything, borrow checker makes writing functions harder but combining them easier.

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

#123

Post by gethly »

imbnwa wrote: post #100
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…

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 without any good reason. We have modern lexers/tokenizers and compilers that can handle if you don't put a stupid ; at the end of every single effing line.

Just go and count how many of these useless characters are in your codebase and imagine how many keystrokes, compilation errors and wasted time it cost you, whilst providing zero value in return.

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

#124

Post by Ar-Curunir »

mrkeen wrote: post #116
zephen wrote: post #74

Earlier quoted context omitted.

It virtue-signals that they're part of the hip functional crowd. (To be fair, if you are programming functionally, it is essential. But to flat-out state that a language that doesn't support isn't "serious" is a bit rude, at best.)

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.

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

#125

Post by oersted »

int_19h wrote: post #104
oersted wrote: post #15

Earlier quoted context omitted.

For people that like functional style and using recursion for everything, TCO is a must. Otherwise there’s no way around imperative loops if you want decent performance and not having to worry about the stack limit. Perhaps calling it an “optimization” is misleading. Certainly it makes code faster, but more importantly it’s syntax sugar to translate recursion into loops.

You don't need full fledged TCO for that; see Clojure's recur for an example. Zig recently added something similar but strongly typed with match/continue. These all map exactly to a closed set of mutually recursive functions with a single entry point, which is quite sufficient (and then some) to fully replace iterative loops while still desugaring to the same exact code.

Indeed there are more explicit versions of such mechanisms, which I prefer, otherwise there’s always a bit of paranoia about recursion without assurance that the compiler will handle it properly.

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

#126

Post by sureglymop »

steveklabnik wrote: post #4
andsoitis wrote: post #2

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

Have you explored the ideas explored for the Vale language: https://vale.dev/

May be an interesting approach. That language seems very academic and slow moving at the moment though.

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

#127

Post by steveklabnik »

ChrisSD wrote: post #113
steveklabnik wrote: post #30

Earlier quoted context omitted.

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.

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

#128

Post by steveklabnik »

a96 wrote: post #101
steveklabnik wrote: post #14

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.

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

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.

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

#129

Post by steveklabnik »

sureglymop wrote: post #126
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.

Have you explored the ideas explored for the Vale language: https://vale.dev/ May be an interesting approach. That language seems very academic and slow moving at the moment though.

I think Vale is interesting, but yeah, they have had some setbacks, in my understanding more to do with the personal lives of the author rather than the ideas. I need to spend more time with it.

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

#130

Post by gethly »

christophilus wrote: post #102
imbnwa wrote: post #100

Earlier quoted context omitted.

What would be better?

I wish more languages would adopt Clojure’s approach to optional delimiters in collections. [2 45 78] It’s just a nicer thing to view and type in my experience. Regarding syntax soup, I think Odin is probably syntactically the cleanest of the lower level languages I’ve played with.

oh, yeah. that looks good. i always hated using ", " delimiter for lists and the amount of typos it always takes to make clean(well, not with Go fmt).

Odin seems interesting but for me it has two deal-breakers: first one use the use of ^ for pointer de/reference. Not that it does not make sense, it's just that it is not an easy key to get to on my keyboard layout and i will not be changing that. The & and * are well known characters for this purpose and, at least for me, easily accessible on the keyboard. Second issue is the need to download many gigabytes of visual studio nonsense just so i am able to compile a program. Coming from Go, this is just a non-starter. Thirdly, and this is more about the type of work i do than the language, there are/were no db drivers, no http/s stack and other things i would need for my daily work. Other than that, Odin is interesting. Though I am not sure how I would fare without OOP after so many years with inheritance OOP and encapsulated OOP.

Post reply on HN