Question

Does Google’s Golang address the problems with languages addressed in Paul’s Graham’s post ‘Why Arc isn’t Especially Object Oriented‘?

Answer 1

My initial feeling towards this is “It is too soon to tell”

1) Object-oriented programming is exciting if you have a
statically-typed language without
lexical closures or macros. To some
degree, it offers a way around these
limitations. (See Greenspun’s Tenth
Rule.)

Go supports Function literals (see docs) which if I am reading this correctly allow you to pass functions as params, whether defined elsewhere or created ad-hoc.

2) Object-oriented programming is popular in big companies, because it
suits the way they write software. At
big companies, software tends to be
written by large (and frequently
changing) teams of mediocre
programmers. Object-oriented
programming imposes a discipline on
these programmers that prevents any
one of them from doing too much
damage. The price is that the
resulting code is bloated with
protocols and full of duplication.
This is not too high a price for big
companies, because their software is
probably going to be bloated and full
of duplication anyway.

This point is far to subjective to answer.

3) Object-oriented programming generates a lot of what looks like
work. Back in the days of fanfold,
there was a type of programmer who
would only put five or ten lines of
code on a page, preceded by twenty
lines of elaborately formatted
comments. Object-oriented programming
is like crack for these people: it
lets you incorporate all this
scaffolding right into your source
code. Something that a Lisp hacker
might handle by pushing a symbol onto
a list becomes a whole file of classes
and methods. So it is a good tool if
you want to convince yourself, or
someone else, that you are doing a lot
of work.

Since go isn’t a truly object oriented language, you can probably solve the problem in whatever fashon you are comfortable with.

4) If a language is itself an object-oriented program, it can be
extended by users. Well, maybe. Or
maybe you can do even better by
offering the sub-concepts of
object-oriented programming a la
carte. Overloading, for example, is
not intrinsically tied to classes.
We’ll see.

Go seems to have an interesting approach to objects, where you are not required to worry / develop large object trees. It looks like the tools are present in the language to structure your data in an object oriented fashion without locking you in to a pure object oriented environment.

5) Object-oriented abstractions map neatly onto the domains of certain
specific kinds of programs, like
simulations and CAD systems.

…