From Python to Go and Back Again • Hacker News Board

Re: From Python to Go and Back Again

#111

Post by kintamanimatt » Sat, Oct 17, 2015, 11:40 AM UTC

sandGorgon wrote: post #89

windlep wrote: post #80

Earlier quoted context omitted.

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

For certain things that they probably shouldn't be used for, not across the board.

Re: From Python to Go and Back Again

#112

Post by dbaupp » Sat, Oct 17, 2015, 11:40 AM UTC

thwd wrote: post #110

dbaupp wrote: 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…

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.

My hand-waving is "disproved" even more easily than that, by passing a dynamically generated string to `eval`. However, that's missing my point (and my "-ish"): the JIT is a constant overhead. Assuming they're being careful to not dynamically generate code for handling each coroutine (seems like an obvious thing to avoid, and a reasonable assumption), the JIT'd code is shared across all coroutines, so as you accept more and more connections, requiring less memory for each coroutine will eventually outweight the memory cost of the JIT.

Re: From Python to Go and Back Again

#113

Post by hyperbovine » Sat, Oct 17, 2015, 11:56 AM UTC

This page displays exactly nothing with JavaScript disabled. I realize that no js makes me something of a Luddite, but there are solid reasons for turning it off, particularly on mobile. Is it really too much to ask of google that the text of a presentation in some way live inside HTML? Novel concept, I know.

Re: From Python to Go and Back Again

#114

Post by laumars » Sat, Oct 17, 2015, 12:10 PM UTC

tome wrote: post #106

laumars wrote: post #99

Earlier quoted context omitted.

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.

Weird, I could have sworn I read that HN was written in Haskell. That error aside, my points were still valid. Most of latch's post were an exaggerated and largely inaccurate generalisation. Personal opinions of Go aside, it's daft to argue "most static languages [are] cumbersome, error prone, slow, inflexible and difficult to test."

I know I've been heavily down voted in my previous comment, but I've developed in well over dozen different languages of different paradigms for the last 3 decades - so I have quite a broad range of experience as well as being language agnostic - ie I'm not just some angry fanboy :p

Re: From Python to Go and Back Again

#115

Post by gnuvince » Sat, Oct 17, 2015, 12:16 PM UTC

BerislavLopac wrote: post #107

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.

Unit testing is a burden because (a) a programmer needs to think of the cases that must be tested, (b) a programmer needs to actually write them, (c) they can only act as a safety net. When possible, it's very advantageous to encode your invariants into the type system. Yaron Minsky gives a good example in his Effective ML talk[1] about how you can take a common data structure and refactor it in such a way that the type system prevents you from ever creating an illegal state. (Note: this doesn't absolve statically typed languages from having suites of tests, it just allows them to remove large swaths of those tests if they can be enforced by the type system.)

[1] https://youtu.be/DM2hEBwEWPc?t=1085

Re: From Python to Go and Back Again

#116

Post by gaius » Sat, Oct 17, 2015, 12:18 PM UTC

hyperbovine wrote: post #113

This page displays exactly nothing with JavaScript disabled. I realize that no js makes me something of a Luddite, but there are solid reasons for turning it off, particularly on mobile. Is it really too much to ask of google that the text of a presentation in some way live inside HTML? Novel concept, I know.

Javascript is like Flash, it's great for the author of a page to show off, or force an ad on you, but how does it actually benefit the end user? Not at all, never has.

Re: From Python to Go and Back Again

#117

Post by latch » Sat, Oct 17, 2015, 12:20 PM UTC

laumars wrote: post #114

tome wrote: post #106

Earlier quoted context omitted.

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

Weird, I could have sworn I read that HN was written in Haskell. That error aside, my points were still valid. Most of latch's post were an exaggerated and largely inaccurate generalisation. Personal opinions of Go aside, it's daft to argue "most static languages [are] cumbersome, error prone, slow, inflexible and difficult to test." I know I've been heavily down voted in my previous comment, but I've developed in we…

I wasn't going to reply, but your misquote is dishonest. I specifically said that it was those thing with respect to dealing with web requests within the further scope of talking to the database and dealing with user input. I also pointed out cases where Go's either "great" or "good", with one of those being some types of web services (thus further scoping my "generalisation".)

Re: From Python to Go and Back Again

#118

Post by laumars » Sat, Oct 17, 2015, 12:35 PM UTC

latch wrote: post #117

laumars wrote: post #114

Earlier quoted context omitted.

Weird, I could have sworn I read that HN was written in Haskell. That error aside, my points were still valid. Most of latch's post were an exaggerated and largely inaccurate generalisation. Personal opinions of Go aside, it's daft to argue "most static languages [are] cumbersome, error prone, slow, inflexible and difficult to test." I know I've been heavily down voted in my previous comment, but I've developed in we…

I wasn't going to reply, but your misquote is dishonest. I specifically said that it was those thing with respect to dealing with web requests within the further scope of talking to the database and dealing with user input. I also pointed out cases where Go's either "great" or "good", with one of those being some types of web services (thus further scoping my "generalisation".)

I did get your scope, but I don't agree with it. I've written web applications (with database hooks, obviously) in both statically typed and dynamically typed languages. Defining the return types from your DB lookups takes only a few seconds of additional mental overhead than dynamic languages do. But that cost does have additional benefits that can save time debugging. So in the grand scheme of things, there really isn't much between ones productivity dynamic and typed languages (assuming someone of equal proficiency in both paradigms)

I will grant you that Go does get a little more awkward if you're dealing with null data types in the database as you then need to start casting interfaces. Which gets a pain real quick. But it's rare that you actually need null types in the database - usually that requirement can be circumvented at the database design level (eg using default values in the table design or defining flag fields).

Sometimes a different language will require you to architect your platform a little differently, but that's kind of the point of having different tools.

Re: From Python to Go and Back Again

#119

Post by dom96 » Sat, Oct 17, 2015, 12:36 PM UTC

zem wrote: post #10

i've seen a lot of these posts ending along the lines of "it's time for rust". two languages that are always conspicuous by their absence are D and ocaml. D in particular seems like it would be the logical upgrade path from python or ruby. it has a comfortably familiar C lineage, supports a variety of programming paradigms, and has good concurrency support. i wonder why people don't at least give it a look. (personal…

Another language that is missing from such posts is Nim. It is a far more logical upgrade from Python than any of the other languages that you mention (or ones that others mention in reply to you) in my opinion. Especially so for the use cases explained in this post, for example Nim supports async very well with a syntax that is very similar to C#'s async await.

Re: From Python to Go and Back Again

#120

Post by mercurial » Sat, Oct 17, 2015, 12:44 PM UTC

zem wrote: post #27

flogic wrote: post #24

Earlier quoted context omitted.

I've tried a couple of times to play with Ocaml. In seem like something that should be great but it just falls short. Some of that is tooling that isn't fully baked. Another issue is the syntax. The weird split between the interface description file and the code file. The lack of a unified DB interface. The lack of proper Windows support.

i enjoy using ocaml a lot, but the lack of a good orm and the bad windows support are indeed very painful. the tooling used to be bad, but at least under linux i'm pretty happy with it these days for my small hobby projects. it's one of those languages that i'd love to be able to use at work; i miss the type system when i'm doing c++.

Having worked with and without ORMs, I'm not sure what a "good ORM" is. On the other hand, a somewhat type-safe generic SQL query builder would be very nice to have.