I am surprised that a language with nothing than a couple of promises gets so much attention. Why exactly?
One of which the implementation is 100% vibe coded even.
Rue: Higher level than Rust, lower level than Go
151–160 of 274 posts
Re: Rue: Higher level than Rust, lower level than Go
#152I 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.
I wonder if it's useful to think of this as go is low type-system-complexity and rust is high type-system-complexity. Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions. As an independent axis from close to the underlying machine/far away from the underlying machine (whether virtual like wasm or real like a sys…
> Where type system complexity entails a tradeoff between the complexity of the language and how powerful the language is in allowing you to define abstractions.
I don't think that's right. The level of abstraction is the number of implementations that are accepted for a particular interface (which includes not only the contract of the interface expressed in the type system, but also informally in the documentation). E.g. "round" is a higher abstraction than "red and round" because the set of round things is larger than the set of red and round things. It is often untyped languages that offer the highest level of abstraction, while a sophisticated type system narrows abstraction (it reduces the number of accepted implementations of an interface). That's not to say that higher abstraction is always better - although it does have practical consequences, explained in the next paragraph - but the word "abstraction" does mean something specific, certainly more specific than "describing things".
How the level of abstraction is felt is by considering how many changes to client code (the user of an interface) is required when making a change to the implementation. Languages that are "closer to the underlying machine" - especially as far as memory management goes - generally have lower abstraction than languages that are less explicit about memory management. A local change to how a subroutine manages memory typically requires more changes to the client - i.e. the language offers a lower abstraction - in a language that's "closer to the metal", whether the language has a rich type system like Rust or a simpler type system like C, than a language that is farther away.
Re: Rue: Higher level than Rust, lower level than Go
#153Earlier quoted context omitted.
In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them. Personally, I would like a language that pushes the programmer to write the types as part of a doc comment. Also think about returning lambda's. S…
> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}
> fn foo(n i32, m i32) (i32, i32) {}
Foo> -> (bool -> IDictionary -> i32 -> T3) where T2 : T3
fn foo(n i32, m T2) (????) {}
Even if you your context-depended parser can recognize it, does the user? I agree that a language designer should minimize the amount of muscle damage, but he shouldn't forget that readability is perhaps even more critical.
____
1. Note, even if the parser can recognize this, for humans the '>' is confusing unless syntax highlighting takes care of it. One time it delimits a generic type argument, the other time it is part of '->'. This is also an argument for rendering these things as ligatures.
Re: Rue: Higher level than Rust, lower level than Go
#154I 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.
> because there are multiple valid ways of interpreting i
There are quantitative ways of describing it, at least on a relative level. "High abstraction" means that interfaces have more possible valid implementations (whether or not the constraints are formally described in the language, or informally in the documentation) than "low abstraction": https://news.ycombinator.com/item?id=46354267
Re: Rue: Higher level than Rust, lower level than Go
#155Okay, right now it's basically Pascal as it was described in Revised Report, only even more restricted. Which is... fine, I guess, you can still write a whole OS with something like that (without using pointers/addresses) as Per-Brinch Hansen demonstrated but it's... an acquired taste.
Are the actual references/pointers coming in the future?
Re: Rue: Higher level than Rust, lower level than Go
#156Earlier quoted context omitted.
> Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}
> 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.
Re: Rue: Higher level than Rust, lower level than Go
#157Earlier quoted context omitted.
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 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 of punctuation thrown in into a long chain of nothing but identifiers and subtly nested parentheses. Some, e.g. you, don't need such assistance and find it annoying and frivolous.
Unfortunately, since we don't store the source code of our programs as binary AST blobs that could be rendered in a personalized matter, but as plain text instead, we have to accept the language designer's choices. Perhaps it actually has better consequences than the alternative; perhaps not.
Re: Rue: Higher level than Rust, lower level than Go
#158Just pointing out here that "rue" is used to express "to regret", emphatically. Perhaps it is not the best name for a programming language.
Re: Rue: Higher level than Rust, lower level than Go
#159Just pointing out here that "rue" is used to express "to regret", emphatically. Perhaps it is not the best name for a programming language.
The best code is the code not written, so perhaps it is the best name for a programming language?
Re: Rue: Higher level than Rust, lower level than Go
#160Just pointing out here that "rue" is used to express "to regret", emphatically. Perhaps it is not the best name for a programming language.
That’s part of the reason for the name! “Rust” also has negative interpretations as well. A “rue” is also a kind of flower, and a “rust” is a kind of fungus.