> because they don't understand memory management. How is memory going to be managed in Dark? If it's GC'd, how is that implemented?
That's one more thing you can afford to not understand and still be productive.
That's one more thing you can afford to not understand and still be productive.
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.
> 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.
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.
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.