On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote:
> Your bench does not make sense. There is no async call at all. So there is no reason to have an _ in the streamline source.
> Streamline does not transform sync fonctions. So the Streamline version of this bench should take 3 ms.
> Callback != asynchronous
> Try again with an async call
I was trying to demonstrate the call overhead but here is an example
with some async code https://gist.github.com/2352116 again a bit
contrived because I really didn't want to spend much time on this.
streamline did close the gap a bit which is what I suspected when I
said "I will agree that for many real world cases this is a tiny piece
of the overall time". But it was still twice as slow. (node 565ms and
streamline 1049ms)
On Tue, Apr 10, 2012 at 3:37 PM, Yi Tan <yi2...@gmail.com> wrote: > you really should spend a few hours learning coffee script if the js > callback syntax make you uncomfortable
Unless coffee script fixes its "implicit local variable is global if the names match and just dont take care to not accidently name it equally" I will not touch it with a long stick.
Anyway, I find this node.js and callback arguments popping up again and again very similar to what happens when asking the PHP guys and gals why func()[1] is not a valid language construct? They get all miffed usual arguments follow, and it happens all the time again. I suppose simply because deeply within they know there is some fundamental problem, but convince themselves with far fetched arguments like "just get a larger screen" etc. at least as much as the repeated questions. Only long after the lifecycle of software solution people come, well yes that sucked didn't it? We kinda knew it all the way, but we just decided to ignore it.
Maybe you have other good examples? Ask GNOME 3 why the panel is no longer customizeable. Ask TCL what the they where thinking when they handled every integer variable as string. Ask Java why multiple inheritence was that bad after all, and all the workarounds they later needed for it. You got an Inputstream object and Outputstream object, but how to get an InputOutputStream? Ask Javascript, about 'this'. Ask terminal guys, about why terminal emulations are that complicated and never compitabitle to anything else. Ask Windows why \r\n, ask why they never ever managed to abolish drive letters. Ask Apple why \n\r Ask Linux why inotify and fanotify while both being non-satisfactory for any usecase but the single one they were designed for. etc.
So now that I annoyed every tech group there is, I better get logged of for a while :-)))
func()[1] not being allowed in PHP is just a silly deficiency in the language grammar and runtime. I "fixed" it in 2009 with a rewrite rule (right before APC in the compile chain). func()[1] -> _helper(func(), 1). I have a habit of not accepting languages the way they're given to me I guess.
Anyway I don't think that's a very good comparison. Or maybe it is because they're both easily fixable problems.
On Tue, Apr 10, 2012 at 1:14 PM, Axel Kittenberger <axk...@gmail.com> wrote: > On Tue, Apr 10, 2012 at 3:37 PM, Yi Tan <yi2...@gmail.com> wrote: > > you really should spend a few hours learning coffee script if the js > > callback syntax make you uncomfortable
> Unless coffee script fixes its "implicit local variable is global if > the names match and just dont take care to not accidently name it > equally" I will not touch it with a long stick.
> Anyway, I find this node.js and callback arguments popping up again > and again very similar to what happens when asking the PHP guys and > gals why func()[1] is not a valid language construct? They get all > miffed usual arguments follow, and it happens all the time again. I > suppose simply because deeply within they know there is some > fundamental problem, but convince themselves with far fetched > arguments like "just get a larger screen" etc. at least as much as the > repeated questions. Only long after the lifecycle of software solution > people come, well yes that sucked didn't it? We kinda knew it all the > way, but we just decided to ignore it.
> Maybe you have other good examples? > Ask GNOME 3 why the panel is no longer customizeable. > Ask TCL what the they where thinking when they handled every integer > variable as string. > Ask Java why multiple inheritence was that bad after all, and all the > workarounds they later needed for it. You got an Inputstream object > and Outputstream object, but how to get an InputOutputStream? > Ask Javascript, about 'this'. > Ask terminal guys, about why terminal emulations are that complicated > and never compitabitle to anything else. > Ask Windows why \r\n, ask why they never ever managed to abolish drive > letters. > Ask Apple why \n\r > Ask Linux why inotify and fanotify while both being non-satisfactory > for any usecase but the single one they were designed for. > etc.
> So now that I annoyed every tech group there is, I better get logged > of for a while :-)))
On Tue, Apr 10, 2012 at 9:03 PM, Marcel Laverdet <mar...@laverdet.com> wrote: > func()[1] not being allowed in PHP is just a silly deficiency in the > language grammar and runtime. I "fixed" it in 2009 with a rewrite rule > (right before APC in the compile chain). func()[1] -> _helper(func(), 1). I > have a habit of not accepting languages the way they're given to me I guess.
You are right, the problems don't compare well, but I compared the community reactions when yet another time someone new mentions it, yet another time, and everybody goes "oh no, not again. stop trolling us. you can work around this or that or thut way." but in the core its a silly deficiency.
I suppose when generators come to V8 we might see a new generation of workarounds 'ehhh I mean solutions.
Still, your bench is wrong because the two programs do different things:
* The streamline program calls socket.write from the callback of the previous socket.write. So it does proper flow control and it won't overflow output buffers. * The callback program calls socket.write in a loop, without chaining them through the callbacks. No flow control here!
So please, go back to the drawing board and come back with a fair bench.
Hint: the callback version should not run the bench with a for loop, it should transform the loop into a recursion (which is what streamline does).
On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote: > > Your bench does not make sense. There is no async call at all. So there > is no reason to have an _ in the streamline source.
> > Streamline does not transform sync fonctions. So the Streamline version > of this bench should take 3 ms.
> > Callback != asynchronous
> > Try again with an async call
> I was trying to demonstrate the call overhead but here is an example > with some async code https://gist.github.com/2352116 again a bit > contrived because I really didn't want to spend much time on this.
> streamline did close the gap a bit which is what I suspected when I > said "I will agree that for many real world cases this is a tiny piece > of the overall time". But it was still twice as slow. (node 565ms and > streamline 1049ms)
When a question rises again and again it's a good sign of problem.
To make clear I'm not in any way blame the node on it, it has tons of advantages and it's ok to have problem. Every advanced machinery have some sort of problems or limitations - it's ok.
But what's not ok - is to have false delusion, to believe that a problem is a feature, or even worse - call it "The Rails/Node way".
Because if You call the problem as it deserves - the problem - there's always room for progress and improvement. And maybe someday it will be completely fixed and become not a problem but another advantage.
But when You ignore it or believe that it's a "feature" or "the right way" - the problem always will be there, it's a way to stagnation.
Yes You can become tolerable to ugly code and buy wider screen to fit all those callbacks, but it doesn't matter. Perceptions doesn't change the objective reality, no matter how much people believe that false is true, false still and always will be the false.
So, maybe it's worth to stop call this problem a "feature"?
I think I'm done writing benchmarks. Even if I come up with a
benchmark that shows streamline is faster I'm still not going to use
it and I couldn't recommend anyone else use it either. The community
as a whole doesn't back that kind of syntax so I couldn't submit a
module to npm if I wrote it using streamline. As I said before I can't
easily run my unit tests or deploy to my server environment. From the
little that I used it, it screws up the stack trace, you get weird
errors like "Function contains async calls but does not have _
parameter" which IMO shouldn't be an error at all. And it obscures
what is really going on under the covers which you pointed out quite
well in your most recent comments.
On Apr 10, 3:24 pm, Bruno Jouhier <bjouh...@gmail.com> wrote:
> Still, your bench is wrong because the two programs do different things:
> * The streamline program calls socket.write from the callback of the
> previous socket.write. So it does proper flow control and it won't overflow
> output buffers.
> * The callback program calls socket.write in a loop, without chaining them
> through the callbacks. No flow control here!
> So please, go back to the drawing board and come back with a fair bench.
> Hint: the callback version should not run the bench with a for loop, it
> should transform the loop into a recursion (which is what streamline does).
> On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> > On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote:
> > > Your bench does not make sense. There is no async call at all. So there
> > is no reason to have an _ in the streamline source.
> > > Streamline does not transform sync fonctions. So the Streamline version
> > of this bench should take 3 ms.
> > > Callback != asynchronous
> > > Try again with an async call
> > I was trying to demonstrate the call overhead but here is an example
> > with some async codehttps://gist.github.com/2352116again a bit
> > contrived because I really didn't want to spend much time on this.
> > streamline did close the gap a bit which is what I suspected when I
> > said "I will agree that for many real world cases this is a tiny piece
> > of the overall time". But it was still twice as slow. (node 565ms and
> > streamline 1049ms)
> errors like "Function contains async calls but does not have _ > parameter" which IMO shouldn't be an error at all.
By all respect you just got little clue. This error is *good*, since it does not allow functions to "yield under your ass", which would technically be impossible in streamline anyway.
Rest of the argument now you fail with benchmarking is "because I say so.". Streamline will run in full potential since it does nothing else than to write the correct javascript for you. The only drawback is, that its syntax is not natively understood by V8 thus error messages contain different text, and if you are using some debugger, it might look a different else than what you expected.
On Tue, Apr 10, 2012 at 22:01, Joe Ferner <j...@fernsroth.com> wrote: > I think I'm done writing benchmarks. Even if I come up with a > benchmark that shows streamline is faster I'm still not going to use > it and I couldn't recommend anyone else use it either. The community > as a whole doesn't back that kind of syntax so I couldn't submit a > module to npm if I wrote it using streamline. As I said before I can't > easily run my unit tests or deploy to my server environment. From the > little that I used it, it screws up the stack trace, you get weird > errors like "Function contains async calls but does not have _ > parameter" which IMO shouldn't be an error at all. And it obscures > what is really going on under the covers which you pointed out quite > well in your most recent comments.
> On Apr 10, 3:24 pm, Bruno Jouhier <bjouh...@gmail.com> wrote: > > Still, your bench is wrong because the two programs do different things:
> > * The streamline program calls socket.write from the callback of the > > previous socket.write. So it does proper flow control and it won't > overflow > > output buffers. > > * The callback program calls socket.write in a loop, without chaining > them > > through the callbacks. No flow control here!
> > So please, go back to the drawing board and come back with a fair bench.
> > Hint: the callback version should not run the bench with a for loop, it > > should transform the loop into a recursion (which is what streamline > does).
> > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> > > On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote: > > > > Your bench does not make sense. There is no async call at all. So > there > > > is no reason to have an _ in the streamline source.
> > > > Streamline does not transform sync fonctions. So the Streamline > version > > > of this bench should take 3 ms.
> > > > Callback != asynchronous
> > > > Try again with an async call
> > > I was trying to demonstrate the call overhead but here is an example > > > with some async codehttps://gist.github.com/2352116again a bit > > > contrived because I really didn't want to spend much time on this.
> > > streamline did close the gap a bit which is what I suspected when I > > > said "I will agree that for many real world cases this is a tiny piece > > > of the overall time". But it was still twice as slow. (node 565ms and > > > streamline 1049ms)
Streamline translates its special syntax to vanilla JS with callbacks. So, if you implement a function like
function foo(x, y, _) { ... }
Normal JS modules (not written with streamline) will be able to call it as:
foo(x, y, function(err, result) { ... });
Streamline is just a tool that helps you write your code. This tool produces vanilla JS that follows the standard node callback conventions. So you can publish it to NPM, you won't be forcing anyone else to use streamline. That's like coding a module in CoffeeScript.
Regarding the stack traces, streamline reconstructs the "synchronous" stack that led to the exception. This is a big plus as the callback stack is usually not very helpful (and if you really want it, you have it with ex.rawStack).
The error message that bugs you is a feature. It ensures that all the yielding points are explicit.
Regarding performance, there is still a need for real benchmarks that compare apples with apples (code that does flow control with code that does flow control). Your half baked pseudo benches are just useless.
On Tuesday, April 10, 2012 10:01:07 PM UTC+2, Joe Ferner wrote:
> I think I'm done writing benchmarks. Even if I come up with a > benchmark that shows streamline is faster I'm still not going to use > it and I couldn't recommend anyone else use it either. The community > as a whole doesn't back that kind of syntax so I couldn't submit a > module to npm if I wrote it using streamline. As I said before I can't > easily run my unit tests or deploy to my server environment. From the > little that I used it, it screws up the stack trace, you get weird > errors like "Function contains async calls but does not have _ > parameter" which IMO shouldn't be an error at all. And it obscures > what is really going on under the covers which you pointed out quite > well in your most recent comments.
> On Apr 10, 3:24 pm, Bruno Jouhier <bjouh...@gmail.com> wrote: > > Still, your bench is wrong because the two programs do different things:
> > * The streamline program calls socket.write from the callback of the > > previous socket.write. So it does proper flow control and it won't > overflow > > output buffers. > > * The callback program calls socket.write in a loop, without chaining > them > > through the callbacks. No flow control here!
> > So please, go back to the drawing board and come back with a fair bench.
> > Hint: the callback version should not run the bench with a for loop, it > > should transform the loop into a recursion (which is what streamline > does).
> > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> > > On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote: > > > > Your bench does not make sense. There is no async call at all. So > there > > > is no reason to have an _ in the streamline source.
> > > > Streamline does not transform sync fonctions. So the Streamline > version > > > of this bench should take 3 ms.
> > > > Callback != asynchronous
> > > > Try again with an async call
> > > I was trying to demonstrate the call overhead but here is an example > > > with some async codehttps://gist.github.com/2352116again a bit > > > contrived because I really didn't want to spend much time on this.
> > > streamline did close the gap a bit which is what I suspected when I > > > said "I will agree that for many real world cases this is a tiny piece > > > of the overall time". But it was still twice as slow. (node 565ms and > > > streamline 1049ms)
On Apr 10, 4:07 pm, Axel Kittenberger <axk...@gmail.com> wrote:
> > errors like "Function contains async calls but does not have _
> > parameter" which IMO shouldn't be an error at all.
> By all respect you just got little clue. This error is *good*, since
> it does not allow functions to "yield under your ass", which would
> technically be impossible in streamline anyway.
This error happened when I tried to mix the syntax.
If I want to mix the syntax, let me, don't error out.
> Rest of the argument now you fail with benchmarking is "because I say
> so.". Streamline will run in full potential since it does nothing else
> than to write the correct javascript for you. The only drawback is,
> that its syntax is not natively understood by V8 thus error messages
> contain different text, and if you are using some debugger, it might
> look a different else than what you expected.
I just don't have time to write more benchmarks that no mater what I
come up with Bruno will find another reason why it isn't valid.
It's not just different text it's a completely different stack trace
so I would have no hope in finding out what failed, especially if it
happened in production. As far as debuggers go, the code looks
completely different not just a little different, it does give me line
numbers which is nice.
> If I want to mix the syntax, let me, don't error out.
I lets you mix it, you just have to do it correctly. E.g: this works without error:
function foo(_) { process.nextTick(_); console.log('a'); process.nextTick(function() { console.log('b'); });
}
foo(_);
Don't blame streamline for your own shortcomings. I know of its drawbacks in debugging mode, but thats about it, i get tired and angry about the FUD spread around it, and you made a ton of it.
> I just don't have time to write more benchmarks that no mater what I > come up with Bruno will find another reason why it isn't valid.
Its not like Bruno is doing an evil plot here. Since as long your benchmark does not compare apple with oranges, it will always be just as fast as vanilla written code, since in the end, it translates to vanilla code.
> Unless coffee script fixes its "implicit local variable is global if
the names match and just dont take care to not accidently name it equally" I will not touch it with a long stick.
I and a number of other coffeescripters have been bitching about this over and over. So far we haven't budged the BDFL.
However, there is a pretty simple workaround. You can use the var statement by using backticks which passes it through to the javascript: `var x;` I use this all the time. It isn't even that ugly.
If you are ignoring coffeescript because of this then that is a shame. I use absolutely nothing but coffeescript and I can't imagine living without it.
Joe your stubbornness speaks volumes. If you'd have quit everything in life after spending 10 minutes and messing up once you wouldn't get anywhere. There's an ever-growing number of supporters of this kind of technology (435 followers on github for fibers, 222 for streamline) and to not even explore it because of baseless assumptions is silly. It's not my problem if you don't want to use fibers or streamline, I don't care.. but it becomes my problem when you literally make up lies about this software. It's good and robust software, I promise. There's a one time cost to learn some simple rules about how the software works and then you can look forward to *significant* reductions in lines of code written.
On Tue, Apr 10, 2012 at 3:01 PM, Joe Ferner <j...@fernsroth.com> wrote: > I think I'm done writing benchmarks. Even if I come up with a > benchmark that shows streamline is faster I'm still not going to use > it and I couldn't recommend anyone else use it either. The community > as a whole doesn't back that kind of syntax so I couldn't submit a > module to npm if I wrote it using streamline. As I said before I can't > easily run my unit tests or deploy to my server environment. From the > little that I used it, it screws up the stack trace, you get weird > errors like "Function contains async calls but does not have _ > parameter" which IMO shouldn't be an error at all. And it obscures > what is really going on under the covers which you pointed out quite > well in your most recent comments.
> On Apr 10, 3:24 pm, Bruno Jouhier <bjouh...@gmail.com> wrote: > > Still, your bench is wrong because the two programs do different things:
> > * The streamline program calls socket.write from the callback of the > > previous socket.write. So it does proper flow control and it won't > overflow > > output buffers. > > * The callback program calls socket.write in a loop, without chaining > them > > through the callbacks. No flow control here!
> > So please, go back to the drawing board and come back with a fair bench.
> > Hint: the callback version should not run the bench with a for loop, it > > should transform the loop into a recursion (which is what streamline > does).
> > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> > > On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote: > > > > Your bench does not make sense. There is no async call at all. So > there > > > is no reason to have an _ in the streamline source.
> > > > Streamline does not transform sync fonctions. So the Streamline > version > > > of this bench should take 3 ms.
> > > > Callback != asynchronous
> > > > Try again with an async call
> > > I was trying to demonstrate the call overhead but here is an example > > > with some async codehttps://gist.github.com/2352116again a bit > > > contrived because I really didn't want to spend much time on this.
> > > streamline did close the gap a bit which is what I suspected when I > > > said "I will agree that for many real world cases this is a tiny piece > > > of the overall time". But it was still twice as slow. (node 565ms and > > > streamline 1049ms)
> Don't blame streamline for your own shortcomings. I know of its
> drawbacks in debugging mode, but thats about it, i get tired and angry
> about the FUD spread around it, and you made a ton of it.
Ok then perhaps you can fix my code because this gives me the error
and from what I can tell it looks to follow your pattern...
var net = require('net');
function foo(_) {
var socket = new net.Socket();
socket.connect(1111, 'localhost', function() {
var start = new Date();
for (var i = 0; i <= 100000; i++) {
socket.write(new Buffer([i]), _);
}
var end = new Date();
console.log("done: " + (end - start));
socket.end();
});
}
foo(_);
> > I just don't have time to write more benchmarks that no mater what I
> > come up with Bruno will find another reason why it isn't valid.
> Its not like Bruno is doing an evil plot here. Since as long your
> benchmark does not compare apple with oranges, it will always be just
> as fast as vanilla written code, since in the end, it translates to
> vanilla code.
I disagree about my benchmarks being incorrect. Benchmark 1 was to
purely compare the overhead of calling functions using traditional
methods vs streamline. Methods with callbacks are not required to have
async code in them, they just generally do. If you replace doIt with
say a getUserFromCache method where 99% of the time you get cache hits
and the function just returns the user this would be completely valid
and you would incur the penalty. But I played along and tossed in an
async call. Benchmark 2 is valid if you want to send data as fast as
possible to the other side. I would love to see this magical
benchmark that streamline is as fast or faster than node but I have
yet to see it.
By that logic we should also be using Coffeescript with it's 4,800+
followers but if you listen to any of the node core team I think you
would hear quite a different story.
On Apr 10, 6:53 pm, Marcel Laverdet <mar...@laverdet.com> wrote:
> Joe your stubbornness speaks volumes. If you'd have quit everything in life
> after spending 10 minutes and messing up once you wouldn't get anywhere.
> There's an ever-growing number of supporters of this kind of
> technology (435 followers on github for fibers, 222 for streamline) and to
> not even explore it because of baseless assumptions is silly. It's not my
> problem if you don't want to use fibers or streamline, I don't care.. but
> it becomes my problem when you literally make up lies about this software.
> It's good and robust software, I promise. There's a one time cost to learn
> some simple rules about how the software works and then you can look
> forward to *significant* reductions in lines of code written.
> On Tue, Apr 10, 2012 at 3:01 PM, Joe Ferner <j...@fernsroth.com> wrote:
> > I think I'm done writing benchmarks. Even if I come up with a
> > benchmark that shows streamline is faster I'm still not going to use
> > it and I couldn't recommend anyone else use it either. The community
> > as a whole doesn't back that kind of syntax so I couldn't submit a
> > module to npm if I wrote it using streamline. As I said before I can't
> > easily run my unit tests or deploy to my server environment. From the
> > little that I used it, it screws up the stack trace, you get weird
> > errors like "Function contains async calls but does not have _
> > parameter" which IMO shouldn't be an error at all. And it obscures
> > what is really going on under the covers which you pointed out quite
> > well in your most recent comments.
> > On Apr 10, 3:24 pm, Bruno Jouhier <bjouh...@gmail.com> wrote:
> > > Still, your bench is wrong because the two programs do different things:
> > > * The streamline program calls socket.write from the callback of the
> > > previous socket.write. So it does proper flow control and it won't
> > overflow
> > > output buffers.
> > > * The callback program calls socket.write in a loop, without chaining
> > them
> > > through the callbacks. No flow control here!
> > > So please, go back to the drawing board and come back with a fair bench.
> > > Hint: the callback version should not run the bench with a for loop, it
> > > should transform the loop into a recursion (which is what streamline
> > does).
> > > On Tuesday, April 10, 2012 5:32:45 PM UTC+2, Joe Ferner wrote:
> > > > On Apr 10, 11:12 am, Bruno Jouhier <bjouh...@gmail.com> wrote:
> > > > > Your bench does not make sense. There is no async call at all. So
> > there
> > > > is no reason to have an _ in the streamline source.
> > > > > Streamline does not transform sync fonctions. So the Streamline
> > version
> > > > of this bench should take 3 ms.
> > > > > Callback != asynchronous
> > > > > Try again with an async call
> > > > I was trying to demonstrate the call overhead but here is an example
> > > > with some async codehttps://gist.github.com/2352116againa bit
> > > > contrived because I really didn't want to spend much time on this.
> > > > streamline did close the gap a bit which is what I suspected when I
> > > > said "I will agree that for many real world cases this is a tiny piece
> > > > of the overall time". But it was still twice as slow. (node 565ms and
> > > > streamline 1049ms)
On Apr 10, 8:30 pm, Mark Hahn <m...@hahnca.com> wrote:
> > By that logic we should also be using Coffeescript with it's 4,800+
> followers but if you listen to any of the node core team I think you
> would hear quite a different story.
> Can you please elaborate on what the core team has said about coffeescript?
I think it was episode 10 of nodeup (http://nodeup.com/ten) where they
railed on it for 10 minutes. There is also a pull request (https://
github.com/joyent/node/pull/2472) where they complain about it that is
pretty funny.
> > Don't blame streamline for your own shortcomings. I know of its
> > drawbacks in debugging mode, but thats about it, i get tired and angry
> > about the FUD spread around it, and you made a ton of it.
> Ok then perhaps you can fix my code because this gives me the error
> and from what I can tell it looks to follow your pattern...
> var net = require('net');
> function foo(_) {
> var socket = new net.Socket();
> socket.connect(1111, 'localhost', function() {
> var start = new Date();
> for (var i = 0; i <= 100000; i++) {
> socket.write(new Buffer([i]), _);
> }
> var end = new Date();
> console.log("done: " + (end - start));
> socket.end();
> });
> }
> foo(_);
> > > I just don't have time to write more benchmarks that no mater what I
> > > come up with Bruno will find another reason why it isn't valid.
> > Its not like Bruno is doing an evil plot here. Since as long your
> > benchmark does not compare apple with oranges, it will always be just
> > as fast as vanilla written code, since in the end, it translates to
> > vanilla code.
> I disagree about my benchmarks being incorrect. Benchmark 1 was to
> purely compare the overhead of calling functions using traditional
> methods vs streamline. Methods with callbacks are not required to have
> async code in them, they just generally do. If you replace doIt with
> say a getUserFromCache method where 99% of the time you get cache hits
> and the function just returns the user this would be completely valid
> and you would incur the penalty. But I played along and tossed in an
> async call. Benchmark 2 is valid if you want to send data as fast as
> possible to the other side. I would love to see this magical
> benchmark that streamline is as fast or faster than node but I have
> yet to see it.
railed on it for 10 minutes. There is also a pull request (https:// github.com/joyent/node/pull/2472) where they complain about it that is pretty funny.
They didn't trash coffeescript, they were trashing the idea of using it for node core. There is a big difference.
Not sure if 10 was it, that's the only one I could find from searching
the text of the episodes. They are definitely not coffeescript fans if
you listen through a couple of the episodes.
On Apr 10, 9:13 pm, Mark Hahn <m...@hahnca.com> wrote:
> railed on it for 10 minutes. There is also a pull request (https://
> github.com/joyent/node/pull/2472) where they complain about it that is
> pretty funny.
> They didn't trash coffeescript, they were trashing the idea of using it for
> node core. There is a big difference.
> They are definitely not coffeescript fans if you listen through a
couple of the episodes.
I'll take your word for it. I can see where people working at the core level may not be excited about higher-level languages. These same people use c++.
I'm working at the app level and I have 10,000 lines of coffeescript. I can't imagine coding all that in javascript.
NodeUp is not exclusively node core committers nor has it ever included the full list of committers so the views represented should not be viewed as "core".
While our personal views about coffeescript may be negative node is committed to support (but not include or bundle) the use compile target languages. No one will ever have the level of support that javascript has but we won't be going out of our way to disable it.
GitHub Followers are a good indication that something is interesting, they should not be considered supporters or an accurate representation of adoption. For instance:
express: 5,823 npm: 2,605
There is no question that npm has wider adoption than express. While express is hugely popular it *requires* npm to be installed :)
One thing I've noticed is that GitHub followers mean you have something interesting, not that you have something they use. My suspicion is that many followers don't actually use the project they are following but find it interesting enough to keep an eye on.
The closest metric we have for adoption is "depended on" http://search.npmjs.org/. But, this metric also falls short. For instance, depending on express is an indicator of how well it's been adopted by people building plugins, same with connect, but not a good indicator for it's actual adoption since web frameworks are mainly used by applications which are not pushed to the registry. Similarly, coffeescript has a larger representation that it's actual usage since *any* module written in coffeescript includes it as a dependency.
Fibers has about 12 modules that depend on it. Streamline has about 4. If you want to compare that against common utilities that use standard node practices for async (request:420,socket.io.202,redis:175) it's quite low. Even comparing fibers and streamline to popular flow control libraries that use standard node practices (async:354,step:64) fibers and streamline have sparse adoption.
Not saying nobody uses them or that they don't have a bit of a following, but by the actual numbers we have their adoption is quite limited compared with standard node practices, especially when compared to how vocal they are championed on this list whenever a thread like this appears.
It would seem that the majority of node developers are content with standard callbacks and find ways to deal with them and are not running towards blocking style abstractions, they just don't care enough to yell a lot on every thread like the authors of alternatives.
On Apr 10, 2012, at April 10, 20126:26 PM, Joe Ferner wrote:
> Not sure if 10 was it, that's the only one I could find from searching > the text of the episodes. They are definitely not coffeescript fans if > you listen through a couple of the episodes.
> On Apr 10, 9:13 pm, Mark Hahn <m...@hahnca.com> wrote: >>> I think it was episode 10 of nodeup (http://nodeup.com/ten) where they
>> railed on it for 10 minutes. There is also a pull request (https:// >> github.com/joyent/node/pull/2472) where they complain about it that is >> pretty funny.
>> They didn't trash coffeescript, they were trashing the idea of using it for >> node core. There is a big difference.
On Apr 10, 2012, at April 10, 20126:36 PM, Mark Hahn wrote:
> > They are definitely not coffeescript fans if you listen through a couple of the episodes.
> I'll take your word for it. I can see where people working at the core level may not be excited about higher-level languages. These same people use c++.
The vast majority of commits to node are in JavaScript. As of 0.5 the majority of C++ heavy lifting is in libuv which has a different committer list (although there is some overlap).
> I'm working at the app level and I have 10,000 lines of coffeescript. I can't imagine coding all that in javascript.
I have about 10 times that in javascript and it's quite easy, when things break I even get line numbers :)
On Tue, Apr 10, 2012 at 18:49, Mikeal Rogers <mikeal.rog...@gmail.com> wrote: > NodeUp is not exclusively node core committers nor has it ever included the full list of committers so the views represented should not be viewed as "core".
I think Felix and I are the only core committers that have been on NodeUp.
> While our personal views about coffeescript may be negative node is committed to support (but not include or bundle) the use compile target languages.
Node is committed to supporting JavaScript programs. How you write those JavaScript programs is your own business.
In retrospect, I think require.extensions was a mistake. But it's a mistake we're stuck with. It mostly stays out of the way, which is good, I suppose.
> One thing I've noticed is that GitHub followers mean you have something interesting, not that you have something they use. My suspicion is that many followers don't actually use the project they are following but find it interesting enough to keep an eye on.
It also indicates that you need to know when to update a thing. npm gets updated whenever you get a new version of node. However, a lot of people post bugs with Express, contribute to it, etc. It's a run-time dependency, not a dev-time one.
The primary major goal of the Node.js project is to make easy to build fast network programs. Making things simpler makes them easier, and hiding the true nature of IO only makes it harder in the long run.
It is not our goal to fix JavaScript syntax (that's tc-39's job). It is not our goal to make programs look blocking when they are in fact parallel (that's a bad complexity trade-off).
> I'll take your word for it. I can see where people working at the core level may not be excited about higher-level languages. These same people use c++.
We are excited about writing high performance network programs. JavaScript is a very easy and effective way to do that. Most of Node.js is in JavaScript. JavaScript is a higher-level language. We're very interested in it.
