5 ms·

Agree 100%. I wonder how much memory management affects this. My journey has been a bit different: traditional engineering degree, lots of large Ruby/JS/Python

Agree 100%. I wonder how much memory management affects this. My journey has been a bit different: traditional engineering degree, lots of large Ruby/JS/Python web applications, then a large C# WPF app, until finally at my last job, I bit the bullet and started doing C++14 (robotics). Coming from more "designed" languages like C#, my experience of C++ was that it felt like an insane, emergent hodgepodge, but what impressed me was how far the language has come since the 90s. No more passing raw pointers around and forgetting to deallocate them, you can get surprisingly far these days with std::unique_ptr and std::shared_ptr, and they're finally even making their way into a lot of libraries. I sense there's a bit of a movement away from JVM/CLR-style stop-the-world, mark-and-sweep generational GC, toward more sophisticated compile-time techniques like Rust's borrow checker, Swift's reference counting, or C++ smart pointers. I mention memory management in particular both because it seems to be perceived as one of the major reasons why languages like C/C++ are "hard" in a way that C#/Java/JS aren't, and I also think it has a big effect on performance, or at least, latency. I completely agree we've backslid, and far, but the reality is, today, it's expensive and complicated to develop high-performance software in a lower-level, higher-performance language (as is common with native), so we're stuck with the Electron / web shitshow, in large part because it's just faster, and easier for non-specialists to develop. It's all driven by economic factors.

mlwiese 6y ago
There is movement away from stop-the-world GC, but not to reference counting. The movement is towards better GC. The language Go has sub millisecond GC with multi-GB heaps since 2018. See https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote Java is also making good progress on low latency GC. Reference counting can be slower than GC if you are using thread safe refcounts which have to be updated atomically. I don't want to have to think about breaking cycles in my data structures (required when using ref counting) any more than I want to think about allocating registers.
- roca 6y ago
  Go achieves those low pause times by allocating 2x memory to the heap than it's actually using. There's no free lunch with GC.
  - pjmlp 6y ago
    Same applies with manually memory management, you get instead slower allocators unless you replace the standard library with something else, and the joy of tracking down double frees and memory leaks.
    - roca 6y ago
      I'm using Rust, so no double frees and no accidental forgetting to call free(). Of course you can still have memory leaks, but that's true in GC languages too.
      - pjmlp 6y ago
        That is not manually memory management though, and it also comes with its own set of issues, like everyone that was tried to write GUIs or games in Rust is painfully aware of. There is no free lunch no matter what one picks.
        roca 6y ago
        That's true. The comment by mlwiese up-thread, that I responded to, praised Go's low GC latency without mentioning the heavy memory and throughput overheads that come with it. I felt it worth pointing out the lack of a free lunch there; I think a lot of casual Go observers and users aren't aware of it.
        pjmlp 6y ago
        Agreed, although if Go had proper support for explicit value types (instead of relying in escape analysis) and generics, like e.g. D, Nim, that could be improved.
    - 6y ago
- tjoff 6y ago
  Yet we still read articles and threads about how bad the Go GC is and the tradeoffs that it forces upon you. I get the feeling that the industry is finally starting to realize that GC has been a massive mistake. Memory management is a very important part of an application, if you outsource that to a GC you stop to think about it. And if you don't think about memory management you are guaranteed to end up with a slow and bloated app. And that is even before considering the performance impact of the GC! The big hinderence has been that ditching the GC often meant that you had to be using an old an unsafe language. Now we have rust, which is great! But we need more.
  - thu2111 6y ago
    The Go GC isn't that great, it's true. It sacrifices huge amounts of throughput to get low latency: basically a marketing optimised collector. The new JVM GCs (ZGC and Shenandoah) are more sensibly designed. They sacrifice a bit of throughput, but not much, and you get pauseless GC. It still makes sense to select a throughput oriented collector if your job is a batch job as it'll go faster but something like ZGC isn't a bad default. GC is sufficiently powerful these days that it doesn't make sense to force developers to think about memory management for the vast bulk of apps. And definitely not Rust! That's one reason web apps beat desktop apps to begin with - web apps were from the start mostly written in [pseudo] GCd languages like Perl, Python, Java, etc.
  - saagarjha 6y ago
    I don’t think it’s fair to call garbage collection a mistake. Sure, it has properties that make it ill-suited for certain applications, but it is convenient and well suited for many others.
tnecniv 6y ago
> Coming from more "designed" languages like C#, my experience of C++ was that it felt like an insane, emergent hodgepodge, but what impressed me was how far the language has come since the 90s. No more passing raw pointers around and forgetting to deallocate them, you can get surprisingly far these days with std::unique_ptr and std::shared_ptr, and they're finally even making their way into a lot of libraries. I worked for a robotics company for a bit, writing C++14. I don't remember ever having to use raw pointers. That combined with the functionality in Eigen made doing work very easy --- until you hit a template error. In that case, you got 8 screens full of garbage.

mlwiese 6y ago

There is movement away from stop-the-world GC, but not to reference counting. The movement is towards better GC. The language Go has sub millisecond GC with multi-GB heaps since 2018. See https://blog.golang.org/ismmkeynote https://blog.golang.org/ismmkeynote Java is also making good progress on low latency GC. Reference counting can be slower than GC if you are using thread safe refcounts which have to be updated atomically. I don't want to have to think about breaking cycles in my data structures (required when using ref counting) any more than I want to think about allocating registers.

roca 6y ago
Go achieves those low pause times by allocating 2x memory to the heap than it's actually using. There's no free lunch with GC.
- pjmlp 6y ago
  Same applies with manually memory management, you get instead slower allocators unless you replace the standard library with something else, and the joy of tracking down double frees and memory leaks.
  - roca 6y ago
    I'm using Rust, so no double frees and no accidental forgetting to call free(). Of course you can still have memory leaks, but that's true in GC languages too.
    - pjmlp 6y ago
      That is not manually memory management though, and it also comes with its own set of issues, like everyone that was tried to write GUIs or games in Rust is painfully aware of. There is no free lunch no matter what one picks.
      - roca 6y ago
        That's true. The comment by mlwiese up-thread, that I responded to, praised Go's low GC latency without mentioning the heavy memory and throughput overheads that come with it. I felt it worth pointing out the lack of a free lunch there; I think a lot of casual Go observers and users aren't aware of it.
        pjmlp 6y ago
        Agreed, although if Go had proper support for explicit value types (instead of relying in escape analysis) and generics, like e.g. D, Nim, that could be improved.
  - 6y ago
tjoff 6y ago
Yet we still read articles and threads about how bad the Go GC is and the tradeoffs that it forces upon you. I get the feeling that the industry is finally starting to realize that GC has been a massive mistake. Memory management is a very important part of an application, if you outsource that to a GC you stop to think about it. And if you don't think about memory management you are guaranteed to end up with a slow and bloated app. And that is even before considering the performance impact of the GC! The big hinderence has been that ditching the GC often meant that you had to be using an old an unsafe language. Now we have rust, which is great! But we need more.
- thu2111 6y ago
  The Go GC isn't that great, it's true. It sacrifices huge amounts of throughput to get low latency: basically a marketing optimised collector. The new JVM GCs (ZGC and Shenandoah) are more sensibly designed. They sacrifice a bit of throughput, but not much, and you get pauseless GC. It still makes sense to select a throughput oriented collector if your job is a batch job as it'll go faster but something like ZGC isn't a bad default. GC is sufficiently powerful these days that it doesn't make sense to force developers to think about memory management for the vast bulk of apps. And definitely not Rust! That's one reason web apps beat desktop apps to begin with - web apps were from the start mostly written in [pseudo] GCd languages like Perl, Python, Java, etc.
- saagarjha 6y ago
  I don’t think it’s fair to call garbage collection a mistake. Sure, it has properties that make it ill-suited for certain applications, but it is convenient and well suited for many others.

tnecniv 6y ago

> Coming from more "designed" languages like C#, my experience of C++ was that it felt like an insane, emergent hodgepodge, but what impressed me was how far the language has come since the 90s. No more passing raw pointers around and forgetting to deallocate them, you can get surprisingly far these days with std::unique_ptr and std::shared_ptr, and they're finally even making their way into a lot of libraries. I worked for a robotics company for a bit, writing C++14. I don't remember ever having to use raw pointers. That combined with the functionality in Eigen made doing work very easy --- until you hit a template error. In that case, you got 8 screens full of garbage.