Profile

Cover photo
Martin Geisler
844 followers|8,148,368 views
AboutPostsCollectionsPhotosVideosReviews

Stream

Martin Geisler

Shared publicly  - 
 
Some background on the tradeoffs made when Go was designed.
Abstract. (This is a modified version of the keynote talk given by Rob Pike at the SPLASH 2012 conference in Tucson, Arizona, on October 25, 2012.) The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at ...
1
1
Radomir Dopieralski (deshipu)'s profile photoMartin Geisler's profile photo
2 comments
 
Yes, that sounds about right — they often say they came up with the idea of Go during one 45 minute compile of a big C++ program :-)
Add a comment...

Martin Geisler

Shared publicly  - 
 
Non-uniform Language Design in Go

One of the very first things I noticed (https://goo.gl/xnWDPs) about Go is that the language is inconsistent or non-uniform. By that I mean that there is a clear difference between what the builtin functions can do and what I as a language user can do.

Take the "comma ok" idiom presented in the Effective Go document (https://golang.org/doc/effective_go.html#maps). Basically, both of these lines compile:

x := someMap[key]
x, ok := someMap[key]

In both cases, the value from someMap[key] is put into x. If key is not present in someMap, a zero value is assigned to x, and in the second line ok will be false.

So far so good — looks like a handy syntax. The same pattern can be used for type conversion where you have an interface value from which you want to extract a concrete value of a given type:

x := someValue.(*ConcreteType)
x, ok := someValue.(*ConcreteType)

The syntax itself doesn't follow any obvious pattern here: it seems we're calling a method with an empty name, passing a type as argument?!

Anyway, the first line succeeds when someValue has ConcreteType, otherwise you get a runtime panic. The second line never panics, instead you get a zero value for x (nil) and ok is false if someValue was not of type ConcreteType.

Since this is presented as an idiom, I expected to take advantage of it with my own functions. After all, Go has support for multiple return values... However, it turns out that the so-called idiom only applies to the two cases above! I cannot write a function getElement(key string) (int, bool) and call it like this

n := getElement("foo")
n, ok := getElement("foo")

I'm obliged to use the "blank identifier" instead. Why does that not apply to the builtin syntax? Probably because it would make it annoying to use maps and interface conversions! :-) This means that you cannot use my getElement function as flexible as a normal map, e.g., this doesn't work:

getElement("foo") + getElement("bar")

This preferred treatment of the builtin types is annoying. In particularly when there are many languages that avoids this. Python is one example where everything in the language works "without cheating". The builtin dict (map) type behaves as if it had been implemented using a normal Python class that defines the _getitem_ method.

This is important for at least two reasons. First, it makes it easy to understand the builtin types since you could in principle have implemented it yourself. No cheating or special treatment going on.

Second, it makes the language flexible. People can extend the builtin types and add entirely new types. Do you need a bounded queue? No problem, implement it and you can give it an interface that makes it look like a builtin list. With duck-typing, you can pass your queue into a function that doesn't know about it — provided the function only requires list-like functionality.

Ironically, Go has the same kind of structural typing, but because the builtin types don't adhere to any interface, you cannot make your own slice-like or map-like types and expect to iterate over them using the builtin range. That seems like a lost opportunity, something that Java managed to do better with the Iterable interface and its enhanced for loop syntax that works for arrays too. In Java, the builtin array type is treated as a special case of a more general syntax there — instead of being the only case as in Go.

Part of the charme with Go is it's simplicity, but I feel like it should be possible to make a simple language that avoids these special cases.
6
Jim Hague's profile photoMartin Geisler's profile photo
2 comments
 
Yes, it baffles me that the language designers didn't focus more on making the basic parts of the language more elegant.
Add a comment...

Martin Geisler

Shared publicly  - 
 
ZuriHack 2016 has started! Save the environment, use continuation-passing style :-)
2
Add a comment...

Martin Geisler

Shared publicly  - 
 
Next week we have another run of the largest Haskell hackathon this side of the Atlantic: ZuriHac 2016. Looking forward to meeting with some Haskell experts and to hear what's new in this field.
1
Add a comment...

Martin Geisler

Shared publicly  - 
 
We have two great events coming up in PyZurich:

July 28th: Data Science and Machine Learning
August 4th: Data analysis with the scientific Python stack

There are still some seats left for the second talk.

1
Add a comment...

Martin Geisler

Shared publicly  - 
 
About time they presented the plan! :-)
3
Add a comment...
Have him in circles
844 people
Warren Baker's profile photo
Sune Mølgaard's profile photo
Mikkel Krøigård's profile photo
Danni Efraim's profile photo
Tim Henderson's profile photo
Rune Fogh's profile photo
Alex van den berg's profile photo
rupert THURNER's profile photo
Kristoffer Sorensen's profile photo

Martin Geisler

Shared publicly  - 
 
Good Things in Go

Based on my other posts, it's easy to get the impression that there's nothing I like in Go. That's not true :-) There are nice things in the language and ecosystem, and that's normally what people focus on.

Some example are the light-weight threads (goroutines) and channels. Goroutines combined with channels make a lot of async code very easy to write and reason about. This is hugely important — by making it easy to start goroutines, they get used more. There are many places where starting a thread pool in a traditional language would be seen as too complicated and too much overhead. In Go it's common practice to spawn a few goroutines and wait for them to complete. The builtin channels are important here too. Without them, synchronizing goroutines would be much harder and annoying.

Goroutines and channels could for the most part have been implemented in a Go library — imagine a library that allows you to submit functions to run in the background. The WaitGroup in the standard library is an example of what you can build yourself without relying on builtin syntax.

A library for channels and goroutines would add syntactic overhead, though, and you would not have a select statement with builtin support for waiting on channels. So it's probably a good thing that this got built in.

Another example is garbage collection — coming from Python, I'm very happy that I don't have to run around cleaning up my own memory :-) It's not a novelty, though, since lots of languages (even very old ones) have garbage collection.

The tooling around Go is in some ways pretty good (and pretty bad in others). Since the compiler rejects programs with unused imports(!) a tool like goimports becomes a must, not just a convenience. I never used such a tool with Python and it's a nice change to stop worrying about this. In particular because goimports also adds missing imports based on its best guess.

So that's nice and helpful. On the other hand, the compiler rejects a program like this:

pair := struct {
X int
Y int
}{
10, 20
}

even though it is okay with this program:

pair := struct {
X int
Y int
}{10, 20}

The problem with the first version is the lack of a "," before the newline inside the literal. If you use a multi-line composite literal, then you must use commas on every line, even the last. That seems like something gofmt (or goimports) could fix automatically for me. However, there is this issue https://github.com/golang/go/issues/7288 which got closed with "works as intended".
by peter.nguyen1802: I know that gofmt only fix code formatting and don't mess with the code itself whereas goimports does. Therefore, it would be nice for goimports to also fix the missing traili...
2
Add a comment...

Martin Geisler

Shared publicly  - 
 
The comment section here is hilarious. I in particular liked this exchange between +Russ Cox and an anonymous user after someone said that Go's interfaces work very similarly to how Emerald (a language from the 1980ties, http://www.emeraldprogramminglanguage.org/):

Russ Cox (October 14, 2010 7:46 PM) [...] It's very cool to see not only that other people explored this space years ago but also that they arrived at essentially the same design.

Anonymous (June 5, 2011 7:43 PM) "It's very cool " -- It's not cool at all; it indicates insufficient search of the literature, which one can see throughout the design of Go. [...]
Go's interfaces—static, checked at compile time, dynamic when asked for—are, for me, the most exciting part of Go from a language design point of view. If I could export one feature of Go into other languages, it would be interfaces. This post is my take on the implementation of interface values ...
2
Add a comment...

Martin Geisler

Shared publicly  - 
 
 
The garbage collector keeps getting better, while needing less and less tuning. Awesome! :-)
We use Go at Twitch for many of our busiest systems. Its simplicity, safety, performance, and readability make it a good tool for the…
2 comments on original post
1
Add a comment...

Martin Geisler

Shared publicly  - 
 
Good points about Go vs Python.
1
Add a comment...

Martin Geisler

Shared publicly  - 
 
Go: Idiomatic or Dogmatic?

Since I knew I would be starting at Centralway, I've been busy getting up to speed with +The Go Programming Language. It's a small language that is easy to pick up and which makes you feel productive from the get-go.

The language and documentation tries hard to make you do certain things in certain ways and isn't shy about this. Infact, I was quite surprised that I kept seeing references to a notion of "idiomatic Go" in the reference documentation. The language is so young that I didn't expect there to be an idiomatic style yet, but the authors think differently. The very first commit of the Effective Go document already had the phrase "This page gives tips for writing clear, idiomatic Go code" (my emphasis, original at https://goo.gl/Yo2OeG).

That is from a draft committed in June 2009, before Go itself was announced in November of that year. The FAQ says that development started less than two years earlier, in September 2007 (https://golang.org/doc/faq#history), so the Go authors already felt that they knew how Go code should be written by then.

The Python community has approached the same question differently. There we speak of code being "pythonic" when it feel right and use the language optimally. The earliest occurrence of "pythonic" on the Python development list is a post with a link to the "First Pythonic Award" from 1998 (https://goo.gl/IZdKRa). Python was released in 1991 with version 1.0 coming out in 1994.

This is to say that Go feels quite dogmatic compared to Python. Yes, there is a standard formatting guideline for Python code (PEP 8) and yes, there are lots of trends and conventions in the language. But I don't see the Python authors claim to know the "right way" as often as I've seen it in the Go documentation.

Providing tools for formatting, documentation, testing, etc is not a bad thing. Infact, it's probably a necessary thing in order to get a new language and ecosystem off the ground quickly. In particularly today where there are so many new projects fighting for the limited attention of the world's programmers. I just wish it was done in a way that was less prescriptive and self-assured.
4
Add a comment...

Martin Geisler

Shared publicly  - 
 
The first post on the new +Centralway Numbrs engineering blog! I'm not an Android developer and doesn't really know about the problems with leaking event listeners, but I think it's cool that we're open sourcing internal libraries and give back to the community.
Eine App. Alle Banken.
1
Add a comment...
Martin's Collections
People
Have him in circles
844 people
Warren Baker's profile photo
Sune Mølgaard's profile photo
Mikkel Krøigård's profile photo
Danni Efraim's profile photo
Tim Henderson's profile photo
Rune Fogh's profile photo
Alex van den berg's profile photo
rupert THURNER's profile photo
Kristoffer Sorensen's profile photo
Collections Martin is following
Basic Information
Gender
Male
Story
Tagline
Open source enthusiast and Mercurial developer
Work
Occupation
Software Engineer
Vegan restaurant and bar.
Public - in the last week
reviewed in the last week
Public - in the last week
reviewed in the last week
Public - 4 weeks ago
reviewed 4 weeks ago
We had a great all-you-can-eat teppanyaki dinner. You sit at a bar next to a big grill where the chef prepares the meat for you. You can choose between beef, chicken, shrimps, salmon, red snapper, and vegetables. The beef and salmon were excellent!
Public - a month ago
reviewed a month ago
662 reviews
Map
Map
Map
I had a nice cannelloni with ricotta and spinach here.
Public - 4 weeks ago
reviewed 4 weeks ago
Tasty fresh juices!
Public - 4 weeks ago
reviewed 4 weeks ago
I had a very nice gorgonzola pizza here. The quality was about average for Zurich, maybe a little over.
Public - a month ago
reviewed a month ago