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

301–310 of 406 posts

Re: Why we switched from Python to Go

#301

Post by StavrosK »

sjellis wrote: post #139
dundercoder wrote: post #3

Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compare…

For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example. I won't say that Go is mainstream yet, but it feels very "production-rea…

Django's ecosystem has spoilt me so much that it's very hard to switch to another language, at least as far as web apps are concerned. I would love to play with Rust/Nim more, but most of the side-projects I'm passionate about involve at least a few things that Python has a lib for that would be a huge time sink to rewrite in another language.

Re: Why we switched from Python to Go

#302

Post by vgbm »

mmargerum wrote: post #225
ryanpepper wrote: post #148

Earlier quoted context omitted.

Does Go have templating?

Templating is built right into the Stdlib https://golang.org/pkg/text/template/ The only 3rd party library I pull in to build web servers is gorilla (routing, sessions) and a database driver . Everything else you need is in the go standard library .

I believe the parent means templating in the sense of generic types: https://en.wikipedia.org/wiki/Template_(C%2B%2B).

Re: Why we switched from Python to Go

#303

Post by shlomi-noach »

ubernostrum wrote: post #71
slackingoff2017 wrote: post #46

Why does anyone write web apps in Python? PHP? Ruby? Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faste…

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

> I'd be willing to bet over 99.999% of all deployed production web applications serving requests today -- has a bottleneck at the database and the network that dwarfs any overhead from language performance

A language is not just about overhead, it's also about capability. For example, your database is slow, and your web page needs to render by executing 20 queries. Will your programming language allow you to parallelize those queries? While your database/network may have high latency, they can still have good throughput.

This particular example is very real, and is incidentally relevant to the original post, since Python and Go implementations have different capabilities.

Re: Why we switched from Python to Go

#304

Post by bronze »

_hyn3 wrote: post #273
nimmer wrote: post #198

Earlier quoted context omitted.

Would you kindly share you experience on using Nim for that project?

For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afai…

> no interpreter

Try running `nim secret` on the command line, it's not perfect but it's enough to play around a bit.

Re: Why we switched from Python to Go

#305

Post by joshuamorton »

sethammons wrote: post #122
joshuamorton wrote: post #101

Earlier quoted context omitted.

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

>But if the build utility was just some binary

I mean it totally would if the binary dynamically linked against a file you didn't have on your system, which is exactly what happened with `wheel` (python 2.6 doesn't have OrderedDict, which wheel now uses).

Re: Why we switched from Python to Go

#306

Post by joshuamorton »

deathanatos wrote: post #113
joshuamorton wrote: post #79

Earlier quoted context omitted.

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…

Wheels doesn't completely solve this problem. For example, your example of matplotlib, IIRC, has a dependency on libblas: a C library. This dependency isn't captured in the wheel metadata, and it's up to you to install the right libblas on the host, or somewhere where it will get loaded. (Though honestly, this isn't usually an unmanageable level of complexity. But virtualenvs are not free from external dependencies a…

As another user mentioned, they do, if the library maintainers take the time to do things correctly. The package I'm describing does not link outside of the virtualenv, the matlplotlib, opencv-python, and tensorflow libraries include all necessary dependencies (although you have to use a non-default renderer in matplotlib, because it doesn't bundle all of them).

What you say is correct, virtualenvs are not free from external dependencies always, but correctly build wheels are. Wheels and virtualenvs aren't the same thing.

Re: Why we switched from Python to Go

#307

Post by joshuamorton »

alfla wrote: post #133
joshuamorton wrote: post #79

Earlier quoted context omitted.

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…

Could you elaborate on how ROS fits into this framework?

That's a different project, but I also use ros in a virtualenv. Its a bit weird because you end up installing ros both inside and outside of the venv (various ros command line tools only use /opt/ros/... python deps), but your actual nodes run in your virtualenv.

And ros doesn't even need to be a wheel fwiw, its pure python, but its also just a painful thing to deal with for many, so it was worth mentioning.

Re: Why we switched from Python to Go

#308

Post by charred_toast »

charred_toast wrote: post #299
charred_toast wrote: post #15

You had me at 4. I'm definitely GOing to give this language a GO now. That was a GOod introduction to the language, a veritable advertisement, if you will.

The audience on Hacker News takes themselves way too seriously, apparently.

Case in point. Thanks. Also, the moderators seem to have no life. Please deactivate my account if you're offended. I'd prefer not to spend more time attempting to communicate with one dimensional, armchair experts.

Re: Why we switched from Python to Go

#309

Post by slackingoff2017 »

luord wrote: post #52
slackingoff2017 wrote: post #46

Why does anyone write web apps in Python? PHP? Ruby? Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important. Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faste…

> 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 :)

Re: Why we switched from Python to Go

#310

Post by slackingoff2017 »

Jach wrote: post #68
adambard wrote: post #50

Earlier quoted context omitted.

The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application. My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and buil…

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...

This just isn't true on any decently designed system I've seen. Practically any database can manage 5k complex-ish queries per second. For the common simple queries closer to 50k.

Good luck getting more than 100 calls per second out of the slow languages

Post reply on HN