Crockford : Ynode : "I would fork node.js"

[Jorge]

http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s

"I would fork nodejs. Nodejs is a great thing and I would bet the company on it, but I would not bet the company on Joyent. I see Joyent doing some stuff which is amateurish, maybe a little chidish, so I would fork it, and, I would then give that back to the community, and it would be industrial strength and secure and designed to operate a Yahoo scale and would make it available for everybody for free"

--
Jorge.

[Arnout Kazemier]

"Pull request or it didn't happen"

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

[Kevin Swiber]

Haven't watched the video yet, but my first reaction is "put up or shut up." :)

Also, trash talking in a US presidential election year seems fitting.
Can't get enough of it. ;)

Sent from my iPhone

[Mikeal Rogers]

His words were something along the lines of "i don't trust Joyent with it" and that Yahoo should fork node. It shows a complete lack of understanding of how node is developed and how our community works. Joyent's involvement has been positive, as they have paid several core contributors include Ryan and Isaacs, but their involvement has never driven the project in a direction that the community wasn't behind for some sort of other corporate interest, nor do I think such an act would even be possible given the dynamics and transparency we have in the project.

In short, Crockford doesn't know what he's talking about, and if he'd spent time in the community he might know better.

-Mikeal

[rektide]

On Sat, Sep 15, 2012 at 04:56:40PM +0200, Arnout Kazemier wrote:
> "Pull request or it didn't happen"

Hi:

https://github.com/xk/node-threads-a-gogo , or preferrably some better isolated manner of
multi-threading with Transferable objects.

[Nuno Job]

This again? Oh mah gawd. :)

Sent from my iPhone

[Ted Young]

I take it no one knows what he's actually complaining about?

Ted

[Mark Hahn]

@rektide, are you saying that joyent is asleep at the wheel because they are stopping the community from using threads? 

The community doesn't want threads because they violate the founding principle of Node, which is to use non-blocking event loops and get rid of threads.

[Jorge]

Please stop, this thread is *NOT* about threads.

Let's just gossip about what Crockford says in this talk: <http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s>

P.S. @Hahn: what's a non-blocking event loop? :-P
--
Jorge.

[Mark Hahn]

> ... what's a non-blocking event loop

An imaginary mash-up of different concepts.  It was a brain-fart.

Actually, it could make sense if you think of it as an event loop that calls non-blocking code on each tick.

[Jorge]

And, that said, what else do you (@Mikeal) have to say WRT "Joyent doing some stuff which is amateurish, maybe a little childish" ?
--
Jorge.

On 15/09/2012, at 19:02, Mikeal Rogers wrote:

> His words were something along the lines of "i don't trust Joyent with it" and that Yahoo should fork node. It shows a complete lack of understanding of how node is developed and how our community works. Joyent's involvement has been positive, as they have paid several core contributors include Ryan and Isaacs, but their involvement has never driven the project in a direction that the community wasn't behind for some sort of other corporate interest, nor do I think such an act would even be possible given the dynamics and transparency we have in the project.
>
> In short, Crockford doesn't know what he's talking about, and if he'd spent time in the community he might know better.
>
> -Mikeal
>
> On Sep 15, 2012, at September 15, 20129:34 AM, Kevin Swiber <ksw...@gmail.com> wrote:
>
>> Haven't watched the video yet, but my first reaction is "put up or shut up." :)
>>
>> Also, trash talking in a US presidential election year seems fitting.
>> Can't get enough of it. ;)
>>
>> Sent from my iPhone
>>
>> On Sep 15, 2012, at 10:45 AM, Jorge <jo...@jorgechamorro.com> wrote:
>>
>>> http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s
>>>

>>> "I would fork nodejs. Nodejs is a great thing and I would bet the company on it, but I would not bet the company on Joyent. I see Joyent doing some stuff which is amateurish, maybe a little childish, so I would fork it, and, I would then give that back to the community, and it would be industrial strength and secure and designed to operate at Yahoo scale and would make it available for everybody for free"
>>>
>>> --
>>> Jorge.

[Alan Gutierrez]

On 9/15/12 10:45 AM, Jorge wrote:
> http://www.youtube.com/watch?v=8HzclYKz4yQ#t=22m30s
>
> "I would fork nodejs. Nodejs is a great thing and I would bet the company on it, but I would not bet the company on Joyent. I see Joyent doing some stuff which is amateurish, maybe a little chidish, so I would fork it, and, I would then give that back to the community, and it would be industrial strength and secure and designed to operate a Yahoo scale and would make it available for everybody for free"

Crockford uses Yahoo! as a trolling platform.

--
Alan Gutierrez - @bigeasy

[Marak Squires]

Crockford is like your JavaScript Grandfather.

Be nice to him and smile and nod when he tells you stories about when he use to wear an onion on his belt, which was the style at the time.

--
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+unsubscribe@googlegroups.com

[Marak Squires]

http://www.youtube.com/watch?v=ARXfQzfl9EQ

[Stewart Mckinney]

He's an opinionated guy, but I would like to hear why he felt that way. You really don't have many people who have seen as much as he has, working in the video game interactive industry, then the web, then taking several major architect roles at massive corporations. It's worthwhile at least hearing some of his reasoning, especially since he no longer works at Yahoo - and thats what his whole speech was about ( what he would do to "fix" Yahoo ). I don't think he's hatin just to be hatin.

Also - not sure if he's quite "senile grandpa" age, but that clip did make me laugh. I'd put him at late 50s, maybe just turning 60? He worked at Lucas Arts in the 80s-90s, I would guess he was 20ish then - i'd put my money at 25 circa 1986, making him 59 now.

Any other bets on his age? :D

http://www.youtube.com/watch?v=ARXfQzfl9EQ

nodejs+un...@googlegroups.com

[Stewart Mckinney]

And I can't do math. At all.

[Jérémy Lal]

Do you even realize Grandpa Simpson is an ass ?

J�r�my.


On 15/09/2012 21:52, Marak Squires wrote:
> http://www.youtube.com/watch?v=ARXfQzfl9EQ

[Tim Dickinson]

I would like to see a fork of node.

[Mark Hahn]

> I would like to see a fork of node.

What would you change?

--

[Marco Rogers]

I'd change lots of things. But it's probably a good idea that I'm not in charge. Ditto Crockford.

:Marco

[tjholowaychuk]

crockford writes code? I haven't seen much ;) I don't he has any place in a community he doesn't contribute to

[phidelta]

Look people, think of the context of the statements he made. I think he gave huge kudos to node. 

I wrote a longer post on that (and this thread) as well:

http://instarant.net/crockford-right-nodejs-joyent

Regards, Philipp

[dhruvbird]

I think his statements should be taken positively - and if anyone cares maybe ask him more details about what he expects to change and see if his concerns are valid in the short/long term. Considering he is far more experienced than the collective experience of everyone on this thread, he should be taken very seriously.

On Saturday, September 15, 2012 10:45:30 AM UTC-4, Jorge wrote:

[Nuno Job]

"Joyent is a tiny paas company."

First and foremost. You are welcome. 

Second they dont do paas.

You state people lack context, seems like they are not alone. Why humans are so drawn to jump to conclusions without any facts is something i find fascinating.

Sent from my iPhone

--

[Ricardo Lanziano]

On Sun, Sep 16, 2012 at 8:24 AM, Nuno Job <nunojo...@gmail.com> wrote:
> "Joyent is a tiny paas company."
>
> First and foremost. You are welcome.
> Second they dont do paas.
>
> You state people lack context, seems like they are not alone. Why humans are
> so drawn to jump to conclusions without any facts is something i find
> fascinating.

And they run the largest Solaris datacenters in the world. That isn't
tiny at all.

--
Ricardo Lanziano
To iterate is human, to recurse, divine.

[rektide]

TL;DR:

1. Threads are a feature, one that will unlock new exciting things we can do and make
existing features better (namely child_process.fork()).
2. "We don't have that feature" is not a feature, is not a pro.
3. Being dogmatic about what others ought do is bad: accept if not embrace input liberally.
4. Doing threads, safe concurrency right is what makes Rust so attractive, and Node can do
it safely, cleanly too and nearly did, in the "isolates" branch.
https://github.com/joyent/node/tree/isolates

Onwards:

On Sat, Sep 15, 2012 at 11:32:56AM -0700, Mark Hahn wrote:
> @rektide, are you saying that joyent is asleep at the wheel because they
> are stopping the community from using threads?�
> The community doesn't want threads because they violate the founding
> principle of Node, which is to use non-blocking event loops and get rid of
> threads.

"violate the founding principle"?
"community doesn't want"?

As for "doesn't want" and "founding principles," before threads became an awful horrible
thing the Node community would have nothing to do with ever, there was a feature that got
canned for being too complicating called Isolates, that, shock and awe, Node leads were hard
at work on which would have added threading as a drop in replacement for child_process.fork().
Certainly no one was calling the feature "anti-Node" at the time, it would have been an
implementation detail, offered the same functionality as already exists in Node today, and
would have made us capable of doing more.
https://groups.google.com/forum/?fromgroups=#!msg/nodejs/zLzuo292hX0/F7gqfUiKi2sJ
https://github.com/joyent/node/tree/isolates

Threading is not evil. Shared state is evil. Which is why the rest of the JavaScript world
has Transferables, a way to move ownership of an object from one isolated thread/container
to another. Processes preservation [read: apropo exclamative], Node is already a
multi-reactor not a reactor, and there's no harm, nothing but technical gain (faster context
switches, Transferables), from allowing that multi-reactor to run on threads as easily as it
runs on processes. Aside from the work to get there, there's no cause to keep ourselves
locked in to just using processes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#transfer-a-transferable-object

I'm not at all saying Joyent is asleep at the wheel. They punted on this topic, this big
hard hairy to implement topic: fine. It does hurt us, is a killer feature a mature runtime
ought have in it's toolkit, but I have faith eventually we'll go to bat on the topic again
in a serious manner in due time and I'm not sweating the innings lost between now and then.
In the mean time, Joyent has been doing great things with Node and I'm delighted they
continue doing so much to further Node.



I know Ryah has gone on twitter and said he still sees Node as a web runtime. Isaac has
similarly lamented allowing other languages to play in Node's pool. Online discussions have
a lot of people defending node's lack of threading. I think much of this makes us look bad,
(hipster-ish, dogmatic, and even jingoistic), to soapbox about what this thing is for, to
rather than find value and positives define negatives and ills, to proscribe.

For comparison, I'd champion Larry Wall's Perl: a super flexible language, but what I love
more than anything else is how a-dogmatic it was, an explicitly post-modern language with
an explicitly post-modern culture, where people didn't tell each other what to think or do
and couldn't do otherwise in any kind of definitive manner because there were a dozen ways
to do a thing: liberty came standard. Even if you were using it to shoot yourself in the
foot, the guy on the other side of the lab can be using feature X or factor Y to great
effect.

Make options available, help people see what things are possible. That's humble, that's
respectful, and speaks to an understanding that lasting things grow and change and take on
new roles. If we knew all the answers, we'd have built ourselves all-too-sterile and
flavorless an environment.

Threads are great. Fact. Better than processes (at at least context switching and
transfering objects). Fact. And like most great powers, they come with great responsibility
(more than processes, fact). Which isolates, WebMessaging all support, all work to harness
the capabilities of while insuring they are used responsibly.



Fwiw, Rust is going to be a serious language to look at because it has such deeply ingrained
respect for safe concurrent containers. And continuing my opining, Node owes itself
isolates, it's parallel: threads are faster context switches than processes, and threads allow
Transferable, both are clear safe wins with zero risk or cost to non-users. Threading is a
feature, one from a usage standpoint that need not be any different than
child_process.fork(), and it's one I hope Node.js comes back to to continue being a
pre-eminent and delighting runtime for all users.

Happy hacking all,
-r



This thread was forked from the Crockford fork YNode thread below,
https://groups.google.com/d/msg/nodejs/QsygwyrXi5U/e9enAhGiVlQJ

> On Sat, Sep 15, 2012 at 11:19 AM, Ted Young <[1]t...@radicaldesigns.org>

> wrote:
>
> I take it no one knows what he's actually complaining about?
> Ted

I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a pretty daft silly thing.
It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That
responsible multi-threading work was attempted in the 'isolates' branch of Node.js. I would
definitely not push the threads-a-go-go work upstream. :)

> On Sep 15, 2012, at 10:52 AM, Nuno Job <[2]nunojo...@gmail.com>

> wrote:
>
> This again? Oh mah gawd. :)
>
> Sent from my iPhone
>

> On Sep 15, 2012, at 6:18 PM, rektide <[3]rek...@voodoowarez.com>

> wrote:
>
> On Sat, Sep 15, 2012 at 04:56:40PM +0200, Arnout Kazemier wrote:
>
> "Pull request or it didn't happen"
>
> Hi:
>

> [4]https://github.com/xk/node-threads-a-gogo , or preferrably some

> better isolated manner of
> multi-threading with Transferable objects.

Sorry for not linking some Isolates earlier, which is the unspoken answer to "better
isolated" above.

[rektide]

Google is too smart for me. I wrote this reply as a new thread, and Google has attached it to the old one. Apologies, but I am about to repost it sans-excerpts.

-r

[rektide]

This thread was forked from the Crockford fork YNode thread below,

http://is.gd/0fiBAV

Happy hacking all,
-r

[Bradley Meck]

There are long discussions in the Node community about what happened when we did try to use Isolates. The lack of thread level protections from things like mucking with process.* and the fact that native modules need to add complex support for Isolates to be first class (many C level libraries deal poorly with Isolates due to them not being exactly like threads from what I understand) are fairly well discussed. In addition things like C's abort(), and any shared memory still cause problems with Isolates. It would be interesting to delve into these problems, but for example if you use rust the runtime has explicit knowledge of threads rather than v8 so you can reduce most of the problems with concurrency to message passing and the same problems as process.* . People who complain about threads generally do not have in depth knowledge of difficulties in doing so with Node's environment, but should feel free to look them up and discuss solutions rather than simply stating "it should have threads". I personally really like what Threads a Go Go does, but it still faces the difficulties listed above difficulties when you start to delve deep into it.

[rektide]

Thanks so much for the informative reply: that's a lot of things I don't know about! 

On Sunday, September 16, 2012 6:22:50 PM UTC-4, Bradley Meck wrote:

There are long discussions in the Node community about what happened when we did try to use Isolates. The lack of thread level protections from things like mucking with process.*

Caveat emptor, doesn't seem like a real issue, just a fact of life.

 

and the fact that native modules need to add complex support for Isolates to be first class (many C level libraries deal poorly with Isolates due to them not being exactly like threads from what I understand) are fairly well discussed.

This in particular would be great to read about! This seems like the chief potential show-stopper, and most open ended problem.

 

In addition things like C's abort(), and any shared memory still cause problems with Isolates.

I'm less willing to say caveat emptor here, sounds harrier, but again "doing it and creating potential problems" (particularly if they're exit case problems) seems preferable to not doing it.

 

It would be interesting to delve into these problems, but for example if you use rust the runtime has explicit knowledge of threads rather than v8 so you can reduce most of the problems with concurrency to message passing and the same problems as process.* 

People who complain about threads generally do not have in depth knowledge of difficulties in doing so with Node's environment, but should feel free to look them up and discuss solutions rather than simply stating "it should have threads".

I have done some attempts at research on the topic: this has been considerably more informative than any threads I've turned up. Perhaps I was doing my search wrong. That all said, apologies for not being able to bring a more balanced perspective to my "should have threads" stance, I would like to be able to do better.

 

 personally really like what Threads a Go Go does, but it still faces the difficulties listed above difficulties when you start to delve deep into it.

Thanks for contributing. 

 

[Kevin Jones]

Just thought I would add from experience of building a threaded version of node. The process.* problem does not really exist if you create a new v8 context for each thread, there are some issues, particularly with process.exit() behaviour but nothing too nasty. 

Modules are a 50:50 issue I think. If threads were supported in the core it would be fairly easy to provide helpers to handle thread specific data, I do that with a C++ template to most of the node globals, it's work but certainly not hard work unless you want to do something more involved that just maintain compatibility. On the other hand, I have just finished work on loading a threaded version of node as a native module into a stock version of node. This is really easy to deploy but I have not found anyway to make this support native modules, I kind of doubt there can be any single process solution given the current code, but I really like the model of being able to bolt fully functioning threads on as a module for those of us who care so I will probably look for other solutions.

I am really only chasing the gains to be had in shared state rather than any philosophical position, to that end I have tuned messaging passing between threads, a rough & ready benchmark shows throughput of 500k-msg/sec between threads, the comparative figure for inter-process is 20k-msg/sec, although this was only tested in WIN32. My work is on github, but I am a couple of week away from an initial release, plenty of test cases to be run yet.

[Marco Rogers]

Your link is being weird for some reason. Here's a better url. https://github.com/hut78/troop.js

[Ben Noordhuis]

On Sun, Sep 16, 2012 at 11:51 PM, rektide <rek...@voodoowarez.com> wrote:
> Threads are great. Fact. Better than processes (at at least context switching and
> transfering objects). Fact.

It's much (much!) more nuanced than that.


Threads in most common threading implementations are only marginally
cheaper than processes. You avoid some TLB flushes and that's about
it.

That small gain is offset by the need to serialize access to your data
structures - which is often a lot more expensive than the small gain
you get by using threads.


As for transferring objects, you don't need threads for that, just
shared memory.

We'll probably implement that someday but don't expect too much from
it. Shared memory avoids some syscalls but the cost of moving the
object from one V8 heap to another remains.

By the way, if you want to hasten that day, post (non-contrived)
benchmarks that conclusively show that IPC is a bottleneck. :-)

[Bradley Meck]

Depends on what you consider to be problematic with process.* ,

process.cwd() in particular bit me while trying a couple things, but could be worked around, a slightly more annoying error dealt with cluster using env variables, once again possible to work around. 

As stated, I really like the approach taken by threads a gogo. I am not against threading, just very cautious.

[Bruno Jouhier]

I've got some idea what Nuno is groaning about. :) Threads-a-go-go is a pretty daft silly thing.
It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That
responsible multi-threading work was attempted in the 'isolates' branch of Node.js. I would
definitely not push the threads-a-go-go work upstream. :)

My FUD detector is blinking red!!!

Threads-a-gogo is perfectly safe and 100% shared nothing. Every worker thread runs in its own isolate, and worker threads communicate with the main thread by passing immutable strings.

If you did not take the time to experiment about it or just read about it, don't post counter-truths like this.

If TAGG could be criticized, it would be for lacking certain useful features. To me, the most crying ones are 1) a module system and 2) the ability to transfer ownership of objects (so that we don't have to serialize everything), or at least pass "frozen" objects.

I don't know if this is behind Crockford's comment but the "thread-a-gogo" story is, IMO, a perfect illustration of the lack of professionalism that's going to hurt node. Instead of embracing something that brings a plus to node (the ability to write CPU intensive operations in JavaScript, with worker threads) and was carefully designed to be aligned with the basic node model (CPU intensive operations are handled as async ops with a standard node callback, eventing API between threads is aligned on node's emitter API), the solution is being at best ignored, when not covered with FUD. The end result is that we are going to get tens of half-backed threading libraries instead of having consolidation around one promising solution (that needed help).

The dogma will be preserved (threads are bad, you need to do this with processes and shared memory, even if this is less performant and more complex) but this is just a childish attitude.

My 2 cents,

Bruno

[Jorge]

On 17/09/2012, at 06:35, Ben Noordhuis wrote:

> (...)

> That small gain is offset by the need to serialize access to your data
> structures - which is often a lot more expensive than the small gain
> you get by using threads.
>
> As for transferring objects, you don't need threads for that, just
> shared memory.

If the processes are sharing memory, then they *too* "need to serialize access to data structures"...

> We'll probably implement that someday but don't expect too much from
> it. Shared memory avoids some syscalls but the cost of moving the
> object from one V8 heap to another remains.

That's the problem for transferable objects: there's no way to grab an object reference from isolate A to use it on isolate B.

> By the way, if you want to hasten that day, post (non-contrived)
> benchmarks that conclusively show that IPC is a bottleneck. :-)

If the processes can communicate via shared memory -which is always a given for threads- then IPC is fast.

But if they can not then you've got to copy the data and speed becomes a function of ( data.length ) which might be *irremediably* slow.

Big data.length copies also flush other data from the caches, which results in extra slowdowns.

And as the memory bus is a shared resource, under high loads these (many) unnecessary big.data.length copies will (pretty soon) have a global impact on the performance of *all* the rest of system (á la `cat /dev/zero > /dev/null` memory bus bandwidth exhaustion).
--
Jorge.

[Jorge]

On 16/09/2012, at 05:39, tjholowaychuk wrote:

> crockford writes code? I haven't seen much ;)
>
> I don't he has any place in a community he doesn't contribute to

Now that's an irony.
--
Jorge.

[Jorge]

On 15/09/2012, at 20:47, Mark Hahn wrote:

> > ... what's a non-blocking event loop
>
> An imaginary mash-up of different concepts. It was a brain-fart.
>
> Actually, it could make sense if you think of it as an event loop that calls non-blocking code on each tick.

But not all code is non-blocking so to compute (e.g.) fib(40) in a non-blocking manner you *need* to do it in another thread.

And, that's *exactly* what node does -internally- to achieve non-blocking IO: it does it in another thread.

Only that it does *not* expose any threads API to its users. Why? I don't know. But it *should*.

DART provides an isolates class for that: <http://api.dartlang.org/docs/continuous/dart_isolate.html>
--
Jorge.

[Ben Noordhuis]

On Mon, Sep 17, 2012 at 10:49 AM, Jorge <jo...@jorgechamorro.com> wrote:
> On 17/09/2012, at 06:35, Ben Noordhuis wrote:
>
>> (...)
>> That small gain is offset by the need to serialize access to your data
>> structures - which is often a lot more expensive than the small gain
>> you get by using threads.
>>
>> As for transferring objects, you don't need threads for that, just
>> shared memory.
>
> If the processes are sharing memory, then they *too* "need to serialize access to data structures"...

Yes, but the big difference - and I hate to spell it out because it
should be obvious - is that you only need to synchronize a single
thing instead of every global data structure.

>> We'll probably implement that someday but don't expect too much from
>> it. Shared memory avoids some syscalls but the cost of moving the
>> object from one V8 heap to another remains.
>
> That's the problem for transferable objects: there's no way to grab an object reference from isolate A to use it on isolate B.
>
>> By the way, if you want to hasten that day, post (non-contrived)
>> benchmarks that conclusively show that IPC is a bottleneck. :-)
>
> If the processes can communicate via shared memory -which is always a given for threads- then IPC is fast.
>
> But if they can not then you've got to copy the data and speed becomes a function of ( data.length ) which might be *irremediably* slow.
>
> Big data.length copies also flush other data from the caches, which results in extra slowdowns.
>
> And as the memory bus is a shared resource, under high loads these (many) unnecessary big.data.length copies will (pretty soon) have a global impact on the performance of *all* the rest of system (á la `cat /dev/zero > /dev/null` memory bus bandwidth exhaustion).

No doubt. Now show me the numbers. :-)

[Jorge]

On 17/09/2012, at 11:12, Ben Noordhuis wrote:
> On Mon, Sep 17, 2012 at 10:49 AM, Jorge <jo...@jorgechamorro.com> wrote:
>> On 17/09/2012, at 06:35, Ben Noordhuis wrote:
>>
>>> (...)
>>> That small gain is offset by the need to serialize access to your data
>>> structures - which is often a lot more expensive than the small gain
>>> you get by using threads.
>>>
>>> As for transferring objects, you don't need threads for that, just
>>> shared memory.
>>
>> If the processes are sharing memory, then they *too* "need to serialize access to data structures"...
>
> Yes, but the big difference - and I hate to spell it out because it
> should be obvious - is that you only need to synchronize a single
> thing instead of every global data structure.

But that's a different problem. If you want to make thread-safe a program that's abusing globals then yes you're ~ fucked.

On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...

>>> We'll probably implement that someday but don't expect too much from
>>> it. Shared memory avoids some syscalls but the cost of moving the
>>> object from one V8 heap to another remains.
>>
>> That's the problem for transferable objects: there's no way to grab an object reference from isolate A to use it on isolate B.
>>
>>> By the way, if you want to hasten that day, post (non-contrived)
>>> benchmarks that conclusively show that IPC is a bottleneck. :-)
>>
>> If the processes can communicate via shared memory -which is always a given for threads- then IPC is fast.
>>
>> But if they can not then you've got to copy the data and speed becomes a function of ( data.length ) which might be *irremediably* slow.
>>
>> Big data.length copies also flush other data from the caches, which results in extra slowdowns.
>>
>> And as the memory bus is a shared resource, under high loads these (many) unnecessary big.data.length copies will (pretty soon) have a global impact on the performance of *all* the rest of system (á la `cat /dev/zero > /dev/null` memory bus bandwidth exhaustion).
>
> No doubt. Now show me the numbers. :-)

Ok. Please tell me the secret :-P

Because to me it's obvious that a copy of (sizeof void*) length is faster than a copy of anything much larger than that.

?
--
Jorge.

[Marco Rogers]

Do you guys wonder why there is a collective groan when you show up? Especially considering how difficult it is for a group of geographically remote people to convey a collective groan in a written medium ;)

Threads-a-go-go lives exactly where it should; in userland where anyone who wants to can try it. You should stop being so bothered by how things work in the community. There are so many people in the node community that wish their modules got more attention. Those people don't have nearly as many stars and forks on github as threads-a-go-go. Whatever it is you think you're entitled to, you've already got it.

:Marco

PS: And find some way to get rid of the "eval" thing for chrissakes. If you want javascript people to take you seriously, show them you're serious about javascript.

[Bruno Jouhier]

So it is perfectly fine if someone writes:

"Threads-a-go-go is a pretty daft silly thing.
It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That
responsible multi-threading work was attempted in the 'isolates' branch of Node.js"

Jorge should just swallow the FUD, bend over and apologize for having proposed such a "daft silly thing" to the community!

BTW, the 'isolates' branch failed, probably because it was trying to do too much (put a complete node into every isolate). TAGG solves a much narrower problem: delegating CPU intensive operations to threads, and it does it in a safe and efficient way.

The problem is that we cannot even discuss anything related to threads in a rational way. There may be perfectly valid use cases for threads in node (I think that CPU intensive computations are one - you can do them in threads with C++, why not in JS?), and there are perfectly safe and clean ways to add threads to node (and I think that TAGG is one - the "eval" situation can be improved with modules). But how can we discuss this without everyone jumping to the ceiling?

Bruno

[Fedor Indutny]

So it is perfectly fine if someone writes:

"Threads-a-go-go is a pretty daft silly thing.
It's certainly not the safe sane shared-nothing threading that keeps Node & JS safe. That
responsible multi-threading work was attempted in the 'isolates' branch of Node.js"

Jorge should just swallow the FUD, bend over and apologize for having proposed such a "daft silly thing" to the community!

BTW, the 'isolates' branch failed, probably because it was trying to do too much (put a complete node into every isolate). TAGG solves a much narrower problem: delegating CPU intensive operations to threads, and it does it in a safe and efficient way.

The problem is that we cannot even discuss anything related to threads in a rational way. There may be perfectly valid use cases for threads in node (I think that CPU intensive computations are one - you can do them in threads with C++, why not in JS?),

 

Let me paraphraze you, why should you do it in javascript, when there're C++/C which is much better for computational problems. Sure you can use 3rd party module for making your js code run in multiple threads, but as far as it can be implemented as a external dependency - why should it be placed in node.js core?

and there are perfectly safe and clean ways to add threads to node (and I think that TAGG is one - the "eval" situation can be improved with modules). But how can we discuss this without everyone jumping to the ceiling?

 

Bruno

--

[marco....@gmail.com]

Jorge doesn't have to swallow anything. In fact he has not. He has engaged with the subject at hand and has not responded to the troll bait about his lib. Notice he continues to receive feedback, about the subject. As does rektide even though he was the person who derailed the conversation in the first place.

You however, chose to respond to the bait by throwing a tantrum and calling the whole community childish and unprofessional (** groan **). Even though it looks like the comment that set you off from rektide, who brought up TAGG in the first place.

So as desperately hard as you're trying to have a rational discussion about this, you seem to be the only person who can't seem to do so. And at this point, responding to you is starting to feel dangerously like feeding trolls... oh damn. Guess I fell for it too.

:Marco

Sent from my iPhone

--

[Bruno Jouhier]

@Marco,

Childish and amateurish were not my words in the first place, they were Crockford's. And, although there may have been a bit of provocation in my post, I think that the problem is real (otherwise, why would Crockford use these words?).

The problem that I see is that a number of smart people (Jorge being one) have proposed interesting things to fill some of the holes in node's story (like the inability to do CPU intensive stuff in JS - remember the "node is cancer" story). Of course, Jorge has been stepping a bit on what node's core team was doing (as they tried to attack the thread problem from a slightly different angle but decided to backtrack) but maybe this means that they took the problem from the wrong angle and that what he has done, although more limited in scope, could be interesting. My expectation would have been that the topic be discussed at the technical, professional level between the different people involved. Did this ever happen? Did any member of the core team ever show any interest in what Jorge had produced? I may be simplifying a bit but I have the impression that all he got was negative feedback. And then people feel authorized to post sarcastic remarks ("this again? oh mah gawd", "daft silly thing") about his work. And of course, nobody reacts. This is what I find very childish and I am sure that a number of other professionals who are watching our discussions feel the same way.

There should be a way to discuss issues like threads without going into sarcasms and personal things.

@Fedor,

Of course, CPU intensive stuff can be done in C++ but this is a completely different story: you have to dive into C++, deploy C++ extensions, etc. Being able to do it in JS (with the help of a generic C++ library) can be an attractive proposition. At least it is for people like me who have rusty C++ skills and are ready to trade a bit of performance for some comfort and piece of mind.

To me, TAGG is a bit crippled today by the fact that you have to serialize data as strings to pass it between threads. But if we were able to transfer ownership of JS objects, or, although this is less powerful, at least pass frozen objects between threads, this would allow us to pass buffers or whole object graphs very efficiently to worker threads. Then the TAGG proposition would become really attractive.

This feature (being able to do CPU intensive stuff in JS) may not hit the sweet spot of node, which is I/O intensive apps. But it does not hurt node either; it enables something that was impossible (or much harder) to do before, and it does it with a design which is aligned with node's principles (computations being treated just like async operations). So why bash it?

[Mikeal Rogers]

If you want to add something to core it'll need to be a GitHub issue.

For all the same reasons non-blocking APIs fail on platforms that traditionally use threading a threading API in Node will fail just the same. It's a matter of community, the two approaches are not compatible and this means that the code in the community divides along these lines.

It's not good for the community to divide in to incompatible camps. Node code runs in node, period. If you want threads you'll need to fork, and you'll need to call it something other than node because it's not Node anymore, it's something else. Maybe it's better, but it's not Node.

You can talk all day about the "possibilities" but your'e just talking about technology and waxing about what is possible. It doesn't really matter, it's not why things gain traction or grow a community, which is necessary for success. If you want to take on this science project, go for it, but take it off the list, this isn't productive.

-Mikeal

[Marco Rogers]

Childish and amateurish were not my words in the first place, they were Crockford's. And, although there may have been a bit of provocation in my post, I think that the problem is real (otherwise, why would Crockford use these words?).

No, childish is your word, and so is unprofessional, which you alude to again in your response. Don't hide behind Crockford just because he also used them. He's not here.

The node community IS sometimes unprofessional. Because we don't really buy the old school idea of why being "professional" is supposed to be so great. If you want to work with people, you deal with real people. Not rigid, restrained approximations of real people. You can make the argument that the underlying irreverence is in some way hampering node adoption. That's debatable I think. But what you fail to realize is that even if it were true to a certain extent, we simply do not care. There are things we're willing to compromise on to push node to the top, and some things we are not. Nuno Job is is part of 2 successful node businesses (Nodejitsu, The Node Firm), and he manages to do it while still being funny. Oh mah gawd, how is that possible?! The community has chosen to be genuine instead of "professional". You can disagree, but I'm afraid your protests fall on deaf ears there. We all get enough of being professional at our day jobs. 

My expectation would have been that the topic be discussed at the technical, professional level between the different people involved. Did this ever happen? Did any member of the core team ever show any interest in what Jorge had produced? 

This is happening right now. In this thread. Ben is a core member and he's being very receptive and offering lots of info in return. Bradley Meck is also very active and expressed his appreciation for TAGG in the right context. And it has happened in other threads as well. I'm not sure what you think this is supposed to look like. Your beef seems to be that the core team isn't over the moon about the way TAGG approaches the problem. Again, they have opinions about what they want threading support in node to look like. If you want to influence those opinions, you should engage more often, with more data, and in better faith. But you should be prepared for some obstinance because first class threaded programming is not something the community at large is clamoring for. It doesn't fit with the current vision of node. So you'll be fighting to change the vision. That is no small thing and I'm not sure why you think it should be easy.

 

There should be a way to discuss issues like threads without going into sarcasms and personal things.

There probably is. I don't think you've found it yet, and you may not find it here. People here are not a huge fan of threads, and we're doing awesome without them.

We may be swayed with some cajoling though. But you are terrible at cajoling. Just terrible. Get your cajoling skills up. <-- This is me having a little fun with you. You could practice reading it and not going into apoplectic fits.

 

This feature (being able to do CPU intensive stuff in JS) may not hit the sweet spot of node, which is I/O intensive apps. But it does not hurt node either; it enables something that was impossible (or much harder) to do before, and it does it with a design which is aligned with node's principles (computations being treated just like async operations). So why bash it?

You've heard the reasons why. You just don't like them. And you also seem to be misunderstanding what node's principles are.

:Marco

[Ben Noordhuis]

On Mon, Sep 17, 2012 at 11:39 AM, Jorge <jo...@jorgechamorro.com> wrote:
> On the other hand it didn't take too long for the V8 guys to fix exactly that in the isolates branch...

That's actually a good example of the cost of threading support: all
benchmarks dropped by 2 to 8% on the day isolates support got merged
into V8 HEAD.

[Jorge]

I don't believe it. The benchmarks of the successive versions of node with a single version of V8 show that 99% of the times the culprit of the decrease in node's performance has *not* been V8, much rather the opposite.
--
Jorge.

[Jorge]

On 17/09/2012, at 12:04, Marco Rogers wrote:

> Do you guys wonder why there is a collective groan when you show up? Especially considering how difficult it is for a group of geographically remote people to convey a collective groan in a written medium ;)

I only hear the usual waa waa of the usual cry babies.


> (...)

>
> PS: And find some way to get rid of the "eval" thing for chrissakes. If you want javascript people to take you seriously, show them you're serious about javascript.

JS programs are text. Guess what happens when you run them? eval(program); As simple as that! E.g., REPL: Read Eval Print Loop.

I chose to use thread.eval(program) because eval() -as the threads- is evil. Will alias it as thread.evil(program) in the next release, just so it's absolutely clear.

:-P
--
Jorge.

[Isaac Schlueter]

Everybody,

These debates give me hives. Seriously, they make my skin crawl.

If you think that providing an API for threads is a great idea, then
just go do it, as a userland module. Jorge did. What's the big deal?
Some people like it, some people don't. That's how anarchy works.
Think his threads_a_go_go thing is the wrong abstraction? Fine. Do a
different one. It's just code. Write some. There's plenty of room
in the npm registry for all of us.

If you think that such a thing absolutely MUST be provided by the core
library, then that belongs in a github issue. Be prepared to make a
VERY strong case for it. It's a huge change to the architecture,
which was tried in the past and turned out to be not a good idea.
You'll need to be patient (since it will take a while), be willing to
help work on it, and have a plenty of new data showing that it's
actually a valuable change to make in the core, and why the problems
encountered last time can be overcome.

I can tell you that it won't have any chance of landing before 2.0,
and you'll have to (at least) convince Ben Noordhuis and Bert Belder
that it's worth doing. They're both rather skeptical right now, and
stubbornly fixated on "evidence" and "use cases" and "reasonable
trade-offs", so that'll be an uphill climb, but I've found them easy
to convince if you can provide these things. If you convince them,
that's probably the best way to convince me.

This is software. All is flexible. But we're not going to make
architectural changes just because someone says that we have to, using
strong words and providing no data. That's not responsible, for a
platform that is used in production by real companies making real
money.

If you can do it in userland, great. Go do that. There's a good
chance we'll never do it in core, then, since we don't have to, it's a
lot of work, and there's no compelling reason to. If you can't accept
that, and can't convince us to do it in core, then weigh your
discontent against the work of forking node and creating a new
project. Some of us will probably even help you. It might be an
interesting project :)

If you are annoyed that people don't *like* the module that you wrote,
or the project you forked, well, get over it. Some people hate
request and express. I have issues with underscore and never use it
in my projects, and Mikeal calls me crazy and superstitious for that.
Maybe he's right. And those are the most popular modules out there.
I would urge any software developer (or any creative person in any
field) to divorce their self-esteem from the things that people say
about their work. Yes, of course, we all want to build things that
are appreciated by the people we respect; but there's always a crowd
of nay-sayers. You should be worried when you write a program and no
one talks shit about it, because it means you're probably not doing
anything interesting or important.

I would very much like to get away from the idea that anyone should
make passionate speeches about how the world will end if we don't do
some feature in node-core, or if some module is or isn't used by
everyone or anyone. Lighten up. We can all do our thing, explore and
experiment, and so on. Having a small set of core functionality is an
important part of a healthy module ecosystem. We won't be making
dramatic architectural changes to node any time soon, and certainly
not without data to justify it.

In debates like this, both sides tend to miss most of the subtlety of
what is actually involved with making major changes to a platform like
node. These debates are an annoying distraction from actually getting
anything done. It's not about dogma vs features. We aren't married
to Ryan's original vision of Node; in fact, he wasn't even married to
that vision when he was running the project. We've deviated from that
vision numerous times. (Qv. commonjs-style module system, synchronous
fs functions, isolates, domains as a JavaScript abstraction rather
than a shared-nothing IO isolation, etc.) In each case, we've done
our best to make decisions based on the trade-offs and data from real
world use cases. Since he's stepped down from day-to-day management
of the project, we've even rejected a few of his feature requests!
Anyone who accuses the Node project of being dogmatic hasn't been
paying attention. Our dogma is just a shorthand for experience, which
is the sum of accumulated evidence; if you want to change it, provide
new evidence. It's not that hard. I've seen it happen several times.

You know who almost never gets involved in these shenanigans? TJ
Holowaychuk, James Halliday, Matt Ranney, and the folks at Joyent and
LinkedIn and Voxer and Cloud9. Do you know why? Because they're too
busy getting things done, writing modules, and keeping production
systems running. What's childish and unprofessional is flinging
insults because node doesn't have a feature you want. Node is for
builders, and builders aren't here kvetching over node's lack of
threads. They're complaining that TLS is 10x slower than stud or
nginx, that readable streams are too hard to extend properly, and that
http is slower than it ought to be. There is no end to the complaints
that they send my way, and taking on a monumental architectural change
because a vocal minority says we need to, would mean turning our backs
on those builders. That'd be amateurish.

Go build something. Come back when you can tell me what you couldn't
ship because you didn't have threads.

[Mikeal Rogers]

Jorge,

This is me asking you nicely to stop. You've succeeded in making some of the most level headed and accommodating people in the community scream. Great work, job well done. Time to stop now.

If you do not stop I'lll consider your behavior outright trolling and ask that you be removed from the list.

-Mikeal

[JeanHuguesRobert]

Hi Isaac

Le mardi 18 septembre 2012 00:09:32 UTC+2, Isaac Schlueter a écrit :

These debates give me hives.  Seriously, they make my skin crawl.

...

You know who almost never gets involved in these shenanigans?  TJ
Holowaychuk, James Halliday, Matt Ranney, and the folks at Joyent and
LinkedIn and Voxer and Cloud9.  Do you know why?  Because they're too
busy getting things done

Getting thing done is good, so is having fun.

Let's evaluate the hypothese that they prefer not to polarize some people against them, fair move.

Back to business. Fiber are nice (not preemptive), Isolate are nice (multi-core), and async is the de facto (nice) standard.

Conclusion to API providers :

  - make it async - standard, fast

  - make it sync, using fiber - convenient, not preemptive hence "manageable"

  - make it sync, using isolates - convenient, multi-core friendly

IN THAT ORDER

[Marco Rogers]

I admit to willingly participating in this because I was off today and had nothing better to do. :)

I don't think Jorge or anyone else has been much out of line in this thread. And it's really only ever a handful of people that perpetuate these debates until they devolve. Myself included. I think they're a lot of fun, but I do try to restrain myself from getting involved in all of them so as not to permanently bring down the atmosphere of the list.

I don't think it's bad to have people debate things on the list. Even if it's the same topics sometimes. Not everyone has been around for 2+ plus years. And not everyone can make it to conferences costing hundreds or even thousands of dollars in order to debate in person. So to a lot of people, this is where the community is. You guys have been increasingly quick to shut down lively debate. And as a consequence, the list is pretty boring these days. Take that however you like.

When you guys stomp in like angry parents all the time, it starts to feel way too "professional" around here. Just sayin.

:Marco

--
Marco Rogers
marco....@gmail.com | https://twitter.com/polotek

Life is ten percent what happens to you and ninety percent how you respond to it.
- Lou Holtz

[Alexey Petrushin]

I guess node.js project reached popularity level when splitting effort into multiple competing implementations would be a good thing, so fork would be good.

[Mikeal Rogers]

This is where we disagree. I think that this is the worst thing we could be doing and that it's actually damaging to the project.

In order for Node to be successful it needs to evolve past each challenge it faces.

In the early days, everything was up for debate, and Node attracted a lot of people doing fun experiments. We went back and forth about various promise APIs and callbacks, then we moved on. We debated the module system for a while, then we moved on. Luckily, we never took responsibility for the language so we've avoid that debate entirely.

Node is approaching the point where Node will not be about Node core anymore. Node core is about to get very boring, API changes will not be happening, it won't be a place to solve problems, and it's already not a place for experimentation. The focus of the community will necessarily shift to being not about Node and about what we build in it instead.

If Node does not move past the same old debates, debates that the community has already decided on (99% of modules are using standard callback interface) it will suffer the same fate as Perl, Python or Ruby that are still enamored with the same problems they were talking about 6 years ago.

This is important. Node should be a fun place and nobody is trying to say "act professional". The problem is that this shit is decidedly *not fun* for anyone but you and Jorge and maybe a few others and is a huge annoyance and distraction for everyone who would like to move forward and have fun talking about robots and websockets. Your discussion makes this list a place for endless debates between camps that have no adoption and people having fun playing devils advocate and not a place for people to talk about real stuff they are building and problems they have.

A conflict is inevitable. The kind of people attracted to experimentation when a project is young will feel alienated when it moves past the experimentation phase, and that is decidedly where node is at.

-Mikeal

[Michael Schoonmaker]

As someone who started using Node after said experimentation was over, I want to publically thank those who argued this sort of thing in the past, and am excited about what we (myself included) can build in and with Node. Those decisions were not easy, but they've been decided, and by incredibly smart people. Let's not short-change that.

As someone who receives every email sent to this list individually, I want my inbox back. TAGG belongs in Userland. So do promises. And Fibers. And Hook. And every other library that builds beyond core Node. You want to change Node? You have your trajectory: fork or get more formally involved. Put your fingers where your mouth is and let's go back to having fun.

-Schoon

[Marco Rogers]

I would very much like to get away from the idea that anyone should make

passionate speeches about how the world will end if we keep having

debates on the mailing list.

It's just not true Mikeal. You and Isaac both are over-reacting to this

issue. It's when I stopped over-reacting a while ago that these debates

stopped giving me hives. And the frequency of these posts went down when

you guys stopped participating directly. It's just a mailing list. It's

not stopping the proliferation of dozens of conferences selling out.

It's not stopping people from posting dozens of messages a day. It's not

stopping more modules from showing up on npm. It's not stopping people

from shipping code.

Just like node core has passed the point of experimentation and endless

tweaking, so has the community passed the point where a few trouble-

making citizens is going to cause the whole fragile house of cards to

fold.

Lighten up. It'll be fine. I promise.

:Marco

[Bert Belder]

Ha! Thanks guys for making my day, nothing beats a good fight on an otherwise very boring evening. Also, it always gives me this warm and fuzzy feeling of self-righteousness every time I decide not to participate. I'm loving it!

I hate TAGG because it's built around the lie that zero-copy data sharing would be at all possible. V8 just isn't built to do it, and making it so would be a monumental task. Google may be able to pull it off it they cared, but the core team can't. Jorge and Bruno don't even know where to look. Call me again when you own a billion dollar company. Or when you're reborn as a crazy Russian super hacker. Zero-copy Buffer/TypedArray sharing *may* be possible but copying binary data is even less likely (by at least an order of magniture I'd say) to be the bottleneck in your app than serialization.

In the meantime, ToString'ing a function and eval'ing it on another thread, are you kidding me? Heavy computation never takes more than a single function right?

Isolates was our (or rather, Ben and Ryan's) attempt to do whatever TAGG might achieve in a proper way, but in the end we figured out that it has no benefits over using child processes. Whatever TAGG does, you can trivially achieve the same with child processes. Ryan even wrote an example fibonacci server to demonstrate this. Obviously nobody cared because this is entirely irrelevant.

- Bert

[Jorge]

On 18/09/2012, at 00:14, Mikeal Rogers wrote:

> Jorge,
>
> This is me asking you nicely to stop. You've succeeded in making some of the most level headed and accommodating people in the community scream. Great work, job well done. Time to stop now.
>
> If you do not stop I'lll consider your behavior outright trolling and ask that you be removed from the list.

Oh my dear take it easy.
--
Jorge.

[Isaac Schlueter]

First of all, saying "I would fork node" is just an absurdly dated
thing to even say as if it's meaningful. There are 2,452 forks of
node right now. It's silly to say that you WOULD fork node, if you
currently can, and haven't. (I'm getting a 404 from
https://github.com/douglascrockford/node.)

I responded to this and a few other questions regarding Joyent and
Node here: http://www.quora.com/Node-js/What-is-happening-to-Joyent-and-how-does-it-affect-NodeJS/answer/Isaac-Z-Schlueter.
The bit that is relevant to this specific topic:

>>>
> In May at HTML5 dev conference, Douglas Crockford said that he would fork NodeJs because he does not trust Joyent.

I emailed Douglas about this asking for more details. He and I are
former colleagues from my time at Yahoo. He claimed that "Joyent's"
management of Node is "amateurish". As I am the person at Joyent who
manages Node, I could not help but take this as a criticism of my own
work.

To date, I have not received a reply. While I of course understand
that the time limits of a talk don't allow for deep discussions of
every subject, I was saddened by the vagueness of his comments, and
consider the lack of follow-up rather unprofessional. I have no idea
what he thinks is amateurish about how I'm running node.
>>>

The fact of the matter is, none of us know what Crockford meant by
that comment, because he hasn't provided any further details, and
that's the end of it.

As for the other issues, I'd rather not try to synchronize a
discussion across threads, as that can result in data corruption ;)

[Shripad K]

Lol :P

[José F. Romaniello]

2012/9/18 Isaac Schlueter <i...@izs.me>

First of all, saying "I would fork node" is just an absurdly dated
thing to even say as if it's meaningful.

this is exactly what I thought from the first mail in this thread.. since when you have to announce in public that you are going to fork a project.. He might have some (good?) reasons to say so, but it has a lot of sensationalism.

now, excuse me, but I am going to fork Rails because those 37Singals guys are bananas..

[Rick Waldron]

This morning I had a chance to ask Doug, in person, to clarify what he meant by his statements about forking Node—as it turns out, his motivations aren't sinister, nor are they really outrageous.

Historically, Yahoo forks technologies that it relies heavily on, eg. Unix and Apache. This allows them to iterate at their own pace and add features they want, when they want them and exclusively to meet their own internal or product based needs. As he explained to me, he simply meant that if he was asked to be the CEO of Yahoo, he would add Node to the technologies that Yahoo maintains its own fork of. Doug also noted that in this hypothetical scenario, the "YNode" code would be released as an open-source project (unlike forks of other technologies at Yahoo)

Seems like way less of a big deal when you actually check sources... weird, right?

Rick

[Rick Waldron]

Almost forgot...

When I mentioned threads, he scoffed and said "threads have no place in JavaScript or Node". 

And there you have it, the rest of the story (sans speculative ad hominem)

Rick

--

[Mark Hahn]

No mention of childishness? 

[Rick Waldron]

eh, there was, but it turned out to be something that was simply misunderstood and not really worth mentioning here. I'm not going to get involved with the "name calling" part of this discussion.

Rick

[rektide]

and is a huge annoyance and distraction for everyone who would like to move forward

I humbly propose not participating in things which annoy you or you find overly distracting.

Everyone who feels capable of engaging in progressive dialectic engagement on technical topics and knows how to avoid meta-moderating, please carry on. Mikeal, this is a victimless crime. If like Socrates you think me in violation of your society, pass the hemlock: this is the way it's gotta be, and the only harm is people that jump to take injury from it.

[rektide]

WebMessaging for life, and as usual, haters gonna hate. Stay positive kids.

[rektide]

On Tuesday, September 18, 2012 1:26:13 PM UTC-4, Rick Waldron wrote:

This morning I had a chance to ask Doug, in person, to clarify what he meant by his statements about forking Node—as it turns out, his motivations aren't sinister, nor are they really outrageous.

Historically, Yahoo forks technologies that it relies heavily on, eg. Unix and Apache. This allows them to iterate at their own pace and add features they want, when they want them and exclusively to meet their own internal or product based needs. As he explained to me, he simply meant that if he was asked to be the CEO of Yahoo, he would add Node to the technologies that Yahoo maintains its own fork of. Doug also noted that in this hypothetical scenario, the "YNode" code would be released as an open-source project (unlike forks of other technologies at Yahoo)

Seems like way less of a big deal when you actually check sources... weird, right?

I'm not sure what was clarified. This still seems like an entirely wide open topic. Aside from "doing it under Yahoo's umbrella," I can't read a single thing different that Crock would do.

So, it's still open hunting season all! Game on!

[rektide]

Isaac: I fully confess to being an ignorant childish distracting useless retrogressive drag on the community, and I'm sorry if this discussion in fact hurts us. Also, seek trained medical professional help.

Alas, the hunger to know more about this topic STILL calls at me. It did before Isolates was cancelled, it did when Isolates was cancelled, and I sought to rectify my ignorance by asking others, not investigating the source which I feel less than capable of, and blaming no one I did not get the help I requested highlighting the "subtleties" of the technical landscape surrounding this still interesting feature:

https://groups.google.com/d/msg/nodejs/zLzuo292hX0/xb30bmk3ds8J

Please let me know if you have constructive advice for better ways to seek knowledge than what I've done here, or back in February when Isolates was canned. I wish to become more informed, and hope this community is civil and mature enough to help explore the topic with me.

Respect,

-rektide

[Karl Tiedt]

Paraphrasing, it was stated that the fork would have been "because of
how Yahoo likes to operate", "if there were any changes they would be
open sourced" and "threads have no place in javascript"

-Karl Tiedt

[rektide]

I hate TAGG because it's built around the lie that zero-copy data sharing would be at all possible. V8 just isn't built to do it, and making it so would be a monumental task. Google may be able to pull it off it they cared, but the core team can't. Jorge and Bruno don't even know where to look. Call me again when you own a billion dollar company. Or when you're reborn as a crazy Russian super hacker. Zero-copy Buffer/TypedArray sharing *may* be possible but copying binary data is even less likely (by at least an order of magniture I'd say) to be the bottleneck in your app than serialization.

Multi-threading, even without zero copy, would allow for faster context switching as well. Context switching is bad, process-per-thread is good and helps avoids context switching, but there is a gain even if there is not an easy zero copy benefit to be had.

Not clamoring for this, zero-copy is far more my interest, but it is a gain for places where concurrency has to happen outside of any given Node process.

 

In the meantime, ToString'ing a function and eval'ing it on another thread, are you kidding me? Heavy computation never takes more than a single function right?

Easy Bert, let's not trash something that works & does more for some people. It doesn't have to appeal to everyone to be a good thing.

 

Isolates was our (or rather, Ben and Ryan's) attempt to do whatever TAGG might achieve in a proper way, but in the end we figured out that it has no benefits over using child processes. Whatever TAGG does, you can trivially achieve the same with child processes. Ryan even wrote an example fibonacci server to demonstrate this. Obviously nobody cared because this is entirely irrelevant.

At the time, the only explanation we got for it being dropped was that it was 15 words, and those rang to a different tune than "had no benefit":

ultimately turned out to cause too much instability in node's internal functionality to justify continuing

https://groups.google.com/d/topic/nodejs/zLzuo292hX0/discussion 

I still am very much interested in technical discussion around this feature, know it abstractly but not deeply, and the cause of it being shelved remains shrouded in mystery. I'm sorry we all feel so dragged into the mud every time it gets raised, thank you for helping share more views which further enlightenment us: any willing to chip in technically on this, thanks (Ben! Jorge! Bert!).

-r

[rektide]

Multi-threading, even without zero copy, would allow for faster context switching as well. Context switching is bad, process-per-thread is good and helps avoids context switching, but there is a gain even if there is not an easy zero copy benefit to be had.

*facepalm* s/process-per-thread/process-per-core/ 

[Isaac Schlueter]

Rick,

That's nice. I've been told that Yahoo does have an internal version
of Node that you can get via `yinst install ynode`, and they use it a
lot. They also pull in changes from the upstream project, and have
sent pull requests for bugs that they've fixed. None of that is
unusual or outrageous. For a company of Yahoo's size, it makes sense
to make sure that all relevant parts of their infrastructure are not
black-boxes, and they've done this in the past with many other
projects.

However, it IS a dated and wrongheaded approach, in my opinion. Yahoo
ought to do what Joyent, Cloud9, Nodejitsu, Microsoft, and others have
done, and hire a developer (or several) to work directly on the open
source libuv and node projects, in a visible way. Forking, renaming,
changing significantly, and then "giving back" is archaic in a day and
age when we can all work on the same thing together using modern tools
like git and github that make all of this completely visible. If
ynode is so great, and ought to be shared, then share it; and if it's
not, then why bother with a separate fork? Seems somewhat foolish.

But really, none of that is what I was confused about. So, he'd open
source ynode. Silly, but ok, whatever. But what's "amateurish" about
"Joyent's management of node", exactly? That's a bold claim. A
person of Douglas's stature in the JavaScript community ought not to
make such bombastic statements in a public presentation unless he's
prepared to point to some examples of amateurishness.

Imagine if I gave a talk at a conference, where I said that Mozilla's
management of the spidermonkey project was amateurish. Then, when
Brendan Eich (or whoever is the lead dev on the Spidermonkey project
at Mozilla, I don't actually know) emails me directly asking what he's
doing that is amateurish, and how I think it could be better, I do not
reply to him. I'd expect a lot of people to lose respect for me if I
did that, and I'm nowhere near Douglas's level of nerd-fame.

[Tim Caswell]

On Wed, Sep 19, 2012 at 2:52 AM, Isaac Schlueter <i...@izs.me> wrote:
> Rick,
>
> That's nice. I've been told that Yahoo does have an internal version
> of Node that you can get via `yinst install ynode`, and they use it a
> lot. They also pull in changes from the upstream project, and have
> sent pull requests for bugs that they've fixed. None of that is
> unusual or outrageous. For a company of Yahoo's size, it makes sense
> to make sure that all relevant parts of their infrastructure are not
> black-boxes, and they've done this in the past with many other
> projects.
>
> However, it IS a dated and wrongheaded approach, in my opinion. Yahoo
> ought to do what Joyent, Cloud9, Nodejitsu, Microsoft, and others have
> done, and hire a developer (or several) to work directly on the open
> source libuv and node projects, in a visible way. Forking, renaming,
> changing significantly, and then "giving back" is archaic in a day and
> age when we can all work on the same thing together using modern tools
> like git and github that make all of this completely visible. If
> ynode is so great, and ought to be shared, then share it; and if it's
> not, then why bother with a separate fork? Seems somewhat foolish.

At Palm we had a fork of node for webos. This was mostly because we
were under very tight deadlines with minimal resources. As awesome as
the node community is at accepting patches, it simply wasn't fast
enough. Also we were using node in a very different manner than most
people and so had wildly different priorities. For example we were
starting node processes on the fly all the time and UI interaction was
waiting on that. We were running on mobile where stock node took
1000ms to boot. A node process would have usually only one client at
a time ever.

I will say that it was constantly a goal of ours to push all our
changes upstream. We didn't want to maintain a fork any more than was
necessary.

[Rick Waldron]

On Tue, Sep 18, 2012 at 2:52 PM, Isaac Schlueter <i...@izs.me> wrote:

Rick,

That's nice.  I've been told that Yahoo does have an internal version
of Node that you can get via `yinst install ynode`, and they use it a
lot.  They also pull in changes from the upstream project, and have
sent pull requests for bugs that they've fixed.  None of that is
unusual or outrageous.  For a company of Yahoo's size, it makes sense
to make sure that all relevant parts of their infrastructure are not
black-boxes, and they've done this in the past with many other
projects.

However, it IS a dated and wrongheaded approach, in my opinion.  Yahoo
ought to do what Joyent, Cloud9, Nodejitsu, Microsoft, and others have
done, and hire a developer (or several) to work directly on the open
source libuv and node projects, in a visible way.  Forking, renaming,
changing significantly, and then "giving back" is archaic in a day and
age when we can all work on the same thing together using modern tools
like git and github that make all of this completely visible.  If
ynode is so great, and ought to be shared, then share it; and if it's
not, then why bother with a separate fork?  Seems somewhat foolish.

Totally agree with everything you've said here... I was just relating a discussion that I had, because I happened to have an opportunity to speak to Doug in person. 

I'm not invested in defending his position ;)

 

But really, none of that is what I was confused about.  So, he'd open
source ynode.  Silly, but ok, whatever.  But what's "amateurish" about
"Joyent's management of node", exactly?  That's a bold claim.  A
person of Douglas's stature in the JavaScript community ought not to
make such bombastic statements in a public presentation unless he's
prepared to point to some examples of amateurishness.

My response to Mark:

"eh, there was, but it turned out to be something that was simply misunderstood and not really worth mentioning here. I'm not going to get involved with the "name calling" part of this discussion."

So, that still stands, I'm sure you can appreciate my position :)

 

Imagine if I gave a talk at a conference, where I said that Mozilla's
management of the spidermonkey project was amateurish.  Then, when
Brendan Eich (or whoever is the lead dev on the Spidermonkey project
at Mozilla, I don't actually know) emails me directly asking what he's
doing that is amateurish, and how I think it could be better, I do not
reply to him.  I'd expect a lot of people to lose respect for me if I
did that, and I'm nowhere near Douglas's level of nerd-fame.

I wasn't really addressing you—your comments were entirely reasonable. I was addressing the shit-talking dog-pile.

FWIW, I think it sucks that a former colleague would make you feel poorly about something that you put a lot of hard work into.

 

Rick

ps. In case it wasn't clear, the only part that I agree with is "threads have no place in JavaScript or Node".

[Bruno Jouhier]

ps. In case it wasn't clear, the only part that I agree with is "threads have no place in JavaScript or Node".

Would be interesting to have his opinion on WebWorkers. Aren't they threads in JavaScript? (same model as TAGG: message passing and share nothing)

Here is John Resig's take on them: http://ejohn.org/blog/web-workers/

But he's just a browser guy.

 

[Isaac Schlueter]

On Tue, Sep 18, 2012 at 12:31 PM, Rick Waldron <waldro...@gmail.com> wrote:
>
> ...

Thanks, Rick. Sorry, I didn't make this clear: your (and Doug
Crockford's) position that threads have no place in Javascript, is
pretty reasonable, and I appreciate you sharing the conversation you
had. You're good people :)

On Tue, Sep 18, 2012 at 1:03 PM, Bruno Jouhier <bjou...@gmail.com> wrote:
> Would be interesting to have his opinion on WebWorkers. Aren't they threads
> in JavaScript? (same model as TAGG: message passing and share nothing)

The implementation of WebWorkers is explicitly vague. They can be
done using any concurrency mechanism (green threads, coroutines,
threads, processes, etc.) The node child_process.fork() API is very
similar.

[P. Douglas Reeder]

FWIW, the webOS fork of Node
1) performs well on hardware with considerably fewer resources than the typical Node installation - it can serve files at the maximum bandwidth supported by WiFI while using less than a third of CPU time.
2) is stuck at version 0.2.3 (phones) or 0.4.12 (tablets)

So forking can offer benefits, but is not something to do lightly.

[Bruno Jouhier]

Implemented as green threads or coroutines??? That would be really daft. The UI thread would yield to the worker and be blocked while worker is running!!!

How are they implemented in Chrome? As threads in V8 isolates (like TAGG), or as child processes?

[Isaac Schlueter]

Rektide,

I told you exactly what has to happen if you're interested in pursuing this:

>>>
If you think that such a thing absolutely MUST be provided by the core
library, then that belongs in a github issue. Be prepared to make a
VERY strong case for it. It's a huge change to the architecture,
which was tried in the past and turned out to be not a good idea.
You'll need to be patient (since it will take a while), be willing to
help work on it, and have a plenty of new data showing that it's
actually a valuable change to make in the core, and why the problems
encountered last time can be overcome.

I can tell you that it won't have any chance of landing before 2.0,
and you'll have to (at least) convince Ben Noordhuis and Bert Belder
that it's worth doing. They're both rather skeptical right now, and
stubbornly fixated on "evidence" and "use cases" and "reasonable
trade-offs", so that'll be an uphill climb, but I've found them easy
to convince if you can provide these things. If you convince them,
that's probably the best way to convince me.
>>>

Familiarizing yourself with the node and libuv source code would be a
good place to start. You should treat this as an experiment: your
goal could be to figure out why several people close to the Node
project are so against a threading API, or resurrecting Isolates.
Collect data about what is possible using threads, which you can't do
now using child processes, and what you'd have to do to make libuv
thread-safe. Experiment with TAGG, and perhaps see how far you can
get with a purely userland approach to the problem. Figure out what
the limitations of TAGG are, and where you'd actually start
implementing it.

If you come back with sufficient data and understanding, I'd be happy
to reopen this issue. I think it's more likely that, armed with that
data, you'll see that threads are just not a good fit for a JavaScript
platform, at not worth the trade-offs required in libuv. But you
shouldn't not do everything people tell you not to do. Sometimes you
just gotta try the crazy thing ;)

> I humbly propose not participating in things which annoy you or you find overly distracting.

> Isaac: I fully confess to being an ignorant childish distracting useless retrogressive drag on the community, and I'm sorry if this discussion in fact hurts us. Also, seek trained medical professional help.

These comments are trollish and inappropriate.

[Isaac Schlueter]

On Tue, Sep 18, 2012 at 1:25 PM, Bruno Jouhier <bjou...@gmail.com> wrote:
> Implemented as green threads or coroutines??? That would be really daft. The
> UI thread would yield to the worker and be blocked while worker is
> running!!!
>
> How are they implemented in Chrome? As threads in V8 isolates (like TAGG),
> or as child processes?

I didn't say it would be GOOD, just that semantically, it could be,
and would be a compliant implementation. ;)

[Bruno Jouhier]

Isaac,

I just reread Ryan's announcement on the isolates feature (https://groups.google.com/forum/?fromgroups=#!topic/nodejs/eVBOYiI_O_A). At the time the word "thread" was not so horrible. Ryan was even talking about "debugging a multi-threaded node process".

The really critical point is not whether you go with threads or processes, it is the sharing semantics that you choose. If you go with "share nothing", threads and processes become "semantically" equivalent (maybe we can agree on this, at least). I think that threads are interesting because they are lighter (*) and they make (or should make **) it easier to implement zero copy.

(*) a TAGG thread is just an isolate + a thread; a child node process is much heavier.
(**) http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast

What I don't get is why the word "thread" has become so horrible and is causing such reactions. To me share-nothing threads are just an optimization over processes. What matters is the "share nothing" semantics.

I can understand that you consider threads to be a low priority on node's roadmap. As I said in my earlier post, the sweet spot of node is I/O intensive apps and these apps don't need this feature. What I don't understand is the irrational reactions that the word "thread" generates.

Bruno

[Paddy Byers]

Rektide,

I still am very much interested in technical discussion around this feature, know it abstractly but not deeply, and the cause of it being shelved remains shrouded in mystery.

I made an independent effort to implement isolates - in the sense of multiple node instances in a process, not TAGG - before the isolates effort by the core team. I wasn't privy to the discussion that led to the decision to remove the isolates feature, but I can give an overview of what I think the issues are in getting that feature implemented, stable and usable in practice.

Before diving in, I should say that this feature really is very different from TAGG, although they share the same underpinnings in terms of the v8 features used. Nonetheless, it is certainly confusing the whole discussion for them to be put into the same bucket.

My own use-case and constraints were quite specific, but the general motivations, as others have commented, were the possibility of:

- lower cost of message-passing between instances, avoiding a data copy. Nobody imagined, realistically, that passing object references from one instance to another was possible, but copies of primitive datatypes, buffers and serialised objects could in principle be enabled between instances in the same process;

- reduced context-switch times;

- reduced instance start-up time;

- miscellaneous reduced overheads from sharing of resources such as libev thread pool, fds, or whatever.

There's a summary of a number of implementation issues in this issue: https://github.com/paddybyers/node/issues/16.

The core team's implementation followed a similar path although there were differences in detail. All of this sounds quite achievable, and there's no reason why this set of features cannot be completed and stabilised with a lot of careful attention to detail. Don't underestimate the effort needed, and the time it will take to iron out all thread-insecurity problems with existing code, but possible.

However, that's only really the beginning. Once you've done this you confront three sets of issues:

1) Lots of expected behaviours simply aren't achievable. This includes state that is shared that people expect not to be shared: process.cwd(), process.env, process.setuid(); now you have to study your app - and reverse-engineer the modules you're using - to understand where these differences in behaviour will affect you. Child_process, SIGCHLD handling, and signal handling generally cannot be implemented completely faithfully. This is all OK if you're prepared to define, document, and accommodate the changed semantics, but it's a huge effort to migrate all existing code to a new set of assumptions - and only worthwhile if there's a big payoff.

2) Existing native modules now operate in quite a different regime, and all existing modules will be broken. When there is only a single v8 isolate you know it's OK to keep v8 handles in statics. You can also get away with being a bit lazy and/or buggy in the way you release native resources. None of that is possible when you have isolates; you need to track and release every resource explicitly and exactly, and you have to have a way of putting your object handles into thread-local storage or some other isolate-wide structure. Every single native module will fail when you use it in the second isolate in a process, which means that every single real-world app that uses a number of such modules will fail in unexpected ways. The maintainers of those modules might not have an interest in your use-case and that's a real barrier to getting any high-quality migration to the new regime.

3) The compelling performance gains you had as motivation for doing any of this are marginal at best. In fact, since you're now using thread-local storage to get context throughout the codebase, it's potentially slower most of the time. The shared memory that you thought was going to be the performance win turns out to be the thing that kills you, and you realise how powerful process separation, with the hardware assistance it gives you, really is. More or less every place you thought of using shared memory - and where it's a practical bottleneck - there's a way of getting pretty much the same thing between processes using shared memory or whatever.

Add these things to be backdrop of having other pressing reasons to get v0.8 out, and you can see why the decision was made to abort the development. I'm sure the decision wasn't taken lightly given the effort that had been sunk into it.

My own use-case for isolates still remains, however, and I do intend to migrate the work I did to v0.8+. I'm optimistic that the performance degradation from thread-local storage can be kept well below the 2-8% that Ben stated, and can be made negligible in the case that you only ever use a single default isolate. But that's speculation at the moment.

Please don't take any of the comments above to apply to TAGG, and I'm not commenting, either positively or negatively, on that.

Paddy

[Kevin Jones]

That's a great post Paddy, lots of the gore on the issue although I maybe don't totally agree on points 1 & 3. Most of process is trivial to virtualise, it's just an effort thing but you are right to point out the concern. But then maybe I am missing the point that your concern is over native modules getting inconsistent views of things shared in process? Signals I have not dealt with yet beyond noting the problem in libev with handling them on a non-default loop. I would think its fixable but haven't implemented it yet.

The performance gains I am seeing are largely down to avoiding OS costs in synchronization. When I first profiled thread message passing it was quicker than the cluster version, by about x5 from memory, the bottleneck was the OS overhead of using an async send. I recoded to avoid entering the OS via atomics and the performance gain shot up as you would expect. Now I have always done this kind of optimization in threaded environments so I know the story, what I don't know of is can you reliably do this cross platform with process shared memory and if you wanted to how would you cope with the memory management aspects of that. If that was solvable then arguably threads don't make any sense, although they may still be the lesser of two evils from a pragmatic point of view.

I decided to pull my work off github as its as done as I needed it to be at this point and clearly there is little wider interest without a lead feature. I was always more interested in pushing on the shared storage which is why I got involved with threads to start with so I am setting off down that route.

Kev

[Isaac Schlueter]

Bruno, I think your comments belong in the other discussion. This is
what I was referring to in that lame shared-state data corruption pun
I made earlier, about sharing data across threads :)

[Bruno Jouhier]

 
Yes they do. I'm following this through the Google web UI. The two discussions are interleaved in a single list and I did not pay attention to the titles. Maybe Google does not like threads either :-)

[rektide]

I wasn't really addressing you—your comments were entirely reasonable. I was addressing the shit-talking dog-pile.

I challenge you to find anything in this thread that directly shit-talks Node or Joyent. I *want* to believe this is fair and balanced discussion. Jorge got a little tweaked at one point, but still refrained from shit talking either.

 

ps. In case it wasn't clear, the only part that I agree with is "threads have no place in JavaScript or Node".

Who is shit talking now? Why hate Rick?

There's a whole lot of over-reactionary fear to a topic some people don't like: as Isaac once insisted, "lighten up people"

[rektide]

 

Yes they do. I'm following this through the Google web UI. The two discussions are interleaved in a single list and I did not pay attention to the titles. Maybe Google does not like threads either :-)

Sorry! I see the same WTF'itude: I meant to cleanly fork & provide some consistency, but it's a mess if you're not email-subscribed, and sorry for that: had hoped for better. How does Google Groups work?

http://3.bp.blogspot.com/-fuukRVObpiI/T_W_LVsivkI/AAAAAAAABB8/YcXkIn4QeDE/s320/magic.gif (translation: magic)

Not sure where this meme came from, having to rock some Axis of Eval here. For the record, although amusing, I'm pretty sure 'macros' is not actually what he's saying.

http://axisofeval.blogspot.com/2012/07/when-somebody-asks-me-how-i-added-dsl.html

[Rick Waldron]

On Wed, Sep 19, 2012 at 5:23 PM, rektide <rek...@voodoowarez.com> wrote:

I wasn't really addressing you—your comments were entirely reasonable. I was addressing the shit-talking dog-pile.

I challenge you to find anything in this thread that directly shit-talks Node or Joyent. I *want* to believe this is fair and balanced discussion. Jorge got a little tweaked at one point, but still refrained from shit talking either.

Reel it in dude, that's not at all what I was talking about. 

...I'm not even sure how you could come to that conclusion. (I don't really want to know either)

 

 

ps. In case it wasn't clear, the only part that I agree with is "threads have no place in JavaScript or Node".

Who is shit talking now? Why hate Rick?

My post script wasn't shit talking, it was clarification of my position, since I figured it might be easily confused as to who I was speaking for: myself, or Doug as I was relating a conversation.

 

There's a whole lot of over-reactionary fear to a topic some people don't like: as Isaac once insisted, "lighten up people"

Um. shut up?

Hugs and kisses, 

Rick

 

ps. I'm really a nice guy, hopefully we can meet in person some day and we'll laugh about this.

[rektide]

 > Isaac: I fully confess to being an ignorant childish distracting useless retrogressive drag on the community, and I'm sorry if this discussion in fact hurts us. Also, seek trained medical professional help.

 

 These comments are trollish and inappropriate. 

No, Isaac. I feel pissed on here. Ack that. People hate this topic. You joining them and saying this mere topic gives you hives? That is what makes me feel ignorant, like a child, worse than useless. I sought to be made better in February when I requested some cause for Isolates being dropped, I seek it now: the reply I've gotten is zealotry and bigotry, and my feeling brought low is natural and expected. I really do lament dragging us all down here, but I also hope there are people willing to tell me more than "see for yourself," as implicit in your February refusal to explain for yourself any reason why Isolates was dropped, as shown again explicitly in your turning it again on me that I must for myself investigate Node core and must find out for myself. Mercifully we have seen some exploration, from Ben, from Jorge, now from paddybyers, providing some great explanations.

> > The problem is that this shit is decidedly *not fun* for anyone but you and Jorge and maybe a few others and is a huge annoyance and distraction for everyone who would like to move forward and have fun talking about robots and websockets. Your discussion makes this list a place for endless debates between camps that have no adoption and people having fun playing devils advocate and not a place for people to talk about real stuff they are building and problems they have.

 

> I humbly propose not participating in things which annoy you or you find overly distracting. 

Mikeal was complaining about nothing except people discussing things, about feeling hurt for others talking. He deserves counter-meta-moderation, and there should be no problems with that. I unequivocally renounce any charge of trolling or inappropriateness on this front.

I don't wish to be inappropriate: the "threads have no place in node" crew vibrate with their dogmatic belief, and thusfar have not tried to explain their belief, but tried to emotionally exploit those who haven't fallen in to line: that's not leadership, nor civil. Thankfully those interested- striving for the topic- have found some of the faults and problems encountered, and have been willing to share: thank you for the exploration, civil gentlemen, thank you for civil and technical discourse.

[Mikeal Rogers]

On Sep 19, 2012, at September 19, 20123:21 PM, rektide <rek...@voodoowarez.com> wrote:

 

> I humbly propose not participating in things which annoy you or you find overly distracting. 

Mikeal was complaining about nothing except people discussing things, about feeling hurt for others talking. He deserves counter-meta-moderation, and there should be no problems with that. I unequivocally renounce any charge of trolling or inappropriateness on this front.

I take issue with these discussions because they make the list a place for your favorite arguments and alienate people from asking real questions about problems they have using node.js. Of the last 100 messages to the list less than 10% are about real user problems.

You don't have to be trolling to be alienating and counterproductive, which is what i charge this conversation with.

You're also ignoring the main point Isaac has been trying to make this whole time: **that this is not how you engage with the node.js project if you want to get something in to core.**

Isaac has reiterated over and over again what you would need to do to make this productive and nobody has followed up. It appears that you prefer to have a discussion that will bear no fruit other than satisfying your own intellectual curiosity at the expense of others.

What gives Isaac hives is the endless conversations you engage in on this list without any intention of actually creating any of the change you advocate for or taking any measurable steps to do so. Sending emails to a mailing list is not how things get done in this project, if you aren't willing to accept than then you'll need to find a new project to email your ideas to.

-Mikeal

[rektide]

On Wednesday, September 19, 2012 6:30:07 PM UTC-4, Mikeal Rogers wrote:

On Sep 19, 2012, at September 19, 20123:21 PM, rektide <rek...@voodoowarez.com> wrote:

 

> I humbly propose not participating in things which annoy you or you find overly distracting. 

Mikeal was complaining about nothing except people discussing things, about feeling hurt for others talking. He deserves counter-meta-moderation, and there should be no problems with that. I unequivocally renounce any charge of trolling or inappropriateness on this front.

I take issue with these discussions because they make the list a place for your favorite arguments and alienate people from asking real questions about problems they have using node.js. Of the last 100 messages to the list less than 10% are about real user problems.

Who here has been alienated anyone? Aside from you trying to shut me down Mikeal? Link me, anyone.

You don't have to be trolling to be alienating and counterproductive, which is what i charge this conversation with.

I certainly gained a lot more knowledge about threading than when I asked for an explanation in February of why Isolates was being cancelled. It may not lead to directly useful things for everyone, here, now but it's part of a wider dialectic, and I charge all civilized people with the responsibility to engage or at least be willing to permit dialectics to happen. I want to learn, I have learned: things were gained. Please deny that.

 

You're also ignoring the main point Isaac has been trying to make this whole time: **that this is not how you engage with the node.js project if you want to get something in to core.**

My main point is that this is a mailing list for discussion. 5% of topics are about node core. Should I show up in all them and tell them, on behalf of Mikeal, stfu, you're damaging our community? Would you like that? If not, just gtfo out of a useful constructive thread we're trying to have for interested parties on prospective ways of making Node core better: we're certainly closer to home than 95% of this mailing list. Do you deny that?

 

Isaac has reiterated over and over again what you would need to do to make this productive and nobody has followed up. It appears that you prefer to have a discussion that will bear no fruit other than satisfying your own intellectual curiosity at the expense of others.

 

I dunno. This is getting dangerously close to being technically topical: I for one have already challenged this thread that there is not much information on the failure of isolates, on where multi-threading has gone awry, and I hereby BEG you to find me some good juicy meat on why. I did try searching, I said that, and I already said this thread provided me a lot more background than I ever knew before. And still, in spite of you insisting we all respectfully STFU, I get fantastic new answers such as Paddy Byers contributing really detailed info we've, best I can tell, never had before.

I really really want to just be quiet about the last proposition, say nothing about it. 'satisfying your own intellectual curiosity at the expense of others'? You really think A) I expect satisfaction, or B) there's an expense here? Don't we have the faculty to not get dragged down by this if we're not interested? How much time am I or anyone else demanding of anyone? I'm sorry Mikeal: again, pass the hemlock: not only are you persecuting a victimless crime, now you're actually accusing me of being bad for trying to raise questions.

What gives Isaac hives is the endless conversations you engage in on this list without any intention of actually creating any of the change you advocate for or taking any measurable steps to do so. Sending emails to a mailing list is not how things get done in this project, if you aren't willing to accept than then you'll need to find a new project to email your ideas to.

And again I repeat the stance I issued you last: you and Isaac need to, for your own and everyone elses sakes, find ways to disengage and:

Lighten up people

Could not be an easier thing to deal with. Not sure why you're making it so hard. 

[Karl Tiedt]

This whole thread business [pun intended] is about the deadest horse
ever to have lived...

I will say this, out of all the mailing lists I am on... This is the
only one that gets these huge conversations where the majority of the
content is pointless to actually improving the community... (and
generally to the conversation itself) -- On other lists... it's
usually a sign that you should pay attention to that topic... no so
much here (in most cases).

It is very off putting and if it weren't for that fact that there are
a few very useful gems that come across the mailing list, I would have
left along time ago, but what little I get to work with Node in my
free time is important to me, and so I always end up tolerating it.

I would say that qualifies as alienating people, and I know I am not
the only one... there are countless others that chime in all the time,
trying to right the path of the topics...

It is a losing battle... but if you care at all about staying apprised
of community ongoings... you suffer silently [for the most part]
through it.

-Karl Tiedt

[Isaac Schlueter]

This issue is done.

> No, Isaac. I feel pissed on here. Ack that.

Ack'ed.

Your original request for threads-in-node has been met with
explanations from me, Ben, and Paddybyers about what would need to be
done to make that happen, and what the challenges are. There's
nothing else to discuss here.

[rektide]

I gently suggest that if we'd found and settled on some technical topics, rather than meta-moderation, there would be six or seven posts here. If you feel topics not to your interest, I revert to my former stance which is: don't read them.

This is a mailing list: 8/10 topics have no interest to me, but I'd be rude and out of line if I or anyone else showed up and claimed those people were alienating and annoying me by discussing a relevant topic they are interested in on my mailing list.

[rektide]

On Wednesday, September 19, 2012 8:55:00 PM UTC-4, Isaac Schlueter wrote:

> No, Isaac. I feel pissed on here. Ack that.

Ack'ed.

Your original request for threads-in-node has been met with
explanations from me, Ben, and Paddybyers about what would need to be
done to make that happen, and what the challenges are.

You are projecting defensively: I never requested this feature. I have no expectations for it.
 

There's
nothing else to discuss here.

I'd love an explanation fulfilling my February request: what factors lead to it being deemed Isolates was adding too much internal complexity?

We have had some discussion, but as to the effort that got the furthest, that seems to have been fairly close, the most information we have for it's cancellation is still:

cause[d] too much instability in node's internal functionality

And your guidance to go figure out what that means for myself:

You should treat this as an experiment: your goal could be to figure out why several people close to the Node project are so against a threading API,

Guess? Repeat the experiment and guess? That's a productive use of my time, becoming as good as Node devs at Node? You thought writing that would be a productive suggestion for a mailing list? I'm all for leadership by anarchy, but certainly there's no reason we ought NOT talk, why finding concordance with another or learning from another is a BAD thing? 

I don't demand my 'intellectual curiosity' be satisfied, I'm fine with "I'm not going to tell you." But I here re-affirm that this hunger is not sated, and that this issue is not closed. If there are Node.js people that feel they can provide technical contributions about what happened, I probably am not going to directly make Node.js better with that knowledge, but I think we'd all be better for the wisdom you knowing people can share.

[rektide]

ps. I'm really a nice guy, hopefully we can meet in person some day and we'll laugh about this.

Me too. I interpretted some subset of the conversation here as your intended target of shit-talking dogpile people, which didn't seem fair to me. Since you've disavowed that connection, attribute it elsewhere, well, fine, I'm not certain I understand, but that's cause enough for peace, and I'll rock that.