Why I Went From Python To Go (and not Node.js) (2012)
jordanorelli.com
jordanorelli.com
"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".
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.
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.
Sure you can learn more than one. But you can only really learn a few, and you only fully master (at the "concert pianist" level) one -- except if you're some crazy outlier.
Same for languages. And I'm including the library and framework ecosystem, language tooling and culture here too.
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.
The customers dictate the technology stack and we are expect to be able to dive in, learn what is missing from our side and start developing.
You just need a mix of real experts, the ones dealing directly with the customer on site, with a blend of not so experts hacking along a few lines behind in the battlefield.
When one those "not so well experts" gets the next gig, they are themselves experts in the said technology. :)
Dynamic languages like python or ruby have very malleable definitions of what a class is, and a lot of static verification you can be used to in C# or Java isn't there anymore.
Pattern-matching heavy languages like ML have much simpler object heirarchies than what you might find in OO languages, and have different design patterns to compensate.
Purely functional languages like Haskell require a completely different way of thinking about state (seeing how there is none on a purely language-semantic level).
There are many languages worth looking at that are not OO, and the lessons learned from really trying to learn them and their design patterns can make your code better in your "native" tongue.
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".
Both sides of the table should embrace programming language agnosticism. I've spent most of my career doing PHP and later Node.js, but I'd be happy to take a job working on a product written in Python or Ruby if such an opportunity arose.
I've happily identified as a "Python programmer" while it was the main language I was using, and now more or less call myself a "Go programmer" after a similar switch. In less code-centric teams it's a handy way to identify where you are coming from.
Another reply here noted the time investment can lead to attachment, I find this true as well. When I decided to switch to Go for my next project, the only way to learn it was to put in some serious hours on the weekend and late into the evenings. You can't help but identify with something when you make that kind of effort towards it. All of the little cognitive biases and tricks with ego keep you invested enough to keep learning.
The Well World series would probably qualify as an example of the latter.
1. Learning a new programming language or a framework requires a significant effort for someone to use it comfortably. No matter how smart you are, there's the inevitable "grind" you have to go through to achieve the level of familiarity with a new language. It's only natural that people gravitate towards what they are familiar with and grow attached to what they know more.
2. Identifying oneself with some programming language is completely fine. Would you have any problem if Dennis Ritchie identified himself as a C programmer or Matz as a Ruby programmer?
You're being unnecessarily harsh, this type of comment might have educational value for newer developers. The fact that a programming language is a tool is not understood by all of us, and I personally admit that a very similar message I read on IRC opened my eyes when I was younger.
> Would you have any problem if Dennis Ritchie identified himself as a C programmer or Matz as a Ruby programmer?
Your own example ruins your whole argument. Matz is a programmer, he invented Ruby and wrote its interpreter in C. Calling him a C programmer or a Ruby programmer makes therefore very little sense. Same goes for Dennis Ritchie and the assembly he used to create C.
Your point still stands though: you need to be fairly competent at assembly language to write a compiler that emits machine code.
>"The origin of C is closely tied to the development of the Unix operating system, originally implemented in assembly language on a PDP-7 by Ritchie and Thompson, incorporating several ideas from colleagues."
It's also written that the B rewrite only came later.
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..."
I thought Hacker School banned "feigned surprise" - (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.
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
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.
Search for pep 325 in pep 333
Would it be worth investigating building it in Go rather than node?
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.
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.
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.
I don't really know what you mean by "big industry". Canonical's Juju is written in Go. Docker is written in Go. Iron.io is written in Go. Cloudflare and Youtube use Go.
Lots of companies use Go.
CodeIgniter and Laravel are web frameworks (which happen to be written in PHP). That's not even a valid comparison to Go, which is a programming language.
I think you should definitely ask about Go, but given that you're new, unless you're going into a technical lead position, be aware that they may have already made up their minds, and might not be open to different ideas. People tend to get stuck on a single idea once it gets into their heads.
That, and they are not anathema to Go. The Go devs want to implement generics, they just have more important things to do right this second.
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.
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).
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.
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".