6 ms·

Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is

Go's garbage collector is faster than you imagine. Have you used it? Go is a good replacement for C and C++ for almost all purposes. Most purposes where Go is inapplicable should be using explicit SIMD (GCC intrinsics) or CUDA C anyway. The others purposes where Go is inapplicable are low-level real-time stuff that should be written in C for a specialized software stack (e.g., software in a car).

synergy20 4y ago
Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++. Go also has the stop-the-world GC problem, GC is great but it does have a price tag. I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.
- bugfix-66 4y ago
  Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either. But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.
  - jandrewrogers 4y ago
    C++17/20 is superior to Go, and widely used, for anything that looks like high-performance data infrastructure, which is a broad class of software. There are classes of common architectural optimizations that aren't feasible with a garbage collector because of how it interacts with scheduling and CPU caches. Even 1 millisecond for a GC pause -- often considered "low latency" -- is much too slow when standard operation rates are tens of millions per second. Go is very good for many things but it does not offer competitive performance for these types of applications because design elements that have a large impact on throughput are poorly supported.
doliveira 4y ago
What are people using C and C++ for that you can comfortably use Go instead?
- bugfix-66 4y ago
  For example, I work at a company (a company you hear about daily here on Hacker News) that has a compiler generating linear algebra kernels. The compiler is a huge assemblage of C++ templates, stitched together with a little Python. The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle. But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators. Go would be a great choice for the compiler. Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...
  - spyremeown 4y ago
    I've read all of your comments and I commend you trying to illuminate these people. Some of them seem to be living in the 1990s, spewing the usual hocuspocus about programming languages, the kind of thing you hear once and it becomes a myth. It's like people don't want to reevaluate their choices, and it's insane we keep using this god-forsaken language when we have much better tooling, as you said.
  - pclmulqdq 4y ago
    Honestly, it sounds like C++ is just a poor choice for this project, since you are not so interested in performance and you are a lot more interested in developer speed. It is not an example as to why Go is a good replacement for C++ in almost every project. This is a case where you could replace C++ with any business-logic-oriented programming language and you would be happier. It just so happens that your language of choice is Go (and presumably the tech lead's language of choice is C++ for some unknowable reason). Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.
galangalalgol 4y ago
Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good fit to the problem. I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.
- bugfix-66 4y ago
  I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - galangalalgol 4y ago
    I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't. Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage. Trying to target that with go would add a lot of extra challenge. I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature. The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.
surajrmal 4y ago
go has other problems that preclude it from being a good option including binary size, memory usage, and portability. There are certainly a lot of places it is a good choice for, but I can't really imagine using it anywhere I use c++ today.
- bugfix-66 4y ago
  Portability? Are you saying Go has portability problems? Can you elaborate on that very surprising claim?
  - synergy20 4y ago
    when you talk about macos/windows/linux without CGO yes Go is very portable and easy to use, when you need CGO, or you need work on other architecture or OSes, Go is pretty much a no-go. and c/c++ are still the only ones close to the claim "runs on everything".

synergy20 4y ago

Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++. Go also has the stop-the-world GC problem, GC is great but it does have a price tag. I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.

bugfix-66 4y ago
Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either. But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.
- jandrewrogers 4y ago
  C++17/20 is superior to Go, and widely used, for anything that looks like high-performance data infrastructure, which is a broad class of software. There are classes of common architectural optimizations that aren't feasible with a garbage collector because of how it interacts with scheduling and CPU caches. Even 1 millisecond for a GC pause -- often considered "low latency" -- is much too slow when standard operation rates are tens of millions per second. Go is very good for many things but it does not offer competitive performance for these types of applications because design elements that have a large impact on throughput are poorly supported.

doliveira 4y ago

What are people using C and C++ for that you can comfortably use Go instead?

bugfix-66 4y ago
For example, I work at a company (a company you hear about daily here on Hacker News) that has a compiler generating linear algebra kernels. The compiler is a huge assemblage of C++ templates, stitched together with a little Python. The generated code is in an assembly language for a highly parallel machine, and needs to be heavily optimized down to the cycle. But the compiler itself does NOT need to be so minutely tuned. It needs to be maintainable and it needs to allow easy development of complex code generators. Go would be a great choice for the compiler. Instead, we struggle with C++ templates, CMake'ing our code slowly and with absurd complexity, modifying the compiler slowly and with great difficulty...
- spyremeown 4y ago
  I've read all of your comments and I commend you trying to illuminate these people. Some of them seem to be living in the 1990s, spewing the usual hocuspocus about programming languages, the kind of thing you hear once and it becomes a myth. It's like people don't want to reevaluate their choices, and it's insane we keep using this god-forsaken language when we have much better tooling, as you said.
- pclmulqdq 4y ago
  Honestly, it sounds like C++ is just a poor choice for this project, since you are not so interested in performance and you are a lot more interested in developer speed. It is not an example as to why Go is a good replacement for C++ in almost every project. This is a case where you could replace C++ with any business-logic-oriented programming language and you would be happier. It just so happens that your language of choice is Go (and presumably the tech lead's language of choice is C++ for some unknowable reason). Also, you should not discount compiler speed completely. You, yourself, were upset at the speed of a compile process. All of your users are going to be waiting to get things done while the compiler is running, so you might want to do some math as to how much a 10% slowdown would cost in developer salaries. The makers of gcc, LLVM, and clang spend a lot of effort on improving the speed of their compiler to make sure that you have minimal time waste.

galangalalgol 4y ago

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good fit to the problem. I like go, I use it on occasion. If I stick to the simple stuff it is really easy to think about and if it is just a back end on a big server, why not. But that is a niche case for me. I usually prototype in matlab, then implement in c++, and yes, often cuda too, but I think saying that go is almost always a drop in for c++ is missing the vast majority of what c++ is used for. Go is not a systems language, it benchmarks slower than many vm lamguages like java and c#. It's gimmick is that it compiles really fast and is easy to reason about, so it is good for velocity. But it sacrifices a lot for that. FFI compatibility, and runtime speed foremost. Sometimes those things don't matter. But for systems programming, dsp, embedded, or AAA games they are deal breakers.

bugfix-66 4y ago
I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- galangalalgol 4y ago
  I disagree, but they do take some effort to use effectively. Isaac (or someone) has spent a lot of time segregating out idiomatic simple, and overoptimized solutions. I have looked at the programs, and within the idiomatic programs similar to the types of stuff I do (not a lot of allocation) go varies between 30% and 300% more CPU time. And I have used it as I said. Because go is compiled to native people keep suggesting it is a systems language. Fortran is compiled to native too, but I don't want to write a kernel driver in it. Go has a huge niche, back-end. I think it has plenty of competition there with java and c#, but I reach for go because it makes things quick and easy. I might learn c# if back-end was my day to day, but it isn't. Using c++17 (don't know 20 yet) for very small embedded targets works fine, easy FFI into the BSP, small to no runtime depending on usage. Trying to target that with go would add a lot of extra challenge. I think something like rust or preferably a subset of it for c++ ise cases makes sense. My next project without a GPU I have penciled in rust on the plan. The other developers are excited. Still too hard to use gpu with it. Or rather too immature. The other developers like go too, but throughput will be critical without the gpu, and every little bit will count. And for numeric code it wouldn't just be a little bit of a hit. I wouldn't even suggest julia, and that is as close to a do-it-all language as I have seen.

surajrmal 4y ago

go has other problems that preclude it from being a good option including binary size, memory usage, and portability. There are certainly a lot of places it is a good choice for, but I can't really imagine using it anywhere I use c++ today.

bugfix-66 4y ago
Portability? Are you saying Go has portability problems? Can you elaborate on that very surprising claim?
- synergy20 4y ago
  when you talk about macos/windows/linux without CGO yes Go is very portable and easy to use, when you need CGO, or you need work on other architecture or OSes, Go is pretty much a no-go. and c/c++ are still the only ones close to the claim "runs on everything".