Live data from Hacker News

From Python to Go and Back Again

docs.google.com

161–167 of 167 posts

Re: From Python to Go and Back Again

#161
post #142
post #60

Earlier quoted context omitted.

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…

The memory used by the JIT will at some point remain constant but before that happens, it will grow as the JIT considers more and more traces to be worthy of compilation. It can take a very long time until the memory consumed by the JIT actually remains constant. If you do continuous integration and deploy several times per day, your application might never reach that point.

The fact it may be less than the long term result isn't so relevant: there's an upper bound so the memory use of the JIT is O(1) with respect to the number of coroutines.

Re: From Python to Go and Back Again

#163
post #4

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

Amen.

This post reminds me of another post I recently saw on HN, in which the author (someone with an Erlang background) lays out all sorts of reasons why he chose Ruby for a highly concurrent application that launches lots of (heavyweight) threads. Upon seeing the link on HN, my first thought was, Ruby!!?? But then I read the post and the reasons were all very sensible and practical-minded, so in that case Ruby was arguably a much better choice than Erlang, Go, Scala, Rust, etc. for a highly concurrent application.

Edit: here's the post I mentioned about Ruby being used for a highly concurrent application: https://news.ycombinator.com/item?id=10394450

Re: From Python to Go and Back Again

#164

Earlier quoted context omitted.

It seems weird how you can't easily package python into an executable without Docker.

You can with various levels of success with a few "freeze" programs. They basically bundle up the entire environment into an executable, so the executables are stupidly large (more-or-less the size of your /usr/lib/python directory plus the python binaries), but they mostly work.

I've done it before, but it was kind of a pain and I got the impression nobody else used that stuff. I wonder why it's not more popular/easy.

Re: From Python to Go and Back Again

#166

Earlier quoted context omitted.

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?

Not sure what you mean, but the site linked above says they do it <10KB and then a few paragraphs down says how they patched it to go down to a bit more than 5KB. So, I don't think it's a typo.

Re: From Python to Go and Back Again

#167
post #51
post #46

Earlier quoted context omitted.

Interestingly, ALGOL failed because it was too complicated to implement.. And Djikstra played a huge role in the formulation of that language. Why aren't you using ALGOL?

ALGOL-60 saw fine use in its day; Dijkstra criticized ALGOL-68, which indeed failed because it was too complicated to implement.

Hmmm... It is interesting how many years urban myths can persist.... 45 years and counting....

"In December 1968 the report on the Algorithmic language ALGOL 68 was published. On 20–24 July 1970 a working conference was arranged by the IFIP to discuss the problems of implementation of the language,[1] a small team from the Royal Radar Establishment attended to present their compiler, written by I.F. Currie, Susan G. Bond[2] and J.D. Morrison. In the face of estimates of up to 100 man-years to implement the language, using up to 7 pass compilers they described how they had already implemented a one-pass compiler which was in production use in engineering and scientific applications."

cf. https://en.wikipedia.org/wiki/ALGOL_68-R

Post reply on HN