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

81–90 of 167 posts

Re: From Python to Go and Back Again

#81

Post by broodbucket »

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…

The difference is that Python 3 is far more backwards incompatible than an update to Ruby, Go or Java. If there's any component of your Python project that was written for Python 2 and it hasn't been ported, your project as a whole is probably staying in Python 2.

I certainly wouldn't call the Python 3 path "dead", as starting a new project you'd be silly not to use Python 3. It's just a very slow process.

Also, porting from 2 to 3 isn't even that hard (there's a script that does 95% of it for you).

Re: From Python to Go and Back Again

#82

Post by bootload »

dbaupp wrote: post #73
bootload wrote: post #70

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

yeah I saw those, what about examples from independent people reading the article on HN?

Re: From Python to Go and Back Again

#83

Post by pekk »

scott_karana wrote: post #7
zeckalpha wrote: post #6

Yes, it is time for Rust.

Yeah, Rust sounds like a great Python replacement. /s I do like Rust, but must we clutter every Go-related thread with comments about it? The zealousness is annoying.

Well, Python-related threads have been cluttered with comments about Go for a few years now...

Re: From Python to Go and Back Again

#84

Post by zobzu »

"drank koolaid, used tool without knowing what its good at, lost 2 years and probably a million or two in engineer resources"

Gratz. Next time, use C. PyPy won't solve your problem. You're writing a low latency, high performance, large throughput, super-optimized message router. Even the libs you like in Cpython are.. freaking C. Do you know why? Do you understand what happens underneath the language? Do you know why PyPy is faster?

Don't get me wrong - and in fact, maybe you get me right:

Go rocks. Python rocks. It's just not the tool for that very job. Today, it's still freaking C.

Re: From Python to Go and Back Again

#85

Post by zobzu »

anacrolix wrote: post #45
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…

> You can't write Java enterprise software in Go, and I really appreciate that. You can, and I've seen it, unfortunately.

"Anybody can fuck stuff up beyond recognition with any language" -anonymous

Re: From Python to Go and Back Again

#86

Post by crdoconnor »

zobzu wrote: post #85
anacrolix wrote: post #45

Earlier quoted context omitted.

> You can't write Java enterprise software in Go, and I really appreciate that. You can, and I've seen it, unfortunately.

"Anybody can fuck stuff up beyond recognition with any language" -anonymous

It's certainly much easier in some languages than it is in others.

Re: From Python to Go and Back Again

#87

Post by sandGorgon »

broodbucket wrote: post #81
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…

The difference is that Python 3 is far more backwards incompatible than an update to Ruby, Go or Java. If there's any component of your Python project that was written for Python 2 and it hasn't been ported, your project as a whole is probably staying in Python 2. I certainly wouldn't call the Python 3 path "dead", as starting a new project you'd be silly not to use Python 3. It's just a very slow process. Also, port…

I understand this in its abstract sense - but I think (IMHO) the fundamental problem is that every framework out there is using Python 2.7.... which means nobody is using it.

I'm not sure if you have worked in the Ruby or Go ecosystem... but if you are starting a new project, you are using latest Ruby+latest Rails. this is not the case in Python. I asked a question here and on the /r/python forums. What framework should one use to build an API using asyncio+postgresql. Nobody seems to be doing it.

the answers I got mentioned using Tornado with Python 3 code on top of it.

People have compared asyncio with goroutines - but even for a project that is a migration from Go -> Python by a fairly advanced developer ... Py 2.7 is being used.

Re: From Python to Go and Back Again

#88

Post by peteretep »

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.

Re: From Python to Go and Back Again

#89

Post by sandGorgon »

windlep wrote: post #80
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 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.

hey - thanks for replying.

if Pypy + asyncio was available, would you have built everything using that stack ? There have been all these benchmarks that asyncio is so much slower than threads [1] How would you compare that with Go ?

[1] http://techspot.zzzeek.org/2015/02/15/asynchronous-python-an...

Re: From Python to Go and Back Again

#90

Post by thristian »

SEJeff wrote: post #75
thristian wrote: post #33

Earlier quoted context omitted.

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. http://platter.pocoo.org/dev/ Really nice stuff

Actually, that's where I got the idea... but when I last looked at Platter it was covered in "experimental only, do not use in production warnings".

Considering I'd have to write a build script to use Platter, it didn't seem like it would be a lot of work to write a few extra lines and not require an additional dependency.

Post reply on HN