

Why I Went From Python To Go (and not Node.js) (2012) - krat0sprakhar
http://jordanorelli.com/post/31533769172/why-i-went-from-python-to-go-and-not-node-js

======
davidw
It's a pity the only thing he has to say about Erlang is

"insane Erlang programmers who are content writing sumerian cuneiform all day
long"

Seems kind of equivalent to: "no, I never looked at Python - I heard it uses
white space".

~~~
drawkbox
The context of that paragraph though shows an understanding of the entire
scale of the development spectrum and was one of the most credible arguments
that peaked my interest in his reasoning. I have to say, this was the most
convincing argument I have read on going to Go and concurrency is very
important. I saw that line more as a joking punchline.

I am in the same Python to Node.js transition recently but still do lots of
Python, but new projects are Node.js more and more. I might dig into Go again
some more. The reason I think Node.js is still nicer, at least for now, is it
mimics the package scale of Python in that there is a package for everything.
A platform is all about the packages after the language/tools.

~~~
davidw
I got that he was joking a bit, but since he never mentioned Erlang again, and
he wanted something good at doing concurrent programming, it seemed a bit
"hah, hah, only serious". There are plenty of good things about Go, so I'm
sure it's a fine language for what he is doing, but I was wondering why Erlang
was never heard from again.

~~~
drawkbox
I see, yes Erlang really did revive the concurrency focus. But I also think
that the syntax is a major hurdle to widespread adoption. Mochimedia did some
cool stuff with Mochiweb in Erlang. Indeed though, you really shouldn't brush
over Erlang when talking concurrency as your main feature to decide on. But he
is right, syntax will hold it back, where Go doesn't really have that problem
as much. We have all experienced the tab push back on Python, dial that up on
Erlang.

------
adamors
>Being a Python programmer

I yearn for the day when we'll stop calling ourselves X programmer, and
writing articles about "switching languages" or "going from one to the other".

A language is a tool, not an identity.

~~~
andybak
Learning a language, tooling and ecosystem represents a significant time
investment.

Whilst I aspire to being a polyglot and agree that it's a desirable trait,
until you can arrange me a 30 hour day and a 10 day week, I'm going to spend
my time where I get the highest return at the moment - getting things done in
the best way I know how.

~~~
ASneakyFox
This is the age of Google. And in top of that all oop languages are basically
based off eachothor. On top of that intellisense. I don't see what's so hard.

~~~
chrisdew
Try some non-oop languages (e.g. Haskell, Clojure, Prolog, etc.) They're not
so easy to switch between.

~~~
espeed
However, once you grok a new language paradigm -- like functional programming
or logic programming if you only knew OOP -- you get to see the world in a
whole new way and then you realize the new way isn't harder, it's just
different. It's experiences like these that reveal a bigger picture. It's
experiences like these where you become more aware of how easy and limiting it
is for our minds to get locked into certain ways of thinking.

With each new lens you come face to face with the reality that the fewer
mental models you have, the more each one colors what you see, think, and
believe -- the thought patterns driving your decisions and ultimately setting
your trajectory. It's experiences like these that transcend tech and reveal
what Alan Kay means when he says "we see things not as they are, but as we
are" and "a change in perspective is worth 80 IQ points".

------
CmonDev
So he went from one language to another language instead of a framework... Ok.
I went from C++ to a C# instead of buying a kilo of bananas. Those are just
different things.

I expected to see something like "I looked at my specific class of problems
and it is not the kind of problems where Node.js gives a distinctive advantage
to justify dealing with a flawed language, so I decided to pick a framework
around a modern well-designed language, so that framework is..."

------
sbecker
I was hoping to learn something, but I found this blog post to be lacking in
actual content or substantial reasoned arguments. Phrases like "What? Come
on.", "Seriously?" and "It was clear-ish." don't tell us anything about what
the author does or doesn't like about a particular language or framework.

I thought Hacker School banned "feigned surprise" \-
([https://www.hackerschool.com/manual](https://www.hackerschool.com/manual)) -
maybe the author attended before this rule was put in place.

I'd love to read a re-write with all of those types of phrases swapped for
detailed explanations breaking down what and why the author thinks X is better
or worse than Y.

~~~
zemo
Feigned surprise is a different concept. Feigned surprise is when you act
surprised that someone else doesn't know something; it's when surprise is used
to illustrate that someone has failed to meet your expectations. "you've never
programmed Haskell?!?!" would be feigning surprise. For one thing, it's not
surprising that someone would have not programmed Haskell; lots of people have
not programmed Haskell. For another thing, it doesn't add anything; it's
tantamount to saying "I'm disappointed you haven't programmed Haskell". The
idea is that if someone hasn't seen or experienced something, you shouldn't
act surprised; you should act excited to introduce something new to the
person.

~~~
sbecker
Hey there, thanks for the reply. Maybe "feigned surprise" isn't the exact same
concept, but I think it's in the same ballpark. In any case, nothing personal.
I checked out the rest of your blog and plan to go back and read your more in-
depth posts about Go when I get a chance.

------
Artemis2
Go is great! It's also a good choice for concurrency operations thanks to
goroutines, which are not really threads nor other processes (this is what
node.js does in the cluster module, it fires a new process every time you fork
the main process - not very efficient by the way).

~~~
stewbrew
IMHO a good choice would be a language where this can be/is implemented as a
library and doesn't not have to be baked in.

------
est
OP is describing a WSGI problem, he then abandoned Python.

I wonder how soon he will abandon Go because of other minor issues.

BTW background processing without any extra library in Django+WSGI is totally
possible and deadly simple. The catch is that it's syncrhonous. But async with
Django+Gevent/uWSGI/Tornado

~~~
scribu
Django noob here. Could you give more details about the mechanism for doing
background processing you mention? (Not sure how it helps the user not wait if
it's synchronous.)

~~~
crucialfelix
Celery is over-engineered but it does get the job done for most of the types
of background tasks that I want a webserver to be involved with.

Sending emails, making thumbnails, building 8MB xml files and uploading them
to other servers, validating objects, sending messages to people, geocoding
addresses with google etc.

These types of things I do not want happening on the webserver at all. Its on
a separate machine. I certainly don't want to block the user from getting a
web response even while waiting for the email to connect and send.

But Django and python could really use lightweight synchronous support for
small things.

> (Not sure how it helps the user not wait if it's synchronous.)

example: Checking several URLs in parallel, collecting all the responses then
returning some summary to the user. User is waiting, but at least the python
doesn't have to do these sequentially so the wait is less.

~~~
crucialfelix
though note that if you are blocking a request for some remote response or
slow thing that your worker is not able to do anything else. it can't start
working on the next request. so in django its not a useable design style if
you have high traffic.

------
Osiris
I am just about to begin work at a new company that's looking to leverage
node.js to develop a fairly robust REST API that should be able to support a
lot on concurrent clients. I've been looking for an opportunity to learn Go.

Would it be worth investigating building it in Go rather than node?

~~~
danieldk
Why not just Java with an JAX-RS-based REST framework, such as Jersey or
RESTEasy? Maybe it's boring, but it is proven technology, the JVM scales very
well. You can develop on OS X and deploy on Linux without recompiles. Added to
that, Java has an enormous ecosystem, including good IDEs (such as IntelliJ)
and libraries.

~~~
NateDad
Go is pretty much proven at this point.

The JVM scales well for CPU cycles and considerably less well for memory
usage.

Recompiling is a non-issue when it only takes 2 seconds to compile a
relatively large application (larger than any REST API is likely to be).

The Go ecosystem is quite robust, you have multiple choices for pretty much
any functionality you need (and where you don't it's because the only one that
exists is just that good).

There are a lot of good editor plugins for Go. You don't generally need an IDE
per se. Auto-complete and go to definition is really all you need, and you can
get that in any major editor you like.

~~~
actf
I don't mean to be pedantic, but I disagree that the Go ecosystem has a good
choice for pretty much any functionality.

I think one major omission from the current Go ecosystem is a decent GUI
library. There have been some attempts however, to my knowledge, they are
mostly alpha/beta quality at best, and most of them are missing important
functionality (the major ones I'm aware of are go-gtk, go-ui, go-fltk, wxGo,
and none of them could be considered production ready IMHO).

I only point this out because I really like Go, and I think Go would actually
be a very interesting language to do client side desktop application
development in.

~~~
NateDad
Take a look at go QML. I think it'll be the one GUI library to really take
off, if for no other reason than the guy working on it (Gustavo), is pretty
brilliant, and it's going to be used to write applications for Ubuntu Touch.

~~~
actf
QML is awesome, and I'm a huge fan of it - and for that matter declarative
GUIs in general.

However the QML-go project, while promising, is definitely not production
ready. Their github page contains a large bold header that says: "this is
alpha software", and it specifically warns about stability issues.

Also QML in general, has some shortcomings right now (granted those problems
are being fixed) when using it for desktop software (specifically the lack of
desktop style widgets).

So while I think the project is awesome and I'm wishing it success, I wouldn't
want to use it for production quality software. I think my original point
still stands.

~~~
NateDad
That's a valid criticism. Mostly wanted to point your attention to the
project, because I think it'll be a big deal in the next year.

------
elmit
"Why I Went From Tractor To Dirigible (and not Balloon)"

------
SatyajitSarangi
The post seems a bit undercooked for my liking. Isn't there a library from
Guido called Tulip for doing Async tasks?

That said, reaching "true" concurrency in Python will always be impossible no
matter how you twist the language or monkey patch it. But one has to also
decide on the trade of. I've personally used Celery in almost all my tasks,
and even though it is bit over-loaded with features, you can always trim it
down to your use, and it works pretty damn smoothly. There is a talk by
Instagram developer Rick Branson regarding the usage of Celery in Instagram. I
would suggest people to check it out.

I'm also surprised that there wasn't a mention of Erlang, which is being
predominantly used by Facebook chat, and Haskel or Clojure, which would allow
us to achieve concurrent programming without breaking a sweat. Surely, one
doesn't have to be a grey beard wizard to learn any one of these three
languages?

Good luck to the him, though. Go seems like a very exciting language, whenever
I've used to it. Sometimes, it doesn't even seem like a new programming
language, just a weird concoction of Java, C++ and Python.

------
avz
I was expecting an article like this to showcase some real advantages of Go
over python, but the cornerstone of the argument is a reference to authority
and a claim that it is faster. This is very disappointing, especially given
the focus on concurrency and not performance.

The article never mentioned any of a number of interesting and relevant
concepts like channels, goroutines or CSP. The specific problem of doing small
amount of work in the background is easily solved using goroutines, but this
isn't even mentioned and the Go code sample at the end is barely relevant to
the rest of the discussion.

Also, I find the derision of Erlang to be out of place in an article on Go and
concurrency since both Go and Erlang base their concurrency model on CSP
(albeit with significant differences in interpretation).

------
gnur
I think that for concurrent programs, there aren't a lot of languages
currently out there that can match Go. I quite like go, but for some things I
really prefer a dynamic language.

The flexibility of Django's object abstraction would be a lot harder to create
with Go. If I don't need to use a database I use Go, but if I do; python is my
language of choice.

~~~
twic
What do you mean by "match"? There are a number of languages whose concurrency
capabilities are a superset of Go's.

------
coldtea
> _Something in my gut said that using a plain-old, library-level function to
> spawn a new background process was unnatural._

Nothing unnatural about it. Besides, that's how Rust and Clojure also do it,
iirc.

Oh, and in this case, it doesn't even spawn a "new background process".

------
avaku
Didn't see any problem with gevent example... Looks like the standard parallel
code.

~~~
arethuza
I've never looked at code using gevent before and that sample looks very clear
and easy to understand - no idea why the author would think it is
"cumbersome".

------
hitchhiker999
'hacker school' \- I'm probably too old, this sounds so entirely lame.

------
funvit
Sounds lame. Background email sending? No problem. Just write management
command and call it from cron...

~~~
Grue3
No, do it with Celery! It does everything cron can, but better.

------
ttty
Did you try to put "line-height: 1.5em;"? is a lot more readable (:

------
bluepill
so fucking full of himself

