I’ve always liked to see and try different technologies, and within these, of course, programming languages.
An example of this was the intensive use I gave at the time, at Arrakis, to Rebol, an interpreted cross-platform language, with everything you could need to perform great data cleaning scripts, in a “strange” syntax, but beautiful in its approach.
The case of Go was a bit different, because just like what happened to me with Angular, at the time (several years ago) I tried to give it a chance, but all the information and examples I found were “very small” blocks of code, I didn’t see in that (at a bird’s eye view) that it was finished, it seemed like a more academic/conceptual language than something for real use.
Years passed and when I looked at it again, the examples were the same, just as small, the code was just as simple. How can this be?, I reviewed some projects made in Go, and my surprise was that they were always like that, they weren’t code “snippets” that could be seen, they were real and complete code.
Having detected my perception error, hands-on with Go, in one afternoon I had already made several proof of concepts:
- A crawler using the Tor network
- Migrate several PHP-Beanstalk task scripts to Go
- ElasticSearch client
- A MongoDB document to ElasticSearch document transformer
- A Json (parser) to XML transformer
- A MySQL to MongoDB transformer
- …
Each one simpler than the previous, and always maintaining simplicity.
That’s Go’s premise: code must be Simple, as simple as the language itself, where its definition (Specs) is 51 pages compared, for example, to Java’s 781 pages.
In Go, we have many elements known from other languages and others completely different, an example is “concurrency”: Go is designed to execute “concurrent” processes, Goroutines, and when we see them for the first time we think of Threads. In Go, Threads don’t exist (from the language’s point of view), but independent and concurrent processes, which also doesn’t mean they execute in parallel (it seems contradictory but it’s Go’s way of calling things). In Go, you can execute something in an “independent process” and, it may execute in parallel to other processes, everything will depend on the assigned processors, but it will execute without stopping the current process (execution thread). It sounds weird, but it’s independent execution (concurrent if possible).
Criticisms and comparisons are based on erroneous premises: Comparing apples to oranges, it’s not that it’s not comparable, but what it is and what it’s for is simple, and what some may consider “limitations” are language features. Examples:
Go is not 100% OOP:
Why should it be? In Go, there are “classes” (Structs) and “objects” (instances of), and they have methods (associated functions), and can implement interfaces. Everything does it in a different way, neither better nor worse, different, and knowing it’s not a problem when using it, it’s only a characteristic to keep in mind.
There are no constructors, because they’re not needed.
Interfaces, they’re not declared in the class definition, they’re defined externally, and if the class complies with it, it implements the interface. To a large extent here, when developing, we enter the question: “What comes first, the interface/egg or the class/chicken”
Inheritance: It exists but it’s “particular”, and perhaps a bit obscure for my taste.
Polymorphism: Absolutely not, since Go is static typed, although it can be emulated.
Namespaces: They’re simple, and yes, there can be “conflict” of names of your packages and others, but you can use aliases, but… and this is the interesting part of Go, since you must (by convention) divide the code into packages with functions organized by “their function” and they should be small, it’s difficult that you need to use in each one many packages that have that name conflict.
Visibility of class properties: Being Go so simple, they eliminated in one stroke defining in the language if a property is public, private,… in Go, if a property starts with uppercase it’s “exported” (it’s public) otherwise it’s only visible in the object, the same applies for methods and functions within a package.
Exceptions: In Go, there are no exceptions, neither as a concept nor as an execution control element, more… there are no “errors” in Go (in the language definition), thus eliminating much need for processing and memory when controlling execution (optimization). It’s in your hands to define, when something is executed, what it must “return” when something “unexpected” happens and act accordingly.
Since Go is a compiled language, and also cross-platform (and allows generating the binary for another platform: Windows, OSX, FreeBSD, Linux x86, Linux 64, Linux Arm…) it gives us full freedom and ease when doing tests and deployment (there are no previous requirements), everything it needs is statically linked in the binary.
It’s simply simple and fast to compile on OSX the binary for my Raspberry PI 2, upload it and execute it.
I know this “brick” of text is poorly organized, but I’ve simply written it as I think I would have said it aloud, I’m missing many things, and others perhaps too many, here I lack the simplicity and conciseness of Go 😉
Comments