3 ms·

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 the

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.

swaroop 14y ago
Please do post the list of things you mentioned in your second paragraph.
georgemcbay 14y ago
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 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.
- waterside81 14y ago
  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.
earthboundkid 14y ago
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.
earthboundkid 14y ago
> 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.
- derefr 14y ago
  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 ;)
  - Evbn 14y ago
    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.
voidlogic 14y ago
"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.
- wging 14y ago
  Can you post an example?
smagch 14y ago
Using bitly/go-simplejson would help the JSON marshalling problem. https://github.com/bitly/go-simplejson https://github.com/bitly/go-simplejson

swaroop 14y ago

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

georgemcbay 14y ago

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 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.

waterside81 14y ago
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.

earthboundkid 14y ago

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.

earthboundkid 14y ago

> 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.

derefr 14y ago
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 ;)
- Evbn 14y ago
  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.

voidlogic 14y ago

"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.

wging 14y ago
Can you post an example?

smagch 14y ago

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