Node in 1 year?

[TipTop]

So I would like to know where node thinks it will be in 1 year?

What are things that are been looked at for improvement with node as a whole?

At some point nodes going to run into a wall, and that wall is javascript. I feel that js is nodes achilles heel. I LOVE js and live by it but its has flaws, maths and stuff like that.

Whats the plan?

[Mark Hahn]

>  At some point nodes going to run into a wall, and that wall is javascript.  

In what way is javascript limiting?

[Joshua Holbrook]

> So I would like to know where node thinks it will be in 1 year?

Well, node core, I think, is in a place where it's starting to
converge on an intended final state. You won't see any sweeping api
changes probably, and instead will see improvement in the user
experience and a lot of stability fixes. In a year, node will be that
much more battle-hardened but not really fundamentally different.

All the action's gonna be in userspace, I think.

First of all, I think we're going to see improvements on the "browsing
npm" front, since they're sorely needed and something people are
already experimenting with.

I also think we're going to see a change/solidification in terms of
common node.js frameworks. Right now express is still really popular
but there are many new frameworks coming out (there was a podcast
about these frameworks on nodeUp not too long ago) and I think at
least a few of them are going to give express a run for their money.
Speaking of money: Mine's on flatiron, but hey, I'm biased.

With improvements on the native bindings experience, I hope we also
see some interesting new native bindings, though current trends
indicate people prefer pure js bindings for reasons other than "oh
maan I have to compile something" imo.

> At some point nodes going to run into a wall, and that wall is javascript.

I will admit that javascript has its limits (numerical stuffs as you
point out). However, I don't think these will be experienced as a
wall. Instead, I predict that other environments and languages will
get libuv bindings (along the lines of luvit), and that for certain
problems these will become popular. For example, I saw a branch on
julia-lang for binding the core to libuv, and that would be a great
way to create services that can data crunch. On a similar note, luvit
is already being used in places where v8 has been deemed to have too
large of a memory footprint.

Cheers,

--Josh

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

--
Joshua Holbrook
Engineer
Nodejitsu Inc.
jo...@nodejitsu.com

[Tim Price]

What about stuff like JSON.stringify. The whole idea of node and its stream with stringify and parse just dont fit. It worked in the browser but might not be the best for node.

How can we better do things that javascript is not so great at. Like JSON.pipe with the work been done in c++ and it passing back a buffer. These are the improvements that node need to think about. 

[Mark Hahn]

Can't this be dealt with in external modules?

On Mon, Apr 2, 2012 at 6:33 PM, Tim Price <price...@gmail.com> wrote:

What about stuff like JSON.stringify. The whole idea of node and its stream with stringify and parse just dont fit. It worked in the browser but might not be the best for node.

How can we better do things that javascript is not so great at. Like JSON.pipe with the work been done in c++ and it passing back a buffer. These are the improvements that node need to think about. 

--

[Stewart Mckinney]

At that point, just like Rails did with Ruby, you need to extend the language by coding C++ modules and wrappers to improve performance where needed, or isolate calculation heavy parts of your solution and spin them out in separate technologies. At that point, when you are building a "for reals" application on the interwebz, you need to start thinking of your app as a conjunction of services and not of a standalone one-size-fits all cluster. Which is really part of what the node.js "revolution" is about - making smaller apps that fit together well in a unified, event-driven whole.

Whats the plan?

Continue kicking ass? 

[Marcel Laverdet]

In a year v8 will implement yield in the form of generators and finally we will have a robust tool that can expressively mitigate the nested callback problem.

I'm sorry.

--

[Tim Price]

> Can't this be dealt with in external modules?

Yes it can but should it? 

Extending the language is where my mind drifts. JavaScript has a lot of baggage thanks to 20 years of crap browsers, and  think some of the baggage has been brought along with the coming of node.

[Joshua Holbrook]

> Extending the language is where my mind drifts.

That's not really something node's interested in. The various working
groups might make language proposals and the v8 peeps might implement
some of them, but that stuff's outside node's scope.

> These are the improvements that node need to think about.

Ehh, it's not node's style. Node's really designed so other people can
write streaming json parsers for it. We already have more than one to
choose from.

--Josh

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

--

[Mark Hahn]

> JavaScript has a lot of baggage thanks to 20 years of crap browsers,  

Your trolling isn't really working.  Why did you change your name since the OP?

[Thomas Shinnick]

On Monday, April 2, 2012 11:22:45 PM UTC-5, Mark Hahn wrote:

> JavaScript has a lot of baggage thanks to 20 years of crap browsers,  

Your trolling isn't really working.  Why did you change your name since the OP?

Apparently threading isn't working, because I can't tell what you are reacting to or for sure who.

The stance that node is based on Javascript and there's no cause to change that is, I believe, reasonable.  We'd have to see real demonstrable limits on node-based applications stemming from the *language*.  As plenty can be done as-is, let's utilize what we've got until a problem forces change.  Even then, that would simply be a reason for developing a new platform, with another language as basis, and perhaps trying to re-use things like libuv or even v8, though I don't know how.

That said, Mark, there are legitimate beefs with Javascript, though not anywhere near crippling.  Regular expression support is not close to where Perl and other languages have gotten to years ago.  And the Unicode situation "We defined it as UTF-16 then and that's good enough forever"!  Javascript not being able to handle the same coding (UTF8) that (modern) browsers can handle makes me despair.  But not terminally.

The original posting seemed like a legitimate query, if misdirected by not understanding the linkages between node, Javascript, v8, and usability (which is very fine thank you).  I read it as wistful wishful thinking.  How did you end up with trolling?

[Brandon Benvie]

Who says we have to fall back to C++.

https://gist.github.com/1973743 

No limits! 30k lines of wrappers is a go.

[Tim Price]

> Your trolling isn't really working.  Why did you change your name since the OP?

Ill troll you ass idiot.

> The various working groups might make language proposals and the v8 peeps might implement some of them, but that stuff's outside node's scope.

See my point is that node need to think about the language. v8 was never made to work on the server, it was made for the browser. where is nodes working group?

json streaming was one thing of many that is part of the pure js that might not work for node.

At some point someones going to have to ask what we can do to make js fit better on the server and with node.

[Tim Price]

PS: I dont see how this is trolling. I'm just asking a question about node. But fuck ill think about it and not ask about. thanks.

[Chris Rhoden]

Probably better to let this thread die, but yeah.

The reason you got called out for trolling is that you asked a loaded question in your first email (one could argue that you were claiming that javascript is a bad language), and then after that point was refuted, you changed the name attached to your email address and looked like you were trying to back yourself up.

Your defensiveness and swearing at people isn't helping your case. Which is a pity, because I would have liked to see where some other people took this thread.

I think it's wrong to conclude that we should extend Javascript. But I don't see anything wrong with folding improvements into v8 over time, it's something that I am fairly certain has happened a few times. And new standards are created when they've been implemented and shown to work, so I think that if there's a wall we hit in the future, we should not be afraid to tweak things.

W/R/T the Ruby/Rails comment - this is just wrong, there are no parts of rails implemented as C extensions. The reason for this is that it greatly decreases the barrier to participation and tweaking, which is the reason I think we should avoid shoving everything into C extensions just because it will shave a few cycles. Javascript is expressive, but more importantly, lots of people know it, and when you're in the OSS world, that's a good thing.

On Tue, Apr 3, 2012 at 7:56 AM, Tim Price <price...@gmail.com> wrote:

PS: I dont see how this is trolling. I'm just asking a question about node. But fuck ill think about it and not ask about. thanks.

--

Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
chrisrhoden

[Tim Price]

But pushing improvements to v8 will only go as far as what the v8 team think will work with v8. Buffer, stream, and others will not apply to v8 but they are a core part of node.

I just want to see what peoples thoughts are on this subject.

Sorry for trolling, I had just linked my groups account with g+

nodejs+unsubscribe@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
chrisrhoden

[Ben Noordhuis]

On Tue, Apr 3, 2012 at 17:08, Tim Price <price...@gmail.com> wrote:
> But pushing improvements to v8 will only go as far as what the v8 team think
> will work with v8. Buffer, stream, and others will not apply to v8 but they
> are a core part of node.
>
> I just want to see what peoples thoughts are on this subject.
>
> Sorry for trolling, I had just linked my groups account with g+

Buffers are based on a low-level primitive that V8 provides.

Streams are a high-level concept that isn't suitable for embedding at
the language level.

[Karl Tiedt]

Similar SSJS solutions have existed for 15 years and are still
actively used... why would you suspect that all of a sudden JS would
be come a hindrance to its serverside self?

-Karl Tiedt

[Chris Rhoden]

You keep mentioning that javascript is going to (or already is?) causing problems for node. Please provide a specific example of some way this might happen, because I just don't see what you're driving at.

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to

nodejs+un...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--
chrisrhoden

[Tim Price]

> Streams are a high-level concept that isn't suitable for embedding at the language level.

As a js user of node the Stream proto is the same leave as Math, String or RegExp. From the prospective of the user it does not matter what magic is been used in the background. Why not use nodes conceptions to fix some of the fallback when coding javascript.

> Please provide a specific example of some way this might happen

String manipulation in javascript could be better. JSON is blocking, for example.

Stuff like using Buffer's as a more core part of the "language"...  as example these are just ideas of improving the "language". Look at a Appcelerator's Titanium use of js outside of the traditional use of javascript, node is in the same ball park but better organized and well coded. To the user coding their code its no different.

SSJS had been around as long as javascript has. The time node has been around more code has been written of node then other vm/env SSJS that has been offed.

These are just thoughts.

[billywhizz]

personally i would like to see javascript get proper support for 64 bit numbers and would like to see node.js/v8 with better support for processing binary data. from the testing i have done, it's a major bottleneck when compared with c# or java. 

JSON.stringify/parse is still very slow for serialisation of js objects (understandably so) and would be good to see some way of sharing/passing objects efficiently between processes. 

would also be good to see libuv and the c++ parts of node.js be able to fully support multi threading and isolates somewhere down the line. is not something i'm particularly interested in right now, but i can see why people keep bringing it up.

[Ben Noordhuis]

On Tue, Apr 3, 2012 at 18:30, billywhizz <apjo...@gmail.com> wrote:
> personally i would like to see javascript get proper support for 64 bit
> numbers and would like to see node.js/v8 with better support for processing
> binary data. from the testing i have done, it's a major bottleneck when
> compared with c# or java.

Yes. It's something we're working on or at least thinking about.
Consider it an ongoing effort.

> JSON.stringify/parse is still very slow for serialisation of js objects
> (understandably so) and would be good to see some way of sharing/passing
> objects efficiently between processes.

Ditto, except for object passing. Non-scientific sampling (IRC, ML,
the bug tracker) suggests that object passing is not a bottleneck - or
even an issue - to most people.

> would also be good to see libuv and the c++ parts of node.js be able to
> fully support multi threading and isolates somewhere down the line. is not
> something i'm particularly interested in right now, but i can see why people
> keep bringing it up.

Those people simply haven't seen the light that's process isolation.
Don't worry, it will come to them.

[Ted Young]

I agree with the core teams decision not to extend javascript.  However, I do think node has massively increased the use of js as a server side language.  Since there is now a large audience that can immediately implement the latest version of js - as opposed to leaving the new features untouched on the vine for years - and that audience now includes Microsoft as well as all the major players in the js game, my hope is that the pace of core language development will increase to fill demand.

[billywhizz]

thanks for the feedback ben.

as for process isolation. i agree it's a better way of doing things for most scenarios but if you want to build a low latency system there is a lot of overhead in having to serialise objects and pass them across a process boundary. at some stage, it would be nice to be able to build a system in node.js that used many cores on one machine and is able to efficiently share objects/data between them without a lot of locking and contention. as far as i can see the only way of being able to do this REALLY fast is to use threads and manage contention using volatile variables or something like that. i have been doing a lot of reading around the LMAX disruptor pattern which is able to get orders of magnitude better performance than a traditional process or thread/mutex based solution. i'd love to see node.js/v8 support for something like this in the future, although i can see that it would be very difficult to achieve.

more info on distruptor here:

http://code.google.com/p/disruptor/ 

[Jorge]

On Apr 3, 2012, at 8:21 PM, billywhizz wrote:

> thanks for the feedback ben.
>
> as for process isolation. i agree it's a better way of doing things for most scenarios but if you want to build a low latency system there is a lot of overhead in having to serialise objects and pass them across a process boundary. at some stage, it would be nice to be able to build a system in node.js that used many cores on one machine and is able to efficiently share objects/data between them without a lot of locking and contention. as far as i can see the only way of being able to do this REALLY fast is to use threads and manage contention using volatile variables or something like that. i have been doing a lot of reading around the LMAX disruptor pattern which is able to get orders of magnitude better performance than a traditional process or thread/mutex based solution. i'd love to see node.js/v8 support for something like this in the future, although i can see that it would be very difficult to achieve.
>
> more info on distruptor here:
>
> http://code.google.com/p/disruptor/

Of course, in the meantime, you can use <https://github.com/xk/node-threads-a-gogo> :-)

It runs JavaScript in threads/pools of threads:

- almost twice as fast as node's main thread
- with several times the throughput of a cluster of nodes communicating via IPC
- needs just a fraction of the memory of a cluster
- will be even faster in the near future: it will soon pass data by reference across threads.
--
Jorge.