What's unusual is that this project uses PyPy in production. PyPy has been a long time coming. Until recently, Python was defined by CPython, which is a naive interpreter. As this article points out, performance is roughly an order of magnitude better with PyPy. Now PyPy has to be taken as seriously as CPython, if not more seriously. In a few years we may look at CPython as the "toy" implementation.
From Python to Go and Back Again
71–80 of 167 posts
Re: From Python to Go and Back Again
#72Earlier quoted context omitted.
node.js has a GIL and nobody talks about that either. The GIL is not relevant because Python is so slow that running it in two threads is hardly an improvement.
But don't you need to run a bunch of node.js instances in production on a multi-cpu system behind nginx or haproxy? Would it be necessary had it not been for the GIL?
Most node.js code spends barely any time on the v8 thread. The node code merely invokes routines in libuv, which has a thread pool for anything computationally intensive.
Re: From Python to Go and Back Again
#73"Go experts still can't write leak-free code" Big statement, anyone confirm this?
The next two slides have screenshots of issue tracker searches for "goroutine leak".
Re: From Python to Go and Back Again
#74There are people who have been working in Go for years, successfully, but who don't post comments with the same frequency and dogged determination as the middlebrow dismissers. Both Python and Go are fine. They both have their strengths and weaknesses. I personally wouldn't write a web app in Go (at least, anything beyond the most basic admin interface). I also personally wouldn't write a very large and complex Pytho…
Do you have any increased optimism about the refactorability of python given the recent addition of type annotations?
Definitely, but given the relative recency my comment still stands. Ultimately, all libraries in use in a given application must support this as well for it to be truly comprehensive.
As a side note, sometimes you do need that performance gain, without wanting to resort to C or C++. I hope to see Python make some gains there with the addition of the type information.
Re: From Python to Go and Back Again
#75I'll be interested in coming back to Python when it isn't a headache to deploy into production. I'm tired of an install requiring a GCC compiler on the target node. I'm also tired of having to work around the language and ecosystem to avoid dependency hell.
The way I deploy Python apps at $EMPLOYER: - CI system detects a commit and checks out the latest code - CI system makes a virtualenv and sets up the project and its dependencies into it with "pip install --editable path/to/checkout" - CI system runs tests, computes coverage, etc. - CI system makes a output directory and populates it with "pip wheel --wheel-dir path/to/output path/to/checkout" - Deployment system dow…
You really should look at Armin's (same guy who wrote Flask and Jinja2) platter tool. It takes a few of the steps out and for an almost identical workflow as you, we are switching to it.
Really nice stuff
Re: From Python to Go and Back Again
#76I appreciate these war stories more than the "look at this great new thing that will take over the world" posts (those have a place as well). We need more war stories in this industry because everything has pros and cons, and our job as software engineers is to be able to make decisions based on limited information. Case studies are great way to glean real-world experience from others without having to implement ever…
Just wanted to share my own very small case study. I had a homework assignment to build a polite crawler. I initially built it in Python, and it was awfully slow. I rewrote same thing in Go, it turned out to very very fast (10x at least IIRC). I liked the fact how quickly I was able to write something so quickly (with not so shabby design) in Go with so much less experience in it. Go is definitely awesome for writing…
Did you try pypy before rewriting?
Re: From Python to Go and Back Again
#77Most people who rewrote their apps from X to Go and saw improved performance and readability benefited much more from the rewrite than they did from Go. At best, the fact that Go has a relatively weak ecosystem, means that they had to write from scratch a lot of things they were getting for free in X. But, because in X is was a library, they only used 5% of the features, but paid a high performance cost and had a com…
This is patently absurd. It's mind boggling that people still hop on here and declare how something is "amazing" or "horrible" for a particular problem-set as fact. You want my anecdote? Go is brilliant for web services. We've decreased server costs significantly while decreasing response times by orders of magnitude for write-heavy APIs. Concurrency primitives that do bleed into parallelism have made a mockery of in…
What is the point of your comment? Your doing the same thing your telling people not to do. You're not even disagreeing with the previous post which essentially states the same things you do. The only thing your comment tells me is that which developers you work with are far more important than the language itself.
Re: From Python to Go and Back Again
#78I have to note this, because I think it deserves quite a bit more attention. SSL is extremely expensive, on RAM (perhaps the implementations have optimized for throughput over RAM). I have yet to benchmark any SSL implementation in any language, with any binding, that can use less than 20kb per SSL connection. I mentioned in my talk here that SSL is very expensive, here's my benchmark suite that others may add to: ht…
Do you have results for the different tests? I did not see any in the repo.
Re: From Python to Go and Back Again
#79what is strange is that everyone seems to be using Python 2.7 in some form. There is all this new work being done in Python 3 asyncio but there is nothing that is being used... and this is from a guy who pretty is a core developer in several python projects.
I look at Ruby or Go... or even Java and every new language feature has a much more rapider adoption curve.
is this a pretty solid statement that the entire Python 3 + asyncio path is a dead end ?
Re: From Python to Go and Back Again
#80what is strange is that everyone seems to be using Python 2.7 in some form. There is all this new work being done in Python 3 asyncio but there is nothing that is being used... and this is from a guy who pretty is a core developer in several python projects. I look at Ruby or Go... or even Java and every new language feature has a much more rapider adoption curve. is this a pretty solid statement that the entire Pyth…
We used Python 2.7 for pypy compatibility. I really dig the new async/await primitives added to Python 3.5 and think the asyncio path is the best path forward. I hope the work to get all the latest asyncio stuff working on PyPy picks up some steam.