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

191–200 of 274 posts

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

#191

Post by reactordev »

scuff3d wrote: post #187
reactordev wrote: post #172

Earlier quoted context omitted.

Yeah go has embedded structs. It’s ugly and allows one to address the fields on the parent and it exposes the struct (with the same fields) so it’s kind of a head scratcher. To be honest, it’s been 3 years since I looked at rust and I might try again. I still prefer inheritance because some things just are-a thing. I also love ECS and components and see traits as that. I just wish I could store local state in those.

You can store state in the struct and then define a method in the trait to return the struct. Then all your default methods can use the "getter" to access the struct and it's state. The only thing you have to do is embed the struct and implement that one "getter" method to return it. I don't think it's much more boilerplate then utilizing inheritance. Fyrox, a game engine written in Rust, uses an ECS and several obje…

Yeah that’s what I did and it’s ugly. It works, and allows me to attach multiple behaviors but I would have to initialize them and write that boilerplate code to return them.

I think I might be able to do it with a macro but I’m not a rust guy so I’m limited by my knowledge.

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

#192

Post by nasretdinov »

9rx wrote: post #164
auggierose wrote: post #143

Earlier quoted context omitted.

Auto generation? If you need to use that a lot, then the programming language is defective, I would say.

When Go was launched, it was said it was built specifically for building network services. More often than not that means using protobuf, and as such protobuf generated code ends up being a significant part of your application. You'd have that problem in any language, theoretically, due to the design of protobuf's ecosystem. Difference is that other languages are built for things other than network services, so proto…

What I've found over the years is that protobuf is actually not that widespread, and, given that, if you ignore gogoprotobuf package, it would generate terrible (for Go's GC) structs with pointers for every field, it's not been terribly popular in Go community either, despite both originating at Google

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

#193

Post by culebron21 »

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…

Usually it takes some time to get used to borrow checker and lifetimes. After that, you stop noticing them.

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

#194

Post by steveklabnik »

culebron21 wrote: post #185

I couldn't figure out the main points, besides the "between Rust & Go" slogan. I've worked both with Rust and Go, and I like Rust more, but there are several pain points: * macro abuse. E.g. bitshift storing like in C needs a bunch of #[...] derive_macros. Clap also uses them too much, because a CLI parameter is more complex than a struct field. IDK what's a sane approach to fixing this, maybe like in Jai, or Zig? No…

It’s too early to have slick marketing and main points.

Noted, thanks for the comment. I share some of these opinions more than others, but it’s always good to get input.

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

#195

Post by steveklabnik »

yoan9224 wrote: post #181

The positioning is interesting - claiming Rust's performance with Go's simplicity is basically every new systems language's promise since 2015. The key differentiator seems to be "zero-cost exceptions" which I assume means compile-time Result types without runtime unwinding overhead? That's compelling if true, since Rust's Result ergonomics can get verbose in deeply nested error chains. But the real test is compile t…

I’m explicitly not claiming Rust’s performance. Rust will always be ahead here. I’m giving up some of that performance for other things.

I do agree that those benchmarks are important. Once I have enough language features to make such a thing meaningful, I’ll be tracking them.

Where did I write that it’s fun to write?

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

#196

Post by exceptione »

gethly wrote: post #156
exceptione wrote: post #153

Earlier quoted context omitted.

> fn foo(n i32, m i32) (i32, i32) {} But now consider returning a function with type¹ Foo > -> (bool -> IDictionary -> i32 -> T3) where T2 : T3 even if you leave out the latter type constraint, I think it is hard to avoid undecidable ambiguity. fn foo(n i32, m T2) (????) {} You quickly get ambiguity due to type parameters / generics, functions as arguments, and tuples if you don't syntactically separate them. Even if…

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.

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

#197

Post by zephen »

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

Earlier quoted context omitted.

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; }

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

Well, sure, but real programmers know how to do while loops without invoking a function call.

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

#198

Post by gethly »

Joker_vD wrote: post #157
gethly wrote: post #123

Earlier quoted context omitted.

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…

> 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. Well, there is, but it's more of a personal trait than a universal truth. Some human programmers (e.g. me) tend to read and parse (and even write, to some extent) source code more accurately when there is a sprinkle…

the only reason why one might hold such an opinion is the lack of syntax highlighting.

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

#199

Post by andsoitis »

pjmlp wrote: post #189
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?

ARC is GC, chapter 5. https://gchandbook.org/

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.

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

#200

Post by 9rx »

hombre_fatal wrote: post #177
9rx wrote: post #161

Earlier quoted context omitted.

> it was annoying to program (due to a lack of enums) Typescript also lacks enums. Why wasn't it considered annoying? I mean, technically it does have an enum keyword that offers what most would consider to be enums, but that keyword behaves exactly the same as what Go offers, which you don't consider to be enums.

They presumably mean tagged unions like `User = Guest | LoggedIn(id, username)`.

That wouldn't explain C, then, which does not have sum types either.

All three languages do have enums (as it is normally defined), though. Go is only the odd one out by using a different keyword. As these programs were told to be written as carbon copies of each other, not to the idioms of each language, it is likely the author didn't take time to understand what features are available. No enum keyword was assumed to mean it doesn't exist at all, I guess.

Post reply on HN