Why don't you use go?

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

This article is translated from Dr. Dobb's editor Andrew Binstock's article "Why not Go?".

Go is an important reflection of the native language of the system, and it has made significant improvements to the C language, while preserving the minimalism of the language.

Earlier this year, we wrote an article on the native (native) language of emerging systems. These languages include D, Go, rust, and Vala. We were committed to exploring these languages in detail at that time. Starting this week, we'll start a series of discovery tours of the new language go from Google, which has five parts. Unlike previous Dr.dobb's tutorial series, we will publish these articles in a matter of weeks, so you can get to know the language in a timely and faster way.

The go language is more appealing to me than the other languages on this list. Although I'm not a go language expert, I like what I've seen so far about go. As you can see, my pleasure comes from appreciating the full range of language features, not the kind of enthusiasm that comes with the new language debut (I admit that I am also susceptible to this excitement – which is why I can identify the difference between the reasons I like go). The following features are especially appealing to me:

Simple and fast compilation . The go language compiles fast. In fact, it compiles so fast that it can be easily used as a scripting language. Several reasons for the speed of compilation include the fact that it does not use a header file, if a module relies on a, and a depends on B, then when a change occurs in a, it is only necessary to recompile the A and a dependencies, and finally, the target module contains enough dependency information so that the compiler no longer needs the make file. You simply compile the main module and it will automatically compile all the modules in the project that need to be updated. Isn't that cool?

error handling through multiple return values . There are two main types of error-handling paradigms in system-native languages today: similar to the return value in C, or similar to an exception in OO language. Both of these paradigms are less than ideal. In both cases, however, the return value paradigm is more frustrating because the returned error code often conflicts with other data returned from the function. Go solves this problem by allowing the function to return multiple values. You can specify that a value returned from a function represents a type error and that it can be checked at any time the function returns. If you don't care about this error value, you can not check it. In either case, the general return value of the function is available for you to use.

a simplified combination (not inheritance). As in Java, a type can be a member of an object by specifying the behavior by using interface. For example, the IO package in the standard library defines a writer that specifies a method: A write function that returns an integer value and an error type with an array of characters as input parameters. Any type that implements the same signature as this write method is IO. A de facto implementation of the writer interface. This design gracefully removes the coupling in the code. It also simplifies the implementation of mock objects when unit tests are made. For example, if you want to test a method in a database object, in a standard language you need to create a database object to create a mock, which requires a lot of initialization and protocol implementation work. In the go language, if the tested method implements a interface, you can use this interface to create arbitrary objects that are handy to use. This way you can create mockdatabase, which is a minimal object, and only need to implement some necessary methods to use the interface– that need to be mocks without constructors, without the need for new features, as long as the method.

simplified concurrency . Concurrency is fairly easy in go. Putting the keyword ' go ' in front of any function will run in its own go-routine (a very lightweight thread). The channel is essentially a blocking message queue between go-routine through channel communication. Common mutex tools are available in go, but the go language simplifies such operations by initiating concurrent tasks and collaborating through the channel.

very good error message . In the language I have seen, no language can match go to the output of diagnostic information. For example, if a program is deadlocked, the go runtime notifies you, even to the extent that it tells you which thread caused the deadlock. The compiler output error messages are also very detailed and useful.

A hodgepodge : The go language has other compelling features, and here's a quick tour: higher-order functions, garbage collection, HashMap, and an extensible array built into the language (part of the language syntax, not through libraries).

Of course, not all things are rainbow lollipop. The tool is still immature and the development community is small, but the lack of a company like Google, backed by the go language, will certainly be offset. Many languages-especially d, dust, and Vala-are dedicated to simplifying C + + and adding specific features, which makes me feel more like "C + + with better features", while the go language has an important rethinking of how the native language of the system works in its design connotation. It is out of this recognition that a graceful realization that has removed many problems was born. Even if you don't have a particular need to think about using the go language, I think the most straightforward way to get to know the language is that you'll find many features of go that will make you look pleasing. cheers!

, Bigwhite. All rights reserved.