5 ms·

I guess every language has its devotees. Go is no exception. My own personal experience with talking to more than a few of these people were that they tended to

by cletus 7y ago

I guess every language has its devotees. Go is no exception. My own personal experience with talking to more than a few of these people were that they tended to be a bit... naive and overly optimistic, which is fine, but often the lessons of history were ignored. The way I like to put it is Go devotees operate under 2 rules: 1. Whatever your complaint about Go is, it's totally not a problem (eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about); 2. Even if it is a problem--which remember it is not--it's totally fixed in Go 1.(N+1) where 1.N is the current version.

wbl 7y ago
Pauseless concurrent collectors have existed for decades.
throwaway894345 7y ago
This comment is transparently trying to incite a flame war, but I'll try to take it on a more productive tangent. > eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"? Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).
- cletus 7y ago
  > This is a really interesting example, because it shows the lack of nuance in the anti-GC position. I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons: 1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this; 2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC. 3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.
  - pjmlp 7y ago
    My experience at CERN ATLAS HLT means that those C++ processes would also have a highly tuned custom multithreaded memory allocator, malloc() and new aren't even in the game to start with, and most likely one is doing a custom protocol at IP level.
zeroc8 7y ago
Well, my personal experience with C++ developers is, that they are a bit ...naive and overly optimistic, when it comes to taking a look at the real world, with real deadlines. "I just write my own half assed string class" comes to mind... As if they are developing in a vacuum, with no competition out there. This really pisses me off.

by cletus 7y ago

wbl 7y ago

Pauseless concurrent collectors have existed for decades.

throwaway894345 7y ago

This comment is transparently trying to incite a flame war, but I'll try to take it on a more productive tangent. > eg stop-the-world GC pauses, a longstanding issue that any experienced Java engineer could commiserate at length about This is a really interesting example, because it shows the lack of nuance in the anti-GC position. By your logic, because Java's 100ms GC pause times have been problematic (and yes, I'm aware that Java's upcoming GC will boast significantly improved pause times and that it's theoretically possible to tune a Java GC for low pause times even if no one has managed it in production) Go's 5us pause times will be equally problematic. Because a pause is a pause, right--why should we muddy the waters with considerations like "duration"? Single- or double-digit microsecond pause times completely change the conventional wisdom about the kinds of applications GC is suitable for. There are still lots of hard real time applications that Go's GC won't be suited for, but there are many soft real time applications for which Go would be fine (or at least the issues will be libraries or support for target architecture/platform and not GC).

cletus 7y ago
> This is a really interesting example, because it shows the lack of nuance in the anti-GC position. I wouldn't call my position strictly anti-GC. I would simply say that GC isn't the panacea it's made out to be and it is at least in part a false economy for at least three reasons: 1. You may need to tune your VM/GC parameters (as you mention). There's a cost to this; 2. GC can make it harder to identify memory leaks (which are still a problem through, for example, dangling references). I've worked on C++ systems where we instrumented many things including process size, which was basically just a flat line. As soon as it wasn't, you knew there was a problem. And this was for a server that read about ~6GB/second off a NIC. 3. Crashing a program due to accessing unallocated memory tends to give a more immediate signal of a problem, which is more often than not better for development.
- pjmlp 7y ago
  My experience at CERN ATLAS HLT means that those C++ processes would also have a highly tuned custom multithreaded memory allocator, malloc() and new aren't even in the game to start with, and most likely one is doing a custom protocol at IP level.

zeroc8 7y ago

Well, my personal experience with C++ developers is, that they are a bit ...naive and overly optimistic, when it comes to taking a look at the real world, with real deadlines. "I just write my own half assed string class" comes to mind... As if they are developing in a vacuum, with no competition out there. This really pisses me off.