Written by
created: 2009 11 12
updated: 2009 11 14

Go language, Google's scripting language

Some considerations and proposals on programming starting from Mountain view's new language.

What Google claims
[...] Go attempts to combine the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. In our experiments with Go to date, typical builds feel instantaneous; even large binaries compile in just a few seconds. And the compiled code runs close to the speed of C. Go is designed to let you move fast. [...]
Go to Golang.org

My point of view
- Go is a scripting language, not a programming one, we could say that is a compiled scripting language
The basic idea is good: simple as scripting language, fast as a compiled one...but I got some doubts on implementation.

-Because Go is designed for scripting it could easily lead to spaghetti code, first of all because of the lack of namespaces and class hierarchies, and, generally the complete absence of object oriented programming.

- Go does non implement in any way object oriented programming.
I'm not a fanatic of object oriented programming, I believe that a modern programming language should allow different paradigms, so Go should implement object oriented features completely.
I think that Google should and could aim to improve and extend object oriented programming, not remove it completely.
For example: how many times, while coding an object, we declare private properties accessing them publicly with respective public methods?
This pattern is widely used, and it clearly makes the code verbose.
So: why don't extend properties' visibility control to solve this (and other) problems?
example: public property => public readonly property
/*the property "property" is public in readonly mode, an attempt to write it outside object's scope raises a compilation error*/
Someone could think that this feature, in languages like C++, is still available, the const modifier (introduced by Bjarne Stroustrup, and called initially just readonly) allows infact a readonly access; but the variable cannot be written dynamically. (The programmer must define it explicitly in the code).
About this kind of problem we can say more.
Besides a readonly modifier for object's properties a writeonce modifier for variables in general should interesting too: a const variable (writable only once) both compile time and runtime.
Let's go on: the absence or the presence of data is only the first characteristic of what I personally call shaping.
How many times, while programming, we must control and filter variable's values?
Maybe this proposal is too data oriented but I think that we should consider a form of strongest typing: define not only the type of a variable but also its shape, performing an immediate consistency control.
examples:
int x; becames (optionally) int[range:<5] x; /* We define an integer x and its value must be < 5 */
string x could be shaped like this string[length:>3,<20] x /* We define a string x and its length must >3 and <20 */
Notice: do not mind at syntax consistency (it should be obviously engineered properly and adapted to the specific language); consider also the shape is intended to be optional and fully compatible with a non-shaped declaration.

- Go introduces Multiple return values and Named result parameters. I think that everything should be implemented in a different way.
The usage of named return values or multiple return values is essentially equivalent to the definition of N variables outside the function/method passed to the function itself by reference.
Go simply splits parameters in two groups: the first is made of "old style" arguments (passed by reference or by value), the second one contains only variables passed by reference. I don't see any usefulness and, considering that a return value in a strong typed programming language defines the type of the function/method, I believe that put the declaration of return values after function parameters is a lack of coherence in language syntax engineering.
In my experience I never need something like multiple return values or named result parameters, but I've felt many times the needing of something like a multiple type return value, a return value of (potentially and optionally) different defined types.
More generally: the possibility of declare a variable of N potential defined types. (variable overloading)
This kind of solution, in my opinion, preserves the well known advantages of strong typing extending it with more flexibility but avoiding the dangers and the annoyances (like if-else controls on type) of a week typed language.
Variable overloading would be a powerful feature used, for example, with method overloading. (That Go does not implement) A simple example:
[string,bool] test() { FUNCTION BODY} /*test could be a string or a bool*/
Let's now define a simple "manager" for "test".
 class manager { public: void execute(bool input) { std::cout << "bool";} void execute(string input) {std::cout << "string";} }; 
...now let's use it
 [string,bool] x = test(); manager y; y.execute(x); 
...no if is used!
Variable overloading should be useful to solve the problems that Go's multiple return values and named results parameters are trying to solve.
Let's consider a real problem in Go
func (file *File) Write(b []byte) (n int, err Error)
Now let's rewrite it with variable overloading
[int,error] File::Write(byte b) {}
Someone could say: why don't use exceptions? (...Go does not have exceptions)
In this example I will sure prefer to catch an exception, but sure exceptions are over-used. (This is not a good reason to completely remove them).
For example: I would use variable oveloading instead of exceptions when I need to stop the execution of a method in a defined condition and this condition is not an error or an exceptional situation but is perfectly legal, expected or high probable.

- Let's have a look to Go For C++ Programmers (My considerations, it should be clear, have C++ in mind)
[...] Go does not have classes with constructors or destructors. Instead of class methods, a class inheritance hierarchy, and virtual functions, Go provides interfaces, which are discussed in more detail below. Interfaces are also used where C++ uses templates.[...]
This is a limit related to the absence of object oriented programming, the main limit of Go
[...]Go uses garbage collection. It is not necessary (or possible) to release memory explicitly. The garbage collection is (intended to be) incremental and highly efficient on modern processors.[...]
In c++ you can create an object in the stack or in the heap...in my programming experience 99% of objects are created in the heap and so destroyed automatically when scope visibility ends.
[...] Strings are provided by the language. They may not be changed once they have been created.[...]
Maybe execution is more fast...but what about language usability?
[...] Hash tables are provided by the language. They are called maps. [...]
...what about STL containers?
[...] Go does not support function overloading and does not support user defined operators.[...]
Function/method overloading makes the code more readable (limiting, first of all, the usage of "if-else"), it allows an higher level of abstraction and a a more easy extension of objects; operator overloading is a feature that you can simply ignore. (You can...not you must)
[...] Go does not support const or volatile qualifiers.[...]
...C++ does.
[...] Go uses nil for invalid pointers, where C++ uses NULL or simply 0. [...]
Not completely true: the upcoming c++ standard (C++0x) will implement the nullptr feature.
A null pointer will be a "null pointer" not a integer or a bool or an empty string...just a null pointer.
Everybody knows clearly how this lack in c++ can be tedious and error prone.