Google Go OOP

[iamthwee]

So it seems google's go is changing the programming landscape, well there probably were other languages out there before but the google-sphere seems to deliver more clout, people take notice.

Google Go appears to have done anyway with classical OOP, especially inheritence, although it can be realised via other ways. In my opinion inheritence is a flawed experiment anyway and is often mis-used in real life situations so that the benefits soon become impractical.

Additionally, the issues specifically to do with multi-threaded applications,( thread locking etc) seem to have a nice replacement in 'go routines' and channels. I really like this idea, I've downloaded the google install for my posix systems and I'm playing around. I especially love the way you can create a simple socket server.

Anyhow, google Go appears to be geared towards the replacement system's programming language. I would love to hear the opinions of others, especially those who have written system like applications (threaded) in c/c++.

I would like to know what your take on this is, have you tried Google go? How are compilation times, syntax, their garbage handling.

And first glance I'm pretty much impressed.

[diafol]

Not into C/C++ but it looks super-cool. However like a lot of languages, it has packages. Argh. How the hell do you remember which commands/functions are in which package? Is there a hint other than the documentation?

[iamthwee]

Sublime snippets my friend, no other editor in the world compares.

http://geekmonkey.org/articles/20-comparison-of-ides-for-google-go

A rather interesting introduction to concurrency. Worth the watch.

https://www.youtube.com/watch?v=f6kdp27TYZs

Looks like Google go might usurp all the other web languages such as php+apache, python django, java and asp.net as the language of choice in time.

Having built a simple web server with concurrent connections, I did a timing exercise and it killed all the other languages.

[mike_2000_17]

I've never looked into this language before you mentioned it. It has some interesting elements. I'm glad you got me to look into it.

First, I love the built-in concurrency support in Go. It has Ken Thompson's finger-prints all over it. It's basically structured like Unix pipes, which are awesome. This whole way of doing concurrency is something that I have grown to love. I wish there was more support for this in C++, the C++11/14 mechanisms like future/promise and async go a long way, but are not quite there yet, but there is more juicy stuff to come in C++17, so I've heard.

Second, the ditching of inheritance in favor of "interfaces" (as it's called in Go) is another cool decision. I use this pattern all the time in C++, and I much prefer it to the traditional OOP patterns (inheritance), I even wrote a tutorial about one form of it. It's part of a trend, mostly born out of modern C++ practices, that is about realizing that dynamic polymorphism is great but inheritance is just the wrong way to do it. Inheritance is still useful for boilerplate code in generic programming (and a few other techniques), but since Go doesn't support generic programming, I guess it doesn't matter. But I love the way Go makes the creation of such "interfaces" so seamless and clean. C++ is about to have a feature called "concepts" that I believe could be used for a similar purpose, I'm seriously considering proposing it to the standards committee.

But the Go language definitely has a lot of important shortcomings too, many of which are painfully obvious. I found this page that is very well written and pretty much summarizes everything I could say is wrong about Go, I agree with everything that is said on that page. These problems are pretty big, and it's really hard to understand how the language designers of Go could have missed those obvious problems.

It feels like Go was built by taking C, adding a couple of cool features (that I just mentioned), and then calling it quits prematurely, leading to a cute but impractical language.

Also, the lack of RAII and exceptions is a show-stopper for me. There's no way I'm going back to the pre-historical age of error-codes and manual resource management.

google Go appears to be geared towards the replacement system's programming language.

Definitely not. Go is anything but a systems programming language (where did you get that idea from?). In fact, I don't really know what space it's trying to compete in. My best guess is that it aims to be playing in the same field as Python (or other high-level server-side languages), while trading-off duck-typing for speed.

google's go is changing the programming landscape

Not really. Go is largely irrelevant. As far as I know, google uses it only very modestly. And I'm not sure what you mean by "changing the programming landscape", it's neither "taking over the world" nor does it contain any paradigm-shifting ideas in it (the cool features it has are nothing new, just not as well known as they should be).

[iamthwee]

In regards to being a systems language:

http://www.eweek.com/c/a/Application-Development/12-Things-to-Know-About-Googles-Go-Programming-Language-859839

The following article mentions the word systems many times. As to being actually useful as a systems language, turning on LEDs or daring to use a garbage collector with low memory usage that is another matter altogether.

Also that article you linked was really well put together about the cons of google go.

I have to admit my interests lie with web development and systems programmes that are usually web servers. This I think is where google's go strength lies. Definitely I've been looking but have never found an inbetween of java and PHP, some language that is easy to write and compiled and doesn't have a a freaking framework.

This is where the 'changing the programming landscape' idea came from. Of course with something quite new, it may take a while to take hold.

[diafol]

Of course with something quite new, it may take a while to take hold.

If ever. There are many good languages out there that failed to grab the attention.

[iamthwee]

If ever. There are many good languages out there that failed to grab the attention.

I think the parody of web languages that exist at the moment, java and asp.net -which are insanely bloated, python and php which are insanely slow and not meant for concurrent applications, will force another language to the frontfront which conveniently sorts out these issues.

[HiHe]

The Python concurrent.futures module provides a high-level interface for asynchronously executing callables.

[iamthwee]

I think the point is the performance issue, and staying in one toolchain without having to fragment your code to gain performance.

[Ene Uran]

I always thought that typing := was one of the less desirable things of Pascal, now GO has picked it up. Otherwise the language has some nice new approaches, some seem to come from Python.

[Reverend Jim]

I think Algol used that form as well. I think it was to appease mathematicians who objected to an equality statement being used for assignment. Same reason that APL uses a left arrow for assignment.

[mike_2000_17]

Following the bits of research I did on Go, I started looking into another recent language, Rust, so I thought I'd share some thoughts about it here too. It's still in a very early stage of development, but it has some truly amazing features. There are a few corners that are still rough, and the language is fluctuating a lot (which is OK, because it isn't really a production-ready language yet). I especially like their statically-validated ownership / lifetimes rules that guarantee memory safety, combined with the "immutable by default" rule, which is a nice way to bring in the benefits of functional programming without the impractical aspects of it.

Also, Rust uses a mechanism similar to Go for their "interfaces", but they call them "traits" and they are closer to C++ concepts (N3701 "Concepts-lite" proposal) as they are checked at compile-time and form "generics" (which actually more like C++ templates, which means no run-time overhead, no indirection, no restrictions, unlike Java/C# generics, which are crap). But the neat thing is that they can also be cast (or coersed) into a run-time mechanism (dynamic dispatch, a.k.a. virtual functions) very easily (through what they call "traits-objects"), which is cool (and it's what I wish C++ would add to the concepts-lite feature too). But if I were to design that feature, I would make those traits-objects have value-semantics instead of the current reference-only semantics, so that they could be used directly in-place of generic parameters (sort of like I demonstrated in my C++ tutorial that I linked to earlier).

The features I love from Rust are ownership / lifetime rules, immutability by default, exhaustive branching rules, pattern matching, value-semantics, extensible classes (separate "impl"), macros that can tap into the AST, no garbage collection, clearly defined (and avoidable) uses of heap memory, fine-grained reference-counting pointers (Rc, ARc, etc.), good concurrency models (similar to Go, but even safer), and the possibility to break free into "unsafe" blocks of code.

The main thing that really needs some serious re-working is the error-handling features. The whole way that Rust handles this is crazy to me, and not in a good way (i.e., it's not audacious, it's just plain stupid). So, Rust doesn't have exceptions, and instead they provide the classic method of "expected" / "maybe" / "optional" return values for the usual errors (like "can't invert this matrix because it's singular") and has asserts / panics for unrecoverable errors (like buffer overflows or sanity-check conditions). The main reason why some people avoid using exceptions is because they want to have direct, manual control over the cleanup code, so that they can keep it to a bare minimum (avoid code-bloat or over-sized binaries) and/or so that they can make latency guarantees about the error-recovery execution path. In other words, they want to avoid the automatic stack-unwinding code that comes with exceptions (as a thrown exception propagates back up the stack until it's caught), and replace it with their own hand-crafted clean-up code, as people do in C (and in C++ when exceptions are disabled by choice). But Rust has stack-unwinding everywhere and you can't disable it! As part of the overall safety policies of Rust, the stack will always unwind, whether you are propagating an error condition through the "Result" or "Option" mechanism or if you are throwing a panic / assert (which is crazy.. even C++, which has one of the strictest stack-unwinding policy, does not unwind on abort / asserts). This is so stupid it's beyond comprehension. They kept the only objectionable thing about exceptions (the code bloat and overhead associated to the automatic stack unwinding code), and kept none of its benefits (clean and optimized "good" path, throw where you detect the error, catch where you can do something about it, and so on), and on top of that, the Result / Option mechanism has run-time overhead on the "good" path which is certainly worse than all modern exception implementations. It completely baffles me. The only reason for this, that I can imagine, is a technical conflict between their exhaustive branching rules, static traits and exceptions (if unchecked), but this is not an unsurmountable problem, after all, most C++ compilers have solved this easily (you can use exceptions without RTTI, you just need to use the static type information to create the necessary run-time pattern-matching data in place so that a matching catch-block can be found). This whole issue shows pretty appalling ignorance on the part of the Rust language designers.

Anyway, enough ranting about that. Aside from that issue, Rust looks like a great language.

[vegaseat]

My problem with Go is that multiple Scanf() functions in a row seem to pick up an Enter key bounce (?) and skip, very annoying! Haven't found a solution yet.
I think I found it, stupid Windows adds a '\n\r' when you press Enter.

I am impressed with the speed of the compiler, going through the code samples at
https://gobyexample.com/
was a pleasure.

The Go syntax is C style without the ';' (the lexer puts it in before compile), or Java without class. I personally like the combination of Python and C++. I am not sure if Python works as glue language with Go at this point?

[iamthwee]

@mike I was thinking the same about rust as well, looks like it allows the flexibility to go low level without automatic garbage collection.

For me, and my interest being in webserver google go is fine to restrict low level stuff.

@vegaseat, I understand your point, some of Go's syntax isn't very friendly, but I think it just takes time to get used to. I think go will gradually pick up python programmers first before everything else.

[vegaseat]

Darn, Go is somewhat addictive!
Has a lot of good Python stuff in it, like dictionaries (map), closures that can be used as generators, anonymous functions etc. On the other hand it reminds me of exploring C in the olden/golden days.

Now if I only could find a Python style list container, or God forbit a list comprehension.
(A Python list and tuple can contain a mix of data types)

Red face ...
Go does have a list that allows mixed data types!

[vegaseat]

A service called "Go Playground" allows you to test Go code online. It does not allow for user input however.

https://play.golang.org/

I am quickly finding out that integers are rather limited in size, simple things like the "nine ones multiplication"
111111111*111111111
give you an overflow.
Python does the big integer thing automatically.

[vegaseat]

As I keep playing with Go I keep finding little gems.

You can use
var name string = "Frank"
or its shorthand version
name := "Frank"

The := operator is really an assignment and infer type operator. In Pascal it is only assignment..

You could also have used

var name string
name = "Frank"

The := operator comes in handy, for instance the usual for loop can be written this way ...

for k := 0; k < 10; k++ {
  // do something inside the loop
}

... since you assign integer 0 to k, it will be type integer by inference.
A little bit like C++ int k = 0.

Somewhere is also a big integer package. Need to read up on that.

[iamthwee]

In regards to big integer calculations I believe you have to look at.

https://golang.org/pkg/math/big/

I'm playing around with socket servers here.

[vegaseat]

Yes, math big works ...

// nine_ones.go

package main

import "fmt"
import "math/big"

func main() {
    nine_ones := "111111111" // nine ones
    big_nine_ones := big.NewInt(0)
    big_nine_ones.SetString(nine_ones, 10)

    big_result := big.NewInt(0)
    big_result.Mul(big_nine_ones, big_nine_ones)

    // result is 1 to 9 and down again
    fmt.Println(big_result) // 12345678987654321

    // console wait till enter is pressed
    fmt.Println("\nPress Enter key ...")
    fmt.Scanln()

}

[iamthwee]

I must admit it is more complicated than python or ruby but I guess that's the compromise you make when using a language where you have to specify datatypes.

[diafol]

Specifying datatypes is a good thing - I often worry about loose typing in PHP, having to force/declare datatypes really does make for a more robust function. The number of times my methods have failed due to string representations of integers for example since some native functions will treat them as strings, others as integers, and others f* knows what's going on.

[vegaseat]

I am finding out that Go is unforgivingly strict with data typing.

Wit ...

// data_typing_test101.go
// Go 'gotcha' stuff

package main

import "fmt"

func main() {

    fmt.Println(7 + 3.14) // 10.14
    fmt.Println(5 / 2)    // 2
    fmt.Println(5 / 2.0)  // 2.5

    var a int = 5
    fmt.Println(a / 2.0) // 2  oops! gotcha!

    // console wait till enter is pressed
    fmt.Println("\nPress Enter key ...")
    fmt.Scanln()
}

In C++

    int a = 5;
    cout << a / 2.0 << endl;  // 2.5

[vegaseat]

Go and Python similarities ...

    // assign and infer data type int
    x, y := 3, 12
    fmt.Println(x, y)  // 3 12
    // a swap similar to Python's tuple swap
    y, x = x, y
    fmt.Println(x, y)  // 12 3

[vegaseat]

Nice info ...
http://www.golang-book.com/

[vegaseat]

Found LiteIDE, a very capable, open source, cross platform Go IDE at:
https://github.com/visualfc/liteide

A joy to work with. Make sure you install Go first so LiteIDE can find it.

[vegaseat]

Declare a function on the fly (in Python you would use lambda for this) ...

package main

import (
    "fmt"
    "strings"
)

func main() {
    // encode/decode with rot13
    rot13 := func(r rune) rune {
        switch {
        case r >= 'A' && r <= 'Z':
            return 'A' + (r-'A'+13)%26
        case r >= 'a' && r <= 'z':
            return 'a' + (r-'a'+13)%26
        }
        return r
    }
    // encode
    fmt.Println(strings.Map(rot13, "peanuts"))
    // decode
    fmt.Println(strings.Map(rot13, "crnahgf"))
}

/*
crnahgf
peanuts
*/

Look at the versatility of switch/case.

[iamthwee]

Found LiteIDE

Excellent find... care to post screenies before I try?

[iamthwee]

For those interested in web just playing around with

http://revel.github.io/

[vegaseat]

Go is very strict on data types, even though it has the := operator that can infere data type. Python makes some old time programmers uneasy because it uses inference only.

[vegaseat]

Go was developed to drastically improve compile times and to address the modern computing environment. So it will find its use in large programs, cloud computing and the like.

Go avoids classical OOP.