This release includes significant changes to the implementation. The compiler tool chain was translated from C to Go, removing the last vestiges of C code from the Go code base. The garbage collector was completely redesigned, yielding a dramatic reduction in garbage collection pause times. Related improvements to the scheduler allowed us to change the default GOMAXPROCSvalue (the number of concurrently executing goroutines) from 1 to the number of logical CPUs. Changes to the linker enable distributing Go packages as shared libraries to link into Go programs, and building Go packages into archives or shared libraries that may be linked into or loaded by C programs (design doc).
I would like to see IDE integration (full debugger support) and some form of templates / generics (compile time like C++ but don’t need to use TMP).
I would look at using the language with that.
From what I understand, Go interfaces are templates without TMP, and without explicit declaration of templates. They’re not Java interfaces or mixins, but sort of like templates with member matching.
Personally, I’ve grown to rely on TMP, not for silly precompilation calculations, but for type deduction and compile-time dispatch, which I don’t think is possible with Go’s interfaces.
My objection is how it essentially boils down to needing to cast things like we used to do in C (void* anyone?).
Seems a really lovely language to me. But as long as it does not feature true inheritance I cannot quite warm up to it.
For me object orientation is more about access control than polymorphy. I like to view a class as an actor. As a result, means to build a private sphere is a must for me.
For me it is all about avoiding code duplication when used sensibly. I have not seen a convincing alternative brought forward.
Inheritance should not be about code duplication. Go’s interfaces can just as well avoid code duplication. Inheritance should only be used for expressing a relation between types, code reuse notwithstanding.
in my opinion an interface shall contain declarations only. No code. So my question is, how do Go’s interfaces help?
I think Go’s interfaces are declarations only.
Basically an interface is a defined method set. For example, you can write a sort package that defines a Sorter interface that requires the methods: Less and Swap. You can than implement your sorting functions based on the Sorter interface of Less and Swap. Now, anything that implements the Sorter interface (e.g. Less and Swap) can use the sorting functions in the package.
OK, Go’s interfaces work as in Java or C#.
No, as in, I don’t think it uses dynamic dispatch. It is a completely compile time affair. Like with C++ templates. Unlike C++, where a type’s methods are implicity (eg, T.do()), you explicitly declare that your function requires a T that has do(). The call to T.do() is compiled in, just like in C++, except that you don’t get the huge error messages.
But it can’t do SFINAE or variadics.
No, go interfaces use dynamic dispatch.
See the discussion here: http://research.swtch.com/interfaces.
I stand corrected.
Go provides public/private methods, const, functions, etc. Go does not use a keyword but capitalization. If the identifier begins with a lower case letter, it is private. If the identifier begins with an upper case letter, it is public.
Inheritance is bad and you should feel bad.
Inheritance is neither evil nor good by itself.
It is a technique that is very helpful when used properly. But can hurt if used in the wrong way.
The biggest problem about inheritance is, it is often used the wrong way. The Liskov substitution principle (Barbara Liskov, 1987) which is isomorph with the more easy to understand design by contract principle (Bertrand Meyer, 1986) is often not recognized.
Almost all books on OO use examples which do not comply with this very basic principle. That is the main problem with inheritance.
Go provides composition and interfaces which cover much of the use cases for inheritance. But, it is not quite the same and takes some getting used to.
What is this ‘true inheritance’ you speak of. I Googled it, but all I got was mystical gobbledygook. Then I added ‘language’ to the search, and the first programming related link I got was for Prototype based programming. I figure you mean something related to sharing implementations or interfaces explicitly, but can’t be certain which, and C++, Java, Javascript, and Sather all go about things slightly differently.
So perhaps you could provide an example of what you mean and why it is important to you, and why it’s lack in Go makes the language inadequate. Because otherwise we’re just talking religion.
I am thinking of a scenario where I have parent class that implements some functionality in a method and a subclass that implements it differently. Now if I have another subclass that does not need to modify the functionality of the parent class it will just inherit it. So we have two pieces of code used in three cases.
Somewhere else I might have a routine operating on an instance of eighter of these classes, not caring which, that wants to just call the method and have the appropriate code executed.
I to date have not seen a suggestion how to implement this cleanly and well structured without inheritance.
Do someone knows how does this new Go compare with Rust performance-wise?
Performance is quite hard to measure, what is sure is that even though the GC induced delays have been reduced they’re still there but Rust doesn’t have a GC so it doesn’t have the corresponding delays..