[sethammons]

What do you mean by small scale? I think requests per second. Our Go-backed API has handled 90k rps without batting an eye. Or do you mean small scale as in team size? It is my understanding that Go was specifically designed to work for large organizations (cough Google cough).

Or do you mean single page JavaScript web sites? At which point Go would be the backing API? I don't see what qualifies Go for "small scale" vs "large scale."

Thanks for any clarification. Cheers!

[Liru]

I would say "small scale" would refer to project size in Go.

[sethammons]

Thanks

[freyir]

Not akditer, but I think the key words are "self sufficient," i.e., the Go standard library provides a great deal of core functionality out of the box.

A larger project is more likely to require features provided by third-party packages.

[akditer]

A small scale means you won't use redis for in memory data storage. You will not need C++ to write heavy string processing and hash table lookup. Golang also doesn't scale well if you have some heavy processing involving trees(http://benchmarksgame.alioth.debian.org/u64q/binarytrees.htm...).

[cdoxsey]

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?

[igouy]

> 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!

https://apr.apache.org/docs/apr/1.5/apr__pools_8h.html