3 ms·

Might be unpopular opinion, but I kinda like to look how people introduce will-be-a-problem-in-the-future things (let's say GC) and than heroically are solving

by dmytroi 10y ago

Might be unpopular opinion, but I kinda like to look how people introduce will-be-a-problem-in-the-future things (let's say GC) and than heroically are solving following problems (pause-less GC), it's like Don Quixotes of modern age, except you build windmills yourself.

usrusr 10y ago
Priorities. Getting rid of manual memory management can be a worthwhile goal even with slow gc, just like not having expensive runtime memory management automatisms can be a worthwhile goal. Making gc faster (or just more predictable) on top of that is not heroically solving a follow-up problem, it's an optional bonus achievement.
- dmytroi 10y ago
  I might be too old fashioned, but the only case where some sort of memory management is pleasant and comfortable - constructing/modifying strings, though even here many languages separate mutable and immutable strings into different beasts. In all other cases just allocate virtual page from OS (way too old school I understand, people usually don't use this one and believe that C Runtime Library with malloc is the only "approved" way to allocate memory), you get from 4kb to many megabytes of continuous memory - do whatever you want there, and deallocate whole virtual page later on, no leaks, no problems. Sure I do understand that manually managing millions of objects on heap is hard, but managing 1 to 10 virtual pages? it's simple and easy, just forged about generic allocators and use specialized ones (like block allocator for example). Also it's good to know if you even need to deallocate at all ... for example ninja build system (https://ninja-build.org https://ninja-build.org) simply doesn't deallocate memory after build is done, just because it's too slow to do it (though they do use heap allocations), just kill the app and OS will clean up after you. PS. On other hand what I'm saying is just a personal rant. Reality is that the industry is mostly moving to tools that don't allow writing unsafe code (for example languages without pointer arithmetic), and this might be very limiting in language expressiveness. There is an another approach - statically proving that unsafe code is safe. This is what "Checked C" is all about, and this is how Windows drivers are working without crashing the kernel (at least BSODs are pretty rare on Windows nowadays). But I do agree that tools for statically proving unsafe code are so non casual that only greybeards are interested in them nowadays :(

by dmytroi 10y ago

usrusr 10y ago

Priorities. Getting rid of manual memory management can be a worthwhile goal even with slow gc, just like not having expensive runtime memory management automatisms can be a worthwhile goal. Making gc faster (or just more predictable) on top of that is not heroically solving a follow-up problem, it's an optional bonus achievement.

dmytroi 10y ago
I might be too old fashioned, but the only case where some sort of memory management is pleasant and comfortable - constructing/modifying strings, though even here many languages separate mutable and immutable strings into different beasts. In all other cases just allocate virtual page from OS (way too old school I understand, people usually don't use this one and believe that C Runtime Library with malloc is the only "approved" way to allocate memory), you get from 4kb to many megabytes of continuous memory - do whatever you want there, and deallocate whole virtual page later on, no leaks, no problems. Sure I do understand that manually managing millions of objects on heap is hard, but managing 1 to 10 virtual pages? it's simple and easy, just forged about generic allocators and use specialized ones (like block allocator for example). Also it's good to know if you even need to deallocate at all ... for example ninja build system (https://ninja-build.org https://ninja-build.org) simply doesn't deallocate memory after build is done, just because it's too slow to do it (though they do use heap allocations), just kill the app and OS will clean up after you. PS. On other hand what I'm saying is just a personal rant. Reality is that the industry is mostly moving to tools that don't allow writing unsafe code (for example languages without pointer arithmetic), and this might be very limiting in language expressiveness. There is an another approach - statically proving that unsafe code is safe. This is what "Checked C" is all about, and this is how Windows drivers are working without crashing the kernel (at least BSODs are pretty rare on Windows nowadays). But I do agree that tools for statically proving unsafe code are so non casual that only greybeards are interested in them nowadays :(