12 ms·
Maybe for prototypes or small scripts but disagree otherwise. The promise of automatic memory management is that you don't have to think about memory. But the
by tjoff 3y ago
Maybe for prototypes or small scripts but disagree otherwise. The promise of automatic memory management is that you don't have to think about memory.
But the second you don't think about memory you are doomed to write bad code anyway. Maybe because of performance but most probably due to architecture. To have a language that forces you to think about memory is not a curse, it is a blessing.
- pjmlp 3y agoWell, I also disagree. Just because a language has some form of automatic memory management, that doesn't mean it doesn't provide the same mechanisms of a language like C for low-level programming. Plenty of options, D, Go, Swift, C#, Nim, Eiffel, Common Lisp, Haskell, OCaml,.... Dead options that unfortunely didn't manage to win market adoption, Oberon, Oberon-2, Active Oberon, Component Pascal, Modula-2+, Modula-3, Cedar, Speaking of Cedar, when will Rust managed to have a full workstation OS? "Eric Bier Demonstrates Cedar" https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 Redox still has a bit to catch with what a full graphical workstation OS was capable of in 1980's hardware, using a systems programming language with automatic memory management. Naturally, there are other examples out from Xerox PARC, Genera and Texas Instruments on that regard.
- tjoff 3y agoI wasn't talking about low level programming? High level programming also benefits from manual memory management.
- pjmlp 3y agoGreat that D, Go, Swift, C#, Nim, Eiffel, Common Lisp, Haskell, OCaml,.... also offer ways of doing it.
- tjoff 3y agoYou don't seem to care but you are missing the point.
- pjmlp 3y agoNope, you're the one missing the point, just because a language has some kind of automatic memory management, it doesn't mean C like features for deterministic manual memory management, or any other kind of manual resource management aren't available. Learn to use them, and then you'll get the point.
- tjoff 3y ago? I didn't claim that.
- morelisp 3y ago> But the second you don't think about memory you are doomed to write bad code anyway. Yeah but the failure modes are different. "Doomed" in C++ means now I've got worms all over my network. Pretty much a fully negative outcome. "Doomed" in Rust means I can't change it anymore until I relearn and refactor everything. If it's a pacemaker or rocket engine, that's probably ideal. But if it's not... "Doomed" in Go or Java means I gotta cough up another few GB of RAM and maybe kick over the service every month. For some random middleware, that's fine.
- tjoff 3y agoThe promise with a good architecture is that the doom part is more infrequent though. And that when the Go/Java doom scenario bites you you'll have a whole lot of technical debt to pay back.
- lenkite 3y agoDunno, tech debt is pretty easy to solve in Go/Java (easier in Java) as long as you dedicate some time to it. Excellent refactoring, code-coverage and instrumentation and profiling tools.
- pjmlp 3y agoThere are more languages to chose from with automatic memory management than Go and Java. Chose the one that provides the right set of tools for high performance code.
- tjoff 3y agoJeeez, I was just commenting on the scenarios from parent.
- morelisp 3y agoBut you're arguing in circles. If attention is paid, if the architecture is good, all else like programmer salary/skill being equal, any of those languages (and plenty of others) will work fine. (And honestly, not a huge difference in the work to achieve that, a good design will look about the same in all four.) It's only an interesting question which to use if attention is not paid, or you don't want to invest enough to ensure attention will be paid; in which case you need to look at the causes and effects of that.