My thoughts on Google Go

http://bentilly.blogspot.com/2009/11/my-thoughts-on-go-googles-new-language.html

by btilly • 17 years ago

39 35 17 years ago

bentilly.blogspot.com

shin_lao• 17 years ago

The question I have about Go is: why?

From what I read, Erlang is better at what Go tries to do.

Maybe it's just a 20% project that is being released into the wild...

davidw4• 17 years ago

Erlang does some stuff very, very well, and other things... perhaps not so well. Also, the syntax for most people is a bit of an initial stumbling block. In other words, I don't think Go is really aimed at Erlang's sweet spot, although perhaps it could be used to build Erlang-like systems, given some time and effort.

legooolas2• 17 years ago

We need to encourage people to get over their fear of syntax which is not C-like. I find much more pain in C-like syntax being jammed onto new languages than new languages daring to be different (and possibly coming up trumps, or being a disaster, but it's more interesting if they're different and perhaps better in some ways, IMHO).

yummyfajitas• 17 years ago

For an example of the broken stuff, consider string handling: [98, 114, 111, 107, 101, 110] == "broken".

It also doesn't have first class records. A record is nothing but a tuple, with some compile-time sugar that reminds you what the fields are. If Employee records have a name field, then you access it by saying e#Employee.name.

stcredzero3• 17 years ago

the syntax for most people is a bit of an initial stumbling block

Rewrite in the past tense, and this is an epitaph for any number of "niche" languages. Sad but true. Computer programming would be much better off if it were not so. Cultural expectations are a major factor in initial impressions. Good initial impressions make for a large, vibrant user base.

Python probably "gets it right" in terms of having enough syntax to satisfy expectations, but little enough to make tool writing accessible. (Except for the indentation thing, of course.) Ruby has too much. Smalltalk drops the ball with no precedence rules for math operations. Lisp and Forth are also a bit too weird, especially if your field is not programming and all you want to do is crunch some engineering data.

rick_2047• 17 years ago

BTW, even if its an 20% project thrown out in the wild it would be interesting to see how it fairs.the people used email before gmail came along, which was also a 20% project.And look at it now, its real big.May be same can happen with Go, or maybe not.Well, I don't care either way :)

uriel2• 17 years ago

While Erlang is great, it is certainly not a systems programming language, it requires a really complex runtime/vm, and it is not related to C in any way (and many of us still love C, and are happy to see a language to fixes its shortcomings).

One could (and some are planning to) write a kernel in Go, doing the same in Erlang would be much harder, if possible at all.

stcredzero3• 17 years ago

One thing a lot of people forget, is how much memory overhead is involved with modern languages like Erlang. (Python and Ruby are bad in this regard as well.) Smalltalk was heavily criticized in its day for this, yet "modern" languages are just as bad or several times worse.

Now Smalltalk and Lisp have both been used for "systems programming" -- years ago, on much older hardware. One can just live with the overhead. Go looks like it would have C-like memory overhead, so perhaps it is a much better choice in this regard?

masklinn• 17 years ago

> From what I read, Erlang is better at what Go tries to do.

Limbo is probably better, Erlang is not a systems/low level language, its aim isn't to come (anywhere) close to C performances, while Go seems to have performances in mind.

jrockway• 17 years ago

By "Erlang", I assume you mean Haskell.

uriel2• 17 years ago

> Maybe it's just a 20% project that is being released into the wild...

It is not "just a 20% project" (the list of people involved is quite big), plus if it was ken's 20% project, 20% of ken is like 20000% of your average hacker.

dkersten9• 17 years ago

My thoughts on Google Go:

1. Terrible name

2. Theres no reason to keep to C-style syntax

3. go <function> is a nice feature

4. Control structures add nothing new and just seem generally underwhelming to me

5. The built-in data types are an improvement over a lot of languages, but are underwhelming when compared to something like Clojure, Haskell, OCaml or Factor

6. Channels are a great way of dealing with mutable data in a concurrent environment, but I'm not convinced they're enough

7. Slices and pointers without arithmetic are a good idea

8. The interface system seems like an interesting idea

9. I'm not sure I understand how this is to be a "systems language", especially when they say that its impossible to do manual memory management

10. Lack of things I like: lisp-like macros, closures, pattern matching, parametric types, dataflow constructs, iterators, list comprehension..

Though I personally don't like the syntax very much, it is certainly familiar and easy enough to pick up, so I imagine this will be useful to a lot of people. I think Go is an interesting experiment which will, hopefully, lead to some more powerful and interesting languages, but I cant see myself ever using Go itself.

Its nice to see a C-like language take concurrency more seriously, but after having used Clojure a lot over the past month or two, it just doesn't really seem so concurrency oriented to me.

mncaudill• 17 years ago

On point 11, the language has closures.

dkersten9• 17 years ago

So it does, oops!

vital101• 17 years ago

"6. Channels are a great way of dealing with mutable data in a concurrent environment, but I'm not convinced they're enough."

Channels are a fantastic for concurrent environments. I took a distributed operating systems course during my graduate work, and we used Inferno as the environment and Limbo as our programming language of choice (you'll notice that one of the developers helped write Limbo). Channels made communicating between threads extremely easy as they could by typed to anything you wanted (primitives, ADT's, etc). Will they be enough? I'm not sure, but my experience tells me that they probably will be.

dkersten9• 17 years ago

Theres no doubt about them being a great concurrency model, which is why Erlang uses this approach. Shared-nothing message passing is actually my favorite non-dataflow approach to tackling not only concurrency, but also a means to build flat hierarchical software components.

However, there are some problems which are not easily modeled in this way. Some people claim that for some problems, this method isn't suitable at all (I'm more inclined to say that its simply more difficult or messy, but IMHO thats reason enough). Sometimes shared memory based concurrency is needed for performance. Whatever the reason, I'm not convinced that channels are enough.

This is one reason why I like Clojure's concurrency support: clojure's agents are similar to go's channels, but clojure also supports shared state, using software transactional memory to ease the locking/synchronization pain. Also, since clojure code is, by default, functional, operating on immutable data-structures, a lot of logic is inherently thread-safe at no effort to the programmer. Yet in some cases even that isn't desirable. So it lets you code however you need, and since Clojure is hosted on the JVM, you can revert to using Javas monitor-based concurrency model when it makes sense.

I don't think Clojure solves the worlds concurrency issues, but I'd argue its a lot closer to doing so than Go, even if its just because it gives you the choice to pick the model that suits your particular problem the best.

I don't actually mean to be advertising Clojure, its simply the most concurrency-oriented language I've been spending a lot of time using lately, so its easier for me to compare and contrast Go with it.

lacker• 17 years ago

Go isn't trying to replace Clojure, Haskell, OCaml, or Factor. It's trying to replace C++.

dkersten9• 17 years ago

Sure, I'm just saying that for me, personally, it doesn't add enough to make it worthwhile[1]. D is a great C++ replacement too and I think one of the reasons it never really took off is because it just doesn't add enough to be worth it (and D adds a good few niceties while still being familiar enough that C++ programmers can pick it up quickly and easily). Admittedly, D has a few other issues, but I don't feel they're relevant to this conversation - Go might have them too, who knows.

Having said that, I'd probably prefer people write code in Go over C hacks.

[1] C++ was my language of choice for a few years, so I do, at least partially, compare a language to C++ when I learn a new one and not only to <latest cool language>, though I admit I do that too.

adamc• 17 years ago

Sure, but is there enough demand for that for it to really succeed? D hasn't, really.

matthw2• 17 years ago

My question about Go: why does it need pointers?

Given that it has garbage collection, arrays/slices, and it disallows pointer arithmetic, it seems it would suffice to use references everywhere.

I thought maybe it was for easy interop with C APIs, but it seems it needs a FFI for that anyway.

Perhaps someone can enlighten me about that design decision? I'm sure there's a reason, I just don't immediately see it.

dkersten9• 17 years ago

I assume its because they don't want references everywhere. For example, allowing the programmer to choose if an object is allocated on the stack or heap, passed by reference (using a pointer) or by value.

matthw2• 17 years ago

Ah, of course.

Although, gotta wonder how these stack-allocated objects interact with closures.

euroclydon• 17 years ago

Can you elaborate on when an object is "allocated on the stack" versus being "allocated on the heap" in Go?

My thoughts on Google Go

Related Stories