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

41–50 of 79 posts

Re: Why We switched from Python To Go

#41

Post by yupyup »

asadmshah wrote: post #18
yupyup wrote: post #14

Earlier quoted context omitted.

About the static type system: When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java. Think about someone that knows Python and have to use Java, then they think that all static type languages are as a pain in the ass. So they begin disliking static type systems when they really just hate the Java's one. And so the moment they are using Python and start p…

Java the language is verbose, sure... but the type system?

Well, having a static type system is a tradeoff...

When using Python I feel the least resistance from the language, you can do a lot with a little code. Problem is, when the system grows you begin to miss the checking that static typing provides (esp. when doing refactors).

When coding in Go I feel that there is a little productivity lost upfront, but when your script begins growing and starts to look like a "serious" project you feel more confident changing your old code. This is because some kind of errors are caught by the type system before doing manual/automated testing.

And I'm talking about personal projects where I'm alone, this could be more important in projects with several coders.

Re: Why We switched from Python To Go

#42

Post by daenney »

forgottenacc57 wrote: post #3

As with all "why we changed from technology X to technology Y", the story is that there was this or that perceived shortcoming in technology X and technology Y will be our savior and fix all our problems, or conform to our software ideology/dogma. I used to read these things but given that I've read one, I've read em all. The only reason people keep writing these things is blog filler to promote their company or do i…

> Surely cannot be cause anyone cares why you use a blue pen instead of a black pen.

Actually... I think folks do care. But I also think that depends a bit on how you look at what's interesting. Some people want to use new languages or different languages for the sake of them being new or different. Others are more restrained but will reach out to a new language or experiment with it if they have some reason to assume this language can solve their problem better (for a definition of better). Others are set in stone and won't consider moving on from what they know.

What makes some of these posts interesting is when it goes much deeper and has thorough details that show how switching to a different language improved the situation for them, on the axis they were looking to improve. With actual metrics, crashes in production for example, deployment size, time from commit to deploy, resource usage etc. etc.

Re: Why We switched from Python To Go

#43

Post by yupyup »

zaphar wrote: post #35
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 cod…

Reading your comment reminded me of this great talk by Christin Gorman about maintainable code:

https://vimeo.com/138774243

(Jump to 25:50 for an anecdote about maintaining a "well engineered" system)

Re: Why We switched from Python To Go

#44

Post by daenney »

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…

Excellent list. Should give everyone a good start. I wish we had more of these for the different languages, that would at least make some discussion around these "switching from X to Y" posts more fruitful.

Re: Why We switched from Python To Go

#45

Post by slrz »

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…

Right, it's almost impossible to get any work done without having pre-approved code to copy and paste from. This is especially true for highly complex problems like reading a CSV file. Those virtually require the presence of promiment PyCon developers as no one else can possibly get this right.

Only use code with at least 500 green ticks.

Re: Why We switched from Python To Go

#46

Post by knorker »

justin_vanw wrote: post #40

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 h…

1. There are other ways to do it, yes. But "just upload anywhere and it works" is not just for server, but for tooling. That what comes out of the compiler can be used everywhere is a huge selling point that also, unfortunately, helped PHP even though there were other ways to do that too.

2. I could not disagree more. Just costs between int, float, int64, and double cause lots of bugs. Go makes costs explicit, which may be annoying, but does fix issues. Also lots of python code needs to check if passed args is str, or Unicode, or byte, or list, or dict, (or does, anyway, even though it shouldn't) so when someone passes in a generator when code assumed, or checked for a list, then all hell breaks loose.

4. I disagree with the article and think that the gorilla Go router is so good that you pretty much need it. :-)

Re: Why We switched from Python To Go

#47

Post by brudgers »

rcpt wrote: post #39
sametmax wrote: post #26

Earlier quoted context omitted.

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.

The lens through which I resolve Go is "it solves Google's problems". These relate to a systems programming codebase in Python and C++. Go makes clear sense for parallel contexts (though nobody has Google's problems). In other use cases, it is more or less just another general purpose programming language and the engineering tradeoffs are less obvious and the programmer ergonomics are more a matter of taste.

Re: Why We switched from Python To Go

#48

Post by yummyfajitas »

unscaled wrote: post #38
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…

If you really want good static typing while being fairly python like, there are other great options. Java or c++ both have decent generics, speed comparable to go, great libraries and years of collective experience using them.

I truly hate the social hacks that are causing go to displace much better languages.

Re: Why We switched from Python To Go

#49

Post by nhumrich »

chmike wrote: post #28
gerenuk wrote: post #9

Earlier quoted context omitted.

How about asyncio in python 3 and gevent etc. in python 2?

Callbacks (asyncio & gevent) are not the same as coroutines. You have to experience the callback hell to understand the difference.

Asyncio does not use callbacks. It uses async/await syntax

Re: Why We switched from Python To Go

#50

Post by sametmax »

brudgers wrote: post #47
rcpt wrote: post #39

Earlier quoted context omitted.

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.

The lens through which I resolve Go is "it solves Google's problems". These relate to a systems programming codebase in Python and C++. Go makes clear sense for parallel contexts (though nobody has Google's problems). In other use cases, it is more or less just another general purpose programming language and the engineering tradeoffs are less obvious and the programmer ergonomics are more a matter of taste.

That's very true. In fact, for most new projects you will never reach the problems or scale to benefit from Go sweet spot. JS will give you the "one language to rule it all the web stack" benefit. Python will give you the "good for almost any task" benefit. Rust will give you the "safe bare metal language" benefit. Erlang the "unkillable service" benefit. Java the "huge pool of talent" benefit. Etc.

For Go, it's not as easy to justify it so you should spend some serious thinking time before investing on it. The reward can be great, but the cost just as well.

Post reply on HN