Golang Annual Use summary, concise not simple

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

Time has gone so fast, more formal use of the go language, has been nearly 300 days. During this period, go from 1.5 to 1.7, their own because of interest + responsibility, came to the new team, once again engaged in once very familiar with the development work, enrich!

After playing Scala, I used the go language.

First learn about the go language, or a project in the original unit of 13. In the case where database operations are not involved, the technical team cannot support 500/s TCP peak requests with. Net. Ben wants to pick up Java, the results inadvertently know go. found that using Go's select is very, very simple. But because of its programming ideas and traditional oo very different, very unaccustomed, there is no follow-up.
Another 2015 years of contact with Scala is a fascinating addition to Scala's group. It's easier to like Scala:
1. Language refinement, Code elegance
Scala's pattern recognition, type inference is just too comfortable, using lambda (the java8, but Scala is more pure), the collection library, a few lines of code can do a lot of things. Moreover, many design patterns of things, in the syntax can be dealt with. For example, null object can be replaced directly with option. Less code, fewer problems, yes!
2. Steep entry, like high IQ
Many people feel that the introduction of the language is difficult, mainly in the FP mode of thinking and the traditional process of thinking different.
3. Distributed actor mode simplifies multi-server synchronization
From the design, the actor model is really very good, plus the Akka framework, in the multi-server can simplify the service discovery, message allocation of the basic framework work. This does provide a great boost to business development. Because I have no experience in this piece, it is not good to evaluate its specific performance.
In the meantime, the most painful thing is SBT. SBT was a good thing, but the download missus was too slow. This would have nothing to do with the tool, but in the Celestial kingdom, must toss, you understand!
However, it is useless to say that there are no more benefits. Come back to start a friend (I am now in the team) to do the game, recruiting experienced Scala programmers did not succeed, and then consider the client is basically C, C + + experience, technical route as close as possible, and then back to go. They say go is simple, right? Is that so?

A comparative evaluation of Go language

Objectively speaking, the current six months, the service side development is still smooth. I also have a look at Scala and I like to compare it with go.
As a language, when the team chooses, the general consideration is the tools and resources, grammatical difficulty, benefit treatment.

Tools and Resources

Everyone knows that go is Google's game, and Scala is the home of Lightbend (formerly known as Typesafe). Don't even think about it, the birth of both is basically not a level. Objectively speaking, the tools and resources are related to the commercialization of the language's initiating units.
-Development tools
Development tools, in addition to Liteide, the rest are plug-ins in idea, Eclipse, sublime and so on. Individuals are mainly used for idea, because refactoring is very convenient, go plug-in update is also very fast, basically at night after the submission of feature, sleep, has been processed. But from Scala, the level of tool support is a different level. For example, if the interface is modified, the plug-in is an interface method that does not refactor the "implementation class". On the one hand, the Scala plugin is official; In addition, the interface model of Go is different from the Java system without explicit definition, and semantic derivation is much more difficult.
-Third party resources
In terms of resources, ETCD, Consul, Groupcache and nsq are all very good outside of the most famous Docker. The individual is currently using Consul, and another simple study of the code, but the distance to use a period of time. Compared to Scala's spark, Akka, play, spray, go framework gin, beego, xorm and so on, in fact, are good, but focus on local functions, less than Scala's comprehensive, has not found a distributed data processing framework.

Language grammar

1. Grammar ambiguity less, easy to get started.
   Go's network Bottom package is good, no obvious bug (of course http2.0 still be perfect). In addition to defer and go, Chan, the code has no features. Missing ternary operators, generics, enumerations, the code will feel very verbose. Maybe that's why anyone can get started quickly.

2. The reliance on design patterns remains strong. Late ascension is harder than Scala.
   Compared to Scala in the grammar phase encapsulated a lot of patterns, go code to primitive some, to write beautiful programs, it takes a bit of effort. To make a good service end, the original design patterns, architectural patterns, and other similar C language, the use of Linux is also important. In contrast to Scala, the later growth curve is steeper. To be a guru, there is no shortcut.

   • For example: Judging the set of different items
     To find out two different collections, Scala only needs a few lines, while the go language, try 20 lines can be done.
   • For example: Set the end point of execution or force exit
     Scala basically has a lot to do with grammar or actor models, while go uses CSP to consider encapsulation in complex business. In fact, the official source of the context package has provided a pattern, very ingenious. Unfortunately, the introduction of a relatively small, need to explore their own, learning cost is no lower than Scala. Still have high IQ!

3. Code reading Difficulty
   Because Golang's code format is mandatory, it's basically easier to read than many languages. But involves the use of the channel module, because very flexible, some coder write out the code, do not ask a question, really do not understand. ^ _ ^ This involves code architecture style, not in the original OO "design mode" has been discussed, I think there should be some good experience.

The future, the money path

Many people learn a language, not because of interest, but because of treatment. It is a reality and must not be avoided. I myself believe that the vast majority of those who are not proficient in two, especially the thinking model are different development languages. So, it is normal to face the choice.
Personally, the treatment is not related to the language, but with the industry, specific unit benefits, luck. Some time ago a postgraduate, network transmission equipment Embedded development 15, treatment only 6500, as we are now engaged in the service side of the development of less than 1 years of specialist graduates. The same industry in different units do not say, the traditional field, the central enterprises, institutions, and private enterprises, it is the same clear black and white.

Scala or go

Regardless of the development language, most patterns, architectures, and professional background knowledge are the same in addition to syntax and partial frameworks. Language is different, more embodies in the combination of tools, ecological chain, each has a good side. Most of the time, language choice lies in business needs and Team Foundation.
1. Operational aspects
The same service-side program, Scala focuses on data analysis preprocessing, the collection library is too convenient. Other business processes, including industry applications, go is not really the difference. If it is game development, the Internet of things, go is also more suitable for some. Think about it, 256M of running memory, you can easily do more than 5K long connection + memory business processing, whether it is very exciting!
2. On the team side,
If the team allows about 1 years of time to toss, Java resources are familiar, there are a lot of server resources, choose Scala good. Forgive me, I always thought Scala's actor model was very resource-intensive. In essence, Scala simply encapsulates the reactor (proactor) schema +bridge (or reflection) to achieve message distribution and response (Akka also encapsulates service discovery, consul protocol as used by gossip). Just what we showed to see this frame. However, when interviewing Scala programmers, the screening cost is much lower, which is actually an advantage.
If three months to reach a large concurrent server, team members C (c + +) more or the membership level is not aligned, the boss cares about the cost of servers. Go is a good choice. This thing is like foreign college entrance examination, wide into the strict out. No good code, better than no code, right?! The problem is that Golang's business is too flexible, and if someone says go for a year, the price is not good to judge.

Both languages are very fond of me. Scala's syntax encapsulates a large number of design patterns, which greatly reduces development costs and focuses on "use." But the go language wins in the grammar simple but also loses the bright spot: the static deployment, the multiple return value, the function + the closure, the simple concurrency + message channel, is more focused on "creation". It is because the core grammar of the go language is not much, in the middle and late, to make a good program framework than Scala burning brain. To really be able to play the CSP, but also in the "design mode" need to accumulate a lot of experience, need to continue efforts!

The expectations for go, not just better C

It is not easy to play a language, and the individual is optimistic about the development of the go language, but at present it is compared to the rapid development of swift, rust, like a rudimentary hair embryo room. It is said that golang1.7 support PKG package directly compiled, this independent developer provides the possibility. Personally, I hope that if we can provide the following points as soon as possible:

1. Unified Package Management
   Lack of a clearly displayed version, the integrity of dependencies can not be verified, has been the team faced with engineering problems. There is an urgent need to be similar to Marven, SBT and so on. GODEP, Govendor, glide, GVT ... Too much, too much, eight Immortals crossing. One, unified, can.
2. Generics, enumeration support
   It is said that Java generics are actually dynamic transformations inside, but is it not better to find the problem at compile time? The Forum mentions Golang 2 support and does not know when.
   As for enumerations, although simple validation can be done with type definitions, they are still open and limited. Does go not emphasize the same?
3. More basic library of data structures
   At present, there are only two-way linked list, ring linked list, heap in container container. Red-black tree or AVL tree, queue, clear stack ..., no. Rely on a third party, or write one according to the textbook, Always trouble.
4. Ternary operator
   This was supposed to be a detail, but a craving for this grammatical sugar. Otherwise seeing if means 3-5 rows. (Maybe it's a matter of implicit conversion, I don't care.) ）
5. Other
   If possible, lambda, FP, collection library, I also very much like. I hope, don't let me dream too long!

Assorted wrote a lot, temporary think, not too comb, so it.