8 ms·

The March Towards Go

185 points by zef_hemel 12y ago

nemasu 12y ago
When node first appeared, the thought of server side JS gave me shivers, maybe I should trust my instincts more often.
- CmonDev 12y ago
  It's good when you are writing it but someone else will be maintaining it :).
jbb555 12y ago
I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though
- ovi256 12y ago
  Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building concurrent programs and distributed systems. These are language features such as go-routines and channels and standard library includes for networking and RPC. These are so great at what they do that they make programmers like me, who like Go, overlook the suck that comes from the existing typing system. My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.
  - davidw 12y ago
    > My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible. Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, and another step up from Go in terms of all the facilities for fault tolerant and distributed programming.
    - Xixi 12y ago
      I second this recommendation: I've started a project with Elixir two weeks ago, and so far I really love it. As far as syntax goes nothing beats the elegance of Python, but in terms of overall application architecture OTP [1] is just miles ahead. That said I can definitely imagine picking up Elixir for a purely imperative/OOP programmer being quite an undertaking. But definitely worth it. [1] http://www.erlang.org/doc/design_principles/users_guide.html http://www.erlang.org/doc/design_principles/users_guide.html
    - pyotrgalois 12y ago
      I would like to mention LFE. Lisp Flavored Erlang (http://lfe.io/ http://lfe.io/) is a great addition to the Erlang/Elixir world/ecosystem. Go on, test it out! I work as an Erlang dev. It is really awesome. It has a simple and consistent syntax (even if don't like the comma, semicolon and period terminators), the most powerful native concurrency semantics I know, the best error detection and handling semantics, pattern matching (you make the compiler work for you), an awesome virtual machine that took correct design choices (gc per process, iolists for concatenating strings), incredible tracing support, good support for connecting with other programming languages, a good optional type system (Dialyzer, http://learnyousomeerlang.com/dialyzer http://learnyousomeerlang.com/dialyzer) for detecting type errors and good patterns as supervisor, gen_server and gen_event . It also has a vibrant community that has created good libraries like Proper (QuickCheck-inspired property-based testing tool for Erlang) and Cowboy (simple http server). I have worked with C, C++, Java, Ruby, Python and Javascript/NodeJs. I really like Python and Ruby as general programming language and for creating prototypes, but I would definitely use Erlang for any real backend project.
  - bcarrell 12y ago
    > My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. Clojure is dynamic and has goroutine and channel constructs through core.async.
  - andor 12y ago
    My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels Erlang is dynamic and has all those features :-) It's true that the GIL in Python prevents interpreter threads to run simultaneously. But for many use cases it's OK to use gevent or multiprocessing (which share the same interface!). Channels are there in the form of queues, but there's no built-in support for selecting from multiple queues. To emulate that, you need an extra greenlet for each queue.
  - rakoo 12y ago
    > The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. I see this repeated again and again. It's wrong. The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type. People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.
    - ovi256 12y ago
      I knew about this solution. It's just that my inner Ruby dev screams "DRY!". Obviously it's so repetitive that it would be a bad sign in other languages. I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines. More here: https://code.google.com/p/go-wiki/wiki/GoVsGenerics https://code.google.com/p/go-wiki/wiki/GoVsGenerics
    - deleted 12y ago
      [deleted]
- otikik 12y ago
  > missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript". It is as expressive as ruby or python, with as much type safety as possible without giving up clarity or speed. And its type system doesn't require weeks to wrap your head around it.
  - bsdetector 12y ago
    > has things others languages don't - fast compilation Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations. Is this supposed to convince C/C++ programmers? Like "sure your program will run 50% slower and have garbage collection pauses, but it compiles faster!". This just boggles my mind.
    - Keats 12y ago
      Scala is pretty slow
      - TheDom 12y ago
        You could call the compiler slow, but at runtime it's comparable to Java (= fast!).
        dlisboa 12y ago
        Compilation time is the only thing in discussion in this thread.
    - randallsquared 12y ago
      I think this depends strongly on your development style. If you come from the world of scripting languages, a common style is "write between one and twenty lines of code; run tests; edit three lines; run tests...", where "run tests" might literally be that, or might just be running the code to sanity check that things are not too broken. In this style, even a twenty second delay would become very painful. I think people who learned on C, C++ or Java tend to write much larger pieces of code in between run attempts, simply because it takes (or took) a while to check your work, instead of being effectively instantaneous. I know at a previous position where I did some Java development, the "tomcat stop; ant remove; ant clean; ant install; tomcat start... okay, NOW you can test" was quite difficult to develop against iteratively, sometimes being measured in minutes instead of seconds.
- lazyjones 12y ago
  > I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. In other words, you have been reading about it, but never tried to learn it. Go is incredibly easy to learn and prevents bugs and cruft as much as possible, makes writing documentation and testing painless and has good performance and concurrency support. It also has a friendly, practically-minded community.
  - Argorak 12y ago
    Or: It doesn't fit the parents taste.
- candl 12y ago
  I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming. To me Go feels like a reincarnation of Fortran 77 with all the restrictions it imposes. There are some good and cool things about Go, no doubt about it but it many places it's just too cumbersome which is unforgivable in this day and age.
  - avz 12y ago
    I'd argue placing error handling in a spotlight is a feature, not a bug. Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.
    - Touche 12y ago
      You can ignore errors in Go.
    - bluecalm 12y ago
      Similarly I would argue that lack of many OOP constructs is a feature as you can't over complicate stuff with class hierarchy and what not. As to unused variables being compile error I guess it's good for big project but it would drive me crazy if GCC throws that in C code instead of a warning for my home projects as there is often a lot of tweaking and being forced to remove the imports between quick test runs would be very time-consuming.
  - rdtsc 12y ago
    Have you looked or tried Erlang? I like its error handling the best (isolate the fault). At least it handled and manages issues with large concurrent backends well.
- chx 12y ago
  Strict typing after JS is like a breath of fresh air. Multiple returns are helpful. Parallelism is real, first class, brilliant. The whole thing is intuitive. Most importantly: at every interesting design decision it's easy to pinpoint which language they got burned by the opposite. It's written by truly experienced people standing on very practical grounds.
- avz 12y ago
  People like Go because of all the things Go does well. Here is a few examples: * benefits of static typing at low cost to the programmer thanks to type inference and duck-typing, * intuitive and easy-to-use concurrency model based on channels and go routines, * functions as first-class objects, * very good performance, * clean, concise and simple syntax, * novel, low-overhead approach to build configuration based on the convention-over-configuration principle (your import statements express all there is to know about how to build your software), * garbage collector. I'm sure I forgot more.
  - Sammi 12y ago
    It basically takes all of the best parts from C++, Java, and Python, and fixes their bad parts. This has proved to be exactly what back-end and distributed systems developers have been screaming for.
lmm 12y ago
Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...
- est 12y ago
  Go has a larger and more active eco-system for today's world.
  - sergiosgc 12y ago
    Larger than...? It's comparable to Node's, certainly smaller than JS in general, much smaller than either python's or C++'s.
- _yosefk 12y ago
  Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves and their users: "Getenv returns the empty string and continues. Then Go somehow manages to parse the empty string as an empty JSON list and still continues. Then it tries to interpret the first of the user arguments to the program as the path of the program to run and execs that instead! Utter failure." I happened to write about it just before Go came out here: http://yosefk.com/blog/what-makes-cover-up-preferable-to-error-handling.html http://yosefk.com/blog/what-makes-cover-up-preferable-to-err... It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage (as in JS's "undefined" string produced from undefined values and propagated, or Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it predates Lisp's exception handling features whereas AREF was added later and indeed complains loudly, etc.
  - 12y ago
Shish2k 12y ago
> Statically linked binaries make for easy deployment They certainly do, but have we solved the problem of statically linked bugs yet? What happens when the next heartbleed happens?
- pgeorgi 12y ago
  How many people updated their libssl packages without restarting the server processes, thinking they're safe when they really aren't? With a bug in such a central place you'll have to touch everything - could as well rebuild everything, when your processes are prepared for it.
  - deleted 12y ago
    [deleted]
- otikik 12y ago
  I suppose you rebuild and redeploy everything.
- sagichmal 12y ago
  Redeploying your entire infrastructure should take on the order of minutes.
peterhunt 12y ago
I want Go but with a really strong static type system. What do I use? Haskell's Hackage seems to be full of broken packages. OCaml seems to be stuck in 1999. F#/Mono is pretty great, but tough to find quality libraries that work with the tools I use (postgres etc) Anything I'm missing?
- deleted 12y ago
  [deleted]
- DCKing 12y ago
  Scala? Strong static types, lots of quality libraries both for Scala and 'inherited' from Java. Fits well among the languages you already mention.
  - peterhunt 12y ago
    Nice. I've heard some complaints about compile times -- are they founded?
    - mhax 12y ago
      Yep. Compile times are comparatively long - the larger the project, the more this is an issue. For me it's not a deal breaker.
    - DCKing 12y ago
      There's a difference between "the language has long compile times" and the implied "you spend a lot of time waiting during development". It is true that Scala's compile times are long, but the tooling provides ways so that you don't have to wait so much during development.
    - th0br0 12y ago
      Scala 2.12 will have a new compiler backend which should speed things up considerably. [1] Other than that, as an avid Scala fan, I've been long wondering why people favour Go so much. Arguably, if you've started out with RoR, then Node.js was a great improvement (dynamic typing with awesome speed). Then came Go, which solves many of the issues you tend to encounter with Node.js. So now, after it has reasonably matured, many people are pivoting to it. Scala, while having a rather "bloated" core library (i.e. quite exhaustive), already does most that Go does (i.e. an Actor is reasonably close to a goroutine etc.) and has an awesome type system. But then, I'm biased and YMMV ;) [1] https://magarciaepfl.github.io/scala/ https://magarciaepfl.github.io/scala/
beck5 12y ago
There are a couple of things which have stopped me getting into go which I am ignorant about. - Lack of decent IDE with intellisense/good refactoring support. - Libraries seem to be globally shared between projects like rvm rather than in the project like nvm. Am I wrong, misguided or out of date on these things?
- sagichmal 12y ago
  > Lack of decent IDE with intellisense/good refactoring > support. Sublime Text + GoSublime; vim + go-vim. > Libraries seem to be globally shared between projects > like rvm rather than in the project like nvm. There's no fixed rule. If you need dependable reproducible builds, current best-practice is to vendor your libraries in your repo.
  - beck5 12y ago
    Thanks, sublime tex and vim with plugins are still a long way off what you get from a good ide. Just glancing there is no real refactoring support, its more around auto complete.
    - sagichmal 12y ago
      Refactoring in Go is accomplished with `go fix`.
  - collyw 12y ago
    Is VIM considered an IDE? I am aware it is powerful and has as many features as an IDE but seems like it will take a fair bit of time to learn (on top of learning a new language). Eclipse is fairly intuitive by comparison.
- Rapzid 12y ago
  I use LiteIDE to good effect. It has a few kinks to work out but is generally everything I need. The Go intellij plugin is supposed to be good too from what I hear. Packages are shared across projects in the same gopath, you could run separate gopaths for isolation.
bsaul 12y ago
I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go. I'd be curious to know how many start ups prototype their first software version with Go. Note : as a coder that writes a lot of python, seing dropbox switch to Go in parallel to python so often having toxic discussions about python 3 vs 2 is really painful.
- jgrahamc 12y ago
  We, CloudFlare, write a lot of new stuff in Go. It works well for our use model: highly-concurrent networked stuff. I've just been rewriting a thing that was in a monstruous mixture of PHP/Python into a single Go program.
  - aikah 12y ago
    Is your front-end/admin panel/... written in Go too? Because when noobs hear "We use Go",they'll think you're using that to generate webpages,CRUD apps,or write CMSes.
- Vieira 12y ago
  Dropbox switch to Go? Where did you read that? If anything they seem to be "investing" in the Python ecosystem[1]. [1] https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/ https://tech.dropbox.com/2014/04/introducing-pyston-an-upcom...
  - xwintermutex 12y ago
    The original article states: "One of Python’s most visible users, Dropbox — who also employs Python’s creator Guido van Rossum — recently announced it has migrated major parts of its back-end infrastructure from Python to Go" and refers to [1]. [1]: https://tech.dropbox.com/2014/07/open-sourcing-our-go-libraries/ https://tech.dropbox.com/2014/07/open-sourcing-our-go-librar...
deleted 12y ago
[deleted]
skrebbel 12y ago
Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code with the browser, but it's a bitch to use. We knew that when we signed up. Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew that when we signed up. It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node. I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.
- facepalm 12y ago
  There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.
  - aidos 12y ago
    As already stated, it depends on what you're doing. I have to calculate lots of numerical things, javascript isn't brilliant for that at all (I'm not against js, I was an early advocate and have used it for years). Python doesn't have real lambda, who cares? That may or may not matter to you, it mostly doesn't matter for me, most of the time. You've directly commented on a post about how understanding the context in which you use your tools is the crucial factor by totally ignoring the point.
  - adamors 12y ago
    If you normally only do a couple lines of jQuery per day then I agree that you don't encounter the warts very often. If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.
lsiebert 12y ago
So I understand there isn't a go package manager like pip/npm/cpan. Is that correct?
- dz0ny 12y ago
  go get behaves in some ways as package manager (installs packages), it's up to the developer how it will vendor them or lock versions.
- percept 12y ago
  See the "Managing Dependencies" section, and comments: https://www.digitalocean.com/company/blog/get-your-development-team-started-with-go/#managing-dependencies https://www.digitalocean.com/company/blog/get-your-developme... Also: http://peter.bourgon.org/go-in-production/#dependency-management http://peter.bourgon.org/go-in-production/#dependency-manage... More discussion: https://news.ycombinator.com/item?id=7971354 https://news.ycombinator.com/item?id=7971354
rcarmo 12y ago
I was kind of expecting this. Although I like Go (and prefer it to NodeJS), I hope forthcoming feedback on TJ's "life choices" does not degrade into a "Let's move from Node to Go" echo chamber. More importantly, I hope the Node community's self-centred "holier than thou" doesn't bleed over, given that Go has (at least so far) kept a fairly high standard of discourse. That said, I, for one, welcome more contributors to the Go ecosystem. It is a good systems programming language, but it needs a few more "horizontal" libraries to make humdrum tasks (like parsing, accessing databases, etc.) more palatable. (edit: removed incorrect double negative)
sz4kerto 12y ago
"In the past week I’ve rewritten a relatively large distributed system in Go" Maybe I don't have any programming talent at all, but I cannot even imagine to rewrite a 'large distributed system' in a week. The not-too-large distributed systems I worked with had years of thinking behind them, I could not even type in the characters of the code in a week.
- jamescun 12y ago
  It is a rather vauge statement and could have used some clarification; however Go does make writing network protocols very simple, and building something like a gossip protocol based system with a leader election system is doable in a week. Even quicker if you use some of the existing distributed systems libraries for Go.
  - cgag 12y ago
    What does Go do that makes writing network protocols simple?
    - skj 12y ago
      Go makes it straightforward to have one program efficiently communicating with many different servers and clients. It does this by having all network IO be event-based in such a way that it's effectively tied directly into the scheduler, and then communicating between the different goroutines managing all these connections is very easy.
    - micro_cam 12y ago
      All of the HTTP, socket, encryption, compression etc libraries have a really clean, consistent design based around stackable reader and writer interfaces. This makes it really easy to combine things, swap out transport layers etc. Go routines and channels are also nice for handling concurrent requests though I find myself using mutexes more than channels for finer grained control.
- thomseddon 12y ago
  You obviously don't know TJ... https://github.com/visionmedia https://github.com/visionmedia http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
jaxytee 12y ago
TL;DR It is very likely that TJH is a hive mind. FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive?share=1 http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...
- abritishguy 12y ago
  Lol, he works at segment.io and he is very much one person.
  - jaxytee 12y ago
    Have you met him?
Udo 12y ago
This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example). Likewise, people will now order their projects in Go whether it makes sense given the requirements or not. 20 years of Go experience will be needed on CVs. And when Go inevitably fails at certain things, "everybody" will move to the next thing - probably Rust, thereby completing the migration away from dynamic scripting. This is not reasonable, is it?
- adamors 12y ago
  > "this is the thing to use now and if you don't you're dead meat". And not just because you'd be unfashionable, but because a lot of crucial libraries in these ecosystems will loose maintainers. The Node guy said the other day that (out of his hundreds of libraries) "Koa is the one project I’ll continue to maintain". If I had any of his packages in production I would be terrified. The fact that he (and other "Node guys") are driving the hype train to Go tells me that I should stay as far from it as possible.
  - Udo 12y ago
    True, I think you're expected to follow the cool people to wherever they go next ;) Maybe some ecosystems are much more about the people leading them than they are about the technology behind them. And while this is not something I'd be interested in as a developer, I understand how there could be huge benefits in that kind of lifestyle. I imagine that's a very supportive, creative, and active community to be in. Looking at some (mis-)uses of Node, maybe that's been the rationale behind some of these frameworks all along. And indeed the first image on the page is of a marching band...
- binocarlos 12y ago
  It's like everyone looking at everyone else's fashion sense and then quickly getting down the shops to buy up the same sort of stuff. I suppose it depends on what you are trying to do - if it is looking good to those with fashion sense - better get down them shops. If it's to like, actually build stuff - the feeling of being uncool because of what language you use is a massive distraction to ignore. I've been learning Go because its a great language for concurrent server systems (and better than node in some areas). That I feel slightly cooler because of that choice feels a bit like having the right daps (sneakers) at school.
ricardobeat 12y ago
> Text processing increased 64 percent just by moving from Node to Go. And rewriting everything from scratch, plus it's a given that node isn't the best tool for data processing..
angularly 12y ago
I wonder why they didn't choose Go in the first place. Both languages were introduced in 2009, I remember evaluating both, and choosing Go because it was clearly superiour when the goal was serverside, speed, stability, maintenance and simplicity.
dccoolgai 12y ago
So what comes after Go? I only ask because I figure if I start learning that now, by the time they switch again I will have a fair chance of being competent at it by then...
- marcosdumay 12y ago
  I'm taking the oposite route. Once all those people live Go for something else, I'll evaluate it and see if it's any good.
eliben 12y ago
It's not surprising that the same crowd that started switching to Node.js en masse a couple of years ago is redoing it for Go :)
rufugee 12y ago
It's a shame that the debugging story in Go is still "use GDB". It's really lacking good visual debugger support afaik.
p0nce 12y ago
> Not looking at Go yet? It may be a good time to do so now — everybody else is. I'll be gladly left behind.
deleted 12y ago
[deleted]
tete 12y ago
I agree. JavaScript is weird. I think ECMAScript will make a lot things better, but it will still be a couple of months and it still won't fix it all - still a huge step of making it a really usable language for many things. Node.js is becoming mature, less trendy. I really find it weird how people compare it age wise with Go. JavaScript is way old than Go or other languages. V8 is also older than Node of course. ECMAScript didn't have breaking changes in a really long time. There are many, many implementations. SpiderMonkey has been used on the server side for over a decade now. Go looks great. There are some rough edges though and whether really good solutions will build up for these things is a really interesting thing to look at. It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of them fixing problems in amazing ways. I love how great concepts, like node.js streams and pipes are copied to Go and Rust in ways that match their styles, not just blindly. All these things even influence languages like Java and C++. Who would have known only a couple of years ago that things would emerge in such ways and that it needs some projects with the idea of yet another programming language. What is even more interesting is that a lot of concepts actually stem from Perl... well, not necessarily the language itself, but libraries, modules or Perl6, which arguably was/is a really ambitious research project. It's a bit how many concepts took ages to be ported from Plan 9 to other operating systems. Anyway. It is great to see how people nowadays look at other projects and don't judge by first impression anymore. At least it seems like it. Node.js looked extremely awful to me in the beginning and turned out to actually not be (despite its shortcomings and JavaScript, which also turned out to be nicer). On the other hand projects, like Meteor that looked at least okay in the beginning turned out to be way more awful than they looked when I first heard that they don't even support proper REST. I know, my opinion on this might not be really popular, but it's amazing to see how so many new concepts emerge, even when they seem crazy, sometimes turn out to be crazy, sometimes turn out to be amazing. It's hard to know where we will stand in a couple of years. However, I don't think only one of Rust, Go or Node.js will make the race and I think none of them will look like they do today in one or two years, especially when it comes to their ecosystems. Just because all of them are too young to be judged upon and all of them are changing too rapidly (or new standards are upcoming, as with ECMAScript), so that nobody really has or can develop a deep understanding of the language/framework yet, not even its developers. What I really hope though is that there will soon be more big projects than just Docker and a bigger ecosystem.

185 points by zef_hemel 12y ago

nemasu 12y ago

When node first appeared, the thought of server side JS gave me shivers, maybe I should trust my instincts more often.

CmonDev 12y ago
It's good when you are writing it but someone else will be maintaining it :).

jbb555 12y ago

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

ovi256 12y ago
Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building concurrent programs and distributed systems. These are language features such as go-routines and channels and standard library includes for networking and RPC. These are so great at what they do that they make programmers like me, who like Go, overlook the suck that comes from the existing typing system. My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible.
- davidw 12y ago
  > My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. AFAIK, the existing GIL in the reference Python and Ruby interpreters makes adding true goroutines impossible. Have you had a look at Erlang and Elixir? The former is not as dynamic as Ruby (not much is), but it's a nice environment, and another step up from Go in terms of all the facilities for fault tolerant and distributed programming.
  - Xixi 12y ago
    I second this recommendation: I've started a project with Elixir two weeks ago, and so far I really love it. As far as syntax goes nothing beats the elegance of Python, but in terms of overall application architecture OTP [1] is just miles ahead. That said I can definitely imagine picking up Elixir for a purely imperative/OOP programmer being quite an undertaking. But definitely worth it. [1] http://www.erlang.org/doc/design_principles/users_guide.html http://www.erlang.org/doc/design_principles/users_guide.html
  - pyotrgalois 12y ago
    I would like to mention LFE. Lisp Flavored Erlang (http://lfe.io/ http://lfe.io/) is a great addition to the Erlang/Elixir world/ecosystem. Go on, test it out! I work as an Erlang dev. It is really awesome. It has a simple and consistent syntax (even if don't like the comma, semicolon and period terminators), the most powerful native concurrency semantics I know, the best error detection and handling semantics, pattern matching (you make the compiler work for you), an awesome virtual machine that took correct design choices (gc per process, iolists for concatenating strings), incredible tracing support, good support for connecting with other programming languages, a good optional type system (Dialyzer, http://learnyousomeerlang.com/dialyzer http://learnyousomeerlang.com/dialyzer) for detecting type errors and good patterns as supervisor, gen_server and gen_event . It also has a vibrant community that has created good libraries like Proper (QuickCheck-inspired property-based testing tool for Erlang) and Cowboy (simple http server). I have worked with C, C++, Java, Ruby, Python and Javascript/NodeJs. I really like Python and Ruby as general programming language and for creating prototypes, but I would definitely use Erlang for any real backend project.
- bcarrell 12y ago
  > My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels. Directly as language features. Clojure is dynamic and has goroutine and channel constructs through core.async.
- andor 12y ago
  My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels Erlang is dynamic and has all those features :-) It's true that the GIL in Python prevents interpreter threads to run simultaneously. But for many use cases it's OK to use gevent or multiprocessing (which share the same interface!). Channels are there in the form of queues, but there's no built-in support for selecting from multiple queues. To emulate that, you need an extra greenlet for each queue.
- rakoo 12y ago
  > The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. I see this repeated again and again. It's wrong. The "solution" to the generics problem is to not try to do anything that is generic, but do it specific: re-write that sort every time you need it for a new type. People who have some experience in Go seem to tell that when you go this path you actually realize that you won't write them hundreds of time as was feared; it's completely manageable. Plus, you have your "sort" re-implementation right next to the struct definition, so you know it is sortable.
  - ovi256 12y ago
    I knew about this solution. It's just that my inner Ruby dev screams "DRY!". Obviously it's so repetitive that it would be a bad sign in other languages. I like more the solution used by the sort package. You can write generic code that delegates specific type code to a few well-defined functions, like ones that sort.Interface defines. More here: https://code.google.com/p/go-wiki/wiki/GoVsGenerics https://code.google.com/p/go-wiki/wiki/GoVsGenerics
  - deleted 12y ago
    [deleted]
otikik 12y ago
> missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript". It is as expressive as ruby or python, with as much type safety as possible without giving up clarity or speed. And its type system doesn't require weeks to wrap your head around it.
- bsdetector 12y ago
  > has things others languages don't - fast compilation Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations. Is this supposed to convince C/C++ programmers? Like "sure your program will run 50% slower and have garbage collection pauses, but it compiles faster!". This just boggles my mind.
  - Keats 12y ago
    Scala is pretty slow
    - TheDom 12y ago
      You could call the compiler slow, but at runtime it's comparable to Java (= fast!).
      - dlisboa 12y ago
        Compilation time is the only thing in discussion in this thread.
  - randallsquared 12y ago
    I think this depends strongly on your development style. If you come from the world of scripting languages, a common style is "write between one and twenty lines of code; run tests; edit three lines; run tests...", where "run tests" might literally be that, or might just be running the code to sanity check that things are not too broken. In this style, even a twenty second delay would become very painful. I think people who learned on C, C++ or Java tend to write much larger pieces of code in between run attempts, simply because it takes (or took) a while to check your work, instead of being effectively instantaneous. I know at a previous position where I did some Java development, the "tomcat stop; ant remove; ant clean; ant install; tomcat start... okay, NOW you can test" was quite difficult to develop against iteratively, sometimes being measured in minutes instead of seconds.
lazyjones 12y ago
> I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. In other words, you have been reading about it, but never tried to learn it. Go is incredibly easy to learn and prevents bugs and cruft as much as possible, makes writing documentation and testing painless and has good performance and concurrency support. It also has a friendly, practically-minded community.
- Argorak 12y ago
  Or: It doesn't fit the parents taste.
candl 12y ago
I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming. To me Go feels like a reincarnation of Fortran 77 with all the restrictions it imposes. There are some good and cool things about Go, no doubt about it but it many places it's just too cumbersome which is unforgivable in this day and age.
- avz 12y ago
  I'd argue placing error handling in a spotlight is a feature, not a bug. Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.
  - Touche 12y ago
    You can ignore errors in Go.
  - bluecalm 12y ago
    Similarly I would argue that lack of many OOP constructs is a feature as you can't over complicate stuff with class hierarchy and what not. As to unused variables being compile error I guess it's good for big project but it would drive me crazy if GCC throws that in C code instead of a warning for my home projects as there is often a lot of tweaking and being forced to remove the imports between quick test runs would be very time-consuming.
- rdtsc 12y ago
  Have you looked or tried Erlang? I like its error handling the best (isolate the fault). At least it handled and manages issues with large concurrent backends well.
chx 12y ago
Strict typing after JS is like a breath of fresh air. Multiple returns are helpful. Parallelism is real, first class, brilliant. The whole thing is intuitive. Most importantly: at every interesting design decision it's easy to pinpoint which language they got burned by the opposite. It's written by truly experienced people standing on very practical grounds.
avz 12y ago
People like Go because of all the things Go does well. Here is a few examples: * benefits of static typing at low cost to the programmer thanks to type inference and duck-typing, * intuitive and easy-to-use concurrency model based on channels and go routines, * functions as first-class objects, * very good performance, * clean, concise and simple syntax, * novel, low-overhead approach to build configuration based on the convention-over-configuration principle (your import statements express all there is to know about how to build your software), * garbage collector. I'm sure I forgot more.
- Sammi 12y ago
  It basically takes all of the best parts from C++, Java, and Python, and fixes their bad parts. This has proved to be exactly what back-end and distributed systems developers have been screaming for.

lmm 12y ago

Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...

est 12y ago
Go has a larger and more active eco-system for today's world.
- sergiosgc 12y ago
  Larger than...? It's comparable to Node's, certainly smaller than JS in general, much smaller than either python's or C++'s.
_yosefk 12y ago
Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves and their users: "Getenv returns the empty string and continues. Then Go somehow manages to parse the empty string as an empty JSON list and still continues. Then it tries to interpret the first of the user arguments to the program as the path of the program to run and execs that instead! Utter failure." I happened to write about it just before Go came out here: http://yosefk.com/blog/what-makes-cover-up-preferable-to-error-handling.html http://yosefk.com/blog/what-makes-cover-up-preferable-to-err... It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage (as in JS's "undefined" string produced from undefined values and propagated, or Go's behavior above, etc.) For instance Lisp's NTH produces garbage and it predates Lisp's exception handling features whereas AREF was added later and indeed complains loudly, etc.
- 12y ago

Shish2k 12y ago

> Statically linked binaries make for easy deployment They certainly do, but have we solved the problem of statically linked bugs yet? What happens when the next heartbleed happens?

pgeorgi 12y ago
How many people updated their libssl packages without restarting the server processes, thinking they're safe when they really aren't? With a bug in such a central place you'll have to touch everything - could as well rebuild everything, when your processes are prepared for it.
- deleted 12y ago
  [deleted]
otikik 12y ago
I suppose you rebuild and redeploy everything.
sagichmal 12y ago
Redeploying your entire infrastructure should take on the order of minutes.

peterhunt 12y ago

I want Go but with a really strong static type system. What do I use? Haskell's Hackage seems to be full of broken packages. OCaml seems to be stuck in 1999. F#/Mono is pretty great, but tough to find quality libraries that work with the tools I use (postgres etc) Anything I'm missing?

deleted 12y ago
[deleted]
DCKing 12y ago
Scala? Strong static types, lots of quality libraries both for Scala and 'inherited' from Java. Fits well among the languages you already mention.
- peterhunt 12y ago
  Nice. I've heard some complaints about compile times -- are they founded?
  - mhax 12y ago
    Yep. Compile times are comparatively long - the larger the project, the more this is an issue. For me it's not a deal breaker.
  - DCKing 12y ago
    There's a difference between "the language has long compile times" and the implied "you spend a lot of time waiting during development". It is true that Scala's compile times are long, but the tooling provides ways so that you don't have to wait so much during development.
  - th0br0 12y ago
    Scala 2.12 will have a new compiler backend which should speed things up considerably. [1] Other than that, as an avid Scala fan, I've been long wondering why people favour Go so much. Arguably, if you've started out with RoR, then Node.js was a great improvement (dynamic typing with awesome speed). Then came Go, which solves many of the issues you tend to encounter with Node.js. So now, after it has reasonably matured, many people are pivoting to it. Scala, while having a rather "bloated" core library (i.e. quite exhaustive), already does most that Go does (i.e. an Actor is reasonably close to a goroutine etc.) and has an awesome type system. But then, I'm biased and YMMV ;) [1] https://magarciaepfl.github.io/scala/ https://magarciaepfl.github.io/scala/

beck5 12y ago

There are a couple of things which have stopped me getting into go which I am ignorant about. - Lack of decent IDE with intellisense/good refactoring support. - Libraries seem to be globally shared between projects like rvm rather than in the project like nvm. Am I wrong, misguided or out of date on these things?

sagichmal 12y ago
> Lack of decent IDE with intellisense/good refactoring > support. Sublime Text + GoSublime; vim + go-vim. > Libraries seem to be globally shared between projects > like rvm rather than in the project like nvm. There's no fixed rule. If you need dependable reproducible builds, current best-practice is to vendor your libraries in your repo.
- beck5 12y ago
  Thanks, sublime tex and vim with plugins are still a long way off what you get from a good ide. Just glancing there is no real refactoring support, its more around auto complete.
  - sagichmal 12y ago
    Refactoring in Go is accomplished with `go fix`.
- collyw 12y ago
  Is VIM considered an IDE? I am aware it is powerful and has as many features as an IDE but seems like it will take a fair bit of time to learn (on top of learning a new language). Eclipse is fairly intuitive by comparison.
Rapzid 12y ago
I use LiteIDE to good effect. It has a few kinks to work out but is generally everything I need. The Go intellij plugin is supposed to be good too from what I hear. Packages are shared across projects in the same gopath, you could run separate gopaths for isolation.

bsaul 12y ago

I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go. I'd be curious to know how many start ups prototype their first software version with Go. Note : as a coder that writes a lot of python, seing dropbox switch to Go in parallel to python so often having toxic discussions about python 3 vs 2 is really painful.

jgrahamc 12y ago
We, CloudFlare, write a lot of new stuff in Go. It works well for our use model: highly-concurrent networked stuff. I've just been rewriting a thing that was in a monstruous mixture of PHP/Python into a single Go program.
- aikah 12y ago
  Is your front-end/admin panel/... written in Go too? Because when noobs hear "We use Go",they'll think you're using that to generate webpages,CRUD apps,or write CMSes.
Vieira 12y ago
Dropbox switch to Go? Where did you read that? If anything they seem to be "investing" in the Python ecosystem[1]. [1] https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/ https://tech.dropbox.com/2014/04/introducing-pyston-an-upcom...
- xwintermutex 12y ago
  The original article states: "One of Python’s most visible users, Dropbox — who also employs Python’s creator Guido van Rossum — recently announced it has migrated major parts of its back-end infrastructure from Python to Go" and refers to [1]. [1]: https://tech.dropbox.com/2014/07/open-sourcing-our-go-libraries/ https://tech.dropbox.com/2014/07/open-sourcing-our-go-librar...

deleted 12y ago

[deleted]

skrebbel 12y ago

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code with the browser, but it's a bitch to use. We knew that when we signed up. Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew that when we signed up. It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node. I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.

facepalm 12y ago
There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.
- aidos 12y ago
  As already stated, it depends on what you're doing. I have to calculate lots of numerical things, javascript isn't brilliant for that at all (I'm not against js, I was an early advocate and have used it for years). Python doesn't have real lambda, who cares? That may or may not matter to you, it mostly doesn't matter for me, most of the time. You've directly commented on a post about how understanding the context in which you use your tools is the crucial factor by totally ignoring the point.
- adamors 12y ago
  If you normally only do a couple lines of jQuery per day then I agree that you don't encounter the warts very often. If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.

lsiebert 12y ago

So I understand there isn't a go package manager like pip/npm/cpan. Is that correct?

dz0ny 12y ago
go get behaves in some ways as package manager (installs packages), it's up to the developer how it will vendor them or lock versions.
percept 12y ago
See the "Managing Dependencies" section, and comments: https://www.digitalocean.com/company/blog/get-your-development-team-started-with-go/#managing-dependencies https://www.digitalocean.com/company/blog/get-your-developme... Also: http://peter.bourgon.org/go-in-production/#dependency-management http://peter.bourgon.org/go-in-production/#dependency-manage... More discussion: https://news.ycombinator.com/item?id=7971354 https://news.ycombinator.com/item?id=7971354

rcarmo 12y ago

I was kind of expecting this. Although I like Go (and prefer it to NodeJS), I hope forthcoming feedback on TJ's "life choices" does not degrade into a "Let's move from Node to Go" echo chamber. More importantly, I hope the Node community's self-centred "holier than thou" doesn't bleed over, given that Go has (at least so far) kept a fairly high standard of discourse. That said, I, for one, welcome more contributors to the Go ecosystem. It is a good systems programming language, but it needs a few more "horizontal" libraries to make humdrum tasks (like parsing, accessing databases, etc.) more palatable. (edit: removed incorrect double negative)

sz4kerto 12y ago

"In the past week I’ve rewritten a relatively large distributed system in Go" Maybe I don't have any programming talent at all, but I cannot even imagine to rewrite a 'large distributed system' in a week. The not-too-large distributed systems I worked with had years of thinking behind them, I could not even type in the characters of the code in a week.

jamescun 12y ago
It is a rather vauge statement and could have used some clarification; however Go does make writing network protocols very simple, and building something like a gossip protocol based system with a leader election system is doable in a week. Even quicker if you use some of the existing distributed systems libraries for Go.
- cgag 12y ago
  What does Go do that makes writing network protocols simple?
  - skj 12y ago
    Go makes it straightforward to have one program efficiently communicating with many different servers and clients. It does this by having all network IO be event-based in such a way that it's effectively tied directly into the scheduler, and then communicating between the different goroutines managing all these connections is very easy.
  - micro_cam 12y ago
    All of the HTTP, socket, encryption, compression etc libraries have a really clean, consistent design based around stackable reader and writer interfaces. This makes it really easy to combine things, swap out transport layers etc. Go routines and channels are also nice for handling concurrent requests though I find myself using mutexes more than channels for finer grained control.
thomseddon 12y ago
You obviously don't know TJ... https://github.com/visionmedia https://github.com/visionmedia http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

jaxytee 12y ago

TL;DR It is very likely that TJH is a hive mind. FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-so-insanely-productive?share=1 http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

abritishguy 12y ago
Lol, he works at segment.io and he is very much one person.
- jaxytee 12y ago
  Have you met him?

Udo 12y ago

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example). Likewise, people will now order their projects in Go whether it makes sense given the requirements or not. 20 years of Go experience will be needed on CVs. And when Go inevitably fails at certain things, "everybody" will move to the next thing - probably Rust, thereby completing the migration away from dynamic scripting. This is not reasonable, is it?

adamors 12y ago
> "this is the thing to use now and if you don't you're dead meat". And not just because you'd be unfashionable, but because a lot of crucial libraries in these ecosystems will loose maintainers. The Node guy said the other day that (out of his hundreds of libraries) "Koa is the one project I’ll continue to maintain". If I had any of his packages in production I would be terrified. The fact that he (and other "Node guys") are driving the hype train to Go tells me that I should stay as far from it as possible.
- Udo 12y ago
  True, I think you're expected to follow the cool people to wherever they go next ;) Maybe some ecosystems are much more about the people leading them than they are about the technology behind them. And while this is not something I'd be interested in as a developer, I understand how there could be huge benefits in that kind of lifestyle. I imagine that's a very supportive, creative, and active community to be in. Looking at some (mis-)uses of Node, maybe that's been the rationale behind some of these frameworks all along. And indeed the first image on the page is of a marching band...
binocarlos 12y ago
It's like everyone looking at everyone else's fashion sense and then quickly getting down the shops to buy up the same sort of stuff. I suppose it depends on what you are trying to do - if it is looking good to those with fashion sense - better get down them shops. If it's to like, actually build stuff - the feeling of being uncool because of what language you use is a massive distraction to ignore. I've been learning Go because its a great language for concurrent server systems (and better than node in some areas). That I feel slightly cooler because of that choice feels a bit like having the right daps (sneakers) at school.

ricardobeat 12y ago

> Text processing increased 64 percent just by moving from Node to Go. And rewriting everything from scratch, plus it's a given that node isn't the best tool for data processing..

angularly 12y ago

I wonder why they didn't choose Go in the first place. Both languages were introduced in 2009, I remember evaluating both, and choosing Go because it was clearly superiour when the goal was serverside, speed, stability, maintenance and simplicity.

dccoolgai 12y ago

So what comes after Go? I only ask because I figure if I start learning that now, by the time they switch again I will have a fair chance of being competent at it by then...

marcosdumay 12y ago
I'm taking the oposite route. Once all those people live Go for something else, I'll evaluate it and see if it's any good.

eliben 12y ago

It's not surprising that the same crowd that started switching to Node.js en masse a couple of years ago is redoing it for Go :)

rufugee 12y ago

It's a shame that the debugging story in Go is still "use GDB". It's really lacking good visual debugger support afaik.

p0nce 12y ago

> Not looking at Go yet? It may be a good time to do so now — everybody else is. I'll be gladly left behind.

deleted 12y ago

[deleted]

tete 12y ago

I agree. JavaScript is weird. I think ECMAScript will make a lot things better, but it will still be a couple of months and it still won't fix it all - still a huge step of making it a really usable language for many things. Node.js is becoming mature, less trendy. I really find it weird how people compare it age wise with Go. JavaScript is way old than Go or other languages. V8 is also older than Node of course. ECMAScript didn't have breaking changes in a really long time. There are many, many implementations. SpiderMonkey has been used on the server side for over a decade now. Go looks great. There are some rough edges though and whether really good solutions will build up for these things is a really interesting thing to look at. It is really nice to see Node.js, Go and Rust emerging in amazing ways, all of them fixing problems in amazing ways. I love how great concepts, like node.js streams and pipes are copied to Go and Rust in ways that match their styles, not just blindly. All these things even influence languages like Java and C++. Who would have known only a couple of years ago that things would emerge in such ways and that it needs some projects with the idea of yet another programming language. What is even more interesting is that a lot of concepts actually stem from Perl... well, not necessarily the language itself, but libraries, modules or Perl6, which arguably was/is a really ambitious research project. It's a bit how many concepts took ages to be ported from Plan 9 to other operating systems. Anyway. It is great to see how people nowadays look at other projects and don't judge by first impression anymore. At least it seems like it. Node.js looked extremely awful to me in the beginning and turned out to actually not be (despite its shortcomings and JavaScript, which also turned out to be nicer). On the other hand projects, like Meteor that looked at least okay in the beginning turned out to be way more awful than they looked when I first heard that they don't even support proper REST. I know, my opinion on this might not be really popular, but it's amazing to see how so many new concepts emerge, even when they seem crazy, sometimes turn out to be crazy, sometimes turn out to be amazing. It's hard to know where we will stand in a couple of years. However, I don't think only one of Rust, Go or Node.js will make the race and I think none of them will look like they do today in one or two years, especially when it comes to their ecosystems. Just because all of them are too young to be judged upon and all of them are changing too rapidly (or new standards are upcoming, as with ECMAScript), so that nobody really has or can develop a deep understanding of the language/framework yet, not even its developers. What I really hope though is that there will soon be more big projects than just Docker and a bigger ecosystem.