Hacker news is not a representative subset of humanity. So you are restricting your range of understanding. Maybe that's necessary for mental health, (it is for me) but the tradeoff isn't great either.
No reliably reachable subset is representative of humanity.
But I also want to argue against the range of understanding argument. Attention has a limit. Anyone who wants develop a deep understanding for any topic would do themselves a disfavor by trying to expand their range aimlessly.
We can't all know everything all at once, so we should just develop some common sense for the most important topics instead. Like "people generally good and against violence". We used to have that once, we can rebuild it now.
In my mind this is what prototyping is for. Just get it working quickly and see if the concept has legs. But be prepared to completely re-write it because the "just make it work" mindset will make it more difficult to change and improve upon in the future.
But when you factor in today's favorite business model of "make it shitty", perhaps this matters very little.
Yes it is nauseating. And it's the norm. Whenever some company finds a way to make a boat-load of money by exploiting a weakness of human nature, the government will demand a portion of the proceeds. It's business as usual, in the USA at least. Even more nauseating is what they could do with that $2.5B...
Maybe they could use this DDoS attack as their 17th round technical interview. Any candidate who successfully mitigates the attack would then make it to the 18th round. Win win!
I got all the way to round 53, but it turned out that one of my semiaquatic tetrapod ancestors from the Carboniferous Period didn't perform on land as well as they would have liked, so that was it for me.
Is their interview process Dungeon Crawler Carl? Do you just apply to work at Canonical, and at the 3rd interview you get to pick what position you're applying for?
I was curious about this so I looked around a bit. My interpretation is that GrapheneOS still has not cracked this nut. Neither has iPhone, unless you enable "Lockdown Mode"
I really like rust because it does NOT have garbage collection. Can someone smarter than me help me understand the benefits of having GC in rust specifically? Does it enable things that are more difficult in "non GC" rust?
To give one trivial example, if you want to write an interpreter for a garbage-collected language in Rust, you need some kind of garbage-collection facility. You could in theory do it C-style by just using raw mostly-untyped pointers everywhere, but this defeats most of the benefit of Rust over C, so you might instead prefer to encapsulate the GC into its own library, so that you can use regular Rust idioms in all the parts of the code that aren't specifically about GC.
More generally, there are various situations where garbage collection is effectively a requirement: namely, when you've got a mutable graph where anything can point to anything else, where some nodes are root nodes and others are not, and so it's possible for cycles of unreachable nodes to occur and you don't want this to result in memory leaks.
You could in theory imagine a language like Rust where garbage collection was integrated more deeply on a syntactic level, such that you might sometimes use it for convenience and not just where it's a requirement (and Rust in fact worked like this for a while pre-1.0), but the way things currently work, integrating a garbage-collection library basically always makes your code more unwieldy and you only do it if you have to.
I've never really had the urge to use GC in Rust, but if I were to speculate, I'd say easier cyclic references would be one benefit. And depending on the specific GC implementation, you can probably get around many of Rust's ownership rules because Gc<T> pointers are usually `Copy`, so you can pass things around everywhere and not think about references/ownership as much.
Okay I could see that - like implementing linked lists would be easier yeah?
I just feel like not having GC is sort of a deliberate, core design choice for the language. Having strict ownership rules and being forced to think about references feels like a feature not a bug you know? Adding GC feels analogous to the "++" in C++ to me.
Not that I have anything against the efforts people are putting into it though - I'm genuinely curious about what it lets me do better/faster within rust.
GC is a similar but different set of strict ownership rules (and its own versions of being forced to think about reference invariants). There's an inherently interesting Venn Diagram overlap between Rust borrow mechanics and GC, they aren't entirely separate worlds. They are more like related worlds with slightly different trade-offs. (Similarly there's C# and .NET actively exploring GC-safe relatives of Rust's borrow mechanics in Memory<T>/Span<T> space right now, to great effect.)
In terms of practical, yeah a doubly linked list (or trees with bidirectional pointers to both parent and children, etc) is especially easier to implement in a GC environment than with Rust borrow checking alone. You can do it without a GC, but a GC can be a helpful intermediary.
I agree completely; I think choosing Rust and then adding a GC is a weird design choice. If I was in a situation where I really, truly needed GC for my memory management, I wouldn't use Rust.
Why do you like managing your own memory exactly? Modern GCs are quite good, so the domain in which you can beat their performance is narrow and will continue getting narrower as time goes on.
The software performance gap between modern GC code and non-GC code is still pretty large almost everywhere. GCs make entire classes of optimization effectively impossible. At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code.
GCs are useful in the same way that Python is useful even though it is slow. Simplicity of use has intrinsic value but that is a tradeoff against other objectives.
I agree that GC code can be and usually is slower. But as a counterpoint: allocation can be very slow. Bump allocation is fast. If you know your lifetimes and can free all of your bump-allocated memory in one go, that's pretty much the best you can do. If not, then you can still bump-allocate, but copy away the live stuff while discarding the rest. You keep bump allocation, you may even improve locality by eliminating the fragmentation in your bump allocation arena. On the other hand, you've written a garbage collector and thus inherit the disadvantages of GC.
My point is that you can start out without a GC and do a series of sane and effective optimizations that end you up with a GC. Just as you can start with a GC and optimize by moving more and more of your allocations to non-GC memory and end up without a GC. Which endpoint is faster depends on the workload.
> At the limit, GCs are an abstraction that is always going to make worse runtime choices than purpose-built code.
You can say the same about any abstraction, such as having a generic memory allocator, using a standard library, actually about any code reuse. For example, many programs use printf, but don’t need all its features, so hand-rolling a custom version may lead to smaller, faster code (things get complicated here on systems with shared libraries)
The question always is whether lost performance (execution time, memory usage) is worth faster development.
I guess I like the idea of having to think a little more deeply about how memory is used while I'm programming. I know that might sound a bit odd, but before I started learning and using rust, I remember being much less aware of certain things while programming, and then discovering much later that I did something very sub-optimally. So rust is kind of a forcing function in a way - it makes me write better code.
I have also worked on projects (web apps) where GC pauses became annoying to end-users. I wouldn't say this is the fault of GC perse, but writing code without a GC, seems to prevent some performance problems for me, and can also make performance problems stand out sooner in the dev cycle.
Many modern GC languages and runtimes have benefited greatly from improved escape analysis, which identifies memory allocations that have short, identifiable lifetimes, and removes those from the GC-managed heap entirely.
Of course, many GCs have indeed gotten better in their own right, but not using the GC at all remains the most potent optimization.
reply