The Go Performance Battle Is Wrong
Why all the Golang frameworks focus on Performance?
I love the Go Language and I introduced it in Arduino more than one year ago. It really changed our way of creating and deploy apps, here the main advantages for us:
- Compiles on every architecture we use
- Blazing fast
- Very easy to deploy, we use the binary + a json config file
- Robust
- Well documented
- High quality libraries
Most of our backend of the brand new Arduino Create project is built on top of Go.
We started using Revel (because of some similarities with Django), than it was Gin Gonic, now Echo with some excursus on other frameworks. It is very easy to rewrite your microservices applications in other frameworks if your app are small enough, and we kept them very small.
Today I heard about Iris, if you compare some of those framework they all speak about speed as the main feature:
The fastest backend web framework for Go. — Iris
The fastest full-featured web framework for Golang. Crystal clear. — Gin Gonic
Fast and unfancy HTTP server framework for Go (Golang). Up to 10x faster than the rest. — Echo
All the new interesting micro web frameworks are almost the same in terms of architecture and they can have pros/cons about their routing method. It is true they are all fast but it reminds me they are competing on the wrong feature.
Some time ago there was a similar battle in the Linux field about the best package format or package manager: apt, yum, nix, pac, etc. and again the movement missed the opportunity to create an homogeneous echosystem for most distribution (it took a while to have .deb and .rpm on completely different markets).
Why should not they compete on the speed? Speed is important, that’s a fact, but a well written Go application is already going to be much faster than the same app written in one of the most famous interpreted languages out there.
Go is still relatively new, not in terms of features or robustness but in terms of number of application written with it and number of available libraries (we had to write our own custom serial library), but it is fast by design, no doubt about that.
I do believe it is better if the various frameworks try to compete or merge some projects around a set of specific features. In these direction the best work was probably done by the Gorilla Web Toolkit providing a lot of small libraries a developer can pick and easily integrate in their project.
This is what new frameworks should compete on:
- Provide a simple way to have a plugin architecture
- Plug a custom language template (most of frameworks now use Go Templating only)
- A simple way to add middlewares
- Good binding options
- Easy pluggable ORM or DB libs (I dislike ORM, but that’s my problem FYI we use RethinkDB)
- Good user and architecture documentation (not developer oriented only)
- Internazionalization
- Support
Indeed if we look at other very popular frameworks for different languages we see the most popular ones were not the fastest, but the more productive. Let’s think about Django or Rails, they became popular for what they provide and how a new developer can start writing code with them.
I really hope Go developers (which are awesome) will try to create a more supported and bigger (in terms of adoption) framework to pick just few features and make them better. Please stop having a lot of microframeworks doing almost the same thing and competing on the speed. In my experience 99.98% speed problems are not about the tools themselves but about how the people use it, wrong algorithms or related to not optimized DB query or session/RAM management.
The good thing is now Go is stable and supported enough I am sure very soon will arise the new Framework that will compete with the most popular in the market, Go Language is awesome, Go developers are exceptional, the community is big enough, it is time to be effective, not (just) fast!
