Permanently Deleted
The bread lines were caused by being under blockade by a superpower nextdoor for 70 years.
Were you under the impression they were caused by Cuba being too democratic?
Again, they’re not a success then.
Your definition of success is that the US government approves of your political system?!
To be fair to Archimedes, heavy objects do usually fall faster than light ones*, and to be fair to Newton, stuff coming towards you usually has a higher relative velocity than things going away from you.+
*You need your objects to be weigh a lot relative to their air resistance to notice otherwise.
+You need some pretty ambitious equipment to detect that electromagnetic radiation such as light does not follow this pattern.
Brilliant, brilliant film.
*couldn't care less.
This means they are at the bottom of the care barrel and that thing is dry.
Compare "couldn't have any less money" with "could have less money".
Afaik, python does both (regular) garbage collection and reference counting. But that's not why Python is much slower. Python is much slower because it's interpreted rather than compiled. Like Java, bytecode is interpreted at runtime. Your jit won't beat compiled haskell, c or rust in most cases. It's good because it's based on real profiling of your actual running code, which not every hand rolled premature optimisation is, but it's limited. I don't see the spineless tagless G machine (or whatever the geniuses in Glasgow have come up with these days for ghc's runtime under the hood), as an interpreter, and haskell compiles the whole thing down to native machine code anyway. Machine code is just faster unless you've made some asymptotic error.
I don't think rust is old, and I'm not trying to tear it down. I'm saying that you can have in place mutation, free on leaving scope, no garbage collection but yet no linear (affine) type system and hence no cumbersome terminology and notation. You can just write lovely functional code and it's all compiled very well.
Roc is like Haskell without the monad transformer stack, just one do-everything monad for each application domain (so no one needs to know what a monad is), partial application but you get to specify which argument is to be filled (not just the final one), and you don't need to know whether you wanted =#~ or &+~ to change something in your nested data structure. (I always found lens to give the most unhelpful errors ever.) Add super fast compilation (seconds, not minutes, even the first time) and genuinely helpful error messages (you know what I mean if you've used elm much).
Well if you're calling any form of automatic memory management garbage collection, then it's only C that doesn't have garbage collection.
Rust does have explicit reference counting with Rc
<T>
and Arc<T>
.I'm trying to explain to you that static analysis that limits references to one can be done in a similar way without the limit of one (especially with the assumption of immutability) whilst retaining in-place mutation where the count really is one. It upsets you when I try to explain that it's a generalisation of the borrow checker (without the programmer pain) by calling the borrow checker a static (compile time) reference counter with a limit of one. I'm making a comparison. But don't be surprised if a lot of programming languages implement their boolean variables as an unsigned int with a maximum of one.
If roc does the equivalent of putting a call to drop where there were two or three references that fell out of scope rather than one, in what sense is that more overhead than rust calling drop when one reference went out of scope? Rust is still "garbage collecting" the references that turned up on the RHS of assignment statements as it goes along.
The overhead we're talking about with reference counting is like DEC r BRZ. It's like array bounds checking. Yes, it's an overhead, but no, it's not worth making a big deal about it if you get to allocate arrays of sizes unknown at compile time or you get to make multiple references without messing with keywords and reference symbols, fighting the borrow checker all day long or manually adding clones.
It says some overheads. It’s different overheads,
What? Overheads are overheads. Either they're small and useful like roc's reference counting when it turns out to need to be at runtime or array bounds checking, or rust calling drop when some variable falls out of scope, or they're big, stop the main thread at random points and take a long time, like garbage collection in garbage collected languages like java.
Why say more if it’s ignored anyway?
I know - I wrote a whole bunch of stuff and this other person just ignored every single nuance and explanation and kept saying the same thing again and again without trying to understand a new thing they didn't know about before, just repeating their favourite criticisms of other programming languages whether they applied or not. Oh wait, that was you.
I don’t think I’m the zealot here.
Interesting.
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".
I think that roc and rust are both aiming for fast memory safety, but rust is aiming to be best at mutable data and rpc best at immutable data.
I heard of someone trying to do exactly that - immutable functional programming in roc, but they gave up for the same reason you said - the whole ecosystem is working on the opposite assumption.
As far as I'm aware most of the roc platforms are currently written in rust or zig. Application-specific code is written in roc calling interface/io/effectful functions/api that the platform exposes and the platform calls into the roc code via the required interface.
I do think it's really interesting, and once they have a desktop gui app platform (which must compile for windows for me to be able to use it for work), I'll be giving it a good go. I think it's one of the most interesting new languages to arrive.
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.
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.
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.
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.
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.
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.
It's a post rust language.
By your definition any automatic memory management is garbage collection, including rust!
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?
In roc, because the platform is in charge of memory management, it can optimise, so that a web server can allocate an arena for each client, a game loop can calculate what it needs in advance etc etc.
But like I say, they do a lot of work on avoiding cache misses and branch mispredictions, which are their own source of "stop the world while I page in from main memory" or "stop the pipeline while I build a new one". If it was doing traditional garbage collection, that would be an utterly pointless microoptimisation.
Rust isn't a religion. Don't treat it like one.
When it was very new a bunch of C programmers shit on its ideas and said C was the only real systems programming language, but rust, which was pretty much Linear ML dressed up in C style syntax came from hyper weird functional programming language to trusted systems programming language. Why? Because it does memory management sooooo much better than C and is just about as fast. Guess what roc is doing? Memory management soooooo much better than C, and sooooo much less niggly and hard to get right than the borrow checker and is just about as fast.
Plenty of beginners program in rust by just throwing clone at every error the borrow checker sends them, or even unsafe! Bye bye advantages of rust, because it was hard to please. Roc calculates from your code whether it needs to clone (eg once for a reference to an unmodified value, each time for an initial value for the points in a new data structure), and like rust, frees memory when it's not being used.
Rust does manual cloning. Roc does calculated cloning. Rust wins over C for memory safety by calculating when to free rather than using manual free, totally eliminating a whole class of bugs. Roc could win over rust by calculating when to clone, eliminating a whole class of unnecessary allocation and deallocation. Don't be so sure that no one could do better than rust. And the devXP in rust is really poor.
Sunk cost fallacy.
I think it's only the state charges. Feds are yet to have their turn.
I never understood why they were putting the internet on fridges and microwaves etc.
Now I understand.