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


On Sat, Apr 7, 2012 at 5:46 PM, Martin Wawrusch <[email protected]> wrote:

> 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 
> <[email protected]>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.
>>
>> --
>> 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 [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>
>
>  --
> 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 [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to