💾 Archived View for republic.circumlunar.space › users › dbane › gemlog › 2023-07-12.gmi captured on 2024-08-18 at 17:39:30. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-07-22)
-=-=-=-=-=-=-
No, I don't mean the bin man (in UK English).
I have always believed the prevailing wisdom that GC is more efficient than manual memory managememt. And, in instructions executed, I still believe so.
However, hardware in the past 10/20 years has improved drastically (cache sizes, number of cores, SSD), with the noted exception of main RAM access times. And GC is very efficient in time, but there is a persistent, high, cost in space (I've seen figures of 4-8x). And to get performance out of modern hardware, you really want to keep your working set in cache. So perhaps hardware changes mean the prevailing wisdom is no longer valid.
Maybe I'm jumping to conclusions, but in $DAYJOB I notice that for Windows programming at least one division of Microsoft is now pushing for the WinRT C++ (so native-code) framework and not C# (on a GC virtual machine). This is also helped by the fact that C++20 is now competitive as language with C#, which wasn't true for a long time. For a second data point on the server rather than client side, an impressive platform engineered for speed on modern hardware is Seastar (C++) running on the OSv unikernel.
Fast C++ application framework
A background assumption to all of this is that you have to write safe code, at least memory-safe at first. This seems to be "table stakes" for development in $CURRENT_YEAR.
So in practical terms, what do we do? Well, there are two extremes, neither of which I am a fan of. There are lots of people evangelising Rust, which certainly solves the problem but causes others. I honestly found it very difficult. The other extreme is to just continue writing C, like most Linux development (although OpenBSD does better here with OS support). In this world, C++ is actually a reasonable centrist position, productive without the security nightmares so long as you use something like the Core Guidelines checker.
Core Guidelines, probably the best-known-methods for writing C++
If you're not doing this for $DAYJOB, you have more options politically. There's SaferCPlusPlus or you could use @safe D. Or just read the following:
A better post than this one on the topic
SaferCPlusPlus, which I found long before the CG
Personally, I feel some lingering regret. I actually really like GC languages like weird Lisp/ML/Prolog dialects because I think they're much better notations for modelling the problem domain. I think this is something that's often forgotten in the current well-intentioned drive for memory-safety. I already know safe (-ish) imperative languages like Oberon, and chose not to use them much. I'll probably continue playing with Prolog/Mercury and just reserve C++/D for hot code.