I don't think it's losing traction so much as it's losing some mindshare to faster-moving projects like Go. JavaScript is moving forward (both in the spec and in the browser) and Node hasn't kept up at all. There's no 1.0 release in sight. ES6 is effectively absent from Node. V8 is around version 3.30, while the version in the build of Node that's in Homebrew is 3.14, which "is so old it doesn't even receive security fixes anymore".
It's frustrating to get invested in a product if you know that it's got stagnant parts that nobody seriously plans to fix in the near-term at all.
By what, hacker news discussions? It seems here only "new" things are discussed, but not as much about platforms growing and stabilizing. Its almost like Rust and Golang have taken over the world if you measure by this community.
My prediction is that Go will disappear in same way as it happen to Ruby, Perl and others. It currently rides on the fame that it comes from Google "so it hast to be good". It doesn't really provide anything revolutionary, it just is more friendly toward writing specific type of applications.
Just by seeing that majority of people who are using Go are the ones who always explore new languages, and you see majority of people coming from dynamically typed languages such as Python, Ruby, PHP and others makes me convinced of this position.
Rust on the other hand also has a bit of hype, but that hype actually has a base. It is due to a features that are quite significant, not because it comes from Mozilla.
The ability to do memory safety checks at compile time is quite a big deal (maybe Rust is not first here to offer that, but it is first that it build the entire language around it).
I believe that Rust actually really has a huge chance to replace C and C++ (languages that were developed in 70s and 80s respectively) and influence future languages.
> My prediction is that Go will disappear in same way as it
> happen to Ruby, Perl and others.
Languages don't really ever disappear, they just become less trendy and therefore invisible to places like HN that revolve around hipness and novelty. Hell, when was the last time you heard about Perl? And yet there is an enormous amount of Perl out there powering systems the world over, and learning Perl will make you quite employable for maintaining and extending these systems. Replace Perl with Visual Basic, or COBOL, or RPG-LE, and this statement remains true.
> Rust on the other hand also has a bit of hype, but that
> hype actually has a base. It is due to a features that
> are quite significant, not because it comes from Mozilla.
Longtime Rustacean here, and I slightly disagree. Rust does get a lot of boost from being backed by Mozilla. People are incredibly wary of investing effort in an unestablished language without full-time corporate backing. But yes, the awesome language semantics are enticing in their own right. :)
> I believe that Rust actually really has a huge chance
> to replace C and C++ (languages that were developed in
> 70s and 80s respectively) and influence future languages.
I definitely don't expect the world to chuck out C++ and rewrite it all in Rust, though I do expect that Rust will provide an enticing proposition for new systems programming projects that value memory safety while demanding zero-cost abstractions. My hope is that with Rust we can gradually move towards a world that is safer by default.
Finally, I agree that Rust will be an influence on future languages. Just yesterday D proposed something akin to Rust's borrowed references (http://wiki.dlang.org/DIP69), and I'm curious to see if something similar emerges in future editions of C++. There's also Microsoft's secretive M# language, which I suspect will use a similar mechanism.
Node is losing traction where? I see it as being very strong, but it isn't the shiny new thing any more -- which means that it is beyond the first few stages of the hype cycle.
I see this more as a return to reality from Node.js's astronomical levels of hype.
The use cases for a single-threaded web server are specific and limited in the real world. Node.js will continue to solve those use cases (simple web server for static content or I/O bound apps) but the resultant decline will lead some to believe that the framework is dying.
> The use cases for a single-threaded web server are specific and limited in the real world.
We use Node.JS to run https://Clara.io. Clara.io isn't at all a simple website. I think you are underestimating Node.JS's flexibilities and capabilities.
Perhaps you could name some website/app servers that aren't mostly i/o (or event-timing) bound? I wouldn't say the use cases are limited at all.
You can always run multiple process instances, and communication between processes isn't really so different in practice than inter-server communication... Which just means you are scaling horizontally by design earlier in development.
I worked on some web-based project management software which was highly CPU-bound.
A typical scenario would be the application querying a database for financial figures, doing a large amount of calculations on those figures and then generating an HTML report from them. I imagine any application with large amounts of business logic like this will be the same.
Could you describe the sorts of calculations those were? Are these regressions or similar? Do PMs really look at that sort of thing? Maybe they were basing a TSP on the latest financial figures? b^)
It seems possible that was a mostly IO-bound system, and the things which could have been conceivably CPU-bound should just have been batched and cached.
I would suggest that what you are describing is the exception to the rule... Most queries, in such a case could either be done in the database or pushed to the browser... Generally if you're doing something CPU bound that isn't video processing or gaming, you push that out of process through a worker queue anyhow.
I have come to believe that the truth about Node is somewhere in the middle: not severely limited, as you imply, but probably not fit to dominate the server ecosystem, either.
I develop on .NET all day, every day, building enterprise CRUD apps with fairly cutting-edge capabilities, for small-to-medium-sized companies. I suspect that Node would fit the server role quite handily if we bothered to port our hand-rolled client-side framework to it. But, as the lady said: "Ain't nobody got time for that."
Just wait 5 years they'll be re-written in Swift, Dart, Rust (other shiny new thing). The important thing is, it will probably be the same people doing it ;-)
As I said on reddit as well, I'd really like to hear from someone with a year of serious Node experience and then a year of serious Go experience who ended up wanting to go back to Node, for anything other than perhaps a library than only Node had. While the Internet is large and any crazy criterion will match somebody, somewhere, my strong suspicion is that this is not a large set of people. I suspect it's more-or-less a one-way door.
Hello World, a todo list and a blog application. After that we put "proficient experience with node.js" on all of our developers their CVs. Our company website now lists that we have "enterprise grade expertise with Node.JS" and I haven't even talked about the nodejs-rebranding of our social media dootprint (exclusively liking, following and interacting with nodejs content). We are basically swimming in nodejs client work now. So much, that we are considering splitting the company and having an exclusive branche for the nodejs playfield.
Keep in mind that opinions on HN often do not reflect the situation in the general programming community.
I think what we are seeing is a particular developer demographic performing their periodic migration. I'm referring to the group of developers that simply follow the heat possibly caused by some sort of anxiety or fear of being left behind.
They did some Java, jumped to Ruby then Node and now Go.
It's frustrating to get invested in a product if you know that it's got stagnant parts that nobody seriously plans to fix in the near-term at all.