3 ms·

See my comment elsewhere in this thread, where I argue that Go is a good replacement for C/C++ for almost all purposes.

pclmulqdq 4y ago
I have spent several years writing C++ in circumstances where Go is a terrible C++ replacement. In these cases, you either need manual control of memory or you have extremely tight requirements on either speed or memory usage. In both cases, Go falls short, and C++ actually works relatively well (so does Rust - everything I am saying about C++ here applies to Rust as well). Despite C++ having a large spec and being complicated, it pushes all of that complexity to compile time. At runtime, you pay nothing for the complexity of the language. Please elaborate to me as to why Go is an appropriate C++ replacement for: * Trading systems that use direct NIC access and need sub-microsecond execution times. * Performance-oriented databases (like ScyllaDB or Aerospike). Like trading systems, these are characterized by having custom shared-nothing (often stackless) asynchronous runtimes that need direct control of syscalls, and optimized IPC and synchronization primitives. * Libraries like memcpy, math libraries, compression libraries, and encryption libraries, which need both SIMD intrinsics and minimal overhead compared to assembly implementations (Go fails on the second part of this criterion - even the Go calling convention has significant overhead). And no, you do not need to write these in assembly: C and C++ versions are far more readable and equally fast. * Memory allocators, which cannot circularly depend on another memory allocator. * Embedded systems with constrained memory footprints. * Hardware drivers. * Code for non-CPU machines, like GPUs or DSPs. Almost all the real use cases for Rust, C, or C++ are not suitable for Go. Go is only a suitable replacement for systems programming languages in places where Java is also a suitable replacement: when you have a powerful computer and fairly loose constraints, and you are primarily doing business logic.
ncmncm 4y ago
Go was specifically designed as a language for un-demanding applications written by coders with strictly limited skills. That is most applications, in practice. Unpleasantly often, though, applications move from un-demanding to demanding, and then having been coded in Go is unfortunate. A nimble organization will code a C++ program for that use case. Lesser shops will lumber along patching the Go code.

I have spent several years writing C++ in circumstances where Go is a terrible C++ replacement. In these cases, you either need manual control of memory or you have extremely tight requirements on either speed or memory usage. In both cases, Go falls short, and C++ actually works relatively well (so does Rust - everything I am saying about C++ here applies to Rust as well). Despite C++ having a large spec and being complicated, it pushes all of that complexity to compile time. At runtime, you pay nothing for the complexity of the language. Please elaborate to me as to why Go is an appropriate C++ replacement for: * Trading systems that use direct NIC access and need sub-microsecond execution times. * Performance-oriented databases (like ScyllaDB or Aerospike). Like trading systems, these are characterized by having custom shared-nothing (often stackless) asynchronous runtimes that need direct control of syscalls, and optimized IPC and synchronization primitives. * Libraries like memcpy, math libraries, compression libraries, and encryption libraries, which need both SIMD intrinsics and minimal overhead compared to assembly implementations (Go fails on the second part of this criterion - even the Go calling convention has significant overhead). And no, you do not need to write these in assembly: C and C++ versions are far more readable and equally fast. * Memory allocators, which cannot circularly depend on another memory allocator. * Embedded systems with constrained memory footprints. * Hardware drivers. * Code for non-CPU machines, like GPUs or DSPs. Almost all the real use cases for Rust, C, or C++ are not suitable for Go. Go is only a suitable replacement for systems programming languages in places where Java is also a suitable replacement: when you have a powerful computer and fairly loose constraints, and you are primarily doing business logic.

ncmncm 4y ago

Go was specifically designed as a language for un-demanding applications written by coders with strictly limited skills. That is most applications, in practice. Unpleasantly often, though, applications move from un-demanding to demanding, and then having been coded in Go is unfortunate. A nimble organization will code a C++ program for that use case. Lesser shops will lumber along patching the Go code.