4 ms·

> 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'v

> 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 ago
The 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 ago
  Dunno, 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 ago
  There 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 ago
    Jeeez, I was just commenting on the scenarios from parent.
- morelisp 3y ago
  But 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.
  - tjoff 3y ago
    Agree. But the argument put forward in favor of automatic memory management is that it speeds up development. But if that is only true if you don't care about the architecture that argument doesn't hold (assuming you want a good architecture). The claim I make is that you have to think about memory, either directly or indirectly. And if you have to think about it dealing with it yourself isn't a burden, it is liberating. In in a similar sense to how a static type system is liberating. Which might sound a bit weird, until you need to refactor.
    - morelisp 3y ago
      This is still a mostly circular argument though. An architecture is "good" if it's saving resources - compute, time, or labor. If your "good" architecture is slowing down development i.e. more time more labor, you'd better be able to point to significant compute gains or it's not actually good. Rust is, only sometimes, and marginally, better than other languages in this regard. And your compute gains need to be something you can't just trade off against money for development time, i.e. it either needs to be a fundamental part of your problem, or you need to be planning for hyperscale. This is also only a small fraction of problems.
      - tjoff 3y ago
        > If your "good" architecture is slowing down development i.e. more time more labor [...] The argument is that it isn't slowing down development in the long run. Because it is a fundamental part of your architecture anyway. (And my argument has nothing to do with Rust per se)
  - marcosdumay 3y ago
    > any of those languages (and plenty of others) will work fine Well, C won't. Any large C code needs a decade or two of bug-fixing before it is safe, and that only happens if the developers are competent and wiling to fix it.
    - morelisp 3y ago

tjoff 3y ago

The 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 ago
Dunno, 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 ago
There 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 ago
  Jeeez, I was just commenting on the scenarios from parent.
morelisp 3y ago
But 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.
- tjoff 3y ago
  Agree. But the argument put forward in favor of automatic memory management is that it speeds up development. But if that is only true if you don't care about the architecture that argument doesn't hold (assuming you want a good architecture). The claim I make is that you have to think about memory, either directly or indirectly. And if you have to think about it dealing with it yourself isn't a burden, it is liberating. In in a similar sense to how a static type system is liberating. Which might sound a bit weird, until you need to refactor.
  - morelisp 3y ago
    This is still a mostly circular argument though. An architecture is "good" if it's saving resources - compute, time, or labor. If your "good" architecture is slowing down development i.e. more time more labor, you'd better be able to point to significant compute gains or it's not actually good. Rust is, only sometimes, and marginally, better than other languages in this regard. And your compute gains need to be something you can't just trade off against money for development time, i.e. it either needs to be a fundamental part of your problem, or you need to be planning for hyperscale. This is also only a small fraction of problems.
    - tjoff 3y ago
      > If your "good" architecture is slowing down development i.e. more time more labor [...] The argument is that it isn't slowing down development in the long run. Because it is a fundamental part of your architecture anyway. (And my argument has nothing to do with Rust per se)
- marcosdumay 3y ago
  > any of those languages (and plenty of others) will work fine Well, C won't. Any large C code needs a decade or two of bug-fixing before it is safe, and that only happens if the developers are competent and wiling to fix it.
  - morelisp 3y ago