3 ms·

> I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and sof

> I do have a hard time to think of use cases other than embedded microcontroller work where that matters nowadays. People keep saying things like this and software keeps getting more bloated and shittier. It is difficult to believe there isn't a correlation.

mr_00ff00 4y ago
I might be misreading this comment, but the answer to bloated software is not writing all of it in rust/C++/zig. The reasons for bloat is not garage collection.
- AnIdiotOnTheNet 4y ago
  It is not about the minutiae of language choices no, it's about a pervasive programmer mindset of not wanting to think about resources like memory of clock cycles or bandwidth as things that actually matter.
  - titzer 4y ago
    A lot of it is that APIs, particularly for GC'd languages, often require lots of intermediate garbage and defensive copies. It wasn't until Java 17 that there was a standard way of parsing integers that didn't allocate. I blame libraries more than languages, TBH.
    - kaba0 4y ago
      Sure, I am just confirming that mindset, but can you really reason about the performance impact of that allocation? Even if it does end up allocating due to escape analysis not being sufficient, it will do a thread local pointer bump allocation on a hot, in-cache arena basically, and will just be zero-cost cleared once the still achievable objects are moved. My point is, knowing when to think/not think about allocating and its relevant costs is the proper way to program in a high level language. Only care about it when you are at a part that runs in a hot loop or very often, etc. Pretty much as per the second part of the often partially quoted “premature optimization…”.
wyldfire 4y ago
I think as hardware and software have matured, more and more people have access to develop software. They get correct results without having to dictate every little item. I think it's great, personally. I don't know if it's necessarily "bloat" because it's probably a net win that we wouldn't get some of this software otherwise. The really awesome news is that for those of us who still develop software whose requirements mandate this kind of control - better tools like Zig (and Rust) are making things easier but without requiring things like a GC.
cmrdporcupine 4y ago
The issue is not always garbage collection. The issue is, as others have pointed out, not having to think about it (memory & cycles.) But this also ties very much into another thing about many modern applications: excessive reliance on third-party packages, many of which are written with (or without) constraints and features that aren't always a match for the core application. It's very easy to blow out your memory use and runtime costs this way. And in this respect Rust could be vulnerable, because Cargo.toml makes it way-easy to pull in a huge tree of transitive third party dependencies without even thinking about it.

mr_00ff00 4y ago

I might be misreading this comment, but the answer to bloated software is not writing all of it in rust/C++/zig. The reasons for bloat is not garage collection.

AnIdiotOnTheNet 4y ago
It is not about the minutiae of language choices no, it's about a pervasive programmer mindset of not wanting to think about resources like memory of clock cycles or bandwidth as things that actually matter.
- titzer 4y ago
  A lot of it is that APIs, particularly for GC'd languages, often require lots of intermediate garbage and defensive copies. It wasn't until Java 17 that there was a standard way of parsing integers that didn't allocate. I blame libraries more than languages, TBH.
  - kaba0 4y ago
    Sure, I am just confirming that mindset, but can you really reason about the performance impact of that allocation? Even if it does end up allocating due to escape analysis not being sufficient, it will do a thread local pointer bump allocation on a hot, in-cache arena basically, and will just be zero-cost cleared once the still achievable objects are moved. My point is, knowing when to think/not think about allocating and its relevant costs is the proper way to program in a high level language. Only care about it when you are at a part that runs in a hot loop or very often, etc. Pretty much as per the second part of the often partially quoted “premature optimization…”.

wyldfire 4y ago

I think as hardware and software have matured, more and more people have access to develop software. They get correct results without having to dictate every little item. I think it's great, personally. I don't know if it's necessarily "bloat" because it's probably a net win that we wouldn't get some of this software otherwise. The really awesome news is that for those of us who still develop software whose requirements mandate this kind of control - better tools like Zig (and Rust) are making things easier but without requiring things like a GC.

cmrdporcupine 4y ago

The issue is not always garbage collection. The issue is, as others have pointed out, not having to think about it (memory & cycles.) But this also ties very much into another thing about many modern applications: excessive reliance on third-party packages, many of which are written with (or without) constraints and features that aren't always a match for the core application. It's very easy to blow out your memory use and runtime costs this way. And in this respect Rust could be vulnerable, because Cargo.toml makes it way-easy to pull in a huge tree of transitive third party dependencies without even thinking about it.