Hacker News Reader

Hacker News

Comment by kitsune_ | Hacker News Reader

Parent Full thread

kitsune_

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?

View on HN

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.

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.

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.

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 :( )

You should write a blog post - "why I used python / postgres 5 years ago and stuck with it until today"

I'm now using ClojureScript + CouchDB

I was (mostly) happily using C and Python 5 years ago. Now I'm much happier using C and Haskell.

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.

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.

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.

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.

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.

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.

I don't know if Node will win for THE non-blocking platform award, but it's coming close to THE non-blocking web platform.

I think Go (and heck even Clojure with it's added core.async model) would be better at winning the first award. They are much more general and can be used freely. Node is basically limited to web and web servers (including tcp servers here).

I think Node is turning onto generator mode. Now that generators hit V8 (and Node under a flag), it's much easier to write async code (even easier than callbacks) yet you write in a synchronous style. That'll definitely improve the concurrency model.

You have a very fundamental misunderstanding that is making you create a distinction that doesn't actually exist. There is no "non-blocking use case". The use case is web development. You absolutely do not need to use event loops to write UIs, or anything else. You should never have to write event driven callback spaghetti, just like you should never have to write direct jumps (goto).

Reasonable languages provide actual concurrency constructs, allowing you to write simple, easy to understand code, while providing all the benefits of both threads and event loops. Traditionally you needed to use a good language like haskell or erlang to get this, and that caused problems for people who want to stick with primitive languages. Now go has come along and offers similar benefits in a primitive package, so there is no need for people to have to stick with low level, error prone event loops.

Definitely. The callback style is horrible as a concurrency model. Truly awful. Compare callbacks to goroutines and it's insane how awesome goroutines are.

But, Node made it easier to write purely asynchronous code and using a language people were familiar with, that's why it became so popular. While Go is has an insanely good concurrency model, Node has it's quick iteration going for it and a large number of packages.

Now that generators (coroutines) have made it into V8, the concurrency model of Node is changing, for the better. Node is still very much limited in application (thanks to JavaScript and the event loop.). Whereas Go can be used for a lot of different things. But Node specializes in web applications, in web servers. Thus, it's going to be more productive than a general purpose solution.

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.

So you are saying ror was a fad? Honest question

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.

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.

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...

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.

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.

If anything, it's a good thing that the cycles are getting shorter. There's more ideas going around between languages, more experimentation, etc. Language evolution is accelerating and it's exciting.

But when do you hit the line on when things are fad or not? 5 years, 10 years, 20 years? How about 50 years?

The word "fad" is being redefined as the cycles are getting shorter. Maybe Node, Ruby, Go are/(will be) all just 10 year fads, but when do we redefine the word to be more appropriate?

Here is some Node.js anti-hype:

http://pages.citebite.com/b2x0j8q1megb

The best part of it:

    if (typeof my_var !== "undefined" && my_var !== null) {
      // you idiots put Rasmus Lerdorf to shame
    }

No one does that any more.

    if(my_var != null) {

    }

Or they just use lodash/underscore which takes care of it for you.

Using a library to avoid typing !=null seems like overkill.

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)

The author's writing style does absolutely nothing for their credibility. I'm inclined to be very distrustful of anything anyone says when their first paragraph includes "butthurt" and "jackass". The author suggests that Ryan Dahl has no idea what he's doing, but all his opening paragraphs certainly don't give me the impression that the author has any idea either. Reading a bit further down the page doesn't change that impression.

I'm no fan of javascript, but I'm also no fan of internet tough-guys who think that throwing a few "fucking"s and "butthurt"s into their prose makes them seem like anything other than bullies. The only thing I take away from that criticism of node is that Ted Dziuba is an awful person.

I'm not a huge node fan, but these are some weak criticisms. Not sure "CGI" is really appropriate for all tasks.

Proxying probably is. nginx is usually a good front end, Apache is not dead yet and it is very stable with plenty of people that would know how to configure it.

> The point is that the HTTP server isn't the same entity doing the application work.

> 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.

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.

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".

Maybe Go isn't very innovative, but that doesn't mean it wouldn't be more useful than the old stuff. With Turbo Pascal and Delphi I could also generate a single exe with no stupid DLL dependencies. But Turbo Pascal and Delphi don't support anything besides Windows and Borland's Kylix never got traction. Go on the other hand can generate no-dependency executables for Windows, Linux and OSX, pretty much all the major players of today. And what's maybe more important than the language's innovativeness is community support. Of all the languages today that allow generating a single executable for all major platforms, Go probably has the most active community.

Actually, there's FreePascal/Lazarus, and IIUC it's quite cross-platform:

from http://www.freepascal.org/ : "It can target multiple processor architectures: Intel x86, AMD64/x86-64, PowerPC, PowerPC64, SPARC, and ARM. Supported operating systems include Linux, FreeBSD, Haiku, Mac OS X/iOS/Darwin, DOS, Win32, Win64, WinCE, OS/2, MorphOS, Nintendo GBA, Nintendo DS, and Nintendo Wii."

You might want to take another look at Delphi, as the recent versions (XE4 and XE5) have added cross-platform support for OSX and Android (at least). While I still have to develop on Windows, I can easily produce native static OSX binaries and Windows binaries from one source tree and with careful selection of UI components also an Android app.

"Windows, Linux and OSX, pretty much all the major players of today" - any plan to support Android and iOS? Why and Why not?

To support Android the Go team needs to accept dynamic loading, at least for the current NDK toolchain as you can only have shared objects as binaries.

That was not a critic toward Go. Quite the contrary.

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.

Our industry's memory is about 5 years, the time it takes to move from graduate to mid-level developer.

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.

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.

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-...

> 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

> 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 ....

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.

> 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.

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...

Thanks for replying. That makes sense. The number of included features is what I liked about Chicago Boss as well and I can see how a small community would make it harder to get started.

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. :)

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.

> 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.

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

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.

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

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

> 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".

Reply on news.ycombinator.com