6 ms·
Why I Went From Python To Go (and not Node.js) (2012)
- gnur 13y agoI 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 13y agoWhat do you mean by "match"? There are a number of languages whose concurrency capabilities are a superset of Go's.
- adamors 13y ago>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.
- franze 13y agosaid 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.
- jacquesm 13y agoI 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. http://en.wikipedia.org/wiki/Well_World_series http://en.wikipedia.org/wiki/Well_World_series
- twic 13y agoA 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.
- andybak 13y agoLearning 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 13y agoThis 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.
- rtpg 13y agoThis only covers a small subset of languages. 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.
- _random_ 13y agoC# supports dynamic typing BTW: http://msdn.microsoft.com/en-us/library/dd264736.aspx http://msdn.microsoft.com/en-us/library/dd264736.aspx
- chrisdew 13y agoTry some non-oop languages (e.g. Haskell, Clojure, Prolog, etc.) They're not so easy to switch between.
- 13y ago
- jsnk 13y agoYes, 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?
- uniclaude 13y ago> 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.
- bryanlarsen 13y agoTo 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.
- uniclaude 13y agoEither you or the wikipedia article is wrong. >"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.
- zgoat 13y agoThis 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.
- myth_drannon 13y agoTell 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
- kethinov 13y agoWhich they shouldn't do. 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.
- joebo 13y agoIs it different than calling oneself a country singer, western author or violin player? All are useful descriptions in context and not necessarily identities
- levosmetalo 13y agoI 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.
- coldtea 13y agoA 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.
- elmit 13y ago"Why I Went From Tractor To Dirigible (and not Balloon)"
- est 13y agoOP 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 13y agoDjango 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 13y agoCelery 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 13y agothough 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.
- est 13y agoIt's pretty simple and works just like fastcgi_finish_request() in PHP Search for pep 325 in pep 333
- hitchhiker999 13y ago'hacker school' - I'm probably too old, this sounds so entirely lame.
- bleebloob 13y agosays a poster on 'hacker news'
- Artemis2 13y agoGo 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 13y agoIMHO 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.
- Osiris 13y agoI 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 13y agoWhy 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 13y agoGo 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 13y agoI 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.
- CmonDev 13y agoSo 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..."
- davidw 13y agoIt'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".
- kibibu 13y agoMakes you wonder what he thinks of APL
- mseri 13y agoAnd even if one doesn't like what Erlang looks like, there is Elixir that has an awesome syntax (IMHO of course).
- Aardshaark 13y agoHe's making fun of himself as an 'enlightened Python programmer'. It's not his honest opinion of the language.
- drawkbox 13y agoThe 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 13y agoI 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.
- avaku 13y agoDidn't see any problem with gevent example... Looks like the standard parallel code.
- arethuza 13y agoI'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".
- ttty 13y agoDid you try to put "line-height: 1.5em;"? is a lot more readable (:
- sbecker 13y agoI 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 13y agoFeigned 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 13y agoHey 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.
- funvit 13y agoSounds lame. Background email sending? No problem. Just write management command and call it from cron...
- Grue3 13y agoNo, do it with Celery! It does everything cron can, but better.
- bluepill 13y agoso fucking full of himself
- coldtea 13y ago>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".
- SatyajitSarangi 13y agoThe 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 13y agoI 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).