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

51–60 of 167 posts

Re: From Python to Go and Back Again

#51

Post by ylh »

FraaJad wrote: post #46
ylh wrote: post #43

Earlier quoted context omitted.

People saying "backwards to Go" instantly reminds me of the following quote: Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set? — Edsger W. Dijkstra

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.

Re: From Python to Go and Back Again

#52

Post by windlep »

I 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: https://github.com/bbangert/ssl-ram-testing/

I have implementations in several languages, so far both Go and Python 3.4 can get as low as the 20kb cited. If you can get your per-connection state below 20kb, then merely adding SSL means doubling or worse your RAM requirements, which is huge.

I appreciate that everyone loves obsessing on the language wars, but the SSL RAM overhead affects us regardless of language. I covered that in one of the slides near the end, it'd be great to see some movement on reducing the RAM footprint here.

Re: From Python to Go and Back Again

#53

Post by proveanegative »

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…

It is unusual to claim that programming in a statically typed language is more error-prone than in a dynamically typed language, even if only when dealing with HTTP requests specifically. Could you elaborate? It sounds like there might be a story behind this.

Re: From Python to Go and Back Again

#54

Post by latch »

proveanegative wrote: post #53
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…

It is unusual to claim that programming in a statically typed language is more error-prone than in a dynamically typed language, even if only when dealing with HTTP requests specifically. Could you elaborate? It sounds like there might be a story behind this.

Thanks for calling me out on that, I might have a hard time justifying the claim. It was a reference to the fact that, at your system boundaries the benefit of a strongly-typed language aren't only offset by the lack of flexibility, but, in the case of Go, it's weak reflection capabilities and type system.

A web app has 4 (often more, rarely less) such boundary:

- Getting input from users

- Querying a database

- Getting results from a database

- Outputting results to the user (html, json, ....)

Within these boundaries, yes, static languages are less error prone. But you get no compile time checks AT the boundaries. You'll need integration tests (and it's easier to write tests in a dynamic language (where IoC is a language feature) than static languages.

You deal with these boundaries via automated mapping (with annotations, or external files (like in Hibernate)) or manual mapping. Automated mapping might not be much more error prone, but it's certainly much more cumbersome (especially with weak reflection). Manual mapping is also much more cumbersome. Does this cumbersomeness make it more error prone? I don't think it helps.

Re: From Python to Go and Back Again

#55

Post by 0x434D53 »

Go is one of my working languages. Like with every other language (Python, OCAML, C#, some Java, Swift) i have a love-hate relationship with go.

What i agree on:

What i agree on with the presentation: Concurrency using goroutines and channels is f... hard besides very primitive scenarios. Even fork-join isn't that easy. There also the lack of expressiveness hurts: It's nearly impossible to build higher level abstractions above the channels/goroutines. You always have to do the bookkeeping of your goroutines.

I also agree on the error-handling problems: It's often hard to locate errors. It requires a big amount of discipline by the programmers to achieve some kind of ability to locate errors. No, i don't want the Java/C#-'i throw exceptions everywhere'-style back, but Go is the other extreme. Some more lightweight-panic wouldn't be bad.

What i can't agree on:

That you cannot mock without interfaces in Go is typically not a problem: There is no real encapsulation (_, ., no constructors) so in many cases you just an instantiate your structs as you need them. The classic for mocking - time - is problematic as in every language. IO is typically behind the various io.Reader/Writer... interfaces: No problems there.

The criticism about memory consumption i don't get: Every system i saw ported to go from Java, Ruby or Python had a much lower memory footprint than before. And typically go allows to optimize allocation quite well when needed.

Re: From Python to Go and Back Again

#56

Post by [deleted] »

themartorana wrote: post #50
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…

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…

[deleted]

Re: From Python to Go and Back Again

#57

Post by falcolas »

thristian wrote: post #33
falcolas wrote: post #12

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

The way I deploy Go apps at $EMPLOYER2:

- go get

- go test

- go build

- copy to target

It's possible with Python, it's easier with Go. It's a place where we could use a lot of progress.

Re: From Python to Go and Back Again

#58

Post by agumonkey »

ylh wrote: post #51
FraaJad wrote: 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.

Too complicated for its time or in absolute terms ? It surely did a lot.

Re: From Python to Go and Back Again

#60

Post by dbaupp »

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 previously, but 2 with Go 1.4 according to the slides).

The JIT memory is constant at runtime (proportional(-ish) to the amount of code, which is fixed) while it is desirable to have the number of coroutines be as large as possible.

Post reply on HN