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

321–330 of 406 posts

Re: Why we switched from Python to Go

#321

Post by bpicolo »

hasenj wrote: post #289
bpicolo wrote: post #272

Earlier quoted context omitted.

> why do people spawn multiple instances of their app For concurrency (number of requests handled at once) instead of speed (end-to-end time of of a single request)

If that was the only reason (which it is not), it would still be a very good reason to stop writing code in these languages. Why waste 10x more memory?

> Why waste 10x more memory?

That sort of question is totally missing the point of why people use these languages, yeah? Languages in the web world don't tend to be chosen based on memory requirements (or speed as this suggests). Are there cases where you want to think about that? Sure.

People have plenty of reasons they'd want to use Python over Go, and vice versa.

Re: Why we switched from Python to Go

#322

Post by sametmax »

pleasecalllater wrote: post #242
sametmax wrote: post #129

Earlier quoted context omitted.

Well, python has type check since 3.4 so...

Really? How does it work?

Google mypy for an introduction. Pycharm has good support for it if you want IDE integration.

The stdlib is globally well annoted now. However, most 3rd party libs are not.

Re: Why we switched from Python to Go

#323

Post by luord »

slackingoff2017 wrote: post #309
luord wrote: post #52

Earlier quoted context omitted.

> Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. You answered your own question. Why bother with those languages when the language isn't the bottleneck? In those cases, what language one uses becomes an entirely subjective matter. > All the big companies are [...] For every large company using Java, Go, Rust, C, etc. There's another…

And most of those other companies like Facebook are writing endless hacks, VM's, or entire languages to fix the slow runtime :)

Sorry, I have no interest in getting into a religious flamewar. I will only say that I find it weird that you think that there aren't endless hacks and VMs in [insert here the languages you like].

Re: Why we switched from Python to Go

#324

Post by SmirkingRevenge »

joshuamorton wrote: post #79
foota wrote: post #37

Earlier quoted context omitted.

Solved as long as there aren't native dependencies not managed by pip, which there often are.

Wheels solved this problem in 2013. For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels. This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and eve…

You can pip install pyspark now too!

Re: Why we switched from Python to Go

#325

Post by luord »

eadmund wrote: post #75
luord wrote: post #55

Oh, terrific, another one. The only solid reason this article gave was the second one and, really, is the only one that would ever make sense: If the language one's using becomes the bottleneck then, by all means, change it[1]. Everything else is fluff and opinions. Every single other reason is stuff that is entirely subjective and/or python already has and even the article itself acknowledges, at least for one "reas…

I don't think that performance is the key reason to switch from Python to Go (although it is nice): as someone who switched from Python to Go, what really made it worthwhile for me was knowing that my code is significantly more likely to be correct when it runs. Go's typing is much nicer than Python's, for this use case. Performance is just gravy.

That's subjective, and part of the sixty-year-old flamewar known as "dynamic vs static".

You like to write the type of your variables next to them, all the power to you. I don't or, more exactly, I prefer the little extra flexibility of not having to do that.

Re: Why we switched from Python to Go

#326

Post by JelteF »

Can_Not wrote: post #317
JelteF wrote: post #257

Earlier quoted context omitted.

No, we didn't try those. Mainly because it wasn't only raw performance that we were after. We also wanted more simplicity and better concurrency than what python was providing for us. Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite…

Did you ever consider Elixir?

We did but Go was deemed better in our case. For more details Ctrl+f for Elixir in the blogpost.

Re: Why we switched from Python to Go

#327

Post by pjmlp »

dx034 wrote: post #286
pjmlp wrote: post #137

Earlier quoted context omitted.

Pick the Fortune 500 list, take out the SV darlings, the majority of their backend stacks will be a mix of Java and .NET deployments. Easy to find out just by looking at their open job positions.

I'd say that you find a fair share of C++ as well. Especially for high volume endpoints.

Quite true, although it tends to be used in native libraries called from one of those managed languages.

Re: Why we switched from Python to Go

#328

Post by Scramblejams »

marcosdumay wrote: post #297
Scramblejams wrote: post #120

Earlier quoted context omitted.

Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.

I don't get how low latency GC can be a good selling point. I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once? Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percen…

Games. I like low latency and garbage collection. I feel like, hey, it's 2017, those things (along with performance within a reasonably small multiple of C's) really should go together.

Re: Why we switched from Python to Go

#329

Post by Scramblejams »

lmm wrote: post #191
Scramblejams wrote: post #120

Earlier quoted context omitted.

Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.

If you want a nice ML with low GC latency, how about Rust? (Did you look at tuning the GC? As a Scala guy I know a some people write off the JVM because the default GC settings are optimised for throughput rather than latency (whereas Go does the opposite), when often their requirements are comfortably within what the JVM can do when suitably configured. That said I've heard the CLR is less tuneable)

Rust is too complicated for me to learn and be productive with in a reasonably short period of time, and the CLR is not good at keeping GC pauses down. :-(

I have high hopes for Pony, though.

Re: Why we switched from Python to Go

#330

Post by Scramblejams »

dualogy wrote: post #186
Scramblejams wrote: post #120

Earlier quoted context omitted.

Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.

I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing PureScript compiler once PR #3117 gets accepted). Watch http://github.com/metaleap/gonad/ --- hoping to "get there" within 2 weeks. Taking unreasonably long already, given that purs already does its jobs on its own like parsing, type-checking, transforming-ML-to-imperative. One reason I'm taking a bit longer than the quickest-dirtiest approach…

Thanks for the tip! I'll keep an eye on it.
Post reply on HN