But if that's so, then simply view this as an explanation for why I don't use server-side Javascript. And Node is still a tool built around a language implementation which is going in a different direction from where a server side environment/general-purpose language needs to go.
You're welcome to use whatever you like, of course — I'm just saying that you haven't really raised any specific objections that couldn't be (and haven't been) leveled against most other languages. Ignoring the confusion of a language and a framework, so far, your concrete objections seem to be:
• Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks)
• If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure)
If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences.
(Edited a bit to clarify and because the original phrasing sounded more combative than I intended.)
No, there is no language v. framework confusion on my part. What I'm arguing is a concrete, fundamental fact that pertains to both the framework and the runtime.
I'm not sure what I can do to clarify the point anymore: the V8 engine is created and maintained for the purposes of speeding up a web browser's processing of Javascript within the context of an HTML document. The goals of the team implementing the runtime are not to create a general purpose language, they are to create an engine which excels at one specific use case, and granted this use case is broadening over time.
But to address your point: yes, the developers of Pyramid (to take an example) have not to my knowledge submitted code to e.g. optimize networking functionality in core Python so that it better suited their specific needs. On the other hand, the Python team has had an excellent track record in observing and adapting to trends within their community -- the introduction of WSGI is one such example.
The Python community has a PEP process for generating discussions about what the language needs. To my knowledge, there is no discussion within the V8 developer community about how to make the engine more suitable for server-side programming. And how would you begin the process of adding general programming features to the language itself? Join ECMA?
If you're really concerned about other people's language choices, you're going to need concrete reasons, not just generalities, vague insinuations and your own personal preferences.
Excellent editing. Much less combative.
EDIT: Actually I'd like to add a couple more things:
Node.js is a framework built by people other than the language's core maintainers (which is true of most frameworks)
That is not a point of contention. That is a simplistic reduction of my point which conveniently serves your argument.
If you want to add fundamental language features, you can't just force it into the core implementation, but will have to implement your own offshoot (which is true of most languages, including, for example, Clojure)
This entirely misses the question -- why use a language whose core feature set does not cover your use cases? Why use a language where you must extend the language to get fundamental features? Moreover, no you will not have to implement an offshoot to get core features. At the risk of repeating myself: when you have control over the direction of the language's evolution, you can petition and propose changes.
With regard to getting changes made: Both V8 and the ECMAScript committee have development mailing lists and issue trackers where you can submit and discuss suggestions. AFAIK, this is basically the same way Ruby operates. They aren't likely to make vast, crazy changes, but I don't think, say, a PEP for static typing would get very far either.
And I think it's kind of a basic misconception that V8 is made just with web browsers in mind. If you look on the V8 developer site, nowhere does it say anything close to that. Their stated objective is "fast execution of large JavaScript applications." They go out of their way to draw a distinction between the browser and the engine, explaining what is and isn't part of JavaScript (e.g. the DOM is just an interface that browsers choose to expose). Is Chrome the original client for V8? Sure. And shell scripts were the original use case for Python. It seems to me that "V8 is just a browser language" is the new "Python is just a scripting language."
And I wouldn't describe the language-level ability to write asynchronous code in a synchronous fashion a fundamental feature. It's really cool and allows a lot of expressiveness, but so would a lot of potential changes in, say, Ruby. If you don't want the language feature, there are really nice libraries that get you most of the way there. (And I don't really see how the existence of CoffeeScript or ICS is any more an indictment of V8 than the existence of Scala is of the JVM. Choice is a good thing. Lots of people prefer vanilla JavaScript.)
But if that's so, then simply view this as an explanation for why I don't use server-side Javascript. And Node is still a tool built around a language implementation which is going in a different direction from where a server side environment/general-purpose language needs to go.