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

101–110 of 274 posts

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

#101

Post by a96 »

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.

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 metal soon. :)

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

#102

Post by christophilus »

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?

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.

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

#103

Post by int_19h »

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.

It's a Lisp thing, obviously, but also there's a benefit to explicit delimiters - it makes it possible to have an expression as an element without wrapping that in its own brackets, as S-exprs require.

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

#104

Post by int_19h »

oersted wrote: post #15
stouset wrote: post #9

Earlier quoted context omitted.

Would someone please explain to me why TCO—seemingly alone amongst the gajillions of optimization passes performed by modern compilers—is so singularly important to some people?

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.

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

#105

Post by int_19h »

steveklabnik wrote: post #10
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.

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.

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

#106

Post by torginus »

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.

Could you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed?

What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?

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

#107

Post by mxey »

est31 wrote: post #72

I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde,…

> On the other hand, these auto generation tools in Go are only somewhat standardized, you don't have a central tool that takes care of things (or at least I'm not aware of it).

https://pkg.go.dev/cmd/go#hdr-Generate_Go_files_by_processin...

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

#108

Post by mxey »

ryanobjc wrote: post #77
est31 wrote: post #72

I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde,…

The "just generate go code automatically then check it in" is a massive miswart from the language, and makes perfect sense because that pathological pattern is central to how google3 works. A ton of google3 is generated, like output from javascript compilers, protobuf serialization/deserialization code, python/C++ wrappers, etc. So its an established Google standard, which has tons of help from their CI/CD systems. F…

> For everyone else, keeping checked-in auto-generated code is a continuous toil and maintenance burden. The Google go developers don't see it that way of course, because they are biased due to their google3 experience.

The golang/go repo itself has various checked-in generated repo

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

#109

Post by tgv »

beautron wrote: post #97
est31 wrote: post #72

I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde,…

> The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation. I'm sure there are pr…

Me neither. My go code doesn't have any auto-generation. IMO it should be used sparingly, in cases where you need a practically different language for expressivity and correctness, such as a parser-generator.
Post reply on HN