Hacker News Reader

Comment by arcticbull | Hacker News Reader

Sometimes, until you can't, then you have a really bad time.

For instance:

- You shouldn't rely on finalizers to manage resources due to the lack of determinism. No compiler support to help you through that.

- Similarly, when the magic blob GC starts acting up, how do you solve that?

- What about memory usage being orders of magnitude higher in a GC'd system?

It's just different problems. To an extent the line where you have to care is much closer in Rust than Java, but in Java, when you cross the line, good luck. Rust forcing you to be expressive from the get-go pays dividends down the line, allowing you to be relatively more productive, later.

I guess it's like skiing vs. snowboarding. Skiing is easy to get going, but really difficult to get good at. Snowboarding is really hard to get started, but once you do, it's relatively much easier to be great at it.

View on HN

If you don't do embedded programming (where you shouldn't do dynamic memory allocation anyway, being that with or without a GC) memory is often not a constraint at all. And in a lot of situation it cost you less to increase the RAM (if you can) than optimizing the code.

> when you cross the line, good luck

And if you never cross the line? You wasted thousands of dollars for developing something in Rust that you could have written in Python in 1/4 of the time and be fine.

To me the job of the programmer is not to reason about memory. The job of the programmer is to reason about algorithms, data structures, and thus a language that abstracts the memory management is better if you can afford it. It has a cost, sure like it has a cost using C instead of assembly.

One thing that gets lost in these discussions is, a GC only helps with memory. Rust's ownership system (and to some degree, RAII & friends in C++) let you manage arbitrary resources here. There's a lot more than just memory going on.

I think you misunderstood, if you run into memory pressure issues in Java you need to spend tons of time tweaking and optimizing your specific garbage collector by poking the black box and hoping.

Of course in certain circumstances where it really doesn't matter you get your choice of languages.

> To me the job of the programmer is not to reason about memory.

The job of a programmer is to describe what needs to happen to a set of inputs to yield a set of outputs, and there are many different ways to do so. Sometimes you do need to describe the relationships between data. Rust attempts to leverage your description of the transformation and relationships to make memory management something you don't have to worry about either.

There are limits, of course, and sometimes you need to help it out, however this amounts to improving or clarifying the description of your system. On the other hand resolving garbage collection issues often involves making surprising and seemingly irrelevant changes to your system that happen to influence via spooky action at a distance the behavior of an unrelated component of the system. And if you remove them it all falls apart again.

To borrow a turn of phrase, it has a cost, sure like it has a cost using C instead of assembly.

> memory is often not a constraint at all

This type of thought process is how we get Electron applications and when several of them are running at the same time they can bring your OS to a crawl by having consumed every bit of memory available for some simple GUIs. Memory absolutely always matters.

Also the people who I see saying memory doesn't matter are usually developers who are running on 32GB+ work stations. They forget about the user still running with 4GB or 8GB of memory.

As much as I hate electron I'm still waiting for an equivalent, low memory native GUI toolkit that has an equally low barrier to entry.

Reply on news.ycombinator.com