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

241–250 of 274 posts

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

#241

Post by steveklabnik »

dxxvi wrote: post #240
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.

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

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

#242

Post by dismalaf »

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.

Go has a GC and Rust doesn't. That alone makes Go higher level.

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

#243

Post by waldrews »

pjmlp wrote: post #190
waldrews wrote: post #67

What the world needs is a more expressive language than Go, that interops with Go's compilation model and libraries.

Nah, we already have that in D, C#, and who knows maybe one day Java finally gets Valhala, or one can use Kotlin or Scala in the meantime.

It's amazing how often C# (or more broadly CLR/JVM) is the pragmatic answer, even when you feel uncool using it.

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

#244

Post by gethly »

exceptione wrote: post #196
gethly wrote: post #156

Earlier quoted context omitted.

This is pointless discussion as Go has all of these things already implemented, so there is no point in going backwards.

The point is that a (new) syntax for any language needs to support any such implementation. The language implementation itself is not the point.

Yes, and I am saying Go has already solved all of this and it makes little sense to deviate too much from its syntax.

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

#245

Post by pjmlp »

waldrews wrote: post #243
pjmlp wrote: post #190

Earlier quoted context omitted.

Nah, we already have that in D, C#, and who knows maybe one day Java finally gets Valhala, or one can use Kotlin or Scala in the meantime.

It's amazing how often C# (or more broadly CLR/JVM) is the pragmatic answer, even when you feel uncool using it.

Indeed. :)

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

#246

Post by mrkeen »

hu3 wrote: post #229
mrkeen wrote: post #121

Earlier quoted context omitted.

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.

You cherry picked a contrived example but that's one of the cleanest generics implementations. Now imagine if it had semicolons, ->, ! and '.

> You cherry picked a contrived example

List.add is contrived? What are you doing that's simpler the list.add?

> but that's one of the cleanest generics implementations.

You're saying it's typically worse than this?

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

#247

Post by Warwolt »

pjmlp wrote: post #202
andsoitis wrote: post #199

Earlier quoted context omitted.

Sure, ARC is a form of very specific, constrained garbage collection. Compile-time, reference-counting GC, not runtime tracing GC. So no background collector, no heap tracing, and no stop-the-world pauses. Very different from the JVM, .Net, or Go.

Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime. Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.

But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector.

Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic

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

#248

Post by Someone »

xorvoid wrote: post #216

"Memory Safe No garbage collector, no manual memory management. A work in progress, though." I wish them the best, but until they have a better story here I'm not particularly interested. Much of the complexity in Rust vs simplicity in Go really does come down to this part of the design space. Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a tr…

> Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a trade-off). No one really knows a sane way to do it otherwise, unless you also want to drop the general-purpose systems programming language requirement.

> I'll be Very Interested if they find a new unexplored point in the design space, but at the moment I remain skeptical.

They’re the somewhat sane “don’t allow dynamic allocations; just dimension all your arrays large enough” approach from the 1950s (Fortran, COBOL).

A variant could have “you can only allocate globals and must allocate each array exactly once before you ever access it”. That would allow dimensioning them from command line arguments or sizes of input files.

The type system then would have “pointer to an element of foo” types (could be implemented old-style as indices)

Yes, that would limit things, but with today’s 64-bit address spaces I think it could work reasonably well for many systems programming tasks.

It definitely would be significantly less complex than rust.

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

#249

Post by gethly »

mrkeen wrote: post #246
hu3 wrote: post #229

Earlier quoted context omitted.

You cherry picked a contrived example but that's one of the cleanest generics implementations. Now imagine if it had semicolons, ->, ! and '.

> You cherry picked a contrived example List.add is contrived? What are you doing that's simpler the list.add? > but that's one of the cleanest generics implementations. You're saying it's typically worse than this?

He is referring to

  &element[T]{val: v}
the & is a pointer, which is common across most languages, but the [T] is a dynamic type T. Otherwise it would be just

  &element{val: v}
He says that element[T] is a clean/simple implementation of generics.

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

#250

Post by pjmlp »

Warwolt wrote: post #247
pjmlp wrote: post #202

Earlier quoted context omitted.

Reference counting is a GC algorithm from CS point of view, it doesn't matter if it is compile time or runtime. Additionally there isn't a single ARC implementation that is 100% compile time, that when looking at the generated machine code has removed all occurrences from RC machinery.

But common, collouqialy "Garbage Collection" as a language feature refers to a run time garbage collector. Saying that the language has GC just because it has opt-in reference counting is needlessly pedantic

Knowlege gets taught in specific institutions exactly because street knowledge is quite often incorrect, like in this case, spreading urban myths based in shaky foundations.
Post reply on HN