[proyb2]

> Honestly, Go is great. Its simplicity is refreshing and its performance unmatched. I would still pick it if we need a small API or something that requires high throughput.

I wonder which part is performance unmatched?

My opinion would be Crystal language for its simplicity and higher throughput but unmatched performance is behind Rust and C.

[pjmlp]

Not sure about the OP, but for many Go is the only compiled language they ever used, so they get to attribute features to Go that aren't that unique of it.

[sacado2]

> for many Go is the only compiled language they ever used

That, or it can be read as "in the family of web-friendly languages". The only other "fast" language widely used for the web is Java.

[pjmlp]

C++, .NET also come to mind in the widely area, with OCaml, Haskell failing under the not so widely, but fast umbrella.

[sacado2]

O'caml and Haskell are extremely niche in the web server world, and are not especially faster than go. C# is not blazingly fast either. They all seem to be in the same ballpark.

[pjmlp]

They are all faster than Go in case you haven't been paying attention.

[sacado2]

I've been paying a lot of attention and, in my experience (but also according to the highly biased benchmark game), C#/Java/OCaml/Haskell/Go are in the same league, i.e usually 3-10 times slower than C/C++/Ada/Rust/D, and 3-10 times faster than "scripting" languages like Python/PHP/Ruby/Perl.

With (in my experience) go being a little faster than java and haskell, and o'caml being slightly faster than anyone, but nothing significative enough for me to expect an article titled "my Java webapp was too slow so I rewrote it in O'Caml" anytime soon.

Benchmarking is very relative, though. I'd be glad to read evidence showing go is significantly slower than any of those in some domain.

[grumpydba]

And java is a memory hog quite painful to deploy and tune.

[pjmlp]

Memory hog only by those that don't know what they are doing and happilly new everywhere.

Yes it is hard to tune, but not so much different than playing with C or C++ compilation switches, across each compiler that is being used in production.

[grumpydba]

> Memory hog only by those that don't know what they are doing and happilly new everywhere.

Go uses an order of magnitude less memory for most type of workloads though. Also you don't tune c++ binaries delivered to you. You have to tune the JVM's option to death for big apps. I can't count the number of incidents "solved" by raising the Xmx param.

[pjmlp]

I tune C++ compilers, just like I tune Java compilers, in both cases I can decide to do it during AOT compilation or at a later moment.

The big question is how properly those big apps were coded.

Go doesn't run Fintech servers, while Java keeps replacing C++ servers. Yes, one needs to code Java with low level tricks like C++, but it is possible and there are many performance experts doing it.

How many Fintech servers are running on Go?

[sacado2]

Yes, launching a new server/executable in java is a PITA dur to the JVM warmup (at least it was a few years ago, don't know whether they improved that point or not).

[grumpydba]

Don't forget that you also have to install and update the JVM. We admins don't like that.

[pjmlp]

Only those that don't know how to bundle the JVM with the application or make use of a commercial AOT compiler to native code.

[pjmlp]

Only for those that don't use a JVM with either AOT compilation or JIT caching.

[silasb]

Crystal is still pretty young and under pretty active development. For me, the biggest con is the long compile times for Crystal.