3 ms·

Why would one prefer a language with a GC? Iced is a great library if you are willing to put in the effort to learn it (as it's new and documentation is still

Why would one prefer a language with a GC? Iced is a great library if you are willing to put in the effort to learn it (as it's new and documentation is still mostly limited to examples)

amelius 2y ago
> Why would one prefer a language with a GC? One thing less to worry about.
- throwadobe 2y ago
  Everything is a tradeoff. Iced is blazing fast, with a low memory footprint (~30MB binary), cross platform, extensible and pretty elegant if a bit challenging to learn.
  - amelius 2y ago
    Your job is to make your users happy. If you spend 2x the amount of time to build a blazing fast UI compared to a normal speed UI, then the question is if you maybe had better spent the time on things your users wanted, like features. Features are not everything, but code that is faster than necessary (or has lower memory footprint) just doesn't bring much to the table from the user's perspective, especially for UI programs. If you were writing an OS kernel or a browser, then maybe (probably even) Rust is a better choice.
    - TazeTSchnitzel 2y ago
      For audio software like this, using a GC-free language translates into reliable, stutter-free, low-latency playback, particularly on lower-power devices. A lot of JavaScript-based audio things I've tried, even really simple ones, become miserable experiences once GC pauses start consuming a lot of CPU. I think it's no surprise that GC'd languages are unpopular for audio applications!
      - amelius 2y ago
        But then you should also run it on a realtime OS.
        TazeTSchnitzel 2y ago
        No, why would you? Normal OSes are pretty good at doing reliable audio playback and recording, musicians wouldn't use them otherwise. They don't guarantee five-nines but who cares. They are unlikely to ruin your audio experience.
    - alt227 2y ago
      > the question is if you maybe had better spent the time on things your users wanted, like features. That question is for the author of the software alone to decide how they want to build their own software.
    - throwadobe 2y ago
      Yeah? Well, you know, that's just like uh, your opinion, man.
      - amelius 2y ago
        You just said that everything is a trade-off yourself ...

Why would one prefer a language with a GC? Iced is a great library if you are willing to put in the effort to learn it (as it's new and documentation is still mostly limited to examples)

amelius 2y ago

> Why would one prefer a language with a GC? One thing less to worry about.

throwadobe 2y ago
Everything is a tradeoff. Iced is blazing fast, with a low memory footprint (~30MB binary), cross platform, extensible and pretty elegant if a bit challenging to learn.
- amelius 2y ago
  Your job is to make your users happy. If you spend 2x the amount of time to build a blazing fast UI compared to a normal speed UI, then the question is if you maybe had better spent the time on things your users wanted, like features. Features are not everything, but code that is faster than necessary (or has lower memory footprint) just doesn't bring much to the table from the user's perspective, especially for UI programs. If you were writing an OS kernel or a browser, then maybe (probably even) Rust is a better choice.
  - TazeTSchnitzel 2y ago
    For audio software like this, using a GC-free language translates into reliable, stutter-free, low-latency playback, particularly on lower-power devices. A lot of JavaScript-based audio things I've tried, even really simple ones, become miserable experiences once GC pauses start consuming a lot of CPU. I think it's no surprise that GC'd languages are unpopular for audio applications!
    - amelius 2y ago
      But then you should also run it on a realtime OS.
      - TazeTSchnitzel 2y ago
        No, why would you? Normal OSes are pretty good at doing reliable audio playback and recording, musicians wouldn't use them otherwise. They don't guarantee five-nines but who cares. They are unlikely to ruin your audio experience.
  - alt227 2y ago
    > the question is if you maybe had better spent the time on things your users wanted, like features. That question is for the author of the software alone to decide how they want to build their own software.
  - throwadobe 2y ago
    Yeah? Well, you know, that's just like uh, your opinion, man.
    - amelius 2y ago
      You just said that everything is a trade-off yourself ...