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

251–260 of 274 posts

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

#251

Post by pron »

aw1621107 wrote: post #231
pron wrote: post #152

Earlier quoted context omitted.

> 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 comm…

But that's why the word "abstraction" is the wrong choice. The ability of a language to express detail and the ability of a language to have high abstractions are two different things, and when we talk about high and low level languages, I claim that what we intuitively mean is abstraction, not the expressivity of contracts. For example, ATS's contracts are virtually unlimited in their expressivity (it makes Rust indistinguishable from C by comparison), yet few would say it's particularly high-level. On the other hand, Scheme or even JavaScript can express few contracts, and yet are considered high level. I think that when we think of a high-level language, what we have in mind is a language where programs typically need to concern themselves with fewer details. This corresponds more with abstraction rather than "contract expressiveness".

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

#252

Post by gf000 »

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.

Low and high level are not well-defined concepts.

One, objective definition is simply that everything that is not an assembly is a high-level language - but that is quite a useless def. The other is about how "deeply" you can control the execution, e.g. you have direct control of when and what gets allocated, or some control over vectorization, etc.

Here Rust is obviously as low-level as C, if not more so (both have total control over allocations, but still leaves calling conventions and such up to the compiler), while go is significantly higher (the same level as C#, slightly lower than Java - managed language with a GC and value types).

The other often mistaken spectrum is expressivity, which is not directly related to low/high levelness. E.g. both Rust and Scala are very expressive languages, but one is low, the other is high level. C and Go both have low expressivity, and one is low the other is high level.

This answer is imo a very must have read about the topic of expressivity: https://langdev.stackexchange.com/a/2016

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

#253

Post by gf000 »

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.

While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.

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

#254

Post by gf000 »

freakynit wrote: post #90
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?

Check out V-lang ... it has the details. It's a beautiful language... but, mostly unknown.

More like "mostly known from stating absolutely ridiculous claims", though I heard they went back on most of them and now are more realistic - but also much less interesting.

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

#255

Post by throwaway7356 »

Someone wrote: post #248
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…

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

As long as the systems programming tasks are strictly sequential, without threads, coroutines or signal handlers.

There is more to memory access than just out-of-bounds access which could be solved by just allocating every accessed memory page on demand as a slightly alteration of your variant.

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

#256

Post by josephg »

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

Earlier quoted context omitted.

> 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 full…

Yes I think I mentioned in another comment that that would be another way to code it up. It’s ugly in a different way to the interface approach. I haven’t written enough go to know which is the least bad.

What are you “fighting all day” in typescript? That’s not my experience with TS at all.

What are the virtues of go, that you’re so enamoured by? If we give up beauty and type safety, what do you get in trade?

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

#257

Post by pjmlp »

gf000 wrote: post #253
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.

While I am usually the one that also goes in and correct people incorrectly calling RC not a GC, the important distinction here is that Rust (and C++) has the necessary language constructs to be able to implement ref counting entirely as a library.

Which is a performance bottleneck, as the compiler is blind to library implementations and cannot optimise accordingly.

Also implementation has nothing to do with CS definition, there are tracing GC libraries for C as well.

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

#258

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

For future readers, please use this link: https://github.com/rue-language/rue/blob/b0867ccff77ee9957d6...

I am going to be cleaning these up, as they don't necessarily represent things I actually want to do in this exact way. My idea was to dump some text and iterate on them, but I think that's actually not great given some other process changes I'm making, so I want to start fresh.

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

#259

Post by 9rx »

josephg wrote: post #256
9rx wrote: post #235

Earlier quoted context omitted.

> 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 full…

Yes I think I mentioned in another comment that that would be another way to code it up. It’s ugly in a different way to the interface approach. I haven’t written enough go to know which is the least bad. What are you “fighting all day” in typescript? That’s not my experience with TS at all. What are the virtues of go, that you’re so enamoured by? If we give up beauty and type safety, what do you get in trade?

I don't become enamoured by language. I really don't care if I have to zig or zag. I'll happily work in every language under the sun. It is no more interesting than trying to determine if Milwaukee or Mikita make a better drill. Who cares? Maybe you have to press a different button, but they both do the same thing in the end. As far as I'm concerned, It's all just 1s and 0s at the end of the day.

However, I have found the Go variant of said project to be more pleasant because, as before, it just works. The full functionality of those libraries is fairly complex and it has had effectively no bugs. The Typescript version on the other hand... I am disenchanted by software that fails.

Yeah, you can blame the people who have worked on it. Absolutely. A perfect programmer can program bug-free code in every language. But for all the hand-wringing about how complex types are supposed to magically save you from making mistakes that keeps getting trumped around here, I shared it as a fun anecdote to the opposite — that, under real-world conditions where you are likely to encounter programers that aren't perfect, Go actually excelled in a space that seems to reflect your example.

But maybe it's not the greatest example to extol the virtues of a language. I don't know, but I am not going to start caring about one language over another anyway. I'm far more interested in producing great software. Which brand of drill was used to build that software matters not one bit to me. But to each their own. Different opinions is the spice of life, I suppose!

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

#260

Post by chuckadams »

amluto wrote: post #230
chuckadams wrote: post #186

Earlier quoted context omitted.

Protected and private inheritance are C++'s equivalent to traits, and they don't suffer from the usual issues of multiple inheritance. As for type classes, check out concepts. By no means am I trying to sell C++, I don't touch it myself, but it doesn't leave you completely adrift in those seas.

> Protected and private inheritance are C++'s equivalent to traits How so? Maybe in a COM-like world where the user of an object needs to call a method to get an interface pointer. I’ll grant that concepts are a massive improvement.

In the sense of supporting mixins that don't necessarily pollute your public API. The overlap with other languages isn't perfect, and traits in the stdlib refer to a rather different template-based thing, but I don't think any language has the monopoly on a canon definition of traits. Certainly they're going to be different than traits in Self, which iirc coined the term.
Post reply on HN