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

261–270 of 274 posts

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

#261

Post by gf000 »

pjmlp wrote: post #257
gf000 wrote: post #253

Earlier quoted context omitted.

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.

I agree with your first point, and I didn't say anything contrary to your second.

My point is about crossing the misunderstanding between the "two camps".

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

#262

Post by aw1621107 »

pron wrote: post #251
aw1621107 wrote: post #231

Earlier quoted context omitted.

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

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

I think you're right with respect to discussion about abstractions in the context of high-/low-level languages, but again, I feel like what GP was trying to get away from the high-/low-level framing in the first place and might have meant something different when they used the word "abstraction".

Perhaps this is me misinterpreting things, but I took GP's use of "abstraction" as something more along the lines of what it might mean in "this library's abstractions are designed poorly/well because they are easy/hard to misuse and/or understand". In that context I think "abstraction" is more about the precise interface contract and its quality - e.g., a poorly-chosen abstraction might not reflect the domain it ostensibly represents well because it permits actions/behaviors that don't make sense for that domain, and that in part might be due to a language being unable to express a more appropriate contract. I feel that better matches GP's high-/low-type-system-complexity axis.

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

#263

Post by pjmlp »

gf000 wrote: post #261
pjmlp wrote: post #257

Earlier quoted context omitted.

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.

I agree with your first point, and I didn't say anything contrary to your second. My point is about crossing the misunderstanding between the "two camps".

Fair enough.

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

#264

Post by Someone »

throwaway7356 wrote: post #255
Someone wrote: post #248

Earlier quoted context omitted.

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

Good points. As to signal handlers, I’m not aware of any language that fully supports them by making it impossible to call other than async-safe functions (https://man7.org/linux/man-pages/man7/signal-safety.7.html) from asynchrony signal handlers.

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

#265

Post by gpm »

aw1621107 wrote: post #262
pron wrote: post #251

Earlier quoted context omitted.

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

> 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. I think you're right with respect to discussion about abstractions in the context of high-/low-level languages, but again, I feel like what GP was try…

I agree with everything you're attributing to me for what it's worth :)

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

#266

Post by dent9 »

josephg wrote: post #36
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.

Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript.…

> I understand why Go exists. But I can't think of any reason I'd ever use it.

When you want your project to be able to cross-compile down to a static binary that the end user can simply download and run without any "installation" on any mainstream OS + CPU arch combination

From my M1 Mac I can compile my project for Linux, MacOS, and Windows, for x86 and ARM for each. Then I can make a new Release on GitHub and attach the compiled binaries. Then I can curl the binaries down to my bare Linux x86 server and run them. And I can do all of this natively from the default Go SDK without installing any extra components or system configurations. You don't even need to have Go installed on the recipient server or client system. Don't even need a container system either to run your program anywhere.

You cannot do this with any other language that you listed. Interpreted languages all require a runtime on the recipient system + library installation and management, and C and Rust lack the ability to do native out-of-the-box cross compilation for other OS + CPU arch combinations.

Go has some method to implement enums. I never use enums in my projects so idk how the experience compares to other systems. But I'm not sure I would use that as the sole criteria to judge the language. And you can usually get performance on par with any other garage collected language out of it.

When you actually care about the end user experience of running the program you wrote, you choose Go.

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

#267

Post by yencabulator »

UltraSane wrote: post #63
wswin wrote: post #40

Earlier quoted context omitted.

Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.

async seems sensible for anything subject to internet latency.

Only in languages/runtimes without threads, like Javascript. In Rust, async vs threads is a performance tradeoffs (and it's definitely not always clear who the winner will be), and mostly relevant when you have tasks >> cores. Something like curl would have practically 0 reasons to be async, but of course is still subject to internet latency.

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

#268

Post by baranul »

aw1621107 wrote: post #182
freakynit wrote: post #118

Earlier quoted context omitted.

"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree. Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 It is also accompanied with a demo video (pretty convincing in case you would like to…

> Im more interested to know the points in relation to autofree. As sibling said, autofree is still stated to use a GC, which obviously disqualifies it from "memory safety without GC". > Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 I did see that! Unfortunately it doesn't really move the needle on anything I said earlier. It d…

Autofree can be combined with other memory management methods, besides GC, and is something V developers have hinted at multiple times. Until autofree becomes the focus of the project, combining it with the already existing GC, looks to have been and is more convenient.

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

#269

Post by baranul »

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.

Interesting, how various people don't feel you are entitled to your opinion about languages or the beauty of V, unless it is to "push" the negative.

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

#270

Post by baranul »

freakynit wrote: post #118
aw1621107 wrote: post #93

Earlier quoted context omitted.

> Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The devel…

"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree. Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 It is also accompanied with a demo video (pretty convincing in case you would like to…

The issue is that autofree is not a 100% solution by itself, in all circumstances. Thus it relies on the existing GC, in situations that it's not. The V developers have already hinted at using alternatives to the GC, for that remaining percentage, so memory safety without the GC is on the table for them.

Based on what I've read and hints dropped, can see them adding some type of additional DFA and borrow checker, somewhat like D, to be combined with autofree. Awareness of this possibility, might be why V's competitors have been so overly focused on them. As we are talking about combining it to an easier to use language, with cleaner syntax.

Post reply on HN