Live data from Hacker News

Why I went from Python to Go (and not node.js)

orel.li

141–150 of 202 posts

Re: Why I went from Python to Go (and not node.js)

#141

Earlier quoted context omitted.

For what it's worth, I've used Python professionally and in several classes. I certainly don't have much experience in it, but it would be odd if I did--why would I use a language I don't particularly like too much? You only say there are no horrible gotchas with tuples because you've never spent hours hunting down a bug and finding that you forgot a trailing comma. More pertinently, changing something like ("foo", "…

I like how after all these paragraphs you've managed to avoid having to offer up your own personal example of a "good" and "outstanding" language. But have no problem labeling other languages as NOT being such, with very poor examples :P You should get an achievement of some sort. Hackernews needs achievements.

Why were the examples poor? Also, if he'd have "Python is mediocre, and X is fantastic", the discussion would've moved to X. He was right in not doing that.

And why the bitterness?

Re: Why I went from Python to Go (and not node.js)

#142
post #68
post #42

It would help a bit if the article included at least roughly equivalent Go code next to the Python code. The Go code is wordier, but maybe it takes less time to write because it doesn't require as many decisions (libraries etc.) as with Python. package main; import ( "fmt" "net" ) func main() { hosts := []string { "www.google.com", "www.example.com", "www.python.org" } c := make(chan string) for _, h := range(hosts)…

This is a very good example of the type of thing I'm talking about. Nobody prompted you to do so, but you gracefully handled the case of a DNS failure in your code, because the control path was obvious throughout. Go makes this type of error handling a topic very early on in the literature. I find this type of clarity when structuring concurrent code to be very helpful in minimizing subtle concurrency bugs.

On error handling in Go vs. Python:

Lack of exceptions means the deeper the call stack the higher the proportion of error handling code relative to a normal (non-exceptional) code path.

For example, if you decide to refactor some code from a bigger function into its own smaller function then all error handling code have to be repeated twice (first in the child function then in the parent that calls it). It introduces unnecessary clutter and boiler-plate.

Exceptions allows you to limit the error handling to two places: the place where you detect an error and the place where you are ready to handle it and not throughout the whole call stack.

Language with a builtin garbage collection can (should) afford a builtin exception support.

I like that Go excludes some language features on purpose but in the case of exceptions Python has its merits.

Re: Why I went from Python to Go (and not node.js)

#143
post #83

Earlier quoted context omitted.

> but this is part of the problem: it's a library. Concurrency deserves language-level support. Adding concurrency at the library level is like adding an object system at the library level. Which is not a problem at all. Lisp and Scheme have been doing that since forever.

I assume they depend on macros to do so? That changes the game. Hans Boehm has an excellent paper on this issue titled "Threads Cannot be Imlemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf That paper was published in PLDI ( http://dl.acm.org/citation.cfm?id=1065042 ). His arguments have much to do with what the compiler doesn't know, which could potentially be solved with macros.

But these arguments are pretty much invalid today: C++11 introduces explicit support for concurrency, and the compiler MUST be aware of it, even though it may look (on the surface) as a "library".

Re: Why I went from Python to Go (and not node.js)

#144
post #90

Earlier quoted context omitted.

"Everyone less nerdy than me is stupid and everyone more nerdy than my is a no-life". I think it's pathetic, not funny.

Sounds like a variation on George Carlin's line that everyone who drives slower than me is stupid and everyone who drives faster is crazy.

Wasn't it asshole/maniac?

Re: Why I went from Python to Go (and not node.js)

#145
post #107

Earlier quoted context omitted.

since Python is a thoroughly mediocre language. Care to elaborate?

Is there anything to add? It's not very fast. It does not have any interesting abstraction. It doesn't push the envelope further. It doesn't allow any clever optimizations. It has a bunch of horrible gotchas (scoping, mutable default arguments, tuples of one element...). It isn't elegant--the grammar alone takes pages and it's just a loose collection of mostly orthogonal features with largely arbitrary (but, admitted…

There are no perfect languages. They aren't a bag of individual features, but platforms these days. Taken as a broad platform, the python ecosystem is up there with the best, warts and all. Why, because others have even more.

No offense, but your youth is showing--it appears you haven't used it long enough to fully understand it (gotchas), have unrealistic expectations of purity, and aren't very aware of the preceding. Yet you still have strong opinions... like most of us experience will beat you down, give it time.

I wrote a few of these stinkers a decade ago and would laugh at them now.

Re: Why I went from Python to Go (and not node.js)

#146
post #97
post #70

Earlier quoted context omitted.

You should update the node.js docs if you consider the original JS snippet ugly, because that's where I pulled the original code sample from verbatim. In any case, it's still not an apples to apples comparison. The node.js example forks separate processes that share nothing, while in the Go example it all runs in one process so the HTTP handlers can communicate with each other via channels or other shared data struct…

The idea with node is that you dont normally need multiple threads or processes because you have nonblocking io. http = require 'http' server = http.createServer 'localhost', (req, res) -> res.writeHead 200 res.end 'ok' app = server.listen 3000

I made a mistake, did not mean to include 'localhost' in there.

Re: Why I went from Python to Go (and not node.js)

#147
post #142
post #68

Earlier quoted context omitted.

This is a very good example of the type of thing I'm talking about. Nobody prompted you to do so, but you gracefully handled the case of a DNS failure in your code, because the control path was obvious throughout. Go makes this type of error handling a topic very early on in the literature. I find this type of clarity when structuring concurrent code to be very helpful in minimizing subtle concurrency bugs.

On error handling in Go vs. Python: Lack of exceptions means the deeper the call stack the higher the proportion of error handling code relative to a normal (non-exceptional) code path. For example, if you decide to refactor some code from a bigger function into its own smaller function then all error handling code have to be repeated twice (first in the child function then in the parent that calls it). It introduces…

Go has panic/recover if you have to propagate an error through multiple layers.

Re: Why I went from Python to Go (and not node.js)

#148
post #20

Another gonatic? I'm immediately reminded of the days when everyone who liked D proclaimed it would overtake C++ and rule the world with terrible, contrived examples: "let me show you why my language is better than yours by completely misunderstanding how to solve a problem, then implementing that broken/overengineered solution in your language, then compare it to something my language's API can do for me, just so we…

> The insight to async I/O is that this server, for this I/O bound task, will perform as well as your GOMAXPROCS example

No, it doesn't scale on multiple CPUs if you don't use the 'cluster' package.

Re: Why I went from Python to Go (and not node.js)

#150
post #91

Earlier quoted context omitted.

Erlang is intimidating? How? It's a braindead simple language.

It doesn't look like C!!!

C is can be intimidating, C++ often is. You have to gain much experience to be able to write good C++ code. With Erlang it's simple. It's supervisiors and gen_servers all the way down.
Post reply on HN