8 ms·

I just prefer to use languages without a Garbage Collector.

njharman 11y ago
Man! I'd never want to code in language that forces me to manage memory. A boring, solved problem the compiler/run time should handle for me.
- Peaker 11y ago
  I enjoy both kinds of languages. I do think garbage collectors are overrated. When using certain styles in C or C++, memory management is really a tiny aspect you have to spend a tiny minority of your time thinking about -- but you gain so much determinism of execution in return. I've been burnt by garbage collection killing my programs' performance many times -- having to tune the garbage collector has taken more time than just writing manual memory management in some cases! Also, dynamic memory allocation and garbage collection just injects so much dynamism and uncertainty in your program's execution. I dislike it for the same reason I dislike dynamic typing. I want to be able to statically reason about the resource use of my program, just like I want to statically reason about any other aspect of my program.
  - njharman 11y ago
    Deterministic! My usual coding projects (distributed, networked, multi-process/multi-thread) are so far from determinism and my problems so many levels above the concerns of C/C++. Both are needed. Just saying I'm glad other devs work on the lower level stuff for me ;)
    - Peaker 11y ago
      Non-determinism comes in many forms. I don't think it's an all or nothing thing. Eliminating non-determinism is always nice, even if lots of other non-determinism remains. Having predictable and understandable resource use is a nice plus. Removing dynamic memory allocation also tends to increase locality, remove indirections, and remove error handling paths from your code.
- Sanddancer 11y ago
  Memory management isn't solved though. In a lot of applications, it takes up a significant amount of memory and/or cpu time, which can be of importance if you have time constraints, space constraints, and/or power constraints. Deterministic memory lets you, for example, know that the 256 bytes on your microcontroller is more than enough, or that you will always hit the timings needed to guarantee that your project will always output at 60 frames per second. Yes, there are a lot of times you can just throw RAM at the problem to make it go away, but there are a lot of really interesting problems out there that do require you to be able to intimately manage resources.
hkjgkjy 11y ago
Any experience doing functional programming without garbage collector? I'm doing a lot of Clojure, and can't really see how it would be a pleasant experience without GC but curious to hear any interesting thoughts.
- Findeton 11y ago
  The closest I've tried is Rust, which is not 100% functional or 100% anything but I like it.
- qb45 11y ago
  ATS claims to support memory safe functional programming without GC. I never used this language, though. IIRC the idea is that allocating memory or writing something through a pointer returns a magic "cookie" value which certifies that the pointer now points to a block of certain size or data of certain type. This cookie can be bound to a variable like any other value and passed to other code together with the pointer so that the code can know that it's safe to access the pointer. There are rules - cookies can't be pulled out of thin air or cloned, have to be destroyed during deallocation, etc. All of this is checked during compilation and removed from the final executable. http://www.ats-lang.org/ http://www.ats-lang.org/
- astrange 11y ago
  Swift is a language with many functional features and no GC. As long as you don't mind breaking cycles yourself, it's fine.
pjmlp 11y ago
And spend time tracking down memory corruption?
- iopq 11y ago
  Rust doesn't require you to track down memory corruption in safe code.
  - pjmlp 11y ago
    No, but it has compiler assisted resource management. Not the first idea that comes to mind when someone complaints about GC. Besides even on Rust, using lock free algorithms without GC help is very tricky.
    - iopq 11y ago
      It's tricky even with a GC.
- Peaker 11y ago
  Having done a lot of C code without dynamic memory allocations at all -- chasing memory corruption was a thing, but a rare thing. I spent more time chasing performance issues and tuning GC in some projects than I did chasing memory corruption in my C projects.
  - pjmlp 11y ago
    How big were such projects? I never saw a C project with teams bigger than 5 developers without memory corruption issues.
    - Peaker 11y ago
      Hundreds of thousands of LOCs. ~15 developers I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spent chasing them. In return, get determinism and optimality of execution.
pmarreck 11y ago
I can tolerate it in Elixir/Erlang because GC is per-process-id (of which there could be dozens or hundreds in a typical Erlang/Elixir app) and not remotely a global world stopper.

Man! I'd never want to code in language that forces me to manage memory. A boring, solved problem the compiler/run time should handle for me.

Peaker 11y ago
I enjoy both kinds of languages. I do think garbage collectors are overrated. When using certain styles in C or C++, memory management is really a tiny aspect you have to spend a tiny minority of your time thinking about -- but you gain so much determinism of execution in return. I've been burnt by garbage collection killing my programs' performance many times -- having to tune the garbage collector has taken more time than just writing manual memory management in some cases! Also, dynamic memory allocation and garbage collection just injects so much dynamism and uncertainty in your program's execution. I dislike it for the same reason I dislike dynamic typing. I want to be able to statically reason about the resource use of my program, just like I want to statically reason about any other aspect of my program.
- njharman 11y ago
  Deterministic! My usual coding projects (distributed, networked, multi-process/multi-thread) are so far from determinism and my problems so many levels above the concerns of C/C++. Both are needed. Just saying I'm glad other devs work on the lower level stuff for me ;)
  - Peaker 11y ago
    Non-determinism comes in many forms. I don't think it's an all or nothing thing. Eliminating non-determinism is always nice, even if lots of other non-determinism remains. Having predictable and understandable resource use is a nice plus. Removing dynamic memory allocation also tends to increase locality, remove indirections, and remove error handling paths from your code.
Sanddancer 11y ago
Memory management isn't solved though. In a lot of applications, it takes up a significant amount of memory and/or cpu time, which can be of importance if you have time constraints, space constraints, and/or power constraints. Deterministic memory lets you, for example, know that the 256 bytes on your microcontroller is more than enough, or that you will always hit the timings needed to guarantee that your project will always output at 60 frames per second. Yes, there are a lot of times you can just throw RAM at the problem to make it go away, but there are a lot of really interesting problems out there that do require you to be able to intimately manage resources.

hkjgkjy 11y ago

Any experience doing functional programming without garbage collector? I'm doing a lot of Clojure, and can't really see how it would be a pleasant experience without GC but curious to hear any interesting thoughts.

Findeton 11y ago
The closest I've tried is Rust, which is not 100% functional or 100% anything but I like it.
qb45 11y ago
ATS claims to support memory safe functional programming without GC. I never used this language, though. IIRC the idea is that allocating memory or writing something through a pointer returns a magic "cookie" value which certifies that the pointer now points to a block of certain size or data of certain type. This cookie can be bound to a variable like any other value and passed to other code together with the pointer so that the code can know that it's safe to access the pointer. There are rules - cookies can't be pulled out of thin air or cloned, have to be destroyed during deallocation, etc. All of this is checked during compilation and removed from the final executable. http://www.ats-lang.org/ http://www.ats-lang.org/
astrange 11y ago
Swift is a language with many functional features and no GC. As long as you don't mind breaking cycles yourself, it's fine.

pjmlp 11y ago

And spend time tracking down memory corruption?

iopq 11y ago
Rust doesn't require you to track down memory corruption in safe code.
- pjmlp 11y ago
  No, but it has compiler assisted resource management. Not the first idea that comes to mind when someone complaints about GC. Besides even on Rust, using lock free algorithms without GC help is very tricky.
  - iopq 11y ago
    It's tricky even with a GC.
Peaker 11y ago
Having done a lot of C code without dynamic memory allocations at all -- chasing memory corruption was a thing, but a rare thing. I spent more time chasing performance issues and tuning GC in some projects than I did chasing memory corruption in my C projects.
- pjmlp 11y ago
  How big were such projects? I never saw a C project with teams bigger than 5 developers without memory corruption issues.
  - Peaker 11y ago
    Hundreds of thousands of LOCs. ~15 developers I didn't say there were no corruption issues. Just that they're rare and a very small minority of the time is spent chasing them. In return, get determinism and optimality of execution.

pmarreck 11y ago

I can tolerate it in Elixir/Erlang because GC is per-process-id (of which there could be dozens or hundreds in a typical Erlang/Elixir app) and not remotely a global world stopper.