Hacker News Reader

Comment by waterside81 | Hacker News Reader

We're going through the same thing right now. Porting a few thousand lines of Python to Go. It's almost a line for line port, with the odd exception here or there. One thing I really miss going to Go from Python is using getattr or dict.get(some_key, default_value). Also tuples. And marshalling from a JSON blob is kind of a pain in Go.

In fact, I started making a list of things Python devs need to know about when switching to Go. It's all a tradeoff, you lose some expressiveness for performance.

View on HN

Please do post the list of things you mentioned in your second paragraph.

"It's all a tradeoff, you lose some expressiveness for performance."

Not only do you gain performance but I think you gain maintainability and clarity. I value that when you read Go the run-time complexity of operations is very clear. In many other languages you often find O(n) or worse operations that appear to many programs in such a way the uninformed assume they are O(1) operations. In Go that does not happen- almost always what you see is what you get. I will gladly write a few more lines of simple code to gain clarity.

Can you post an example?

> Also tuples.

A tuple is just a makeshift struct. Think about it this way: by replacing it with a real struct, you're documenting your code.

Imagine if every function was only allowed to take a single parameter--and in order to write a function that takes multiple, what you really had to do was declare a struct of type "the set of parameters foo() takes" and then construct one whenever you called foo().

This is what it feels like going from a language with tuples, to one without :)

(I would also say "imagine further that you had to do the same whenever you returned multiple values"--but you don't have to imagine ;)

Go has tuple return values and of course input values.

The only thing missing is giving a tuples a name. But if you do that, you should make a struct, or you will forget which field is which and have bugs.

You can do a sorta-like getattr in Go using reflect, though I'm not sure exactly what your use case is. Fields need to be exported (upper-case names) though:

http://play.golang.org/p/XPgHkKCz_D

But you're absolutely right, you trade in some easy expressiveness and lack of boilerplate for better performance and easy concurrency.

But Go is much better about the boilerplate required than most other static/compiled languages, IMO.

I like your solution but that's kind of the rub about Go, at least at this stage of its still-early life. You have to re-invent the wheel a lot. It's frustrating to have to implement things that you know exist elsewhere, especially things like collections.defaultdict in Python.

Agree re: boilerplate. Much slimmer than Java or C++. And the build times, my God, the build times. It almost makes up for not having a true REPL.

If the original Python is d[key] = d.get(key, 0) + value, in Go it can be replaced with m[key] += value, since the default value for a map[string]int value is 0. This doesn't totally replace the need for defaultdicts, but it should greatly lessen it.

Using bitly/go-simplejson would help the JSON marshalling problem. https://github.com/bitly/go-simplejson

Reply on news.ycombinator.com