5 ms·

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

by 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.
    - TheHydroImpulse 13y ago
      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.
general_failure 13y ago
So you are saying ror was a fad? Honest question

by octo_t 13y ago

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.
  - TheHydroImpulse 13y ago
    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.

general_failure 13y ago

So you are saying ror was a fad? Honest question