Modest proposal to make async optional in Node.js

[Olivier Lalonde]

I'm sorry if this has been discussed before, but I couldn't find anything. This a modest proposal to introduce sync APIs in Node.js

A lot of people would like to use Javascript for their web backend, but don't want to program in an async style (I believe those reasons have already been discussed at length). 

As it stands right now, it is practically impossible to program in Node.js in a sync style, since most core modules and native extensions only provide an async interface. 

I believe there would be an easy way to change the status quo without impacting developers who chose to adhere to a strict async style. The solution I propose is simply a pattern for writing I/O APIs: every I/O call should be async unless no call back is supplied, in which case the I/O call should be sync and use return / throw statements instead of calling a callback.

There is probably a flaw in my reasoning since I'm probably not the first one to come up with this pattern. That being said, I think it would be an elegant way to make both async/sync fans happy while keeping all the backend JS community focused on one project rather than fragmenting the community in multiple CommonJS server implementations.

Thoughts?

[Mark Hahn]

>   every I/O call should be async unless no call back is supplied, 

This would clobber my app.  Many times I invoke something without a callback.  I know it will happen but not when and I don't care.  Logging is a good example.  I don't wait around for log write callbacks.

You know that you couldn't do anything async like serve web pages, right?  It would basically only be useful for command-line utilities or a website accessed by only one person.

P.S.  I predict no one will touch this with a ten-foot pole.

[Olivier Lalonde]

> Many times I invoke something without a callback.

I didn't think about this. It seems this problem would only affect "output" functions. Not convinced it is a deal breaker yet, I'll try to come up with some workarounds.

> You know that you couldn't do anything async like serve web pages, right?

I'm aware of that. Writing sync web apps would imply using one process/worker by request like other popular languages do (PHP/Ruby/etc.). I think it is still interesting to use Javascript for backend development even without the async stuff.

[Mark Hahn]

>   I think it is still interesting to use Javascript for backend development even without the async stuff. 

I'm sure there will be sync web servers based on javascript.  Node isn't going to be one though.  It goes against the grain of everything node is.  And I wouldn't want node developers spending time supporting something like this.  I (we) need them to continue what they are doing.

You know that you can run V8 javascript from PHP now, right?  I would bet there are ways to run javascript cgi from apache.

[Bruno Jouhier]

This would be a total nightmare. Today you can spot if a module uses sync calls by doing a grep Sync. With something like this we'd end up having all sorts of sync modules that kill the event loop and it would be very hard to find out where the sync calls are buried.

There *are* solutions to the async problem. Things like streamline.js or fibers/futures. If you find it too difficult to write code with callbacks, you should give these tools a try first.

IMO, sync calls should even have been banned from the start. Or at least, libraries that use Sync calls under the hood should be required to advertise it so that people don't run into performance issues with them (and I will streamline them if I need them).

Bruno

[Isaac Schlueter]

We're definitely not going to change node in the way you suggest.

Async is the default by design. Mark Hahn expressed the reasons quite
well, so I won't reiterate them.

Sync methods look different because they *are* different.
Automatically switching from async to sync would be a violation of
Node's core principles, and a disaster.

"Node is not pretending it is blocking when it is not."
http://www.mikealrogers.com/posts/the-way-of-node.html

> --
> 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

[Nuno Job]

>> I'm sorry if this has been discussed before, but I couldn't find anything.

It has, probably 10 times a month. :) No joke!

Nuno

[shawn wilson]

On Apr 2, 2012 3:19 AM, "Nuno Job" <nunojo...@gmail.com> wrote:
>
> >> I'm sorry if this has been discussed before, but I couldn't find anything.
>

> It has, probably 10 times a month. :) No joke!
>

Also, 'use the right tool for the job'. No one seems to get this.

I'd start killing if I ever saw a js library talking about cv.conv (or some similar continuation mechanism). I started using node because I got tired of writing a dozen languages to display a web page but along the way started liking not having an event framework (or threads) or dealing with mod_perl apache threads or fcgi and dealing with a message queue (or an event module and memcache - it works :) ) to do cool things.

Lastly, you can embed js, both seamonkey and v8 in perl (and probably other languages). You can use a queue or rpc or gearman etc to communicate between processes. Which lets you to program in anything to get the job done.

[Oliver Leics]

Asynchronicity in Node can not be made optional as it is (by design)
the default.

On Mon, Apr 2, 2012 at 4:20 AM, Olivier Lalonde <olal...@gmail.com> wrote:
> I believe there would be an easy way to change the status quo without
> impacting developers who chose to adhere to a strict async style. The
> solution I propose is simply a pattern for writing I/O APIs: every I/O call
> should be async unless no call back is supplied, in which case the I/O call
> should be sync and use return / throw statements instead of calling a
> callback.

Please, have a look at streamline.js
https://github.com/Sage/streamlinejs

It kind of reveres your proposed solution by giving every async
function the same callback that turns the async function into a sync
function (aka: you can write code that looks synchronous)

Short example:

var s = fs.stat(path, _)
console.log(s.size)

The underscore "_" is the callback you have to give to every async
function to turn it into a function that behaves like a synchronous
one.

I would really like to know if that might work for you.

[Axel Kittenberger]

> I'm aware of that. Writing sync web apps would imply using one
> process/worker by request like other popular languages do (PHP/Ruby/etc.). I
> think it is still interesting to use Javascript for backend development even
> without the async stuff.

Since Node/V8 has a rather longish startup time, this would be the
horrors for performance.

I suggest simply using streamline, your code will feel like writing Sync!

[Axel Kittenberger]

> Sync methods look different because they *are* different.

'xcept require...

[Michael Nisi]

I think the Sync alternative functions in core should go entirely.
They clutter APIs (and mentalities).

[Chakrit]

> It goes against the grain of everything node is.

I'm gonna second that. And besides, I imagine it shouldn't that hard
to roll a thin sync interface over the node core APIs using something
like fibers (https://github.com/laverdet/node-fibers)

[dhruvbird]

I think that the sync API is useful (and I extensively used it) for
shell scripts mainly.

Especially the following API *should* (in my opinion) have sync
alternatives (maybe a separate module so that there is NO confusion
what-so-ever).

1. Filesystem (already exists)
2. SQL (sqlite/mysql/pg/etc...) - I don't think all have sync
alternatives
3. http (basic implementation: https://github.com/dhruvbird/http-sync
)
4. Basically [3] speaks about blocking network calls

IMHO, if you want to implement anything that isn't reactive to user
input (something like a batch process), then sync APIs are much
cleaner to work with. On the plus side, if you are invoking these API
many times (for example processing wikipedia pages for every day hit
counts), then the sync API would probably have a smaller constant
overhead per call.

Regards,
-Dhruv.

On Apr 2, 5:27 am, Michael Nisi <michael.n...@gmail.com> wrote:
> I think the Sync alternative functions in core should go entirely.
> They clutter APIs (and mentalities).
>
>
>
>
>
>
>
> On Mon, Apr 2, 2012 at 10:53 AM, Oliver Leics <oliver.le...@gmail.com> wrote:
> > Asynchronicity in Node can not be made optional as it is (by design)
> > the default.
>

[Oleg Podsechin]

Async is a lower level of abstraction than sync, so having sync versions of existing calls wouldn't be as useful as it may first seem. 

For example, to make an HTTP request and read data from it, you would still need to make multiple calls: first to make the request, then upon receiving the socket event and after that for every data event. In fact, you wouldn't even be able to handle errors in a completely synchronous manner, since the error event could be fired instead of the socket event and you would have no (easy) way to wait for both in synchronous code.

Now, if you still want to achieve what you're asking for, there's the node-sync library (https://github.com/0ctave/node-sync) which modifies the Function prototype.

If however you want to work at a higher level of abstraction with an API designed to be synchronous from the start, you should check out my Common Node project (https://github.com/olegp/common-node). The library also addresses the issue of fragmentation that you mention by making it possible to run the same code on RingoJS and other CommonJS compatible platforms.

Oleg

[Tim Caswell]

Node is non-blocking and will always be.  That's the core concept of node.

However there are other use cases.  I believe the original question was asking if there was a way to have a blocking system (which is simpler in many respects), but only diverge from node as much as required.

The one question I have with such a suggestion is how much code do you expect to share with the node ecosystem?  Anything that does I/O or uses timers won't be portable across the systems.  About all that can be shared is pure-js computation (like most of the code in node's path module).  All that's required to achieve this level of compatibility is to use a es5 javascript engine.

Yes blocking code is simpler, not just in terms of avoiding all the callbacks.  Take back-pressure in streams, for example.  In a blocking system, you're blocked till the kernel can consume the data.  Instance bac-kpressure built-in without needing drain and resume.  You system would be limited to doing one thing at a time, but often that's ok, especially for shell-script type use cases.

Read up on binding to V8 (or spidermonkey or javascript-core) and start to make such a system.  libuv won't be much good except for maybe cross-platform sync fs.  The pure JS modules from node can be used mostly as-is.

[Mark Hahn]

>  The pure JS modules from node can be used mostly as-is. 

The only one I can thing of is underscore.

[Tim Caswell]

Fibers aren't blocking.  They are faux blocking.  If the process was really blocked it wouldn't be able to work on other stuff.  And you can do fibers in node today, just be aware of the tradeoffs and concurrency gotchas involved.

My recommendation is to not use fibers or code transforms like streamline, or even coffeescript till your first understand the simple callback based approach of raw node with vanilla javascript.  Then once you're mastered that, if the other tools make you more productive, then by all means use them if you want to.  Adding abstractions is always a poor substitute for understanding what's going on.  Callbacks aren't that hard to understand.  Anyone serious about writing large servers in nodejs should do themselves a favor and learn the basics before reaching for tools that "ease the pain".  Tools are tools, not magic.

On Mon, Apr 2, 2012 at 1:18 PM, Bryan Donovan <brdo...@gmail.com> wrote:

The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace.  I've never tried it myself though.

BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber support.  See Sinatra::Synchrony (https://github.com/kyledrake/sinatra-synchrony) and Goliath (http://www.igvita.com/2011/03/08/goliath-non-blocking-ruby-19-web-server/).  They both work very well, with pure synchronous code style.

Bryan

--
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

[Oliver Leics]

On Mon, Apr 2, 2012 at 8:33 PM, Tim Caswell <t...@creationix.com> wrote:
> My recommendation is to not use fibers or code transforms like streamline,
> or even coffeescript till your first understand the simple callback based
> approach of raw node with vanilla javascript.  Then once you're mastered
> that, if the other tools make you more productive, then by all means use
> them if you want to.  Adding abstractions is always a poor substitute for
> understanding what's going on.  Callbacks aren't that hard to understand.
> Anyone serious about writing large servers in nodejs should do themselves a
> favor and learn the basics before reaching for tools that "ease the pain".
> Tools are tools, not magic.

This can't be stressed too often.

I wonder if the OP is still around?

[Ben Noordhuis]

I suspect that the OP is congratulating himself on a well-executed
April Fools' joke...

[Bryan Donovan]

The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace.  I've never tried it myself though.

BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber support.  See Sinatra::Synchrony (https://github.com/kyledrake/sinatra-synchrony) and Goliath (http://www.igvita.com/2011/03/08/goliath-non-blocking-ruby-19-web-server/).  They both work very well, with pure synchronous code style.

Bryan

On Apr 1, 2012, at 7:49 PM, Olivier Lalonde wrote:

[Mark Hahn]

>  I suspect that the OP is congratulating himself on a well-executed
April Fools' joke...

Damn, you're probably right.

[Axel Kittenberger]

> The one question I have with such a suggestion is how much code do you
> expect to share with the node ecosystem?

I suppose if the answer is zero, this is what I've also been looking
for! A syncronous javascript engine for little syncronous scripting
tasks. Not web-serving, not web-scale etc. Just some routine tasks to
calculate. It just doesn't exist yet. But honestly this is nothing
node.js should care about. Pulling together the V8 into a syncronous
script executer isn't hard, the V8 comes even with a prebuild demo
console. The hard part is establishing an alive ecosystem around that,
and I don't see that coming. As we know from other language, language
is one part, a sized standards library and solutions ecosystem is
another, and the second is difficult to pull off. Node.JS has an alive
ecosystem, and so far its simpler to workaround the async style for
that one, rather than trying to set up an alternative ecosystem.

PS: I'll just pretend it isn't an April fools...

[Alexey Petrushin]

We already have it with fibers, synchronous code can look like this http://alexeypetrushin.github.com/synchronize 

It's also possible to write synchronized wrappers for all node core libraries (say name it like `fs-sync`, `dns-sync`) and in the code it will looks like it's just an usual synchronous methods.

But, do You really need it? That's the question. Tools like fibers allows You to cut 90% of fat caused by async functions, and remaining 10% are usually too small problem to care about it.

[Tim Caswell]

Fibers are not blocking.  This is not the same thing.  If the issue is that writing callbacks is hard and it's easier to reason about multiple stacks, threads, or other techniques that appear blocking but really are not, then sure use fibers.  But like I already stated.  True blocking is an entirely different model.  It's much simpler, but much less parallel.

--

[Angel Java Lopez]

I see (minor?) points to have a Node.js with "buit-in" sync support:

- Easy Windows support (V8 should be compiled)

- Azure support

- Leverage of NPM

- Leverage the current ecosystem (that is, it is not needed to build an alternative ecosystem)

instead of having V8, or other engines.

I see such Node.js as "Ruby for Javascript" ;-) (even with similar problems like global lock in Ruby) (and with better package management, without the need of gemsets)

[Alexey Petrushin]

Yes, surely fibers aren't true blocking system. 

I just thought that the implicit intention in this discussion is not to actually get the true blocking system but mainly eliminate callback burden.

And Yes, Fibers are non-blocking and that exactly the reason I love it - because it allows You to get both - performance of async code and simplicity of synchronous code. You get the best from both of worlds.

If You need true blocking system then Yes, fibers aren't option.

[Glenn Block]

+1

Sent from my Windows Phone

---

From: Tim Caswell
Sent: 4/2/2012 11:34 AM
To: nod...@googlegroups.com
Subject: Re: [nodejs] Re: Modest proposal to make async optional in Node.js

Fibers aren't blocking.  They are faux blocking.  If the process was really blocked it wouldn't be able to work on other stuff.  And you can do fibers in node today, just be aware of the tradeoffs and concurrency gotchas involved.

My recommendation is to not use fibers or code transforms like streamline, or even coffeescript till your first understand the simple callback based approach of raw node with vanilla javascript.  Then once you're mastered that, if the other tools make you more productive, then by all means use them if you want to.  Adding abstractions is always a poor substitute for understanding what's going on.  Callbacks aren't that hard to understand.  Anyone serious about writing large servers in nodejs should do themselves a favor and learn the basics before reaching for tools that "ease the pain".  Tools are tools, not magic.

On Mon, Apr 2, 2012 at 1:18 PM, Bryan Donovan <brdo...@gmail.com> wrote:

The Ace lib does this, via some Fiber stuff. https://github.com/maccman/ace.  I've never tried it myself though.

BTW, with ruby 1.9 you can handle lots of requests per process via native Fiber support.  See Sinatra::Synchrony (https://github.com/kyledrake/sinatra-synchrony) and Goliath (http://www.igvita.com/2011/03/08/goliath-non-blocking-ruby-19-web-server/).  They both work very well, with pure synchronous code style.

Bryan

On Apr 1, 2012, at 7:49 PM, Olivier Lalonde wrote:

> Many times I invoke something without a callback.

I didn't think about this. It seems this problem would only affect "output" functions. Not convinced it is a deal breaker yet, I'll try to come up with some workarounds.

> You know that you couldn't do anything async like serve web pages, right?

I'm aware of that. Writing sync web apps would imply using one process/worker by request like other popular languages do (PHP/Ruby/etc.). I think it is still interesting to use Javascript for backend development even without the async stuff.

On Monday, April 2, 2012 10:20:01 AM UTC+8, Olivier Lalonde wrote:

I'm sorry if this has been discussed before, but I couldn't find anything. This a modest proposal to introduce sync APIs in Node.js

A lot of people would like to use Javascript for their web backend, but don't want to program in an async style (I believe those reasons have already been discussed at length). 

As it stands right now, it is practically impossible to program in Node.js in a sync style, since most core modules and native extensions only provide an async interface. 

I believe there would be an easy way to change the status quo without impacting developers who chose to adhere to a strict async style. The solution I propose is simply a pattern for writing I/O APIs: every I/O call should be async unless no call back is supplied, in which case the I/O call should be sync and use return / throw statements instead of calling a callback.

There is probably a flaw in my reasoning since I'm probably not the first one to come up with this pattern. That being said, I think it would be an elegant way to make both async/sync fans happy while keeping all the backend JS community focused on one project rather than fragmenting the community in multiple CommonJS server implementations.

Thoughts?

[Tim Caswell]

Alright we're all in agreement.  I love when that happens!  So to summarize:

 - Node is non-blocking and at the core uses callbacks and event emitters to handle the control-flow.
 - Fibers, code rewriters, and all other forms of faux blocking are technically compatable with node as well as giving the appearance of blocking.  They are powerful tools as long as you are aware it's not what it appears on the surface.
 - True blocking is not compatable with node except for javascript modules that don't do any I/O.  A fork or node or another project that uses some node code, but is truly blocking could be made. It's questionable how much code and ecosystem can really be shared.

--

[Matthew Hazlett]

It's easy to write JS in async, node gives you "event".

Here's an example.
http://www.pastebucket.com/1981

On 4/1/2012 10:20 PM, Olivier Lalonde wrote:

I'm sorry if this has been discussed before, but I couldn't find anything. This a modest proposal to introduce sync APIs in Node.js

A lot of people would like to use Javascript for their web backend, but don't want to program in an async style (I believe those reasons have already been discussed at length). 

As it stands right now, it is practically impossible to program in Node.js in a sync style, since most core modules and native extensions only provide an async interface. 

I believe there would be an easy way to change the status quo without impacting developers who chose to adhere to a strict async style. The solution I propose is simply a pattern for writing I/O APIs: every I/O call should be async unless no call back is supplied, in which case the I/O call should be sync and use return / throw statements instead of calling a callback.

There is probably a flaw in my reasoning since I'm probably not the first one to come up with this pattern. That being said, I think it would be an elegant way to make both async/sync fans happy while keeping all the backend JS community focused on one project rather than fragmenting the community in multiple CommonJS server implementations.

Thoughts?

[Chris Rhoden]

This is amazing.

--
chrisrhoden

[AntZ]

There are async lib that helps do things synchronously. Example is:

async.series([
function1,
function2,
function3
]);

Making node optionally syncronous is certainly a stupid thing, node
made syncronous will be PHP. Why not to use PHP to make things
synchronously?

Sometimes authors do another stupid thing by making syncronous things
looks to be asyncronous. There is XML parser that is used like this

var parser = new GreatXmlParser;
parser.parse(xml, function onFinished(err, doc) {...});

Why not just return doc in parse? I never believe XML parsing in
memory is asyncronous. I am not pointing to the real parser, just
pointing that sometimes syncronous things should be syncronous.

[henry....@sharelatex.com]

perhaps you should look at icedcoffeescript which has the await keyword. I've never used it but it may be of help.

[Axel Kittenberger]

> Why not to use PHP to make things synchronously?

Because Javascript > PHP === true;

[Angel Java Lopez]

Why not PHP? Because Node sync could leverage NPM, Javascript ecosystem, and NodeJs ecosystem. PHP will be "another tier/language" over all that. 

Ah! Yes!!! Alex K just wrote "Javascript > PHP" ;-)

I could write console utilities or general libraries in Javascript in a easier way, instead of relying on bare V8 (no NPM, no download/run experience in Windows, fragmented community?.. )

One ring to rule them all ... and I see Node.js the candidate ring in Javascript world (Share or Mordor? ;-) the "Ruby for Javascript"

[AntZ]

> > Why not to use PHP to make things synchronously?
>
> Because Javascript > PHP === true;

I node go syncronous, then fairwell node.
Forunately it will never happen

[alessio_alex]

Node is not the "Ruby of JavaScript", Node is Node.

If you like the syntax of Ruby, try CoffeeScript.

If you want blocking-style code, use libraries that abstract stuff
(but like Tim said, the code will just look "sync" at the surface).

[Angel Java Lopez]

Sync node will not kill async node. Is like saying "GUI/Multithread PHP will kill Web PHP".

Lot of people will still use async node.

But a sync-flavor io libs could nurture another set of projects. Let the community decide.

Project example? I don't sure, but maybe compilers, interpreters, or a Redis-like servers (redis serialize income requests, don't use async, AFAIK). Again, the community will decide.

The only blocking issue (that is, for people that want to consume node.js and not struggle with modify/fork it, or switch to another engine) is missing io sync libs ready to use. The initial proposition in this thread could be a bit intrusive in the existing core libs. It could be easier to have explicitly different require('sync<whatever>") for the every core (precompiled, builtin) async module/function.

Yes, Node is Node. I wrote "Ruby of Javascript" not for the syntax, I mean: the community and ecosystem.

Angel "Java" Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

[Bradley Meck]

I would take a look at SilkJS.

[shawn wilson]

ya know the cool thing about open source? if you want a feature - you
can write it yourself! the core team has said push('again').join(' and
') that this is not a feature they will add which probably means it
probably won't be done.

but, hey, this has become a reddit post - stupidest comment generates
the most response. congrats!

[Axel Kittenberger]

On Fri, Apr 6, 2012 at 4:07 PM, Bradley Meck <bradle...@gmail.com> wrote:
> I would take a look at SilkJS.

Oh thats nice to see someone is putting some effort in that! Next time
I will take a serious look at SilkJS for some scripting tasks rather
than working around node.js async style, when the job at hand is
synchronous, but I want to do it in javascript nevertheless. So far it
just never has been a hugh problem to workaround.

I'm sure there is quite a place and need for syncronos
Javscript/Shell, it just has nothing to do with node.JS. I'm just not
sure the needs are large enough to develop a satisfactory ecosystem
around it.

[Axel Kittenberger]

On Fri, Apr 6, 2012 at 5:23 PM, shawn wilson <ag4v...@gmail.com> wrote:
> ya know the cool thing about open source? if you want a feature - you
> can write it yourself! the core team has said push('again').join(' and
> ') that this is not a feature they will add which probably means it
> probably won't be done.
>
> but, hey, this has become a reddit post - stupidest comment generates
> the most response. congrats!

Boring sermon and an insult. Most useless post in this thread so far.

[Scott González]

On Fri, Apr 6, 2012 at 1:21 PM, Axel Kittenberger <axk...@gmail.com> wrote:

I'm sure there is quite a place and need for syncronos
Javscript/Shell, it just has nothing to do with node.JS. I'm just not
sure the needs are large enough to develop a satisfactory ecosystem
around it.

There's already a project for portable, synchronous shell scripting in node: https://github.com/arturadib/shelljs

[Bradley Meck]

If this is supposed to be sarcasm it is poorly presented. I work full time in and love Node, but some people want other things. Find the tool for the job. I prefer Node, but informing the community of all things available such that we can examine and learn from their strengths is a valuable asset. Never, ever, ignore competition or the desires of people even if you choose in the end to disagree.

Cheers,

Bradley

[Axel Kittenberger]

If "sarcasm" is poorly presented, it propably never was sarcasm. I
agree, thus just reread it in assuming that please.

[shawn wilson]

On Fri, Apr 6, 2012 at 15:15, Axel Kittenberger <axk...@gmail.com> wrote:
> If "sarcasm" is poorly presented, it propably never was sarcasm. I
> agree, thus just reread it in assuming that please.
>
> On Fri, Apr 6, 2012 at 8:30 PM, Bradley Meck <bradle...@gmail.com> wrote:
>> If this is supposed to be sarcasm it is poorly presented. I work full time
>> in and love Node, but some people want other things. Find the tool for the
>> job. I prefer Node, but informing the community of all things available such
>> that we can examine and learn from their strengths is a valuable asset.
>> Never, ever, ignore competition or the desires of people even if you choose
>> in the end to disagree.
>>

nah, he wasn't being sarcastic. but to have the most useless post in a
pretty useless thread is a honor. thanks for the props axel :)

ps - i think some don't like hearing the truth of things they think
they'll be able to change (ie, getting more sync put into the core of
node).

[Oleg Podsechin]

But a sync-flavor io libs could nurture another set of projects. Let the community decide.

I think it's clear that sync I/O won't be going into Node core. That being said, I agree that a set of standard sync I/O APIs would be very useful indeed. It would help unify the currently fragmented efforts and allow for innovation higher up the stack.

Would there be interest from others in setting up a separate group, say "nodejs-sync", where discussion about such a set of APIs could take place? 

The added benefit would be that any posts on the topic of sync I/O could be redirected there, keeping this group's signal to noise ratio high.

Oleg

[Mikeal Rogers]

That's kind of what commonjs was. All the sync server side js implementations were there. 

Is it still active?

Are you specifically wanting "blocking js that is not commonjs"?

Saying "nodejs-sync" is a little silly since synchronous APIs would be entirely incompatible with the rest of node. Would be better to create a new name, new flag to fly under, if you want such a fork to gain momentum.

-Mikeal

[Oleg Podsechin]

CommonJS had a much more ambitious goal of defining APIs "that handle many common application needs ... across different JavaScript interpreters and host environments" (quoting commonjs.org).

I'm not proposing a fork of Node, but rather a place where developing for Node using a synchronous style could be discussed without upsetting anyone.

[Martin Wawrusch]

I am feeling upset actually. I think I never posted anything in all those sync related threads, but this thread tipped it for me.

You know the what's the best way to kill something great? To add features that destroy its identity. The moment you add things like sync to node you blur the message, node.js becomes fuzzy, neither fish nor meat, impossible to explain in one sentence.

Even worse you complicate things enormously for all the newbies that we need to bring to the platform to make it really succeed. Node needs to cross the chasm, and this is not helping, and I am sick of discussing the same stuff over and over again.

My 2 cents and I apologize if I offended anyone.

On Sat, Apr 7, 2012 at 1:38 PM, Oleg Podsechin <oleg.po...@gmail.com> wrote:

CommonJS had a much more ambitious goal of defining APIs "that handle many common application needs ... across different JavaScript interpreters and host environments" (quoting commonjs.org).

I'm not proposing a fork of Node, but rather a place where developing for Node using a synchronous style could be discussed without upsetting anyone.

--

[Mikeal Rogers]

On Apr 7, 2012, at April 7, 20121:38 PM, Oleg Podsechin wrote:

> I'm not proposing a fork of Node, but rather a place where developing for Node using a synchronous style

that's called a fork :)

[Marcel Laverdet]

I don't get it if people want sync stuff why not just use one of the many sync modules out there. This argument is like talking about putting redis in core what's going on?

[Nuno Job]

*applause*

[Oliver Leics]

On Sun, Apr 8, 2012 at 1:55 AM, Marcel Laverdet <mar...@laverdet.com> wrote:
> talking about putting redis in core

awesome idea

> what's going on?

;-)

[Angel Java Lopez]

Hi people!

Martin, I understand your argument. And yes, that is the kind of argument I would prefer to read in this thread. Usually, I don't participate in this list, I'm usually a lurker ;-)

But.... There are sync IO functions in node core. It's not the case:

- Node is async by principle AND it don't support sync IO, sync IO support is incompatible with node

The AND is not the case. There is sync IO in node core. And I didn't see it killed node or that fact hurting the CURRENT identity of node. I read your argument as: it could hut the FUTURE identity of node.

Node is 0.x, under constant flux. The initial proposal (as far as I understand it) it was directed "to iron" the core to have, for every async func, a sync counterpart, wo/having to fork, to have another software to keep an eye on it, etc... I prefer to have a different require('fssync") or something like that. If that could be done using a module not in core, welcome! But, could all core async functions have a sync-flavor variant using user modules, wo/convoluted implementations, and with automatic Unix/Linux/Windows/other platform support? with no npm install problems? I liked icecoffescript, great idea! But I feel it adds "another brick on the wall".

Then, back to your argument: yes, adding sync could hurt node.js identity. But, sync is already in node.js. Then, the argument is: you and others, want to see Node.js crossing the chasm with new developers embracing async. Your "fear": adding sync open the door to a "cross the chasm" with lots of new devs using sync. Sorry if I misinterpreted your argument,  or if I was not able to reproduce exactly in my bad English.

As a developer, newbie or not, I prefer to have the option. The proposal of this thread is, to me, an "ironing and completing" of an existing "feature" without having another community, fork, etc.. or wo/struggling with different client compiling experience in user modules (*nix vs Windows).

Node is a great piece of software mounted on the outstanding V8 engine. And now, we can use it in *nix, Windows, even Azure. Sync is ALREADY in core, then, I guess, it is not a silly thing; adding/completing sync to core is possible, and it's not incompatible with core/Node (in the sense of "multithread is incompatible with V8"). 

Martin: your argument is the best I read against the initial proposal and others, concerning the FUTURE ADOPTION of node.js. I only want to raise the hand, and expose other reasons (right or wrong) to have some features added to core in the near 0.x future, giving more options to developers. In my opinion, async approach will survive to complete sync IO  implementation in core, because of scalability reasons AND a vibrant community and ecosystem. But I understand your concerns. I just wrote this email in an attempt to put my ones clear. I don't mean to bother anyone.

Angel "Java" Lopez
http://ajlopez.wordpress.com

http://twitter.com/ajlopez