3 ms·

People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages

People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages (see MLTon for example) are very advanced and the ability to do multi core with ease (I know this is more recent to OCaml) can be a big performance unlock that is very hard to get right in C.

pornel 2y ago
GC is perfectly fine for ~99% of applications, which is why all the languages in the last few decades adopted it, and eliminated themselves from being direct C/C++ competitors. Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.
dgrunwald 2y ago
The GC does matter. Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks. Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having to be re-implemented in that language. The only exception are the C/C++/Rust libraries, as these can be used (through C FFI interface) by almost every other language. This is precisely because these languages do not introduce their own heavy-weight runtime (especially: no GC), allowing them to be combined with another language's runtime. Thus widely used libraries must be written in one of the non-GC languages, even if 100% of the applications using them are fine with having a garage collector.
- bryanlarsen 2y ago
  I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun. This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.

pornel 2y ago

GC is perfectly fine for ~99% of applications, which is why all the languages in the last few decades adopted it, and eliminated themselves from being direct C/C++ competitors. Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.

dgrunwald 2y ago

The GC does matter. Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks. Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having to be re-implemented in that language. The only exception are the C/C++/Rust libraries, as these can be used (through C FFI interface) by almost every other language. This is precisely because these languages do not introduce their own heavy-weight runtime (especially: no GC), allowing them to be combined with another language's runtime. Thus widely used libraries must be written in one of the non-GC languages, even if 100% of the applications using them are fine with having a garage collector.

bryanlarsen 2y ago
I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun. This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.