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

Why we switched from Python to Go

getstream.io

Post reply on HN
Print view View original

121–130 of 406 posts

Re: Why we switched from Python to Go

#121

Post by kbp »

it wrote: post #91

I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language. To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've s…

> Quite often, the error message in Go will be clear and to the point. On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail.

An error message like '1 != 2' is a lot more meaningful when it's reported as the reason that test_new_foo_has_2_bars failed. Occasionally it's nice to give a more explicit message, which is why in eg Python you can optionally supply one, but it's not generally an issue if every test is really only testing one thing. To me, the Go approach seems to encourage writing cluttered tests that test several things at once.

Re: Why we switched from Python to Go

#122

Post by sethammons »

joshuamorton wrote: post #101
sethammons wrote: post #98

Earlier quoted context omitted.

Wheels just broke something in our build pipeline. They removed support for Python 2.6 and started tossing errors. I was able to fix it by pinning Wheel which probably should have been done originally by who ever made the build utility, but it would have been a non issue with Go and a binary.

Well, python 2.6 was also EoL'd 4 years ago, so yes, if you're using a no longer supported piece of software and not pinning your versions, I'd argue that you're inviting issues.

Sure. But if the build utility was just some binary, then it wouldn't matter. If Go was abandoned by all maintainers tomorrow or they broke all the packages, the already built binary will still work.

Should someone have changed the Python build tool to be 2.7 or 3? Maybe if they were bored and new it was something that needed work or wanted to be good tech citizen. However, what really happened is that no one even knew what the tool was really doing, just that it was part of a suite of tools in a build process, and no one would have looked twice at it ever again had wheel not removed support for 2.6. /me shrugs.

Re: Why we switched from Python to Go

#123

Post by BaronVonSteuben »

setheron wrote: post #30

How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity". Let me give a specific example where moving to Go really helped our tooling: Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when a…

I think in general people vote up stuff that glorifies their favorite language/smartphone vendor/operating system, even tho many of the comparisons are shallow.

Re: Why we switched from Python to Go

#124

Post by kbaker »

seabrookmx wrote: post #66
stuartaxelowen wrote: post #54

Earlier quoted context omitted.

For context, Instagram's primary web servers are Django.

And reddit. And a little thing called youtube (though to be fair last I read they're offloading a lot of the hot paths to golang and c via native modules).

Curious, where do you see that youtube is running Django? Python, maybe, but I don't think they run Django?

Re: Why we switched from Python to Go

#126

Post by sidlls »

cgag wrote: post #69
Jach wrote: post #68

Earlier quoted context omitted.

Yeah, plus even if performance is important, the app layer isn't necessarily the best place to optimize. It doesn't really matter how fast you sprint between database calls if the database and its IO dominate your site's performance profile, which they often do...

Everyone seems to say this and also to write really slow websites.

Are these sites slow because the software on the server-side is slow or because they're JavaScript bloated garbage?

That's a serious question: I find it's often hard to tell what the bottleneck might be in these applications.

Re: Why we switched from Python to Go

#127

Post by lonk »

setheron wrote: post #30

How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity". Let me give a specific example where moving to Go really helped our tooling: Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when a…

Because title starts with "Why". Psychological effect.

Re: Why we switched from Python to Go

#128

Post by sametmax »

pmattos wrote: post #7

A nice write up generally. I just feel he should also mention the classic static vs dynamic typing thing. From my perspective, teams switching to Go — from dynamic typed language such as Python — really appreciate the additional compiler help it provides ;)

You have type checks in python if you want them. It's just opt in.

Re: Why we switched from Python to Go

#130

Post by ubernostrum »

adwn wrote: post #103
ubernostrum wrote: post #71

Earlier quoted context omitted.

Why does anyone write web apps in Python? PHP? Ruby? First: Because squeezing every last nanosecond's worth of performance out of your web app is actually an extremely rare problem to have. And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly, but I'd bet a lot of money that you don't do that. The typical web application -…

> And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly The performance gain from Python/Ruby to Java/Go is an order of magnitude larger than the performance gain from Java/Go to assembly. The productivity loss from Python/Ruby to Java/Go is an order of magnitude smaller than the productivity loss from Java/Go to assembly.…

If you're disregarding programmer convenience in the name of performance, then do it. But once you make the decision to trade off some performance for convenience -- no matter how much or how little you give up/get -- you start losing the high ground for preaching to others about how they should refuse to trade what you see as inappropriate amounts of performance for convenience, because now you're just arguing matters of degree and unquantifiable personal taste.
Post reply on HN