LLVM

[email protected]

It's not as simple as that.

Roc does static reference counting too, otherwise it wouldn't be able to do opportunistic in place mutation. It can do static reference counting up to a known compile time bound, whereas rust can only count to one. Both of them can do runtime reference counting, but it's implicit in roc and explicit with Rc and Arc in rust.

For example, consider the pseudocode
{
h = "Hello, "
hw = h + "world."
hm = h + "Mum!"
}

In real life, this could be something less swervable.

Roc counts, at compile time, 1,2,3,0, drop. No problem.

Depending on how you declare these variables (with what additional keywords, symbols, string types and concepts), rust counts, at compile time, 1,release,1,2! No no no stop broken! Bad programmer! This was in this case an unnecessary premature optimisation. That's what I mean by rust counts references, but only counts up to 1.

The borrow checker is a static reference counter with an arbitrary number of immutable references that you must declare explicitly and a maximum of one mutable reference that you declare explicitly with mut or let under different circumstances. Arc and Rc are runtime reference counters that you declare explicitly. This is essentially all tracked in the type system.

Roc does the static reference counting and if the total doesn't rise above rust's maximum of 1, uses in place mutation (as opposed to the default immutability). If it is bounded it can use static (compile time) reference counting so that when, for example, all four local references fall out of scope, the memory is dropped. If the number is unbounded (eg parameter passing recursion that can't be tail-cpseudocode ilarly removed), runtime reference counting is used. This is all essentially tracked in the runtime system, but calls to clone are automated in roc. A beginner absolutely can write a memory hog in roc, but the same beginner is likely to overuse clone in rust and write a similar memory hog.

[email protected]

runtime check. Which in turn results in a runtime performance.

If you're calling drop on a mutable string that's been extended repeatedly, you're recursively dropping all kinds of mess all over the heap. Checking for zero beforehand has an insignificant impact. Those cache misses you had because rust pays less attention to "where" than it does to "whether", they cost you a lot more than the reference count check. In the real world, in practice, under profiling of real code, the cache misses and the branch misses are more expensive than the reference counting.

You sound a little bit like a C programmer who claims his code is fast because his arrays don't do bounds checking. That's not why C is fast. Similarly rust isn't fast because it never does runtime reference counting. It does sometimes, but that code isn't pathologically slow.

Also, rust isn't just fast because of the borrow checker, primarily it's memory safe because of the borrow checker.

If it's any consolation, afaik, most of the roc platforms are written in rust. Also afaik only application specific code is written in roc. There are no memory management primitives in roc code unless a platform author exposes them in their api/interface, and I don't think anyone is working on implementing C on top of roc.

[email protected]

I don't know what you read on my reply. But your reply makes no sense.

Let me rephrase it if you prefer:

Claiming that Rusty's borrow checker is reference counting is hugely misleading. Since the borrow checker was made specifically to prevent the runtime cost of garbage collection and reference counting while still being safe.

To anyone unaware, it may read as "rust uses reference counting to avoid reference counting, but they just call it borrow checking". Which is objectively false, since rust's solution doesn't require counting references at runtime.

I don't know what mutable string or any of the other rant has to do with reference counting. Looks like you're just looking to catch a "rust evangelist" in some kind of trap. Without even reading what I said.

[email protected]

I'll make my own LLVM, with blackjack and hookers.

[email protected]

I don't know whatever that language is doing is called, but it's not reference counting. It's doing some kind of static code analysis, and then it falls back to reference counting.

If you call that reference counting, what stops you from calling garbage collectors reference counting too? They certainly count references! Is the stack a reference count too? It keeps track of all the data in a stack frame, some of it might be references!

[email protected]

Thanks, this looks really interesting. I've thought for a while that Rust's borrow checker wouldn't be such a pain in the ass if the APIs were developed with immutable data in mind. It's not something you can easily slap on, because the whole ecosystem fights against it. Looks like Roc is taking that idea and running with it.

[email protected]

Garbage collection is analyzing the heap and figuring out what can be collected. Reference counting requires the code to increment or decrement a counter and frees memory when the counter hits zero. They’re fundamentally different approaches. Also reference counting isn’t necessarily automatic, Objective-C had manual reference counting since day one.

[email protected]

TinyGo isn’t that much slower and it uses LLVM

[email protected]

I guess I should have put a /s but I thought it was pretty obvious. The 68 in Algol 68 is 1968. COBOL is from 1959. Modula-2 is from 1977.

My point exactly was that all the hot new languages are built with LLVM while the “new” language options on GCC are languages from the 50’s, 60’s, and 70’s.

I am not even exaggerating. That is just what the projects look like right now.

[email protected]

I have built single pass compilers that do everything in one shot without an AST. You are not going to get great error messages or optimization though.

[email protected]

If Algol68 is from 1968, shouldn't Modula-2 be from 1898?

[email protected]

It's still mentioned as one of the main approaches to garbage collection in the garbage collection Wikipedia article.

[email protected]

Did you think rust doesn’t free up memory for you? That would be the biggest memory leak in history! No! Rust does reference counting, it just makes sure that that number is always one! What did you think the borrow checker was for?

There is no runtime garbage collection in Rust. Given a legal program, it can detect where free-type instructions are needed at compile time, and adds them. From there on it works like C, but with no memory leaks or errors because machines are good at being exactly correct. If you want to say that's just a reference counting algorithm that's so simple it's not there, sure, I guess you can do that.

Roc has runtime overhead to do garbage collection, it says so right on their own page. It might be a post-Rust language but this feels like the same conversation I've had about D and... I can't even remember now. Maybe Roc is a cool, innovative language. It's new to me. But, it doesn't sound like it's doing anything fundamentally new on that specific part.

Edit: Reading your follow up to the other person, it sounds like it has both a Rust-style compile time algorithm of some sort, and then (reference count-based) garbage collection at run time for parts of the program that would just be illegal in Rust.

[email protected]

Yeah, it might be better, I don't actually know. It's not as novel as OP maybe thinks it is, though.

[email protected]

"Garbage collection" is ambiguous, actually; reference counting is traditionally considered a kind of "garbage collection". The type you're thinking of is called "tracing garbage collection," but the term "garbage collection" is often used to specifically mean "tracing garbage collection."

[email protected]

That's fair; Python, Swift, and most Lisps all use or have previously used reference-counting. But the quoted sentence isn't wrong, since it said no "garbage collection pauses" rather than "garbage collection."

[email protected]

Roc has runtime overhead to do garbage collection, it says so right on their own page.

I was sceptical about your assertion because the language authors made a design decision not do do garbage collection. So I did a google search for garbage on roc-lang.org to try and find evidence of your claim. It doesn't say it does garbage collection. It does say overhead, but you're talking about it like it's a big slow thing that takes up time and makes thread pauses, but it's a small thing like array bounds checking. You do believe in array bounds checking, don't you?

So no, that's not what it says and you're using the phrase garbage collection to mean a much wider class of things than is merited. Garbage collection involves searching the heap for data which has fallen out of scope and freeing that memory up. It's slow and it necessitates pausing the main thread, causing unpredictably long delays. Roc does not do this.

Here's what the website actually says on the topic.

https://www.roc-lang.org/fast

Roc is a memory-safe language with automatic memory management. Automatic memory management has some unavoidable runtime overhead, and memory safety based on static analysis rules out certain performance optimizations—which is why unsafe Rust can outperform safe Rust. This gives Roc a lower performance ceiling than languages which support memory unsafety and manual memory management, such as C, C++, Zig, and Rust.

Just in case you missed it, that was unsafe rust that lacks the overheads. If you're advocating for using unsafe to gain a tiny performance benefit, you may as well be writing C, or zig, which at least has some tools to cope with all that stuff.

https://www.roc-lang.org/fast

When benchmarking compiled Roc programs, the goal is to have them normally outperform the fastest mainstream garbage-collected languages (for example, Go, C#, Java, and JavaScript)

Just in case you missed it, roc is not in the list of garbage collected languages.

https://www.roc-lang.org/platforms

The bigger benefit is tailoring memory management itself based on the domain. For example, nea is a work-in-progress Web server which performs arena allocation on each request handler. In Roc terms, this means the host's implementation of malloc can allocate into the current handler's arena, and free can be a no-op. Instead, the arena can be reset when the response has been sent.

In this design, heap allocations in a Web server running on nea are about as cheap as stack allocations, and deallocations are essentially free. This is much better for the server's throughput, latency, and predictability than (for example) having to pay for periodic garbage collection!

Summary: roc doesn't have the performance disadvantages of garbage collected languages because it's not a garbage collected language.

[email protected]

Garbage collection is pausing the main thread while you go searching the heap for memory to free up. It's slow and unpredictable about when it'll happen or how long it'll take. That's a very different process indeed and roc doesn't do it.

Whether you call it static reference counting or not, when roc chooses in-place mutation it's because it would have satisfied the borrow checker. It can do a wider class of such things when stuff goes out of scope. There's a webserver platform that does arena allocation, often swerving cache misses as a result, but crucially frees the entire arena in one step. Freeing up all the tiny little bits of memory for lots of individual stuff as you go along as rust would do would be far slower.

Calling that kind of thing garbage collection is I think very misleading indeed.

Optimising your memory management for each problem domain/platform actually give you memory management efficiencies.

[email protected]

A boolean is a non-negative integer with a maximum of one, often literally, but I see that calling the borrow checker a static reference counter with a maximum of one is frustrating you in the same way that you calling roc's reference counting a garbage collector is frustrating me.

The string example is because the thing you're calling runtime overhead is cheap compared to freeing up a string that's been extended even just a couple of times. It's not a trap. It's an example where freeing the string itself could be considerably more expensive than the DEC c and BRZ that you're calling overhead.

It's a bit hypocritical to tell me off for not reading what you said when you haven't bothered to figure out the relevance of the memory management examples I gave and just dismissed them out of hand as "rant" and a "trap".

[email protected]

Yes, I read or interpreted that wrong at first.

agnos.is Forums

LLVM