Message from discussion fibers 0.5; say "no" callbacks (when it makes sense in your application)
Received: by 10.236.176.36 with SMTP id a24mr1503770yhm.60.1312708402077;
Sun, 07 Aug 2011 02:13:22 -0700 (PDT)
Received: by 10.91.66.28 with SMTP id t28ls15860465agk.3.gmail; Sun, 07 Aug
2011 02:13:12 -0700 (PDT)
Received: by 10.90.168.7 with SMTP id q7mr274988age.45.1312708392534; Sun, 07
Aug 2011 02:13:12 -0700 (PDT)
Received: by f20g2000yqm.googlegroups.com with HTTP; Sun, 7 Aug 2011 02:13:12
Date: Sun, 7 Aug 2011 02:13:12 -0700 (PDT)
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0)
Subject: Re: fibers 0.5; say "no" callbacks (when it makes sense in your application)
From: Bruno Jouhier <bjouh...@gmail.com>
To: nodejs <email@example.com>
Content-Type: text/plain; charset=ISO-8859-1
Sounds so familiar! And very well written!
Bruno, another maladjusted weirdo who wakes up in the middle of the
night thinking about software while the others carry on their dreams.
On Aug 7, 4:37=A0am, Will Conant <will.con...@gmail.com> wrote:
> Here's the reason I'm using node-fibers for my current project:
> I'm using it to hoodwink my team and my clients into building software
> that has the potential to really scale.
> Among the programmers that I work with, I'm the maladjusted weirdo
> that spends all his time thinking about software. I spend the whole
> work-week writing software, and then I spend all weekend writing
> software too. When I drive my car, I think about software. When I go
> for walks, I think about software. Most of the programmers I work
> with, on the other hand, are pretty well adjusted people. They put in
> 40-45 hours of programming per week, and they spend the rest of their
> time hanging out with their kids or riding their mountain bikes.
> It doesn't matter what I think about the ease and clarity of using a
> callback-style API to talk to the database. They won't like it. They
> won't do it. They'll make fun of me. They'll convince everyone I'm
> crazy, and we'll have to go back to Perl.
> With node-fibers, I have tricked them, and here's how: I wrote every
> bit of code that spawns fibers or yields control. I hid that stuff in
> libraries with nice traditional synchronous APIs. I fibbed a little
> bit and told them that each web request, api request, and triggered
> process ran in its own thread-like thing that may be suspended at any
> moment. I told them to call me the moment the word "mutex" popped into
> their heads.
> I am well aware that there will be complications. I'm sure they'll
> occasionally find ways to make code that behaves very strangely. I'm
> sure they'll call me with baffling problems, but, honestly, it's
> always been that way. I'm always the guy who understands the whole
> framework. Everyone else is usually content to write request handlers
> and business logic. They leave the weird stuff to me.
> To be fair, I'm dramatizing this story a little bit. Of course, I had
> to sell everyone on a modern concurrency solution in the first place,
> and, of course, I explained how the whole fibers thing was going to
> work. But the crux of the sale was the assurance that they wouldn't
> have to think about it--that I would take care of the tricky stuff,
> and they'd be able to write nice normal code.
> I came up with this plan a long time ago, and I considered many
> alternatives to Node/node-fibers. Erlang is too weird. Go's static
> types are mediocre for manipulating JSON data structures. Perl/Coro is
> still going to leak memory, and it won't work with all the synchronous
> CPAN modules. Ruby 1.9 is almost there, but you still have to avoid
> all the synchronous modules. The actual runner up was Node/streamline,
> but streamline has its underscores and confusing stack traces.
> Regardless of the intent of its authors, Node was made for fibers.
> They don't need to add fibers to the core. Marcel has done an
> excellent job of making fibers work as an npm module, so they're off
> the hook.
> Without fibers (or something like it), Node wouldn't even be on my
> radar. It simply wouldn't solve my problem, which, to summarize, is
> marrying modern concurrency with traditional server-side programming.
> I doubt the authors even care. From their perspective, I'm using their
> software to do something they didn't build it for. I might even be
> using it to do something they think is despicable.
> However, I'm going to make a prediction: In a couple of years, I'll
> have a lot of company. Lots of development teams are composed of nerds
> and bigger nerds. The bigger nerds will want to use Node for its
> amazing power and flexibility, and they'll want to use fibers to hide
> the tricky details from their teammates behind a facade of clean,