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.
said that, i find it kinda cool that reality trumps fiction: no SF author (really no one) predicted that we will build tribes around the languages we use to speak to machines.
I think you're wrong about that. There were some stories in the 70's about that theme, specifically the parallels between 'magic' in one branch of fiction and programming a computer by interacting with them in some arcane language casting spells in another.
The Well World series would probably qualify as an example of the latter.
A 1977 collection called "Tales From The Computer Room" contains a Bradbury pastiche called "On Mars, Sloppy COBOL is Sudden Death" (or something like that - that's from memory), in which the Martians end up murdering a Terran astronaut because he uses a GOTO.
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.
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.
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.
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".
Between, say, Python and Haskell is a pretty solid difference. If you spread out your known languages well enough, however, most languages become very close.
Well in other consulting worlds, and lucrative ones at that, they specifically ask for people like C++ experts, Java experts, Fortran and Cobol experts etc. Heck, I've seen people specialized in some specific vendor toolset get top dollar from consulting.
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. :)
Yes, we get it, but repeatedly stating "A language is a tool, not an identity." every thread about X programming language adds nothing to the conversation.
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?
> repeatedly stating "A language is a tool, not an identity." every thread about X programming language adds nothing to the conversation.
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.
To be pedantic: Ritchie did not write C in Assembly, he wrote it in C. Or more accurately, version N of C was written in version N-1 of C. Version 0 of C could be compiled by the B compiler.
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.
This can be dictated by circumstances though, I work in a situation where programming isn't the main value add of the work (but is necessary anyhow), so people tend to identify with their language and formally "switch" because there isn't time to work with / learn more than one or two languages max.
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.
Tell that to the interviewer who needs you to dive into the project right away and he can't wait couple of weeks until you brush up your rusty X language that you used 4-5 years ago or even worse learned on your own time.
It's not we that call us it's the other side of table that feels compelled to compartmentalize us
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.
Is it different than calling oneself a country singer, western author or violin player? All are useful descriptions in context and not necessarily identities
I don't know much about the difference between country and western, but would that mean that someone that sings western professionally won't be able to sing some country song the same day he haer it? Sorry, but if he can't do it, he's not a singer at all, neither country nor western.
A language is like a musical instrument. People say "I'm a pianist", or "I'm a guitarist" all the time.
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.
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
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.)
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.
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.
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).
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?
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.
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 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.
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.
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.
Go is still a very young language and will probably subject to a lot of changes, especially for optimization. No big industry builds apps using Go, in the same way that no big industry build app using Laravel. They prefer for instance CodeIgniter, which has been combat-tested and is more mature.
Go has been very stable for quite some time now. There is a backwards compatibility guarantee while it stays in 1.x. Your old code will still build with new versions of Go. As for optimization, yes, it will get faster and better... I don't see why that's a drawback?
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.
And if Java isn't trendy^W exciting enough for you, Scala offers many of the same benefits, in particular the use of the JVM and access to the Java ecosystem, but with many more options for functional programming, "expressive" constructs like DSLs, actor-based architecture, etc.
Go is the future of server side programming. I don't consider that to be an exaggeration. Node is not the future. Node is an interesting technical achievement, but programming in javascript on the server is not going to create the most robust environment.
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.
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..."
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.
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.
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.
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".
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) - 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.
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.
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.
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.
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).
72 comments
[ 3.1 ms ] story [ 80.7 ms ] threadThe 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.
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.
The Well World series would probably qualify as an example of the latter.
http://en.wikipedia.org/wiki/Well_World_series
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.
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".
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. :)
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'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.
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.
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.
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.
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..."
"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 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.
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".
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).