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

From Python to Go and Back Again

docs.google.com

Post reply on HN
Print view View original

101–110 of 167 posts

Re: From Python to Go and Back Again

#101

Post by bipin_nag »

My take on the points mentioned:

1. Goroutine memory use - Post happens to be about 1.2 and 1.4 and I started with 1.5.

2. Debugging - yes handling errors are a bit tedious. I have not written much boilerplate to handle errors. I just copy error handlers a lot. Maybe that’s why error strings are a lot common.

3. Goroutine leaks - This is scary, I have used goroutines with channels but properly so far. Yes you can write code that leaks. This is something you will have to check yourself.

4.Testing - not done much.

Overall - I feel author learned of some negative aspects about Go and turned away. Some of them like Goroutine memory footrpint will improve with time (e.g. 1.5 earned a lot of praise for GC improvement). A lot places author mentions possible improvements for e.g godebug or latest Go with SSL but did not try it as much. So it may not be as relevant to new Go adopters.

Re: From Python to Go and Back Again

#102

Post by spoiler »

nulltype wrote: post #59
eugenekolo2 wrote: post #39

Does anybody have some comments on the closing statements on Google's 10KB secret?

I suppose there's the relevant blog post https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...

Is it possible that it's just a typo, though?

Re: From Python to Go and Back Again

#103

Post by azazel75 »

sandGorgon wrote: post #79

what 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 use ayncio and async/await coroutines of Python 3.5 on each of our packages.

I hope that PyPy will have a Py3.5 compatible interpreter someday, but CPython is good enough for now.

Re: From Python to Go and Back Again

#104

Post by azazel75 »

sandGorgon wrote: post #94
Too wrote: post #91

Earlier quoted context omitted.

> every framework out there is using Python 2.7.... That's just FUD, it might have been true many years ago but not any longer. http://python3wos.appspot.com/ , there are a few red holes but from what I could tell some of those have substitutes that in many cases are better even. It might also be true for in house libraries but at least there you have the chance to upgrade yourself.

I know that. But I'm hard pressed to find anyone who is using this stuff in production. the ecosystem is still running 2.7. I cant wait to switch to Py3.

> the ecosystem is still running 2.7. I cant wait to switch to Py3.

Which one? Pyramid and SQLAlchemy work like a charm in Py3. Until you really name what your need is, that's just fud.

Re: From Python to Go and Back Again

#105

Post by buro9 »

This is interesting, there are places I would still choose Python over Go. But usually these are front-ends due to the richness of the l10n, i18n and template options that Python has. On the backend I exclusively use Go and have not seen route leak issues or some of the other things. The only thing that I do feel is that some Go code is harder to mock and fully test effectively.

Re: From Python to Go and Back Again

#106

Post by tome »

laumars wrote: post #99
latch wrote: post #9

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

While there is a nugget of truth in your statements, the generalisations are so excessive that the overall point is completely wrong. Lets take a few statements: > Most 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. Yes, the rewrite would certainly have helped. However some compilers and runtimes are just faster than…

> This forum, HN, is written in Haskell, which is also statically typed.

No, it's written in Arc, which is a variant of Lisp and is not statically typed.

Re: From Python to Go and Back Again

#107

Post by BerislavLopac »

mratzloff wrote: post #15

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

"huge unit testing burden necessary"

Why do you consider unit testing a burden? I find unit tests the best way to formalize specifications before even starting to write code.

Re: From Python to Go and Back Again

#108

Post by zimbatm »

Jabbles wrote: post #98
windlep wrote: post #42

Earlier quoted context omitted.

I should note, we don't care about throughput for the most part. Our constraint is purely the memory use of holding open the connections. The aim is to hold as many connections as possible within 10-20% of the machines RAM, and not exceed it. As such, we need to be careful about resource usage and spikes. Goroutines feel cheap, but if you're holding 140k connections, and just 20k of them do something that spins up a…

Typically if you wish to limit the number of goroutines you would spawn N workers and have them read from a single channel. If 20k of your incoming connections want to do something they send on the channel, without spawning a goroutine themselves. Did you try something like that?

How do these 20k connection feed the channel without being themselves managed by goroutines ?

One thing I wish was possible in go is being able to use the `select` keyword with both channels and IO.

Re: From Python to Go and Back Again

#109

Post by thwd »

peteretep wrote: post #88
mratzloff wrote: post #15

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

> the middlebrow dismissers The totally misplaced condescension is one of many reasons the Go community appears to be a net negative.

Come visit, we're quite friendly!

You know what really grinds our gears, though? People who don't read documentation.

If you don't read documentation, you'll get a negative vibe. Because your question is literally sitting at the top of the FAQ. It's been asked 2^1024 times before. WHY WON'T YOU READ THE DOCS?

Re: From Python to Go and Back Again

#110

Post by thwd »

dbaupp wrote: post #60
stock_toaster wrote: post #20

The claim that pypy uses less memory than Go seems...rather extraordinary. I worked with a fairly complex http api app that ran as a rather svelte wsgi framework under gunicorn, and we saw at least 10x or more increase in memory usage than cpython when we switched to pypy, once the jit was fully warmed up (memory usage seemed to hit steady state after about an hour). pypy has also historically (in my experience) been…

I don't know the details, but the memory difference was almost certainly due to the different approaches to concurrency. Python coroutines just need to save their exact stack frame while a Go goroutine will spawn a "massive" stack that likely has much more space than needed. The first case might only need tens or hundreds of bytes for a dozen local variables, while the latter case is a fixed overhead of several KB (8…

Your theory regarding PyPy's JIT is disproved rather easily. Python's grammar has been shown to not be context free. This implies that in the best case, the parser is supralinear in both time and space. Just the parser. Now add the rest of the JIT.
Post reply on HN