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

201–210 of 274 posts

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

#201

Post by Hemospectrum »

whimsicalism wrote: post #188
yoan9224 wrote: post #181

The positioning is interesting - claiming Rust's performance with Go's simplicity is basically every new systems language's promise since 2015. The key differentiator seems to be "zero-cost exceptions" which I assume means compile-time Result types without runtime unwinding overhead? That's compelling if true, since Rust's Result ergonomics can get verbose in deeply nested error chains. But the real test is compile t…

Your style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes. e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.

Rather than downvoting you, I will speak up to say I don't see what you're seeing. Spaces around hyphens, yeah, sure, but LLMs prefer em dashes, and even that is unreliable, because it's borrowed from habits that real humans have had for many years.

For me, the more important indicator is the content. I see reports of personal experience, and thoughts that are not completely explained (because the reader is expected to draw the rest of the owl). I don't see smugly over-the-top piles of adjectives filling in for an inability to make critiques of any substance. I don't see wacky asides amounting to argumentum ad lapidem, accomplishing nothing beyond insulting readers who disagree with a baseless assertion.

I think it's likely you have drawn a false positive.

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

#202

Post by pjmlp »

andsoitis wrote: post #199
pjmlp wrote: post #189

Earlier quoted context omitted.

ARC is GC, chapter 5. https://gchandbook.org/

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.

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

#203

Post by 9rx »

pjmlp wrote: post #111
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.

All are high level as long as they don't expose CPU capabilities, even ISO C is high level, unless we count in language extensions that are compiler specific, and any language can have compiler extensions.

C pointers expose CPU capabilities.

You can always emulate functionality on different architectures, though, so where is the practical line even drawn?

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

#205

Post by dkdcio »

whimsicalism wrote: post #188
yoan9224 wrote: post #181

The positioning is interesting - claiming Rust's performance with Go's simplicity is basically every new systems language's promise since 2015. The key differentiator seems to be "zero-cost exceptions" which I assume means compile-time Result types without runtime unwinding overhead? That's compelling if true, since Rust's Result ergonomics can get verbose in deeply nested error chains. But the real test is compile t…

Your style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes. e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.

A) you cannot tell B) you have said nothing productive toward discussion, you’ve just accused someone of using a tool (that you don’t know if they used)

I’d prefer actual criticism of the content. (I cannot downvote and would not if I could)

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

#206

Post by pjmlp »

9rx wrote: post #203
pjmlp wrote: post #111

Earlier quoted context omitted.

All are high level as long as they don't expose CPU capabilities, even ISO C is high level, unless we count in language extensions that are compiler specific, and any language can have compiler extensions.

C pointers expose CPU capabilities. You can always emulate functionality on different architectures, though, so where is the practical line even drawn?

C pointers are nothing special, plenty of languages expose pointers, even classical BASIC with PEEK and POKE.

The line is blurred, and doesn't help that some folks help spread the urban myth C is special somehow, only because they never bother with either the history of programming language, and specially the history of systems programming outside Bell Labs.

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

#207

Post by josephg »

9rx wrote: post #161
josephg wrote: post #36

Earlier quoted context omitted.

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

> it was annoying to program (due to a lack of enums) Typescript also lacks enums. Why wasn't it considered annoying? I mean, technically it does have an enum keyword that offers what most would consider to be enums, but that keyword behaves exactly the same as what Go offers, which you don't consider to be enums.

In typescript I typed my text editing operations like this:

    type Operation = {type: “insert”, …} | {type: “delete”, …} | …;
It’s trivial to switch based on the type field. And when you do, typescript gives you full type checking for that specific variant. It’s not as efficient at runtime as C, but it’s very clean code.

Go doesn’t have any equivalent to this. Nor does go support tagged unions - which is what I used in C. The most idiomatic approach I could think of in Go was to use interface {} and polymorphism. But that was more verbose (~50% more lines of code) and more error prone. And it’s much harder to read - instead of simply branching based on the operation type, I implemented a virtual method for all my different variants and called it. But that spread my logic all over the place.

If I did it again I’d consider just making a struct in go with the superset of all the fields across all my variants. Still ugly, but maybe it would be better than dynamic dispatch? I dunno.

I wish I still had the go code I wrote. The C, rust, swift and typescript variants are kicking around on my github somewhere. If you want a poke at the code, I can find them when I’m at my desk.

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

#208

Post by whimsicalism »

Hemospectrum wrote: post #201
whimsicalism wrote: post #188

Earlier quoted context omitted.

Your style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes. e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.

Rather than downvoting you, I will speak up to say I don't see what you're seeing. Spaces around hyphens, yeah, sure, but LLMs prefer em dashes, and even that is unreliable, because it's borrowed from habits that real humans have had for many years. For me, the more important indicator is the content. I see reports of personal experience, and thoughts that are not completely explained (because the reader is expected…

It saddens me a bit that this can't be distinguished by people on here. I encourage you to take a look at their profile and see if you are still as skeptical. Noticing em-dashes is facile and as you mention, common among human written text - but there are more subtle stylistic cues (although now that you mention it, this writer likely went out of their way to replace emdashes with hyphens).

I was raised in a family of professional writer-editors (but now am the tech-y black sheep) which might make the cues a bit more obvious to me. The degree to which this style of writing was common prior to 2022 is vastly overstated, the tells were actually not really that common.

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

#209

Post by 9rx »

pjmlp wrote: post #206
9rx wrote: post #203

Earlier quoted context omitted.

C pointers expose CPU capabilities. You can always emulate functionality on different architectures, though, so where is the practical line even drawn?

C pointers are nothing special, plenty of languages expose pointers, even classical BASIC with PEEK and POKE. The line is blurred, and doesn't help that some folks help spread the urban myth C is special somehow, only because they never bother with either the history of programming language, and specially the history of systems programming outside Bell Labs.

They're nothing special, but were designed for a particular CPU and expose the details of that CPU. And since we were talking about C specifically, not a bunch of other random languages that may have did similar things...

While most modern CPUs are designed for C and thus share in the same details, if your CPU is of a different design, you have to emulate the behaviour. Which works perfectly fine — but the question remains outstanding: Where does the practical line get drawn? Is 6502 assembler actually a high-level language too? After all, you too can treat it as an abstract machine and emulate its function on any other CPU just the same as you do with C pointers.

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

#210

Post by whimsicalism »

dkdcio wrote: post #205
whimsicalism wrote: post #188

Earlier quoted context omitted.

Your style of commenting is pretty full of LLM tells fyi. Normally don’t comment on it but this is the second such comment of yours I have read in a few minutes. e: I would be curious of the thoughts of those downvoting as personally I don’t think mostly LLM written comments are a direction we want to move towards on HN.

A) you cannot tell B) you have said nothing productive toward discussion, you’ve just accused someone of using a tool (that you don’t know if they used) I’d prefer actual criticism of the content. (I cannot downvote and would not if I could)

I am certain that they used a tool. As I said, I normally do not complain and typically engage on the merits -- but these have been among the top comments on every front page article I've read today and it gets tiresome! To me, if you cannot invest enough effort to remove the pretty obvious cues, why am I investing the effort in reading the comment?

After seeing your reply, I looked at their comment history which makes it even more obvious imo.

Post reply on HN