4 ms·

Sure but my use cases would be stuff I'd normally write in TypeScript or Python that already have garbage collection. Like I said I'm not doing embedded program

Sure but my use cases would be stuff I'd normally write in TypeScript or Python that already have garbage collection. Like I said I'm not doing embedded programming so I don't have too much of a need to manage memory. My question could be further constrained then to be, is learning Rust or Zig despite its manual memory management worth it for applications that are normally already garbage collected in their current implementations? Or are languages like Nim and Crystal enough? Does Rust and Zig have other benefits despite manual memory management?

adgjlsfhk1 5y ago
imo, most code can do just fine with GC. modern GCs can be relatively low overhead even with guaranteed small pauses (10ms). furthermore, most code that can't handle pauses can be written to not allocate any memory (so GC can be temporarily turned off). as such, the only two places where you need manual allocation are for OS development, and hard real time requirements.
- Comevius 5y ago
  When tail latency (high-percentile latency) is important GC is not a good choice. Wait-free (threads progress independently) concurrent algorithms also need wait-free memory reclamation with bounded memory usage to be able to guarantee progress. But most software are throughput-oriented.
  - pjmlp 5y ago
    Additionally, not all GCs are made alike, and languages like D, F#, C#, Nim, Swift, among others, also offer value types and manual memory management, if desired.
    - elcritch 5y ago
      Also Swift and Nim w/ ARC use reference counting, which generally give much better latency and lower memory overhead. Reference counting is part of the reason iOS devices don’t need as much RAM. Nim’s ARC system also doesn’t use atomic or locks which means it’s runtime overhead is very low. I use it successfully on embedded devices for microsecond timed events with no large tail latencies.
      - pjmlp 5y ago
        Reference counting is a GC algorithm. I wouldn't buy into much Apple marketing regarding its performance though, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages It makes sense in the context of tracing GC having been a failure in Objective-C due to its C semantics, while automating Cocoa's retain/release calls was much safer approach. Swift naturally built on top of that due to interoperability with Objective-C frameworks. Nim has taken other optimizations into consideration, however only in the new ORC implementation. Still, all of them are much better than managing memory manually.
        elcritch 5y ago
        > I wouldn't buy into much Apple marketing regarding its performance though, I wouldn’t make claims on Swifts overall performance, but just it’s memory usage (really Obj-Cs) and particularly for GUI development. Java’s GCs have always been very memory hungry, usually to the tune of 2x. Same with .Net. Though to be fair Go’s and Erlang’s GCs have much better memory footprints. Erlang’s actor model benefits it there. Agreed, they’re all better than manual memory management.
- kaba0 5y ago
  OSs and hard real time can also be written in managed languages — there are many research OS written in managed languages (with a bit of assembly, but you also need it for C as it is not low-level either), like Midori, and there are even hard-real-time JVMs used in military settings like jamaicavm.
MarcusE1W 5y ago
The way you describe your use case I think you are fine with a language with garbage collection like Nim (which has has a syntax a bit like Python) or Crystal. I would also throw Go in the ring or if you are interested to learn a bit of functional programming then you also could look at Ocaml. Zig has no garbage collection btw, but makes it easier than C to handle that. Another language without garbage collection that helps a lot to avoid memory issues is Ada (Looks a bit like Pascal). So there are alternatives to Rust.
mlindner 5y ago
Rust's memory management is "manual" but it feels automatic for most uses.

adgjlsfhk1 5y ago

imo, most code can do just fine with GC. modern GCs can be relatively low overhead even with guaranteed small pauses (10ms). furthermore, most code that can't handle pauses can be written to not allocate any memory (so GC can be temporarily turned off). as such, the only two places where you need manual allocation are for OS development, and hard real time requirements.

Comevius 5y ago
When tail latency (high-percentile latency) is important GC is not a good choice. Wait-free (threads progress independently) concurrent algorithms also need wait-free memory reclamation with bounded memory usage to be able to guarantee progress. But most software are throughput-oriented.
- pjmlp 5y ago
  Additionally, not all GCs are made alike, and languages like D, F#, C#, Nim, Swift, among others, also offer value types and manual memory management, if desired.
  - elcritch 5y ago
    Also Swift and Nim w/ ARC use reference counting, which generally give much better latency and lower memory overhead. Reference counting is part of the reason iOS devices don’t need as much RAM. Nim’s ARC system also doesn’t use atomic or locks which means it’s runtime overhead is very low. I use it successfully on embedded devices for microsecond timed events with no large tail latencies.
    - pjmlp 5y ago
      Reference counting is a GC algorithm. I wouldn't buy into much Apple marketing regarding its performance though, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages It makes sense in the context of tracing GC having been a failure in Objective-C due to its C semantics, while automating Cocoa's retain/release calls was much safer approach. Swift naturally built on top of that due to interoperability with Objective-C frameworks. Nim has taken other optimizations into consideration, however only in the new ORC implementation. Still, all of them are much better than managing memory manually.
      - elcritch 5y ago
        > I wouldn't buy into much Apple marketing regarding its performance though, I wouldn’t make claims on Swifts overall performance, but just it’s memory usage (really Obj-Cs) and particularly for GUI development. Java’s GCs have always been very memory hungry, usually to the tune of 2x. Same with .Net. Though to be fair Go’s and Erlang’s GCs have much better memory footprints. Erlang’s actor model benefits it there. Agreed, they’re all better than manual memory management.
kaba0 5y ago
OSs and hard real time can also be written in managed languages — there are many research OS written in managed languages (with a bit of assembly, but you also need it for C as it is not low-level either), like Midori, and there are even hard-real-time JVMs used in military settings like jamaicavm.

MarcusE1W 5y ago

The way you describe your use case I think you are fine with a language with garbage collection like Nim (which has has a syntax a bit like Python) or Crystal. I would also throw Go in the ring or if you are interested to learn a bit of functional programming then you also could look at Ocaml. Zig has no garbage collection btw, but makes it easier than C to handle that. Another language without garbage collection that helps a lot to avoid memory issues is Ada (Looks a bit like Pascal). So there are alternatives to Rust.

mlindner 5y ago

Rust's memory management is "manual" but it feels automatic for most uses.