Hacker News Reader

I agree. If the use-case requires no GC then Rust or Zig or C++ is a better fit.

I don't see much point in choosing a language just to bypass it's features.

Coming from an environment in which we extensively use mixed codebases (C++ and Python) to combine performance and ease of prototyping, one of the pain points is that there is almost always some impedance mismatch between the lifetime/ownership models of the two languages. When something goes wrong here, it's usually a real pain to debug and resolve, and often the resolution involves imposing constraints from one language onto the other (e.g. C++ that would idiomatically use unique_ptr instead needs to use shared_ptr because unique_ptr is essentially impossible to completely capture in Python).

Given the issues involved in mixing languages, there can be cases where sticking with one "good enough" GC'd language and having to write a few performance-sensitive parts in very unidiomatic form to minimize/eliminate GC work is preferable.

I feel like that may be more of an issue with how Python's C API is designed, leaking basically most of its internals, and then having to remember to manage (increment/decrement) Python objects correctly.

I don't think that's the problem, at least not directly for us. The immediate interface between the languages is handled by a binding layer (e.g. pybind11 or nanobind), but that rarely lets you fully express object relationships (something that would be more possible without the binding layer) so it is very easy to either not capture ownership (and thus the C++ object is destroyed out from underneath you) or express a cycle that cpython can't understand (and thus the C++ objects are never destroyed and can leak a significant amount of memory). Explicit manual control would avoid that, but at a level of work that would be prohibitive of having extensive bindings in the first place.

Reply on news.ycombinator.com