Linked by Thom Holwerda on Wed 19th Aug 2015 21:01 UTC
General Development

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 GOMAXPROCS value (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).

Order by: Score:
Two things more please
by zzing on Thu 20th Aug 2015 04:27 UTC
zzing
Member since:
2014-10-03

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.

Reply Score: 1

RE: Two things more please
by kwan_e on Thu 20th Aug 2015 11:17 UTC in reply to "Two things more please"
kwan_e Member since:
2007-02-18

I would like to see [...] 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.

Reply Score: 2

RE[2]: Two things more please
by zzing on Thu 20th Aug 2015 16:58 UTC in reply to "RE: Two things more please"
zzing Member since:
2014-10-03

My objection is how it essentially boils down to needing to cast things like we used to do in C (void* anyone?).

Reply Score: 1

Wish it was object oriented
by ThomasFuhringer on Thu 20th Aug 2015 10:16 UTC
ThomasFuhringer
Member since:
2007-01-25

Seems a really lovely language to me. But as long as it does not feature true inheritance I cannot quite warm up to it.

Reply Score: 2

RE: Wish it was object oriented
by pica on Thu 20th Aug 2015 11:02 UTC in reply to "Wish it was object oriented"
pica Member since:
2005-07-10

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.

Reply Score: 2

ThomasFuhringer Member since:
2007-01-25

For me it is all about avoiding code duplication when used sensibly. I have not seen a convincing alternative brought forward.

Reply Score: 2

kwan_e Member since:
2007-02-18

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.

Reply Score: 2

RE[4]: Wish it was object oriented
by pica on Thu 20th Aug 2015 13:00 UTC in reply to "RE[3]: Wish it was object oriented"
pica Member since:
2005-07-10

in my opinion an interface shall contain declarations only. No code. So my question is, how do Go's interfaces help?

Reply Score: 2

kwan_e Member since:
2007-02-18

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.

Reply Score: 2

SlothNinja Member since:
2011-03-22

in my opinion an interface shall contain declarations only. No code. So my question is, how do Go's interfaces help?


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.

Reply Score: 1

RE[6]: Wish it was object oriented
by pica on Thu 20th Aug 2015 15:01 UTC in reply to "RE[5]: Wish it was object oriented"
pica Member since:
2005-07-10

OK, Go's interfaces work as in Java or C#.

Reply Score: 2

kwan_e Member since:
2007-02-18

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.

Reply Score: 2

SlothNinja Member since:
2011-03-22

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.


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.

Reply Score: 1

RE: Wish it was object oriented
by kwan_e on Thu 20th Aug 2015 11:18 UTC in reply to "Wish it was object oriented"
kwan_e Member since:
2007-02-18

Seems a really lovely language to me. But as long as it does not feature true inheritance I cannot quite warm up to it.


Inheritance is bad and you should feel bad.

Reply Score: 2

RE[2]: Wish it was object oriented
by pica on Thu 20th Aug 2015 11:49 UTC in reply to "RE: Wish it was object oriented"
pica Member since:
2005-07-10

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.

Reply Score: 4

RE: Wish it was object oriented
by SlothNinja on Thu 20th Aug 2015 14:30 UTC in reply to "Wish it was object oriented"
SlothNinja Member since:
2011-03-22

Seems a really lovely language to me. But as long as it does not feature true inheritance I cannot quite warm up to it.


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.

Reply Score: 1

What IS object oriented?
by anon.adderlan on Sun 23rd Aug 2015 11:08 UTC in reply to "Wish it was object oriented"
anon.adderlan Member since:
2015-04-02

Seems a really lovely language to me. But as long as it does not feature true inheritance I cannot quite warm up to it.


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.

Reply Score: 1

RE: What IS object oriented?
by ThomasFuhringer on Mon 24th Aug 2015 09:02 UTC in reply to "What IS object oriented?"
ThomasFuhringer Member since:
2007-01-25

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.

Reply Score: 2

Rust
by ebasconp on Thu 20th Aug 2015 14:43 UTC
ebasconp
Member since:
2006-05-09

Do someone knows how does this new Go compare with Rust performance-wise?

Reply Score: 2

RE: Rust
by renox on Mon 24th Aug 2015 12:29 UTC in reply to "Rust"
renox Member since:
2005-07-06

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..

Reply Score: 2