Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Child pages (Children Display)

 


Reviews of the language

  • 2015.04.21 - Evan Miller - Four Days of Go
  • 2017.08.22 - Michal Konarski - 5 things about programming I learned with Go
    1. HN discussion
    2. It is possible to have both dynamic-like syntax and static safety
      1. Go is not an object-oriented language. But it does have interfaces. And they are pretty much the same as these you can find in Java or C++. They have names and define a set of function signatures.
      2. Then we have Go’s equivalent of classes - structs. Structs are simple things that bundle together attributes.
      3. We can add a function to a struct.
      4. Go uses a concept called “automatic interface implementation”. A struct containing all methods defined in the interface automatically fulfills it. There is no implements keyword. Isn’t that cool? A friend of mine even likes to call it “a statically typed duck typing”. Thanks to that feature and type inference that allows us to omit the type of a variable while defining, we can feel like we’re working in a dynamically typed language. But here we get the safety of a typed system too.
    3. It’s better to compose than inherit
      1. if we want to mitigate the risk of getting lost inside the dark forest of code complexity we need to avoid inheritance and prefer composition instead.
      2. Go doesn’t support inheritance at all.
      3. There is a feature called embedding. Every method in an embedded interface is accessible directly on the struct that the interface is embedded in.
    4. Channels and goroutines are powerful way to solve problems involving concurrency
    5. Don’t communicate by sharing memory, share memory by communicating.
      1. Instead of using locks to control access to a shared resource, Go coders can simply use channels to pass around its pointer. Then only a goroutine that holds the pointer can use it and make modifications to the shared structure.
    6. There is nothing exceptional in exceptions
      1. there is nothing exceptional in exceptions. They are usually just one of possible return values from a function....it’s good to think about exceptions like they were regular return values. Don’t pretend that they just won’t occur.
      2. f, err := os.Open("filename.ext")
  • Quora - Why did Google create the Go language? Isn't Python good enough?
    • "Python is a dynamically typed language, and as such it can present, er, challenges for working on large programs, in large teams. A quick example, is that if you make a function in Python to call, and call it from a few places, you’ll find that if you change the number of parameters, or types of parameters that the function takes, there is no compile time error, only a runtime error. Now that’s no big deal on a small program of only a few hundred or even few thousand lines, but once you go up to hundreds of thousands of lines, or millions of lines, working with hundreds of other people, it’s a major problem.Statically typed language like Go turn that runtime error into a compile time error, and it’ll point out each and every time that function is called with the wrong parameters. This is a huge difference, when working on medium or large scale projects."

    • "Python is very good at making programming simple and easy, but it suffers a performance hit compared to compiled languages. Compiled languages such as C or C++ are very fast, but they're not as simple and easy to use as Python. Go aims to be almost as easy to use as Python while being compiled, and almost as fast as traditional compiled languages. It's also very good at concurrency by design, which is its main strength."

  • Go FAQ - Why are you creating a new language?
    • We wanted the ease of programming of an interpreted, dynamically typed language...
    • ...and the efficiency and safety of a statically typed, compiled language.
    • Finally, working with Go is intended to be fast: it should take at most a few seconds to build a large executable on a single computer.

...

 

 

...