13 ms·

I'm looking forward to all the "Why I switched from Go to XXX" posts in three years. Same thing will probably happen to node.js pretty soon. It has already be

I'm looking forward to all the "Why I switched from Go to XXX" posts in three years. Same thing will probably happen to node.js pretty soon. It has already been happening to MongoDB for quite some time. Go is currently in its hype phase. Some people seem to make a living by writing post-mortems. Why does everything always have to be the latest and greatest thing on earth? Can't we just institutionalize the hype cycle? Like fashion, minus the seasons? One big show every year where everyone can compare their dicks and then let's shut up about it until next year?

TheHydroImpulse 13y ago
While there was some hype about Node, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with 0.12 and then 1.0 coming quite soon. While I tried getting into Go, and initially didn't like it but wanted to like it. Seems like the more I read about it, the more I get into it, the less I like it. Which kinda sucks, Go seems like a powerful platform.
- octo_t 13y ago
  people said/saying the same thing about ruby/RoR too. "While there was some hype about Rails, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with Ruby 2.0 and then Rails 4.0 coming quite soon." is a thing someone could have easily said on this site in January 2013.
  - rtpg 13y ago
    Isn't this still pretty true? I've seen a lot of job offers for RoR (granted, when looking in Japan it might be biased). Just because it's not Java-sized doesn't mean the community isn't there.
  - rpedela 13y ago
    Yeah, but Node.js actually has a valid use-case: code that needs to be non-blocking. Most of the time, you want web servers to behave that way. Yes you can do that in other languages/frameworks, but Node.js is the only one with an ecosystem where most modules are also non-blocking by default. If you look at the languages/frameworks that have survived their initial hype, it is almost always ones where there is a use-case that the language/framework uniquely solves well. C/C++: Easier than most of the other low-level languages. Used when performance and/or memory management are critical: kernel, database, embedded system, etc. BASH: Dammit, I just need a script that executes five commands in a row! PYTHON: A scripting language that properly handles gigantic numbers and seamlessly integrates with R. The scientists love it! And the list goes on. Of course those languages have other use cases, but the point is that they all have at least one use case that they are the best at. However only time will tell if Node.js ends up being the non-blocking scripting language or something else will take its place.
    - asdasf 13y ago
      What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actually caring about concurrency like erlang and haskell have forever, node is a throwback to the error prone and convoluted event loops of C. Go is far better for the very use case you think node excels at.
      - rdtsc 13y ago
        I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.
      - rpedela 13y ago
        Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.
  - general_failure 13y ago
    So you are saying ror was a fad? Honest question
- epo 13y ago
  Oh please. Come back in 10 or 20 years time and say it is not a fad. Technology cycles are getting so compressed that everything is a fad now. The whole thing being fuelled by the immature and inexperienced who know nothing about the past and consequently think they have nothing to learn from it.
  - threeseed 13y ago
    Our industry could really do without this type of condescending, unhelpful attitude. Big deal. Concepts are being repeated and technology stacks are stealing ideas from one another. Remind me again how that is a bad thing ? The fact is that there is no perfect solution to every problem.
    - deleted 13y ago
      [deleted]
    - Peaker 13y ago
      Concepts and good ideas being repeated and stolen is great! However, the problem is repeating mistakes. Go's nullability, lack of generics, ... Node doing manual CPS where past work (e.g: Haskell) does non-blocking IO without forcing manual CPS on the programmer. It would be nice if we learned not to repeat past mistakes...
      - jaegerpicker 13y ago
        The problem lies in that not everyone agrees on what are mistakes and what isn't. I know a lot of go programmers who do not want generics. Many also disagree that manual CPS is a mistake.
        Peaker 13y ago
        I think the majority of people who disagree that nullability everywhere is a mistake, as an example, are people who've only ever used languages that had that bug.
  - 13y ago
- CmonDev 13y ago
  Here is some Node.js anti-hype: http://pages.citebite.com/b2x0j8q1megb http://pages.citebite.com/b2x0j8q1megb
  - nakkiel 13y ago
    The best part of it: if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put Rasmus Lerdorf to shame }
    - Touche 13y ago
      No one does that any more. if(my_var != null) { }
      - snarkyturtle 13y ago
        Or they just use lodash/underscore which takes care of it for you.
        Touche 13y ago
        Using a library to avoid typing !=null seems like overkill.
        snarkyturtle 13y ago
        It's more for handling all those js quirks with equality, though yeah if it's your var, you'll probably be fine with != null (though jshint probably won't like it)
  - wcummings 13y ago
    I'm not a huge node fan, but these are some weak criticisms. Not sure "CGI" is really appropriate for all tasks.
    - rdtsc 13y ago
enen 13y ago
What's your point? We should just not try out new things? It's not like HN is representative of the industry as a whole anyway. Platforms, languages, frameworks etc etc learn and copy from each other, imo people switching technologies are helping these processes.
onion2k 13y ago
I'm looking forward to all the "Why I switched from Go to XXX" posts in three years. I really hope that "XXX" mean "a different language" and not "porn". That'd be horrible. :)
- deleted 13y ago
  [deleted]
Shish2k 13y ago
Meanwhile, I've was happily using python / postgres 5 years ago and I'm still happily using python / postgres today... (I was also unhappily maintaining legacy php / mysql code 5 years ago and I'm still unhappily maintaining legacy php / mysql code today :( )
- theorique 13y ago
  You should write a blog post - "why I used python / postgres 5 years ago and stuck with it until today"
  - bkurtz13 13y ago
    I'm now using ClojureScript + CouchDB
- Peaker 13y ago
  I was (mostly) happily using C and Python 5 years ago. Now I'm much happier using C and Haskell.
randomdata 13y ago
> Why does everything always have to be the latest and greatest thing on earth? Probably because the existing solutions have pain points and the "latest and greatest" technology solves those problems, but introduces new ones, which will be solved by the next big thing. It is a never-ending cycle because people tend to want to improve on what they have.
- ams6110 13y ago
  My answer would be, "those who do not learn from history are doomed to repeat it" These trends/fads seem to me to roughly follow cycles where a new "generation" of devs enters working/professional life, seemingly unaware of many solved problems and instead solving them all over again rather than actually pushing the state of the art forward.
  - jacques_chester 13y ago
    Our industry's memory is about 5 years, the time it takes to move from graduate to mid-level developer.
  - sacado2 13y ago
    You're right, although I doubt Ken Thompson & Rob Pike can be called a new generation. Actually, Go seems to be history going the other way ; Go isn't very innovative, it's the main this his detractors point to, it's just Pascal/Oberon/C with almost-new clothes. So Go is "solving" issues that were raised by Python/Ruby et al, mainly regarding performance, programming in the large and ease of deployment. Most of the "I'm switching for 10 years ago's hype to Go" articles (including this one) are actually saying "whoops, 10 years ago's technology had drawbacks, I just discovered them, let's use 15 years ago's technology with fancy clothes".
    - nakkiel 13y ago
      How about goroutines? Not that they created them (although their actual implementation is fairly unique) but they certainly gave them a chance to make them mainstream.
JoshGlazebrook 13y ago
I look forward to "Why I switched from Go to XXX in only 1 paragraph!" in the next week.
- drdaeman 13y ago
  The shortest version I've seen: https://twitter.com/rakyll/status/340187980452999169 https://twitter.com/rakyll/status/340187980452999169
hugofirth 13y ago
They already have them - they're called conferences. I think web developers tend to notice the absurd pace more than many because they are, by necessity, often polyglot programmers.
pjmlp 13y ago
> Can't we just institutionalize the hype cycle? Like fashion, minus the seasons? One big show every year where everyone can compare their dicks and then let's shut up about it until next year Hype cycles are required for people to write books about, provide certifications, create conferences explaining how the respective technology will save the world, get contracts to re-write working systems ....
jacques_chester 13y ago
> Can't we just institutionalize the hype cycle? Indeed, it's already been done, by Gartner, would you believe? http://en.wikipedia.org/wiki/Hype_cycle http://en.wikipedia.org/wiki/Hype_cycle
loudmax 13y ago
You could have said the same thing about Java in 1996. Saying there's a lot of hype around Go isn't particularly interesting. Claiming that Go isn't suitable for some particular purpose, or even any particular purpose is more interesting as long as you explain your reasoning. The author if this post explains why he switched to Go, and that is interesting and informative. Maybe three years from now, Rust will be ready for production use and switching from Go to Rust will help people become more productive and we'll see blog posts about it. This is how progress works and it's nothing to scoff at.
- wpietri 13y ago
  Saying there's a lot of hype around something is very interesting to me. The hype cycle has well-known biases. Knowing when a product is peaking is helpful to me, in that I can basically ignore 95% of the noise about it. This post is a fine example. He could have written exactly the same post about C, because he's basically saying "compiled binaries are easier to distribute". He's been blogging about Go for an entire two weeks. The only potentially new information here is "Go produces a binary." That's not to say he shouldn't have written the post. He learned something and he shared it, which is great. It's just that nobody would be talking about the C version of the post, because that's not the hyped technology.
  - muaddirac 13y ago
    I got more something like: "I love writing a cli in a nice, expressive language like ruby, but ruby is a pain to distribute. I wrote this library for Go that lets me write simply and expressively, and I still get the advantages of Go's portability." Not a groundbreaking revelation, but his point, I thought, was the expressiveness of the syntax PLUS the portability of the code.
mtrn 13y ago
If you are in for the hype, it might be tiresome. Once you mastered the tech, it goes out of fashion. If you try to be in for a new perspective, it might be useful, since 'Everything is a tradeoff' (tm ;)[1]. Currently I evaluate tradeoffs between speed, readability and maintainability. In case of Go, I'm also interested in how someone like ken designs a language today. [1] http://michaelrbernste.in/2013/11/13/the-only-sure-thing-in-computer-science.html http://michaelrbernste.in/2013/11/13/the-only-sure-thing-in-...
Xixi 13y ago
My policy is to stick to a couple of stacks for projects I will have to maintain 5 years down the road: currently Python/PostgreSQL for server side code, and AngularJS or Unity for client side code (depending on the nature of the project, but really there's not much overlap there). It will definitely evolve whenever I find something warranting the switch, but the bar is set pretty high. At the end of the day it's what you ship that matters, much more than how it's built. On the other hand, when I get to do a short-lived project I tried to use a new technology: that's still the best way to learn, plus it's loads of fun. If it's great then I start using it for longer term projects: that's how I found (and so far sticked to) AngularJS. In 2013 I shipped small projects built on top of nodejs, chicago-boss (erlang), meteor, but also RethinkDB and coffeescript. RethinkDB genuinely seems like a great document store: I will probably give it a second shot when it's more production ready.
- rdtsc 13y ago
  > My policy is to stick to a couple of stacks for projects I will have to maintain 5 years down the road: > On the other hand, when I get to do a short-lived project I tried to use a new technology: Hey, that's a pretty good idea, I like it. So what are your impressions so far on Chicago Boss, and what do you like about RethinkDB? I have been following those as well but haven't got a chance to try them yet.
  - Xixi 13y ago
    To put things in perspective my goto stack is Django/Celery/RabbitMQ/PostgreSQL. Chicago Boss is quite impressive in that it replaces all of that (except PostgreSQL, though for an adequate project you could use mnesia instead) in just one piece of software, thanks largely to Erlang/OTP. With boss_mq you get your websocket/comet stuff for free, while with Django the best I found so far is to use the RabbitMQ-WebStomp plugin. The less impressive part is the general lack of polish: for instance the Django templating system is quite forgiving when it comes to types and data you feed it with. Chicago Boss not at all, which can be frustrating. The lack of community around Chicago Boss is probably the biggest downside though. Anyway I got a working demo product, which was good enough to land a bigger project. For that one I moved back to my usual stack, to avoid codebase fragmentation. I'll probably give Elixir and Dynamo a try if I get an adequate project...
twerquie 13y ago
Technology moves forward quickly. You might see these languages and frameworks as basically all the same from one perspective, but really there are fundamental differences in the way you shape your application in different ecosystems like Go or nodejs or Python or Java, and that ultimately influences the products you build and the direction the industry goes in. It's important.
JulianMorrison 13y ago
There were good reasons to switch to Java. In some contexts, it was clearly better. Most of its bloat hadn't happened yet. It had an axe to grind, but it was a popular axe back then. There are good reasons to switch to Go (mainly: fast compiles, WYSIWYG syntax, tooling, standards, a good library, and static compiles). In some contexts, it is clearly better. It isn't bloated, and unlike Java, the authors don't seem inclined to make it so, nor do they have any axe to grind except simplicity.
geoka9 13y ago
> Why does everything always have to be the latest and greatest thing on earth? To me, Go feels like an old friend that I've been missing for many years. I've always had C and Python, they serve me well, but there was a big gap of uncovered space in between them - you know, when C is too fine a tool for the job, while Python is a bit too "dynamic" - until Go came along. I tried filling that gap with Scala, and while the cleverness of the (most of the) language did have its appeal, eventually I stopped using it, since it was just too much of a tool which got in the way. Go hits the sweetspot. Everything about it screams unix. The toolchain, the speed, the simplicity of the language, the powerful concepts delivered in a dead simple to use way (goroutines/channels)... It's like a breath of fresh air whenever I have to work with Go. Just like C and Python, it's a keeper.
- jqgatsby 13y ago
  "Everything about it screams unix" Strong agree. I've often described Go to people as "if unix were a programming language"
bsg75 13y ago
> Why does everything always have to be the latest and greatest thing on earth? Go is less than the "latest thing" and more of an evolution of some old ideas, especially when compared to other "latest things".

TheHydroImpulse 13y ago

While there was some hype about Node, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with 0.12 and then 1.0 coming quite soon. While I tried getting into Go, and initially didn't like it but wanted to like it. Seems like the more I read about it, the more I get into it, the less I like it. Which kinda sucks, Go seems like a powerful platform.

octo_t 13y ago
people said/saying the same thing about ruby/RoR too. "While there was some hype about Rails, it didn't turn out to be a fad. The ecosystem is thriving and not slowing down anytime soon, especially with Ruby 2.0 and then Rails 4.0 coming quite soon." is a thing someone could have easily said on this site in January 2013.
- rtpg 13y ago
  Isn't this still pretty true? I've seen a lot of job offers for RoR (granted, when looking in Japan it might be biased). Just because it's not Java-sized doesn't mean the community isn't there.
- rpedela 13y ago
  Yeah, but Node.js actually has a valid use-case: code that needs to be non-blocking. Most of the time, you want web servers to behave that way. Yes you can do that in other languages/frameworks, but Node.js is the only one with an ecosystem where most modules are also non-blocking by default. If you look at the languages/frameworks that have survived their initial hype, it is almost always ones where there is a use-case that the language/framework uniquely solves well. C/C++: Easier than most of the other low-level languages. Used when performance and/or memory management are critical: kernel, database, embedded system, etc. BASH: Dammit, I just need a script that executes five commands in a row! PYTHON: A scripting language that properly handles gigantic numbers and seamlessly integrates with R. The scientists love it! And the list goes on. Of course those languages have other use cases, but the point is that they all have at least one use case that they are the best at. However only time will tell if Node.js ends up being the non-blocking scripting language or something else will take its place.
  - asdasf 13y ago
    What you think is node's strength is its weakness. Having to write event-driven code is terrible. Just as the world is finally waking up and moving to actually caring about concurrency like erlang and haskell have forever, node is a throwback to the error prone and convoluted event loops of C. Go is far better for the very use case you think node excels at.
    - rdtsc 13y ago
      I agree and I could probably stomach it better if community centered around Node.js wouldn't be so arrogant. Arrogance to be tolerated needs to be backed up by technical knowledge. Linus Torvalds is arrogant and abrasive. I don't mind it as much because of his experience, knowledge and his contribution. Some guy yelling about how asynchronous callback programming is the best way to handle concurrency and is the way of the future is doing a disservice to whatever community he belong s to (well node.js in this case), it just deepens the negative stereotypes. Technology in itself is fairly neutral, tools that work for some use cases and don't work for others, trade-offs and so on. It is the people that use the tools that give those tools a bad wrap usually.
    - rpedela 13y ago
      Like I said, only time will tell if Node.js is THE non-blocking scripting language/framework. Still too early in hype mode to know for sure. At the moment it is and it has the momentum. Doesn't mean Go won't take its place at some point in the future assuming it really is better at the non-blocking use case. Or Go could just be another language in a long line of languages that go nowhere. We shall see. No matter the mechanism, event-driven programming is here to stay. All UIs must be event-driven unless you enjoy pissing users off. Games must be event-driven. Web servers should usually be event-driven for similar reasons. Callbacks are just the most basic way to achieve that when you have an event that won't finish processing for awhile like a DB call. I certainly understand the desire to not use callbacks since I also loathe them. But they are also much easier to understand than something that looks synchronous but actually isn't. But there are a lot of people who have tried and are still trying now to rid us of the need for callbacks but still allow for async. I certainly hope they prevail, but, historically speaking, I am not optimistic.
- general_failure 13y ago
  So you are saying ror was a fad? Honest question
epo 13y ago
Oh please. Come back in 10 or 20 years time and say it is not a fad. Technology cycles are getting so compressed that everything is a fad now. The whole thing being fuelled by the immature and inexperienced who know nothing about the past and consequently think they have nothing to learn from it.
- threeseed 13y ago
  Our industry could really do without this type of condescending, unhelpful attitude. Big deal. Concepts are being repeated and technology stacks are stealing ideas from one another. Remind me again how that is a bad thing ? The fact is that there is no perfect solution to every problem.
  - deleted 13y ago
    [deleted]
  - Peaker 13y ago
    Concepts and good ideas being repeated and stolen is great! However, the problem is repeating mistakes. Go's nullability, lack of generics, ... Node doing manual CPS where past work (e.g: Haskell) does non-blocking IO without forcing manual CPS on the programmer. It would be nice if we learned not to repeat past mistakes...
    - jaegerpicker 13y ago
      The problem lies in that not everyone agrees on what are mistakes and what isn't. I know a lot of go programmers who do not want generics. Many also disagree that manual CPS is a mistake.
      - Peaker 13y ago
        I think the majority of people who disagree that nullability everywhere is a mistake, as an example, are people who've only ever used languages that had that bug.
- 13y ago
CmonDev 13y ago
Here is some Node.js anti-hype: http://pages.citebite.com/b2x0j8q1megb http://pages.citebite.com/b2x0j8q1megb
- nakkiel 13y ago
  The best part of it: if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put Rasmus Lerdorf to shame }
  - Touche 13y ago
    No one does that any more. if(my_var != null) { }
    - snarkyturtle 13y ago
      Or they just use lodash/underscore which takes care of it for you.
      - Touche 13y ago
        Using a library to avoid typing !=null seems like overkill.
        snarkyturtle 13y ago
        It's more for handling all those js quirks with equality, though yeah if it's your var, you'll probably be fine with != null (though jshint probably won't like it)
- wcummings 13y ago
  I'm not a huge node fan, but these are some weak criticisms. Not sure "CGI" is really appropriate for all tasks.
  - rdtsc 13y ago

enen 13y ago

What's your point? We should just not try out new things? It's not like HN is representative of the industry as a whole anyway. Platforms, languages, frameworks etc etc learn and copy from each other, imo people switching technologies are helping these processes.

onion2k 13y ago

I'm looking forward to all the "Why I switched from Go to XXX" posts in three years. I really hope that "XXX" mean "a different language" and not "porn". That'd be horrible. :)

deleted 13y ago
[deleted]

Shish2k 13y ago

Meanwhile, I've was happily using python / postgres 5 years ago and I'm still happily using python / postgres today... (I was also unhappily maintaining legacy php / mysql code 5 years ago and I'm still unhappily maintaining legacy php / mysql code today :( )

theorique 13y ago
You should write a blog post - "why I used python / postgres 5 years ago and stuck with it until today"
- bkurtz13 13y ago
  I'm now using ClojureScript + CouchDB
Peaker 13y ago
I was (mostly) happily using C and Python 5 years ago. Now I'm much happier using C and Haskell.

randomdata 13y ago

> Why does everything always have to be the latest and greatest thing on earth? Probably because the existing solutions have pain points and the "latest and greatest" technology solves those problems, but introduces new ones, which will be solved by the next big thing. It is a never-ending cycle because people tend to want to improve on what they have.

ams6110 13y ago
My answer would be, "those who do not learn from history are doomed to repeat it" These trends/fads seem to me to roughly follow cycles where a new "generation" of devs enters working/professional life, seemingly unaware of many solved problems and instead solving them all over again rather than actually pushing the state of the art forward.
- jacques_chester 13y ago
  Our industry's memory is about 5 years, the time it takes to move from graduate to mid-level developer.
- sacado2 13y ago
  You're right, although I doubt Ken Thompson & Rob Pike can be called a new generation. Actually, Go seems to be history going the other way ; Go isn't very innovative, it's the main this his detractors point to, it's just Pascal/Oberon/C with almost-new clothes. So Go is "solving" issues that were raised by Python/Ruby et al, mainly regarding performance, programming in the large and ease of deployment. Most of the "I'm switching for 10 years ago's hype to Go" articles (including this one) are actually saying "whoops, 10 years ago's technology had drawbacks, I just discovered them, let's use 15 years ago's technology with fancy clothes".
  - nakkiel 13y ago
    How about goroutines? Not that they created them (although their actual implementation is fairly unique) but they certainly gave them a chance to make them mainstream.

JoshGlazebrook 13y ago

I look forward to "Why I switched from Go to XXX in only 1 paragraph!" in the next week.

drdaeman 13y ago
The shortest version I've seen: https://twitter.com/rakyll/status/340187980452999169 https://twitter.com/rakyll/status/340187980452999169

hugofirth 13y ago

They already have them - they're called conferences. I think web developers tend to notice the absurd pace more than many because they are, by necessity, often polyglot programmers.

pjmlp 13y ago

> Can't we just institutionalize the hype cycle? Like fashion, minus the seasons? One big show every year where everyone can compare their dicks and then let's shut up about it until next year Hype cycles are required for people to write books about, provide certifications, create conferences explaining how the respective technology will save the world, get contracts to re-write working systems ....

jacques_chester 13y ago

> Can't we just institutionalize the hype cycle? Indeed, it's already been done, by Gartner, would you believe? http://en.wikipedia.org/wiki/Hype_cycle http://en.wikipedia.org/wiki/Hype_cycle

loudmax 13y ago

You could have said the same thing about Java in 1996. Saying there's a lot of hype around Go isn't particularly interesting. Claiming that Go isn't suitable for some particular purpose, or even any particular purpose is more interesting as long as you explain your reasoning. The author if this post explains why he switched to Go, and that is interesting and informative. Maybe three years from now, Rust will be ready for production use and switching from Go to Rust will help people become more productive and we'll see blog posts about it. This is how progress works and it's nothing to scoff at.

wpietri 13y ago
Saying there's a lot of hype around something is very interesting to me. The hype cycle has well-known biases. Knowing when a product is peaking is helpful to me, in that I can basically ignore 95% of the noise about it. This post is a fine example. He could have written exactly the same post about C, because he's basically saying "compiled binaries are easier to distribute". He's been blogging about Go for an entire two weeks. The only potentially new information here is "Go produces a binary." That's not to say he shouldn't have written the post. He learned something and he shared it, which is great. It's just that nobody would be talking about the C version of the post, because that's not the hyped technology.
- muaddirac 13y ago
  I got more something like: "I love writing a cli in a nice, expressive language like ruby, but ruby is a pain to distribute. I wrote this library for Go that lets me write simply and expressively, and I still get the advantages of Go's portability." Not a groundbreaking revelation, but his point, I thought, was the expressiveness of the syntax PLUS the portability of the code.

mtrn 13y ago

If you are in for the hype, it might be tiresome. Once you mastered the tech, it goes out of fashion. If you try to be in for a new perspective, it might be useful, since 'Everything is a tradeoff' (tm ;)[1]. Currently I evaluate tradeoffs between speed, readability and maintainability. In case of Go, I'm also interested in how someone like ken designs a language today. [1] http://michaelrbernste.in/2013/11/13/the-only-sure-thing-in-computer-science.html http://michaelrbernste.in/2013/11/13/the-only-sure-thing-in-...

Xixi 13y ago

My policy is to stick to a couple of stacks for projects I will have to maintain 5 years down the road: currently Python/PostgreSQL for server side code, and AngularJS or Unity for client side code (depending on the nature of the project, but really there's not much overlap there). It will definitely evolve whenever I find something warranting the switch, but the bar is set pretty high. At the end of the day it's what you ship that matters, much more than how it's built. On the other hand, when I get to do a short-lived project I tried to use a new technology: that's still the best way to learn, plus it's loads of fun. If it's great then I start using it for longer term projects: that's how I found (and so far sticked to) AngularJS. In 2013 I shipped small projects built on top of nodejs, chicago-boss (erlang), meteor, but also RethinkDB and coffeescript. RethinkDB genuinely seems like a great document store: I will probably give it a second shot when it's more production ready.

rdtsc 13y ago
> My policy is to stick to a couple of stacks for projects I will have to maintain 5 years down the road: > On the other hand, when I get to do a short-lived project I tried to use a new technology: Hey, that's a pretty good idea, I like it. So what are your impressions so far on Chicago Boss, and what do you like about RethinkDB? I have been following those as well but haven't got a chance to try them yet.
- Xixi 13y ago
  To put things in perspective my goto stack is Django/Celery/RabbitMQ/PostgreSQL. Chicago Boss is quite impressive in that it replaces all of that (except PostgreSQL, though for an adequate project you could use mnesia instead) in just one piece of software, thanks largely to Erlang/OTP. With boss_mq you get your websocket/comet stuff for free, while with Django the best I found so far is to use the RabbitMQ-WebStomp plugin. The less impressive part is the general lack of polish: for instance the Django templating system is quite forgiving when it comes to types and data you feed it with. Chicago Boss not at all, which can be frustrating. The lack of community around Chicago Boss is probably the biggest downside though. Anyway I got a working demo product, which was good enough to land a bigger project. For that one I moved back to my usual stack, to avoid codebase fragmentation. I'll probably give Elixir and Dynamo a try if I get an adequate project...

twerquie 13y ago

Technology moves forward quickly. You might see these languages and frameworks as basically all the same from one perspective, but really there are fundamental differences in the way you shape your application in different ecosystems like Go or nodejs or Python or Java, and that ultimately influences the products you build and the direction the industry goes in. It's important.

JulianMorrison 13y ago

There were good reasons to switch to Java. In some contexts, it was clearly better. Most of its bloat hadn't happened yet. It had an axe to grind, but it was a popular axe back then. There are good reasons to switch to Go (mainly: fast compiles, WYSIWYG syntax, tooling, standards, a good library, and static compiles). In some contexts, it is clearly better. It isn't bloated, and unlike Java, the authors don't seem inclined to make it so, nor do they have any axe to grind except simplicity.

geoka9 13y ago

> Why does everything always have to be the latest and greatest thing on earth? To me, Go feels like an old friend that I've been missing for many years. I've always had C and Python, they serve me well, but there was a big gap of uncovered space in between them - you know, when C is too fine a tool for the job, while Python is a bit too "dynamic" - until Go came along. I tried filling that gap with Scala, and while the cleverness of the (most of the) language did have its appeal, eventually I stopped using it, since it was just too much of a tool which got in the way. Go hits the sweetspot. Everything about it screams unix. The toolchain, the speed, the simplicity of the language, the powerful concepts delivered in a dead simple to use way (goroutines/channels)... It's like a breath of fresh air whenever I have to work with Go. Just like C and Python, it's a keeper.

jqgatsby 13y ago
"Everything about it screams unix" Strong agree. I've often described Go to people as "if unix were a programming language"

bsg75 13y ago

> Why does everything always have to be the latest and greatest thing on earth? Go is less than the "latest thing" and more of an evolution of some old ideas, especially when compared to other "latest things".