FWIW that benchmark is not reliable . Developers have submitted go programs that do far better, but they get rejected because they use custom memory allocators. This is despite the fact that C++ does precisely this with an arena allocator.
Go was not designed for the small scale, but the large:
- it has a sensible module system that makes compilation fast
- it's a simple language that encourages boring code - your coworkers will probably write code that works and that you can maintain
- Multithreading is a first class concept. Programs you build locally using typical patterns scale when you run them on massive multi-core servers
- the language is memory safe by default
C++ projects require experts to build, scale and maintain. Go is designed to give that capability to journeyman developers.
Yes C++ is generally going to be faster, but rarely do people talk about why that is. It usually comes down to: a smarter compiler, unsafe operations, or clever optimization. The first is legitimate, but rarely that significant. The second is a penalty that's usually worth keeping (you want bounds checking on arrays), and the third misses the point.
Sure the expert c++ developer could write faster code, but is that who you have? Are you going to take the time to do all that optimization work?
> Developers have submitted go programs that do far better, but they get rejected because they use custom memory allocators. This is despite the fact that C++ does precisely this with an arena allocator.
No, apr_pools.h was not custom written to make some programming language look better on a toy benchmark!
Go was not designed for the small scale, but the large:
- it has a sensible module system that makes compilation fast
- it's a simple language that encourages boring code - your coworkers will probably write code that works and that you can maintain
- Multithreading is a first class concept. Programs you build locally using typical patterns scale when you run them on massive multi-core servers
- the language is memory safe by default
C++ projects require experts to build, scale and maintain. Go is designed to give that capability to journeyman developers.
Yes C++ is generally going to be faster, but rarely do people talk about why that is. It usually comes down to: a smarter compiler, unsafe operations, or clever optimization. The first is legitimate, but rarely that significant. The second is a penalty that's usually worth keeping (you want bounds checking on arrays), and the third misses the point.
Sure the expert c++ developer could write faster code, but is that who you have? Are you going to take the time to do all that optimization work?