New essay: "Golang is not Ready for Enterprise Systems yet and Here’s Why"

[onlyjob]

Please consider adding the following new essay (2020-09-13) "Golang is not Ready for Enterprise Systems yet and Here’s Why":

https://medium.com/@afondmitro/golang-is-not-ready-for-enterprise-systems-yet-and-heres-why-c0ee72069963

CC: @djzort

[jordicaballero]

The author deleted this Medium story.

[QiangF]

Introduction

Enterprise application is a long-lived, reliable system, having a lot of persisting data for many years. Nowadays the world of Golang is not providing possibilities to build systems in the way that enterprise systems are built.

Culture of developing in Golang

Let’s consider few problems such as poor error handling, manually composed SQL queries and wheel - oriented development.

Poor error handling

Golang provides more freedom in error handling. It often leads to poor error handling in applications because of lack of responsibility on the developers’ side.

The most popular case is related to execution of sql query:

defer rows.Close() // omitted errors from sql driver

There is no clear way to handle this returned error. Actually, the language provides particular method of catching errors:

result, err := foo()

The error is a typical returned value that can be ignored in various ways:

defer rows.Close() // omitted errors from sql driverdefer body.Close() // omitted IO errorsresult, _ := foo() // omitted errors from foo function

sketch: Now you come to Me and you say “Don Gopher, handle Me.” But you don’t ask with respect. you don’t offer friendship.

In addition, it leads to increased risk of application crashing immediately after panic function invocation, and that it is against reliability in general.

According to ‘Release it!’ by M.Nygard reliable systems must handle every and each not critical error without crashing. There is no trade-off.

As a solution, we can add a reliable mechanism with try/catch/finally construction from other languages. Also it is needed to remove the panic function. Of course, it will be a slower method but more reliable.

Writing manually composed SQL Query

Typical method in Golang of working with database queries is to write a query by hand. If SQL queries are being written manually, then database integration is going to be a bottleneck. Not all developers are good at SQL and using databases. Full-featured ORMs such as Hibernate(Java) and Entity Framework(.NET) generate typical queries are open for database and cache data optimization. It’s one of the most effective ways to write reliable applications according to ‘Release it”.

There are libraries which can be full-featured ORMs in the future (such as GORM and XORM). I believe that in the future they will be more popular than manually composed SQL queries.

Reinventing development wheel

Often golang developers are choosing to reinvent the wheel. Reinventions are everywhere: task scheduler, migration tool, logger, worker pool, library for working with decimal numbers, authorization library and other tools .

They are not well tested, not well documented and not used enough in production. The risk is too high to use them in enterprise applications.

To decrease the amount of risky programming code it is enough to check existing libraries for available solutions. For example, you can use the catalog awesome-go.
Ecosystem

Ecosystem in the golang world consists of Consul, Kubernetes, Zipkin and Træfik and others. It’s a very young and fast evolving technology stack without well-established standards of use.

There are no tools in golang ecosystem which can help in building reliable enterprise systems.

Considering all the above, we need to be quite cautious integrating third-party middleware in the infrastructure, and company must have enough expertise in this middleware to support the process. Otherwise, it’s going to be a minefield in a production environment with different technologies. Good news is that market has a lot of management solutions to minimize the risk while using golang ecosystem. Unfortunately, it is expensive.

The golang ecosystem is too young and lacking in tools, culture of programming but I believe it will become a great ecosystem with great people in the future. Community of the language is working in the right direction: performance and simplification. But we mustn’t forget that reliability is also important. The sooner we understand the value of reliability the faster we will be coding more enterprise systems in Golang.

P.S.

I am surprised, that there are so many interpretations of this article. Unfortunately, a lot of people miss the point of the article.

This is about some risk of using Golang(under “Golang” I mean more culture and ecosystem and less the design of language) for enterprise so as I can observe. It’s my opinion and my view.

Sure, a lot of big companies as Google and Netflix use Golang in enterprise and they have a risk in my view (remember, Google used Golang when this language didn’t have package manager with versioning). Other developers can have other view and other experience and observes and it is ok.

The main goal of the article is to create discuss and see how many people have the same view.
Thank you for reading!