
What Python developers need to know before migrating to Go - rachbelaid
http://blog.repustate.com/migrating-code-from-python-to-golang-what-you-need-to-know/
======
wting
> The code you write with Go just seems to be correct. I can’t really put my
> finger on it, but somehow once the code compiled (and it compiles QUICKLY),
> you just get the feeling that it’ll work (not just run without error, but
> even logically be correct). I know, that sounds very wishy-washy, but it’s
> true.

This statement needs to be qualified.

Switching from an interpreted to a static language will catch a certain class
of bugs upfront. I've rewritten some small programs from C to Go, and the same
logic bugs are present in both.

In this sense, switching to Go is no different than switching to Java/C in
terms of the bugs it will catch. There's nothing in Go that sets it apart from
other static languages in this respect (unlike Haskell).

> It’s very similar to Python in terms of verbosity (or lack thereof) and it
> treats functions as first-class objects, so functional programming is easy
> to reason about.

Where is map, reduce/fold, filter, scan? Go doesn't support functional
programming primitives due to lack of generics.

I may not have written enough Go programs, but I find Go marginally less
verbose than C thus far (ignoring concurrency). Channels and goroutines and
are its most interesting features.

~~~
pjmlp
For me it is mainly a C successor that catches up with what the Pascal family
of languages has been offering since the mid-80's, in terms of compilation
speed, modules, concurrency and safety.

~~~
wting
I know Go has been touted as a C successor since inception, but most new users
seem to be coming from interpreted languages. Like this blogger, they
attribute a lot static language advantages as unique to Go.

I don't see a lot of C/C++ developers switching, probably because they have
sunk costs with their respective languages and Go doesn't offer very much by
comparison.

I would definitely use Go where it seems appropriate, but I don't see it
replacing C as a systems language.[0] Sometimes when I write something in Go,
I look back and wonder why didn't I just do it in C. However, Go is great in a
distributed systems / networking environment where most new code seems to be
written.[1]

In the words of a friend, "You can pry raw memory access from my cold, dead
fingers."

[0] systems == OS, drivers, etc.

[1] Motivations summarized in the abstract:
<http://talks.golang.org/2012/splash.article#TOC_1>.

~~~
pjmlp
This is one of the areas where I actually take Go's defence.

Have a look at Native Oberon and AOS, both desktop operating systems developed
at Zurich's technical university.

They are done in GC enabled systems programming languages and were used both
as desktop systems by the teachers, as well as to teach operating systems
classes.

Quite nice desktop environments using strong typed languages, but offering a
Smalltalk like user experience.

[http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...](http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pdf)

<https://www.ics.uci.edu/~franz/Site/pubs-pdf/BC03.pdf>

<http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager>

The problem with any systems programming language is that it is only used as
such, if an OS vendor makes it the only way to do OS programming. Like
Microsoft does with C++ or Apple with Objective-C.

~~~
wting
I worked on GNOME for a summer, and can see Go being a viable option for DE's.
GNOME has added a lot of libraries to bring object support to C, but Haskell
has proven gc language is fast enough for a WM (xmonad).

Go might need to improve its gc to prevent the occasional stutter, but it
would otherwise be sufficient.

However my original statement defined systems as kernel code, since HN tends
to have many opinions on the topic.

> The problem with any systems programming language is that it is only used as
> such, if an OS vendor makes it the only way to do OS programming. Like
> Microsoft does with C++ or Apple with Objective-C.

I see plenty of new C code still be written outside of systems, the problem is
lack of exposure. HN community is fairly web focused but HPC, scientific
computing, graphics, engines are still predominantly done in C/C++.

~~~
pjmlp
> However my original statement defined systems as kernel code, since HN tends
> to have many opinions on the topic.

That is how I understood it. Have a look at the Project Oberon book.

Assembly is only used for the boot loader, device driver glue and some GC
implementations. The same type of stuff you need language extensions in C as
well, as they are not part of ANSI C.

Everything was coded in Oberon or Active Oberon, depending on which OS version
we talk about.

This startup is selling embedded compilers for Oberon that target 32 bit ARM
since the late 90's.

<http://www.oberonday2011.ethz.ch/talks/armembedded.pdf>

The trick is to have control when the GC happens and to allow for manual
memory management via a SYSTEM pseudo module.

But yes, in the current state of affairs C and C++ will outlive us anyway.

------
jgrahamc
A very large amount of this is "Moving to a statically typed language".

1\. "Different assignment operator is used depending on whether you are inside
& outside of function ie. = vs :="

= is an assignment, := is a declaration and assignment at the same time. It's
true that you can't := outside a function (which I think is silly), but the
comparison should be between these two:

    
    
        var foo string = "Hello"
        foo := "Hello"
    

2\. "Else (or else if) has to be formatted properly, where the else is on the
same line as the curly bracket from the if clause. Weird."

Whereas, coming from Python where indentation matters. Weird :-) Both are
style conventions enforced by the language.

~~~
shadowmint
Come on, those are the two weirdest things about go syntax, especially for new
comers.

(Honestly, why can you not 'for var x = 0; ...'? and only 'for var X := 0;
...; ...' but immediately below var x = 0; is just as valid. The := / var
syntax in go is just plain weird).

Go is also the only place I've ever seen this syntax:

    
    
       if blah {
         ..
       } else {
         ..
       }
    

Maybe that's popular in some obscure places, but it _is_ weird they made that
the only valid syntax.

I mean, fair enough, Go has its own syntax, but these are pretty valid gripes.

~~~
masklinn
> Go is also the only place I've ever seen this syntax:

Do you mean

    
    
        if blah {
            code
        } else {
            code
        }
    

as in parens-less if statement? Because I don't see anything odd in what you
wrote, it's valid C or Java.

And if it's putting else, } and { on the same line, it's "standard" K&R, 1TBS,
BSD KNF and java indent style/coding conventions.

~~~
shadowmint
it is weird they made that _the only valid syntax_

~~~
wonderzombie
It's because of arguments like this, that's why. They render a huge swath of
subjective, unproductive discussions about style completely moot.

~~~
jlgreco
Well, that is the idea at least. Unfortunately it almost seems as though the
style arguments will be replaced with the "pro/against enforced style"
arguments.

Hopefully this new topic has less staying power.

------
mratzloff
Many of these points are only really relevant to a Python developer new to
statically-typed languages. For those points you could substitute s/Go/Java/g
and it would be just as true, except that someone new to Java would probably
lean on generics more than they should.

As for the other points, it would be nice to have more built-in types like a
Set type, to be able to ignore "unused dependency" errors when running "go
install", etc.

Oh, and I think he missed the most surprising thing about Go for newcomers:
that "if" creates scope!

~~~
ominous_prime
> Oh, and I think he missed the most surprising thing about Go for newcomers:
> that "if" creates scope!

Go is block scoped, and if statements are blocks. I don't see this as
surprising.

I agree some set operations would be nice, maybe using an interface like Sort,
but you can use a map as a basic generic set data structure. This is how many
language implement a set anyway.

~~~
mratzloff
_Go is block scoped, and if statements are blocks. I don't see this as
surprising._

I meant surprising for someone used to Python, like the article author. I'm
surprised he didn't mention it.

------
ominous_prime
This seems more like a list of things developers need to know if they've only
ever used python.

Go has different syntax and rules than python, but so does C, Java, Erlang,
and so on. I don't get why this is such a surprise. Don't approach a new
language assuming you can directly translate from your last language du jour,
and you'll be much happier.

------
RyanMcGreal
I hope that "how to handle getting hackernewsed" is on the list. Text-only
cache:

[http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://blog.repustate.com/migrating-
code-from-python-to-golang-what-you-need-to-know/&strip=1)

------
grey-area
_No constructors, so common idiom is to create NewType() functions that return
the struct you want_

It would be nice to see official constructors in Go, to encourage consistency,
it feels a little ad hoc at the moment.

 _You can’t have mixed type data structures. Maybe it’s not kosher, but
sometimes in Python I’ll have a dictionary where the values are a mix of
strings and lists. Not in Go, you have to either clean up your data structures
or define custom structs_

I didn't understand this point. If you want you can use a
map[string]interface{} to store arbitrary mixed types in a map (dictionary),
though obviously no type checking is then done on the dictionary, but you
could define an interface Inter which both types conform to and use
map[string]Inter instead so that you know what you're getting and that it will
respond as you expect.

 _If I want a list of just the keys or just the value, as in dict.keys() or
dict.values(),_

It'd be nice to see some enhancements to map for common operations like this,
it's something I missed from Ruby. It'd be nice to have an ordered map in the
standard library as well.

 _Else (or else if) has to be formatted properly, where the else is on the
same line as the curly bracket from the if clause. Weird._

This sort of grammar quibble mystifies me - one of the nicest things about go
is gofmt and the recommended formatting - I like that, for trivial points of
grammar like this, there's only one way to do things which is considered
correct. This isn't the style I'd personally use elsewhere (in C for example),
but it's great that all Go code is formatted in exactly the same way - it
makes it easier to read, and really is not hard to pick up.

 _If you’re using JSON and your JSON is a mix of types, goooooood luck. You’ll
have to create a custom struct that matches the format of your JSON blob_

This does have the advantage that you know what you're getting, and can't
unmarshal unexpected objects by mistake when fed malicious/broken JSON.

~~~
maxtaco
I wrote a little wrapper while at OkCupid for dealing with adhoc JSON objects
in Go, available here: <https://github.com/okcupid/jsonw>

------
bayesianhorse
Switching from Python to GO is a big boost in speed and a big sacrifice in
terms of third party code.

~~~
pekk
Why is it necessary to 'switch' at all? Can you only hold one language in your
head at once?

~~~
bayesianhorse
I wasn't distinguishing between switching completely and switching just a part
of the infrastructure to go, for brevity's sake.

------
JulianMorrison
map[rhubarb]bool is how Go does sets and []interface{} is how Go does
heterogenous lists.

Also you can unmarshal JSON into an interface{} variable and get a mix of
map[string]interface{} and []interface{} that you can deconstruct via type
assertion if you know what to expect, so you can be a bit python-ish about
JSON if you don't want to read it into structs.

~~~
stevvooe
> map[rhubarb]bool is how Go does sets

Actually, you should use map[rhubarb]struct{} since a struct{} requires no
storage. You can test membership with this:

    
    
        _, ok := m[strawberryRhubarb]

------
orangethirty
I just jumped into Go a couple of days ago. Was minding my own business when I
suddenly arrived at its homepage. The online tutorial seemed interesting and I
began completing it. Well, hello, where have you been all of my life? Go is
quite something. To me, is like the right mix of C and Python. It reads very
well, and is very minimal. I have been spending all of my night learning it.
Have had so much much, in fact, more fun than I ever remember. Right now, I'm
not very productive with it, but give me a few days. I never paid much
attention to it, because what could be better than Lisp or Python? Go is not
better, but its in the same category as those two (for me, at least).

------
nphase
> If you’re using JSON and your JSON is a mix of types, goooooood luck. You’ll
> have to create a custom struct that matches the format of your JSON blob,
> and then Unmarshall the raw json into an instance of your custom struct.
> Much more work than just obj = json.loads(json_blob) like we’re used to in
> Python land.

I believe you can use json.NewEncoder().Encode() to arbitrarily deal with
interface{}'s

------
oddshocks
If only the site would load.

~~~
mattsfrey
This. I've been trying it off and on for half an hour now, how did all these
other people manage to see it?

~~~
garfij
By viewing the Google web cache of it.

------
reyan
Did you use Python bindings for libsvm?

------
sebjapon
the link doesn't work for me. anyone knows why?

------
michaelochurch
One thing I can't wait to see (maybe when the Go ecosystem is more mature) is
Gojure, a Clojure that runs on top of the Go environment. That would be
badass.

ETA: I realize that it just looks like I'm spouting opinions if I don't get
into _why_ it would be badass. Essentially, Go is a language designed for
production systems in one of the most demanding large-scale software
environments on earth. Compilation is rapid, and the language does a lot of
things that force code quality. The problem is that it still feels a bit
verbose. Putting a Lisp on top of that (and Clojure is my favorite Lisp) would
be really interesting.

~~~
kyllo
Out of curiosity, are there any particular reasons why you like Clojure more
than other Lisps/Schemes? I've played with it a little and found it kind of
weird due to no car/cdr/cons, no TCO, loop/recur/trampoline, the usage of [],
and various other quirks. It's a Lisp but you can't just write Lisp code in
it, it requires learning new idioms. But I'm not good enough at Clojure yet to
know what advantages it has over other Lisp family languages, aside from the
Java libraries. What features of Clojure do you particularly like?

