Concise GO language and future language trends ?, Future trends of the go Language

Concise GO language and future language trends ?, Future trends of the go Language

It is actually two words --Concise!

Many of my friends' comments think that such things, such as "less braces and less semicolons", do they really mean anything? The problem is, since there is no such thing, why? Why is it fun to play less than one character? Do you still think it is justified? Here is a little simpler. In general, is it much simpler? The design here is concise and concise. Is it compact and efficient as a whole?

A lot of things can be truly powerful only by understanding them as a whole. Without the support of these syntaxes, how can we make the design concise?

 

I firmly believe that less is more, simple is more powerful, and a design that cannot be reduced by one is truly a good design!

 

Simple variable declaration and value assignment

In the simplest declaration variables and values, the following sentence completes the Declaration type to the value assignment, and finally the common Semicolon is used as the end of the statement.

Var I int = 10;

This is not concise at all, right? Why is "var" required "? Why cannot I deduce the variable type by myself? Why must I add a semicolon at the end? I believe that the designers of the Go language have also asked these three questions and have made targeted improvements. Come back.

I: = 10

How is it? ": =" Is the syntactic sugar that declares and derives the type, and the semicolon at the end is also saved, because here I wrap the line and the compiler understands.

You can also declare and assign values to multiple variables at a time.

I, j, k: = 1, 2, 3

Different types are also supported.

I, j, k: = 1, 1.0, "hello"

What if I want to declare a bunch of variables without assigning values for the moment? Yes.

Var (

    i, j int

    s string    u, v, s = 2.0, 3.0, "bar"

)

The Go designers even thought that they should not play a few more "var!

 

Concise if

A little interesting, right? When I learned a new language, I first looked at the variable type and declaration, and then I went to the logic control syntax. Now let's take a look at what is there?

If I> 10 {

Println ("Greater then 10 ")

}

It's common. Can a simple if statement be simpler? Well, it is. First, the condition judgment behind if is no one forces you to add parentheses. It's just two fewer buttons. What else? And! The following is a common if application scenario.

Result: = SomeMethod ()

If result> 0 {

}

In many cases, the result variable is only used for condition judgment and can be discarded after if. Therefore, Go has such a statement.

If result: = SomeMethod (); result> 0 {

}

This expression is too often used. Who knows it? Every time I write a line, I feel a good feeling. Let's take a look at the tangle of if segments.

If {

} Else if B {

} Else if c {

} Else {

}

This method can be used, but it is not recommended by Go. The reason is that it can be simpler. For example, a powerful switch.

 

Powerful switch

This is a well-known switch usage. Note that there is no break! In Go, case is not "underworn ".

switch tag {    default: 

        s3()    case 0, 1, 2, 3:

        s1()    case 4, 5, 6, 7: 

        s2()}

A magic switch, hey, is the same as if.

switch x := f(); {  // missing switch expression means "true"    case x < 0: return -x    default: return x}

In addition, with this more explicit method, you will still... Else if... Else if... Else... ?

switch {    case x < y: f1()    case x < z: f2()    case x == 4: f3()}

The condition judgment is comfortable. What about the cycle?

 

Lonely

In fact, I have never quite understood why multiple loop syntaxes should be provided in a language? For, while, do... While... Are they all irreplaceable? Which one is used? It seems like they all look at personal hobbies, right? You may just give an example to prove the differences between the three things, but for me, if there are multiple ways to do the same thing, the design redundancy will cause more or less troubles to users. Let's take a look at the Go loop.

For I: = 0; I <10; I ++ {

}

For a <B {

}

For {

}

Let's see, one for will handle all the situations. Let's look at a commonly used traversal set, which can be written as one.

Count: = len (someArray)

For I: = 0; I <count; I ++ {

Println (someArray [I])

}

To simplify this process, Go provides a keyword "range", which is used first.

For I, value: = range someArray {

// I is an integer that represents a subscript.

// Value is the type of the value in the array.

}

Range can be used not only for arrays, but also for any set, such as map.

m := map[string]int{"mon":0, "tue":1, "wed":2, "thu":3, "fri":4, "sat":5, "sun":6}for i, s := range a {    // type of i is int    // type of s is string}

Here we only mention some of the most basic syntax scenarios. There are many more in Go!

 

The function can return multiple values.

In fact, there are many languages that can assign multiple values in a row, but only a few can return multiple values in a function. For example, if two int values are returned in C #, this is usually the case.

Public class TwoInts

{

Public int;

Public int B;

}

Public class Foo

{

Public TwoInts ReturnTwoInt ();

}

Then, can TwoInts ti = foo. CalcTwoInt () feel sad? Maybe you're all numb, right? Many languages are designed in this way. The biggest problem that a function can return only one value is that there are many unnecessary data structures. The above shows this redundancy. Of course, you can use the out keyword to let the function return, but this syntax is not so secure. This problem is too easy to solve in Go, because the Go function can return multiple values!

Func returnTwoInt () (int, int ){

}

A, B: = returnTwoInt ()

My preference for Go comes from here, which removes a lot of data structures in my library! This virtually reduces the complexity of the design.

 

The Object Pointer declared in the function can be returned safely.

Func ReturnPointer () * Object1 {

Obj: = new Object1 ()

Obj. A = "hello"

Return obj

}

Go's garbage collector will handle this situation, so don't worry!

 

Exception Handling? What is defer? Can you eat it?

Why is Exception Handling so complicated? How many people can safely implement the following logic? The following is the pseudocode.

File f = File. Read ("c: \ text.txt ")

F. Write (xxx)

F. Close ()

I believe that experienced coders instantly see various versions of try... Catch... Finally ..., There are also a variety of writing specifications, such as the logic in "catch" cannot throw exceptions or other things. In fact, our requirements are simple. Open a file and ensure that it is closed at the end. That's all. Why is it so complicated to do such a simple task? Let's see how Go works!

Func SaveSomething (){

If f, err: = OS. Open ("c: \ text.txt"); err = nil {

// Various read/write operations

Defer f. Close ()

}

}

All functions with defer are executed after the current function (SaveSomething) is executed. Even if an exception occurs during "// various reads and writes", f. Close will be executed firmly when SaveSomething exits. With this, it is no longer necessary to release some resources and close a handle!

 

The interface no longer needs to be "implemented"

As a result of my understanding of OO, all languages with interfaces require Class "implemented" interfaces in different ways. I have always considered this method to be justified, until I met Go.

Type Speaker interface {

Say ()

}

An interface is defined above. There is only one method, Say, no parameters or return values. In Go, all things that have all the methods defined by an interface are implemented by default. This is a sentence with too many connotations, it is enough to have a significant impact on the design ideas. For example, the following method accepts a parameter of the Speaker type.

Func SaySomething (s Speaker ){

S. Say ()

}

All the things that have the Say () method can be put in the past.

In the Go world, all things implement the interface {} by default. With this concept, the design complexity can be effectively reduced even without generics.

 

Can multithreading be simpler?

To write multithreading, you need to understand Thread, various locks, and various semaphores. In various systems, "Asynchronous" logic usually represents "difficult ". This is the strongest part of Go. Have you ever seen this simple asynchronous Code (the following code is taken from the official example of Go )?

Func IsReady (what string, minutes int64 ){
Time. Sleep (minutes * 60*1e9 );
Fmt. Println (what, "is ready ")
}
Go IsReady ("tea", 6 );
Go IsReady ("coffee", 2 );
Fmt. Println ("I'm waiting ....");

The execution result is: Print:
I'm waiting... (right away)
Coffee is ready (2 min later)
Tea is ready (6 min later)

The Go language has the built-in "go" syntax. Any go method will be executed asynchronously. What about passing messages before the asynchronous method? Use a channel. Its name is a pipeline, one writing in, and the other waiting for reading.

Ch: = make (chan int) // create a pipe that can only pass Integer Data

Func pump (ch chan int ){
For I: = 0; I ++ {ch <-I} // write a value to the pipeline
}

Func suck (ch chan int ){
For {fmt. Println (<-ch)} // wait until there is a value coming out of the pipeline.
}

Go pump (ch) // asynchronous execution of pump

Go suck (ch) // asynchronously execute suck

Then you can see that a bunch of numbers are output on the console.