Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We switched from Python To Go

medium.com

Post reply on HN
Print view View original

31–40 of 79 posts

Re: Why We switched from Python To Go

#31

Post by giancarlostoro »

ra7 wrote: post #4

> #2 Static Type System It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you. > For example it has http, json, html templating built in language natively So does Python with urllib and json modules. I don't know if it has…

> Not even a mention for the excellent PyCharm or so many of the useful Python vim plugins?

I must also mention Python Tools for Visual Studio is REALLY good. I have used PyCharm and PTVS and I must say PTVS is absolutely fantastic. PyCharm wins for me in the Cross-Platform aspect though.

Re: Why We switched from Python To Go

#33

Post by lewisjoe »

I've tried moving one of my projects from Django to Go before. I must accept that I had to wire a lot of stuff in Go, that Django handled for me like a cake. I'm talking about configuration, patterns and common features.

Others who've been where I was: how did you cope up with this? Would you be ready to move another project from Django to Go, without the mental fatigue?

Re: Why We switched from Python To Go

#35

Post by zaphar »

lewisjoe wrote: post #33

I've tried moving one of my projects from Django to Go before. I must accept that I had to wire a lot of stuff in Go, that Django handled for me like a cake. I'm talking about configuration, patterns and common features. Others who've been where I was: how did you cope up with this? Would you be ready to move another project from Django to Go, without the mental fatigue?

For the majority of my career I haven't worked on greenfield projects. I've been debugging, modifying, and otherwise maintaining pre-existing projects. As a result I've grown to really dislike frameworks that autowire things together. The very same features that made it easy to get started make them harder to maintain going forward. It turns out following the code in your own codebase is easier than following the code in the framework.

Django isn't as bad as some in this respect, (cough, spring, cough), but it still exhibits some of the same issues regarding maintainability. Go front-loads some work so that longer term maintenance is easier. And the vast majority of code work is maintenance not greenfield development.

Re: Why We switched from Python To Go

#36

Post by tonyedgecombe »

flavor8 wrote: post #23
ra7 wrote: post #4

> #2 Static Type System It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you. > For example it has http, json, html templating built in language natively So does Python with urllib and json modules. I don't know if it has…

I haven't used Jetbrains' go ide, but extrapolating from my time with intellij and pycharm it seems that their ides work significantly better with static type systems. (Find usages, rename function, etc are less accurate.)

PyCharm does support type hinting now which should help: https://blog.jetbrains.com/pycharm/2015/11/python-3-5-type-h...

Re: Why We switched from Python To Go

#37

Post by tonyedgecombe »

bpizzi wrote: post #15
throwaway_374 wrote: post #10

As an aside, the greatest thing about Python is StackOverflow one-liner solutions to common problems. How do you find your developer productivity fares in Go? To take a simple example, I was experimenting with C++ and had the simple task of "reading in a CSV". This simple C++ task does not have a nicely formatted, pre-approved, community rubber-stamped, best practice 500 green ticks StackOverflow top accepted answer…

> How do you find your developer productivity fares in Go? To take a simple example, I was experimenting with C++ and had the simple task of "reading in a CSV". Not sure if reading data from a csv formatted file is a great example for differentiating Python and Go: both languages have a builtin csv package/module. Python: https://docs.python.org/3/library/csv.html#examples Golang: https://golang.org/pkg/encoding/csv/…

> And, errors handling put aside, both takes more or less the same number of LOC.

So apart from the difference in line count they are the same line count :)

Re: Why We switched from Python To Go

#38

Post by unscaled »

ra7 wrote: post #4

> #2 Static Type System It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you. > For example it has http, json, html templating built in language natively So does Python with urllib and json modules. I don't know if it has…

> It's really weird to see one of the reasons for their switch to Go was because it's a statically typed language. If you want static typing, you don't choose Python in the first place. You know it beforehand and it shouldn't come as a surprise for you.

It's weirder that many Python/NodeJS switchers cite this reason, since out of all the commonly used statically typed languages, Go has the second weakest type system (the first place obviously Goes to C).

With so many methods returning an interface{}, you'll get exactly the same crashes you had with Python.

If type safety is really such a major issue for you, you'll get a significantly better deal from Python Type Hints (using mypy or PyCharm) and TypeScript/Flow. All of them support generics (and hence nearly eliminates the need for wildcard types).

I suspect performance and static binaries are the real reason for most of the cases of projects switching from dynamic languages to Go.

Re: Why We switched from Python To Go

#39

Post by rcpt »

sametmax wrote: post #26
henrik_w wrote: post #17

Earlier quoted context omitted.

What are those reasons in your opinion?

You identified that your code has few data parsing and manipulation, and a lot of concurrency bottlenecks after auditing your system and making measurements. You have a lot of technical debts in your concurrency code and don't think you have the skills to solve them internally while Go would let you do it. You have data about your deployment and weighted security updates easiness against self enclosed binaries and th…

Seriously thank you for this. So many "Python-Go" articles are indiscernible from Google marketingspeak and just sit on the front of HN without being called out. Your list of tests will be a great reference.

Re: Why We switched from Python To Go

#40

Post by justin_vanw »

So this lists the usual stuff that people who aren't experts in any system think are good reasons to pick one or the other for.

1. The single binary is attractive, but with modern virtualenv and wheel and anylinux wheel files this is far far less important than it would have been 10 years ago. I count this as irrelevant but probably python's library packaging is confusing to a beginner.

2. Static types don't really help you here, yes you can run into some issues where you have an object that is a different type than what you thought it was, but this is not common and your tests will catch it for you. I'm not sure why django's orm will fail on the wrong type since SQL is loosely typed anyway, but everything django is garbage so don't use django.

3. Performance in python can be pretty awful. Not going to argue. It's usually not too slow and you should focus on algorithms first, if you agorithm is efficient then you should be able to do whatever computation you need to render html or json for your service in plenty of time. But Python is slow sadly.

4. You don't need a web framework for Python either, Werkzeug is a great toolkit to roll your own micro framework. So I'll just count this as lack of experience and knowledge, plus confusion.

5. Great IDE support. I guess this is a thing people like to have, personally I think if you are being slowed down by how fast you can type or remember method names something is horribly wrong. The other things IDE's do are usually pretty pointless, at least for me, but if you feel like you need it then I agree IDE support for python is usually pretty weak because python is very hard to statically analyze. None of the more productive programmers I've known through the years used IDE's, they all used Vim or Emacs. If you feel like you need hand holding I guess IDE support would be important for you though.

Post reply on HN