Go language for one year of practical experience!

This is a creation in Article, where the information may have evolved or changed.

Guide

As the company name implies, we are developing mobile applications. After releasing an app to the public, we quickly realized that we were missing a tool to check what actually happened to the user and how they interacted with the app-it would be handy if there were any problems or bug reports.

There are several tools that claim to be able to help developers in this area, but none of them fully satisfies the requirements, so we decided to build one ourselves. We started to create a basic set of scripts, and now it quickly evolved into a complete tool called bugfender! Since this was initially an experiment, we decided to use a new trend technique. The love of learning and continuing education is one of the core values of Mobile Jazz, so we decided to build with Go. This is a relatively new programming language developed by Google. It is a new player in the world of programming and has been praised by many respected developers.

A year later, the experiment became a start-up project, and we have an incredible tool that has helped thousands of developers from all over the world. Our servers process more than 200GB of data from 7 million devices per day. After using Go for a year, we wanted to share some of the ideas and experiences that we turned a small experiment into a production server dealing with millions of logs.

Go Eco-System

No one in the company has the experience of using Go. Bugfender is the first time we have been into this language.

Learning is basically quite straightforward. Our previous experience in c/c++/java/objective-c/php has allowed us to learn go quite quickly and has been developed within a few days. Of course there are new and uncommon things to learn, including Gopath and how to handle packages, but this is within our expectations.

Within a few days, we realized that even a language that was designed to be simplified, Go is very powerful. It can do what any modern programming language should do: It's OK to handle JSON, communicate between servers, and even Access databases (and only a few lines of code).

When building a server, you should first decide whether to use any third-party libraries or frameworks. For Bugfender, we decided to use:

Martini

Martini is a powerful web framework for Go. When we started this experiment, it was a great solution, and so far, we haven't had any problems. However, if we start this experiment again today, we will choose a different framework because Martini is not being maintained.

We also experimented with Iris (our current favorite) and Gin. Gin is a Martini successor, and migrating to this allows us to reuse existing code.

Over the past year, we have realised that the standard library of Go is very powerful, and you don't have to rely on a bloated web framework to build a server. It is best to use specialized high-performance libraries on specific tasks.

modification: After discussing all aspects of iris, we realized that Iris may not be the best choice. If we decide to rewrite our web components, we may look at other options and we welcome your suggestions.

Gorm

Some people like ORM, while others dislike it. We decided to use ORM, or rather GORM. Our implementation is only for the Web front end and continues to use manually optimized SQL for the log extraction API. At first we really liked it, but as time went on, we started to discover the problem, and we quickly removed it from the code and used the standard SQL library SQLX.

One of the main problems with GORM is the Go ecosystem. As a new language, Go has a lot of new versions since we started developing our products. Some of the changes in these new versions are not backwards compatible, so to use the latest version of the library, we often rewrite the existing code and examine the hack we have done to resolve the version issue.

These two libraries are the main components of most Web services, so making a good choice is important because future changes can be difficult and affect the performance of your server.

third-party services

Another important aspect of creating a real-life product is to consider the availability of libraries, third-party services, and tools. Go also lacks maturity, and most companies don't have a go library, so you might want to rely on libraries that other people write that don't always guarantee quality.

For example, there are good libraries for using Redis and ElasticSearch, but not for other services such as Mixpanel or Stripe.

We recommend checking to see if there is a good library available for the product you need before using Go.

We also encountered a lot of problems on Go package management system. The way it handles versions is far from optimal, and over the past year we have had a lot of problems using different versions of the same library across different team members. Recently, however, thanks to the vendor package feature of Go's new support, this problem has been largely resolved in addition to the gopkg.in service.

Developer Tools

Since Go is a relatively new language, you may find that the development tools available are not very good compared to other mature languages like Java. When we started Bugfender, it was difficult to use any IDE, and there seemed to be no IDE support for Go. But over the past year, this has improved a lot with the introduction of the IntelliJ and Visual Studio Code Go plugins.

Finally look at the other Go tools, the debugger is not very good, and the parser is even worse, so it is sometimes difficult to debug your code or try to optimize it.

go to production

This is really one of the best things to go, if you want to deploy something into a production environment, you just need to build your binary and send it to the server, no dependencies, no need to install additional software, you just need to be able to run binary files on the server.

If you're used to dealing with languages that require a Package manager or need to be careful with the language interpreter you're using, going to work will be nice.

We are also happy with the stability of Go because the server seems to have never crashed. We had a problem sending a lot of data to Go Routines, but we barely saw any crashes. Note: If you need to send a lot of data to Go Routine, you need to be careful with heap overflow.

If you're interested in performance, we can't compare it to other languages because we're using Go from scratch, but for the amount of data we're dealing with, we feel that performance is very good, and we definitely can't use PHP so easily to handle an equal number of requests.

Summary

Over the past year, we have been feeling the ups and downs of Go. At first we were excited, but after the experiment turned into a real product, we began to find the problem. We've considered a lot of rewriting in Java a couple of times, but so far, we're still using go, and the past year has been a great boost to the go ecosystem, which simplifies our work.

If you want to use Go to build your product, you can make sure it works, but you really need to be careful about one thing: the developer you can hire. There are only a few advanced Go developers in Silicon Valley and it's a very difficult task to find elsewhere.

Via:https://bugfender.com/one-year-using-go

Author: Aleix Ventayol Translator: GEEKPI proofreading: Wxy

This article was compiled by LCTT original, Linux China honors launched

This article was reproduced from:http://www.linuxprobe.com/go-1years-experence.html

Free to provide the latest Linux technology tutorials Books, for open-source technology enthusiasts to do more and better, open source site: http://www.linuxprobe.com/