12 ms·
What Python developers need to know before migrating to Go
- robdoherty2 13y agoAny HN readers of this post have any similar experience? I know the bright team over at bit.ly made a successful switch from python to go-- anyone else? The more I hear about go, the more I like it.
- sigzero 13y agoI don't think they did an entire switch over. "We identified early on that Go had all the makings of a language that could supersede some of the places we would have traditionally turned to C and some of the places where we wanted to move away from Python."
- gtaylor 13y agoI'm working on a personal project that uses Python for most of the page rendering and Go for the heavy lifting (receiving a large stream of data that I have to process quickly and efficiently). The ecosystem has a long way to go (compared to Python), but goroutines and channels are a pleasure to work with. It's nice being statically typed again, and I really like object composition versus Python's inheritance. Resource usage for my cases is much lower, latency is much lower, throughput is much higher, and my deploy/provisioning scripts are a lot more simple due to Go's static compilation. At my day job, we may start mixing in Go for background tasks that are a bit too slow/inefficient in our current Python stack. I could also see it being a good fit for some of our more high traffic HTTP APIs.
- TylerE 13y agoI've been messing around with it for some internal infrastructure. I like it so far. Excellent performance characteristics, and the tooling is supremely good, making the dev workflow much less painful than traditional compiled languages.
- codygman 13y agoI've been using Go for my company's backend api which communicates with Youtube movies, amazon movies, Netflix, etc and it seems very well suited to the work.
- mratzloff 13y agoPrevious discussions: - https://news.ycombinator.com/item?id=5600883 https://news.ycombinator.com/item?id=5600883 - https://news.ycombinator.com/item?id=5596422 https://news.ycombinator.com/item?id=5596422
- mjschultz 13y agoHere's a previous discussion of this post as well: https://news.ycombinator.com/item?id=5600883 https://news.ycombinator.com/item?id=5600883
- hvs 13y agoThis is purely anecdotal on my part, but I've been working on a project for a few months and I've been developing it in Go and it has just been a pleasure to use. It's like C with the edges smoothed out using Python sandpaper.
- DannoHung 13y agoI thought Go had union types? Do those not work... normally?
- TylerE 13y agoNope. I agree that it would be a good thing, and also cover about 80% of the usecases for "true" generics as well.
- alok-g 13y ago>> No built-in type for sets (have to use maps and test for existence) Is there any particular reason for this? Sets are so fundamental to mathematics and beyond that I am concerned right away about this. Sure you could use a map as a replacement, but what happens to "user experience"? I do not get this for other languages as well. Data structures that are present in nearly all computer science books are often not built into the language or standard libraries, like trees, graphs. Reasoning given is that some other data structure could serve as a replacement (never mind that the programmer's intentions are not directly reflected in the code anymore), or because it is considered too removed from practical usage, or because some third-party library includes it. I do not buy any of these arguments.
- gamegoblin 13y agoIn Java, sets are merely wrappers around a map that maps to a dummy. I guess Go just left off the wrapper.
- guelo 13y agoCPython's sets are implemented the same way.
- alok-g 13y agoA wrapper is totally fine really, actually better in some cases (see later). It still allows the programmer to map his intentions directly to the code, and make that intention directly visible to the reader. This adds to the "user experience" for the programmers. Agreed that such wrappers are then easily built by the programmer himself. But then comes the added pain of including those definitions in everywhere within a project and in-between projects. They become one more dependency to handle. Then come these wrappers or even whole data structures from third-party libraries. Nearly in every case I see, there is some impedance matching issue with some other libraries, requiring glue-logic to convert from one format to another. [Edit: Plus the added licensing/cost issues for those libraries.] If a set is just a wrapper around some more generic data structure, it is OK to implement it like that in the library to avoid duplication of code in that library. However, by not making that wrapper, the system is resulting in much more amount of duplicated code in the user space and now with the mentioned impedance mismatch or with weak mapping of programmer's intentions to the code.
- stcredzero 13y agoMany of the things he says he misses from Python, I would rather not have in production code. Heterogenous dictionaries are often objects that should have been, with no encapsulation and a high degree of implicitness that makes them hard to refactor later.
- phren0logy 13y agoI can't help but feel like criticisms along the lines of "you have to be more precise with what you want, because unlike python it won't let you get away with blah" and praise like "it seems to run correctly as soon as it compiles" are two sides of the same coin.
- TylerE 13y agoThey are, for sure. The difference, I'd say, is that compared to most other mostly-static compiled languages, Go generally feels a bit more velvet glove about it, rather than iron fist. The language principle of warnings are errors really helps here, as you tend to figure out potential issues sooner rather than later, and via a clear error message rather than subtle misbehavior.
- Arnor 13y agoAlso, if you're using Google App Engine SDK it can compile in realtime (i.e. every time you save a file in the project). So if you have one terminal open to the dev server process and another for your editor, you get instant feedback each time you save. It's a very Pavlovian experience :)
- morpher 13y agoIf you use vim, the syntastic[1] plugin has go support and gives you this sort of feedback directly in the editor (for any go code, not just app-engine -- and many other languages) every time you save. [1] https://github.com/scrooloose/syntastic https://github.com/scrooloose/syntastic
- Arnor 13y agoThanks!
- Osmium 13y agoIs there a decent numpy/scipy equivalent for Go yet? By which I mean an easy way to manipulate matrices, complex numbers perform discrete Fourier transforms and the like.
- kisielk 13y agoNothing nearly as mature, but the project is here: https://github.com/gonum https://github.com/gonum and the mailing list is here: https://groups.google.com/forum/#!forum/gonum-dev https://groups.google.com/forum/#!forum/gonum-dev
- rlpb 13y agoHas anyone tried to integrate Go with Python? Right now, optimizing Python code by replacing critical sections with C works really well and isn't too hard to write or distribute. How well would tooling around doing the same thing with Go work?
- sprash 13y agoThat won't help you much with concurrency problems, however "multiprocessing" does.
- akavel 13y agoHaven't tried any of them, but I remembered there are some, so after quick googling: https://github.com/sbinet/go-python https://github.com/sbinet/go-python https://github.com/qiniu/py https://github.com/qiniu/py https://github.com/qur/gopy https://github.com/qur/gopy
- est 13y agouWSGI with CPython and Go workers, with RPC each other. http://uwsgi-docs.readthedocs.org/en/latest/Go.html http://uwsgi-docs.readthedocs.org/en/latest/Go.html
- beering 13y agoSome of the things they listed are dubious... Writing to a file, there’s File.Write([]byte) and File.WriteString(string) – a bit of a departure for Python developers who are used to the Python zen of having one way to do something Simply because it's not currently feasible to write a function that can have multiple type signatures (via overloading, generics, etc.). Going between []byte and string. regexp uses []byte (they’re mutable). It makes sense, but it’s annoying all the same having to cast & re-cast some variables. There are actually two different versions of each regexp function: one for strings, one for []byte. Maybe they're using a different version? No tuples, have to write your own structs or use slices (arrays) Actually, you can declare a fixed-length array as a type. So if you need to return a triple of ints, you can declare the return type to be [3]int and have the type system check that you're actually returning an array of ints of length 3. Similarly, a lot of the other bullet points are natural results of having a static type system. I was expecting more points like: * you can't monkey-patch functions into external libraries like you can with Python modules * no generics, so you can't write a generic "map" function, for example * no preemptive multitasking, so one goroutine can wedge the entire program * passing around arrays and structs is by value, leading to unexpected allocation and memory usage * pointers
- pcwalton 13y ago> Actually, you can declare a fixed-length array as a type. So if you need to return a triple of ints, you can declare the return type to be [3]int and have the type system check that you're actually returning an array of ints of length 3. That's different from a tuple as it is commonly known in Python and statically typed languages. Tuples can be heterogeneous in languages like Python, OCaml, and Haskell, which Go fixed length arrays can't be. For example, in Go you can't have `(int, float)`.
- 16s 13y ago"No built-in type for sets (have to use maps and test for existence)... In absence of sets, have to write your own intersection, union etc. methods" In my mind, a map is a set. They are both Associative containers. It's just that the key and value can be different things in a map while in a set, the key and value are the same thing. Edit: I speak from a strong C++ viewpoint, but maybe Go is not like that (I'm not sure why it would not be): https://en.wikipedia.org/wiki/Associative_containers_%28C%2B%2B%29 https://en.wikipedia.org/wiki/Associative_containers_%28C%2B...
- RHSeeger 13y agoBy that logic, a map is just a list where every odd element is a key and every even element is a value. There are semantic differences between maps and sets and lists. Just because you can use one to represent all the others doesn't remove the benefit of having all 3 available.
- smegel 13y ago> The map/reduce idiom stinks in Python. Actually multi processing has a reasonable implementation.
- Arnor 13y agoSome of the items mentioned in that list are the reason why: "The code you write with Go just seems to be correct." e.g. - Having to always check errors (or at least explicitly ignore them) * By the way, do this anyway. It's really nice when every error in your app is handled. Since I've started with Go for a personal project, I've used a similar approach in my sigh PHP project so every error now has an explanation and suggestion. -Can’t have variables/packages that aren’t used so to test simple things requires sometimes commenting out lines -Python is more forgiving. You can take slices of strings using indexes that are out of range and it won’t complain. You can take negative slices – not Go.
- pallinder 13y ago"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." Could just load it into a map[string]interface{} and then just make sure he does type assertion on the value before using it.
- deleted 13y ago[deleted]
- n1ghtm4n 13y agoSome thoughts after spending ~100 hours with Go. - Function overloading is a major convenience that you will miss. There are differently named versions of every function and you will call the wrong version with the wrong arguments all the time. The number of functions in the standard library could be reduced by at least 1/4 if they'd got this right. The official FAQ (http://golang.org/doc/faq#overloading http://golang.org/doc/faq#overloading) explains that leaving out overloading is "simpler", meaning simpler for them. - Default parameters are a major convenience that you will miss. Using strings.Replace() to remove some chars from a string? Don't forget to pass the -1 at the end, asshole! The -1 says don't put a limit on the number of replacements. In Python there would be a max=None default parameter and this would never bite anyone. - No named arguments, because fuck readability. - Forcing me to handle errors is great. Having 20 different ways to do it is not great. Examples: fmt.Errorf(), fmt.Fprintf(os.Stderr), errors.New(), log.Fatal(), log.Fatalf(), log.Fatalln(), panic/recover... - Using && and || for logical operators in this day and age is just ridiculous. Why do people keep inventing programming languages as if Python doesn't exist? - Don't think that just because the Unicode guys invented Go that Unicode is going to be easy. Their solution is not to create an airtight abstraction layer between chars (or "runes" WTF?) and integers. Their solution is to provide almost no abstraction and force you to deal with the inherent integer-ness of all characters. Example: In Python: len("нєℓℓσ") # 5, because there are 5 chars In Go: len("нєℓℓσ") // 12, because there are 12 bytes utf8.RuneCountInString("нєℓℓσ") // 5, plz kill me i am an abomination tl;dr If you're inventing a programming language for human beings (not UNIX gods), try it out on a group of smart high school students first. It will be a humbling experience.
- dbaupp 13y ago> Using && and || for logical operators in this day and age is just ridiculous No it's not, it takes 10 minutes to learn that && means and and || means or (maybe a little longer to get the hang of it properly), and this knowledge transfers to many programming languages. (This is a little like arguing "we shouldn't use + when English has a perfectly good word 'add'"; symbol reasoning is valuable.)
- count 13y ago
- rwedf67 13y agoso you still trust the google compiler for your business critical apps do you? haha
- liveoneggs 13y agoI agree with this 100% Who would adopt a NEW google-ism at this point?
- jlgreco 13y agoIs C an "ATT-ism"?
- liveoneggs 13y agoI keep looking for IEEE or ISO spec for Go and not finding it. I keep looking for alternative compilers and can't find any. Is there a defined standard library that you can count on for the next decade? Maybe in 15 years when Go has outgrown its lock-in it may be worth considering. At this point signing on with google is like playing russian roulette.
- jlgreco 13y ago> I keep looking for alternative compilers and can't find any. Really??? How long did you look? I call bullshit; you did not look. GCC is an alternative compiler. Go away troll.
- liveoneggs 13y agogccgo is still from the same google-owned go project. I'll gladly go away, fanboy.
- jlgreco 13y agoIt is a first class member of GCC, under the GNU project. There are no possible concerns. I challenge you to attempt to articulate even one. No vague "google pulls the plug" statements, articulate a specific concern. Try it. You idiot crybabies, seemingly primarily people who got butthurt at having their hosted RSS reader pulled out from under them, never can. You are either a troll or an idiot. Actually, I'm leaning towards both.
- pekk 13y ago'migrating to Go' implies that Go has the same advantages as Python, which is not really true.
- 13b9f227ecf0 13y agoI keep seeing articles about Go where Python developers seem to be shocked to discover that interpreted dynamically typed languages are very slow. This wasn't obvious from the get-go? Practically anything not disk bound will be many, many times faster in C++ or whatever.
- callesgg 13y agobasicly most of the difrences that is mentioned comes down to that one of the languages is compiled.