>I prefer Lisp's/Clojure's approach here - have many functions operating on few data types, as opposed to the inverse.

...that doesn't accurately describe a flaw in Go at all, and stems from a common misconception of Go's type system; namely that it is Java's type system, which it is decidedly not. The interfaces make a big difference.

An interface is simply a set of methods. Any object that implements those methods implements that interface. Adhering to an interface is implicit; you never have to say "type Stanley implements the Cat interface". If the Cat interface is just a "Meow" method, and Stanley can "Meow", Stanley is a Cat.

Take, for example, the io.Writer interface. io.Writer is a method set that contains a single method: the write method. This is the definition for io.Writer:

    type Writer interface {
        Write(p []byte) (n int, err error)
    }

This interface definition says "a Writer is any object that has a Write method. The Write method must accept a slice of bytes as its only argument, and it returns an integer and an error". Any object that implements this method also implements io.Writer. Therefore, any function that accepts an io.Writer may accept any object that defines this method. (when accepting io.Writer, the object's type is io.Writer; the only thing you can do with an io.Writer object inside of a method that accepts an io.Writer parameter is utilize its Write method, since that's the only thing you know it has).

So, for example, in the encoding/json package, there is an Encoder object. The Encoder object has just one method: the Encode method. This is the signature for the Encode method:

    func (enc *Encoder) Encode(v interface{}) error

this method definition reads "the function for the * Encoder type called Encode accepts an interface{} v and returns an error". interface{} is the empty interface; all objects implement at least zero methods, so any object can be supplied; it is valid to pass any object into the Encode method. The returned "error" value will let us know if something has gone wrong.

Now then. We know that we're encoding data to the json format, but to where is it being encoded? Where is the output going? The io.Encoder object embeds an io.Writer object; encoded items are written into the writer. That's a big leap. How do we know which io.Writer to write to? We inject the io.Writer when we create the encoder. This is the signature for the function that creates a json encoder:

    func NewEncoder(w io.Writer) *Encoder

It has only one argument; io.Writer. io.Writer has only one method; the Write method. That means that for any data target at all, if you define a Write method, you can encode json to it.

So what io.Writers are commonly found? There is an io.Writer for a UDP socket, a TCP socket, a websocket, an http response, a file on disk, a buffer of bytes, etc. The list goes on.

With this one Encode method, and this one Write interface, we are able to Encode json data to arbitrary targets. There's none of that JSONFileWriter, JSONHTTPResponseWriter, JSONUDPSocketStreamer stuff like you would get in other statically typed languages.

If the function returns a useful value and an error then you'll have to assign to error to "_" to ignore it, which is a pretty big hint to the reviewer that it's being suppressed. So in cases where you want to "force" error checking, returning multiple values is probably good enough.

Parametric polymorphism has nothing to do with OOP.

  > spend a month moving our framework over to Go

Seems a little extreme. Just use it for small, discrete projects. No need to bet the farm.

Since posting my comment about sublime text, I went ahead and downloaded and gave it a try. I must say it seems to fit my needs as far as python is concerned quite well, from the short time I spent with it.

It hits the sweet spot between emacs and pycharm quite nicely and I am at this point inclined to buy a license, I think an IDE is more useful for languages like java or scala but for python sublime text will do for me.

Re. the use cases for an IDE, my point was that as my side projects keep growing in size, I need something which is smart about things like refactoring, comprehensive autocomplete, support for debugging etc.

In my humble opinion, in the vast majority of cases, yes. Because " C ", " D ", " C# " should be easier for search engines to disambiguate (at least working with Lucene, it is, and I imagine Google etc are similar-ish).

As for Java, Python the context in the page likely to point to its intended audience (and it helps they have been around for ages etc). Otoh, " go " is likely to be used in a lot of literature, including other programming related texts.

Try searching for something with clojure, and then try go -- the quality of results is usually substantially different, and my unsubstantiated hunch is that not all of it has to do with lack of go-related content.

Seems to be getting better though..

But then you lose the information that both ((usually modular) arithmetic, and strings with concatenation, et al.) are monoids, and have a similar structure, and creating generic functions which might use that symmetry becomes more difficult.

In python you can overload + and a lot of other numeric operators by implementing certain methods __add__ for +, see others here: http://docs.python.org/reference/datamodel.html#emulating-nu...

In ruby you can implement certain numerical methods including +

In smalltalk + is a binary method, you can give your methods all sort of symbol names. Same with Scala I think.

> For example, in Javascript: "Hello" + " " + "World!". What the operator there is doing is concatenating the strings

Hmm, are we talking about (user defined) operator overloading as a language feature, or about overloaded operators? For example, I hate that 1/2 and 1.0/2 are different things in most languages, but I haven't heard anyone call this operator overloading in the context of C.

> designing a GUI

Not really. HTML/CSS/JavaScript combination is not really OO, but works really really well.

In general, I think that any "programming language" for GUI is a fail - we need to develop a declarative approach to GUI (like HTML/CSS, but with more features (e.g. effects) and more emphasis on Application Development (e.g. it's still really hard to create a photoshop-like interface in HTML), less on text presentation).

A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception:

http://www.reddit.com/r/programming/comments/w1ig0/things_i_...

I was about to say "you can't do it", but I think you can -- the trick is to use a bounded generic implementation. Once "Mul" becomes a trait, you'll be able to say this:

    trait MatrixMultiplyRHS<Result> {
        fn mul(matrix: Matrix) -> Result;
    }

    impl<RHS:MatrixMultiplyRHS<Result>,Result> Matrix : Mul<RHS, Result> {
        fn mul(rhs: RHS) -> Result {
            rhs.mul(self)
        }
    }

    impl float : MatrixMultiplyRHS<Matrix> {
        fn mul(matrix: Matrix) -> Matrix {
            // ...implementation of matrix scalar multiply...
        }
    }

    impl Vector : MatrixMultiplyRHS<Vector> {
        fn mul(matrix: Matrix) -> Vector {
            // ... implementation of matrix multiply for vectors ...
        }
    }

    impl Matrix : MatrixMultiplyRHS<Matrix> {
        fn mul(matrix: Matrix) -> Matrix {
            // ... implementation of matrix multiply for matrices ...
        }
    }

It's admittedly a bit awkward, but maybe that's OK to discourage overloading unless you actually need it. Still, your point was very interesting -- I didn't realize this was possible! -- and I'll spread it around the team.

I don't know rust but rust seems very much like C++.

Did you have a look at the Eigen library (C++)?

http://eigen.tuxfamily.org/dox/TutorialMatrixClass.html

I have never worked with this library but it seems to me that they have not the problems you described. Maybe having a look at it brings up some new ideas...

You said that sum types were omitted from Go because the designers were not aware of more recent developments. That's not true. They were omitted because they do not mesh well with the other features of the language, such as zero types, interfaces and embedding.

Whether you agree with that latter point is moot. Go's designers were and are fully aware of sum types; they chose to omit them from Go for a reason, not because they were ignorant of their existence.

You don't count this as inheritance? Also, classes aren't required for OOP.

    function Parent() {
        // somestuff
    }
    function Child() {
        Parent.call(this);
    }
    Child.prototype = new Parent();
    Child.prototype.constructor = Child