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

231–240 of 274 posts

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

#231

Post by aw1621107 »

pron wrote: post #152
gpm wrote: post #31

Earlier quoted context omitted.

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

The way I understood the bit you quoted was not as a claim that more complex type system = higher abstraction level, but as a claim that a more complex type system = more options for defining/encoding interface contracts using that language. I took their comment as suggesting an alternative to the typical higher/lower-level comparison, not as an elaboration.

As a more concrete example, the way I interpreted GP's comment is that a language that is unable to natively express/encode a tagged union/sum type/etc. in its type system would fall on the "less complex/less power to define abstractions" side of the proposed spectrum, whereas a language that is capable of such a thing would fall on the other side.

> which includes not only the contract of the interface expressed in the type system, but also informally in the documentation

I also feel like including informal documentation here kind of defeats the purpose of the axis GP proposes? If the desire is to compare languages based on what they can express, then allowing informal documentation to be included in the comparison renders all languages equally expressive since anything that can't be expressed in the language proper can simply be outsourced to prose.

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

#232

Post by AdieuToLogic »

steveklabnik wrote: post #82
AdieuToLogic wrote: post #62

Earlier quoted context omitted.

> 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. Out of curiosity, how would you compare the goals of Rue with something like D[0] or one of the ML-based languages such as OCaml[1]? EDIT: This is a genuine language design question regarding an imperative/OOP or declarative/FP focus and is relevant to understanding the memory managem…

Closer to an OCaml than a D, in terms of what I see as an influence. But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them.

> But it's likely to be more imperative/FP than OOP/declarative, even though I know those axes are usually considered to be the way you put them than the way I put them.

Fascinating.

I look forward to seeing where you go with Rue over time.

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

#234

Post by steveklabnik »

metaltyphoon wrote: post #233

What was the rationale to not use cargo? By the way, I really enjoy when you are a guest on the fallthrough podcast.

Thanks!

So, one reason is "I just want to learn more about buck2."

But, for the first iteration of Rue, I maintained both. However, for a language project, there's one reason Cargo isn't sufficient now, and one reason why it may not later: the first one is https://github.com/rue-language/rue/blob/trunk/crates/rue-co... : I need to make sure that, no matter what configuration I build the compiler in, I build a staticlib for the runtime. With Cargo, I couldn't figure out how to do this. In test mode, it would still try to build it as a dylib.

Later, well, the reason that rustc has to layer a build system on top of Cargo: bootstrapping. I'm not sure if Rue will ever be bootstrapped, but rustc uses x.py for this. Buck does it a lot nicer, IMHO https://github.com/dtolnay/buck2-rustc-bootstrap

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

#235

Post by 9rx »

josephg wrote: post #222
9rx wrote: post #219

Earlier quoted context omitted.

> C has numeric enums and tagged unions C has unions, but they're not tagged. You can roll your own tagged unions, of course, but that's moving beyond it being a feature of the language. > How would you model this in Go? I'm committing the same earlier sin by trying to model it from the solution instead of the problem, so the actual best approach might be totally different, but at least in staying somewhat true to yo…

> C has unions, but they're not tagged. You can roll your own tagged unions, of course, but that's moving beyond it being a feature of the language. This feels like a distinction without a real difference. Hand-rolled tagged unions are how lots of problems are approached in real, professional C. And I think they're the right tool here. > the actual best approach might be totally different, but at least in staying som…

> As I said, I ended up needing about 50% more lines to accomplish the same thing in Go

I'd be using Perl if that bothered me. But there is folly in trying to model from a solution instead of the problem. For example, maybe all you needed was:

    type OpType int
    const (
        OpTypeSkip OpType = iota
        OpTypeInsert
        OpTypeDelete
    )

    type OpComponent struct {
        Type OpType
        Int int
        Str string
    }
Or something else entirely. Without fully understanding the exact problem, it is hard to say what the right direction is, even where the direction you chose in other language is the right one for that language. What is certain is that you don't want to write code in language X as if it were language Y. That doesn't work in programming languages, just as it does not work in natural languages. Every language has their own rules and idioms that don't transfer to another. A new language means you realistically have to restart finding the solution from scratch.

> You'd probably need a different problem to show Go or C# in their best light.

That said, my profession sees me involved in working on a set of libraries in various languages, including Go and Typescript, that appear to be an awful lot like your example. And I can say from that experience that the Go version is much more pleasant to work on. It just works.

I'll agree with you all day every day that the Typescript version's types are much more desirable to read. It absolutely does a better job at modelling the domain. No question about it. But you only need to read it once to understand the model. When you have to fight everything else beyond that continually it is of little consolation how beautiful the type definitions are.

You're right, though, it all depends on what you find most important. No two programmers are ever going to ever agree on what to prioritize. You want short code, whereas I don't care. Likewise, you probably don't care about the things I care about. Different opinions is the spice of life, I suppose!

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

#236

Post by delifue »

rayiner wrote: post #217
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…

If you look at the Github, there's a design proposal (under docs/design) for that. It looks like the idea at the present time is to have four modes: value types, affine types, linear types, and rc types. Instead, of borrowing, you have an inout parameter passing convention, like Swift. Struct fields cannot be inout, so you can't store borrowed references on the heap. I'm very interested in seeing how this works in pr…

Not being able to store mutable ref in other type reduces expressiveness. The doc already mentions it cannot allow Iterator that doesn't consume container

https://github.com/rue-language/rue/blob/trunk/docs/designs/...

No silver bullet again

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

#237

Post by steveklabnik »

delifue wrote: post #236
rayiner wrote: post #217

Earlier quoted context omitted.

If you look at the Github, there's a design proposal (under docs/design) for that. It looks like the idea at the present time is to have four modes: value types, affine types, linear types, and rc types. Instead, of borrowing, you have an inout parameter passing convention, like Swift. Struct fields cannot be inout, so you can't store borrowed references on the heap. I'm very interested in seeing how this works in pr…

Not being able to store mutable ref in other type reduces expressiveness. The doc already mentions it cannot allow Iterator that doesn't consume container https://github.com/rue-language/rue/blob/trunk/docs/designs/... No silver bullet again

Just to be clear, these proposals are basically scratch notes I have barely even validated, I just wanted to be able to iterate on some text.

But yes, there is going to inherently be some expressiveness loss. There is no silver bullet, that's right. The idea is, for some users, they may be okay with that loss to gain other things.

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

#238

Post by josephg »

aw1621107 wrote: post #81
asa400 wrote: post #78

Earlier quoted context omitted.

I wholeheartedly concur based on my experience with Rust (and other languages) over the last ~7 or so years. > If I call a function which returns an object of type T, I can safely assume the object lasts forever. It cannot be mutated by any other code (since its mine). And I'm not going to break anything else if I mutate the object myself. These are really nice properties to have when programming at scale. I rarely s…

> I rarely see this mentioned in the way that you did, and I'll try to paraphrase it in my own way: Rust restricts what you can do as a programmer. One can say it is "less powerful" than C. In exchange for giving up some power, it gives you more information Your paraphrasing reminds me a bit of structured vs. unstructured programming (i.e., unrestricted goto). Like to what you said, structured programming is "less po…

I really like this analogy. In a sense, C restricts what you can do compared to programming directly in assembly. Like, there's a lot of programs you can write in assembly that you can't write in the same way in C. But those restrictions also constrain all the other code in your program. And that's a wonderful thing, because it makes it much easier to make large, complex programs.

The restrictions seem a bit silly to list out because we take them for granted so much. But its things like:

- When a function is called, execution starts at the top of the function's body.

- Outside of unions, variables can't change their type halfway through a program.

- Whenever a function is called, the parameters are always passed using the system calling convention.

- Functions return to the line right after their call site.

Rust takes this a little bit further, adding more restrictions. Things like "if you have a mutable reference to to a variable, there are no immutable references to that variable."

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

#239

Post by AdieuToLogic »

pjmlp wrote: post #211
AdieuToLogic wrote: post #76

Earlier quoted context omitted.

> C was designed as a high level language and stayed so for decades C was designed as a "high level language" relative to the assembly languages available at the time and effectively became a portable version of same in short order. This is quite different to other "high level languages" at the time, such as FORTRAN, COBOL, LISP, etc.

When C was invented, K&R C, it was hardly lower level than other systems programming languages that predated it, since JOVIAL in 1958. It didn't not even had compiler intrisics, a concept introduced by ESPOL in 1961, allowing to program Burroughs systems without using an external Assembler. K&R C was high level enough that many of the CPU features people think about nowadays when using compiler extensions, as they ar…

I think we are largely saying the same thing, as described in the introduction of the K&R C book:

  C is a relatively "low level" language. This
  characterization is not pejorative; it simply means that C
  deals with the same sort of objects that most computers do,
  namely characters, numbers, and addresses.[0]
0 - https://dn710204.ca.archive.org/0/items/the-c-programming-la...

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

#240

Post by dxxvi »

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.

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.

Post reply on HN