
Zedshaw/Tir - shawndumas
https://github.com/zedshaw/Tir
======
sigil
I'm really excited about async programming in what Zed dubs the "natural
style": using coroutines to suspend and resume processing at points where
input is needed.

Can this eliminate the callback hell that plagues the explicitly async
frameworks (node.js, jquery, twisted, etc)?

But what about the downside? Now your handler is stateful and the language
runtime is taking care of suspend / resume of the handler code. Can you
migrate the suspended coroutine to another process, possibly on another
machine? Or do you just take care to use sticky load balancing for all your
stateful routes?

HN does something similar right? My understanding is that the fnid=... query
param identifies a closure that's serving up a pagination of stories, and the
"Unknown or expired link" error message happens when your own personal closure
gets garbage collected by Arc.

In both the coroutine and closure cases, you've got something on the server
side that's consuming resources even when there are no requests. This seems
like a problem for scaling.

~~~
gcr
(Edit: Sorry, you seem to know all this. Keeping my post here for posterity)

The logical end to this road is continuation-based web servers. See
<http://docs.racket-lang.org/continue/index.html> and my approach to the Arc
challenge, <https://gist.github.com/1304257>

The interesting function which does all the work is:

    
    
      (define (start req)
        ;; First, we get input from the user
        ;; Then, we pause for the link
        ;; Finally, we show what the user typed.
        (let ([input (get-input-from-user)])
          (pause-for-link)
          (show-input input)))
    

Each of these calls - _get-input-from-user_ , _pause-for-link_ , and _show-
input_ sends a complete page back to the user and waits for them to click a
link or submit a form request. It's a really smooth way of solving some
problems.

~~~
sigil
_Sorry, you seem to know all this._

Not at all, this is interesting. Thanks for the info.

------
stcredzero
_No Core

This isn't really a Tir feature, but do you hate when there's bugs in your
core libraries and that guy who "owns" the broken library refuses to fix it?
Me too, that's why Lua and LuaRocks are awesome. You get a tight core language
that's completely described in_a_few_HTML_pages and then install all the
platform libraries you need with LuaRocks. No more gatekeepers with Lua._

"No more gatekeepers" seems to be a theme with Zed's contributions of late.
(And quite possibly over a longer time span.) In the case of Lua, the role of
"core" and the "glue" are both a particular small and fast language. Because
"core" is so small, any "benevolent dictators" in this environment have a
small footprint. (Yes, there's a "small government" analogy here, but let's
leave the politics out.)

The price of this is library fragmentation. There's more than one approach to
objects, for example.

I wonder if there's a middle ground? Node.js seems successful in promoting a
community standard of no blocking code.

~~~
wetbrain
>The price of this is library fragmentation. There's more than one approach to
objects, for example.

I've found that to be the case with Lua in general. The language is pretty
easy to hack with, and so there's alot of wheel making. Lua has a mantra of
"provide mechanisms, not policies", and since there's no formal class system,
and multiple ways to define modules it's almost fragmented by design.

I think the designers are working on a better module system for the next
release, or did that make it into 5.2?

------
dinedal
Actually really excited about this.

My big problem with most frameworks is that any moderately sized application
becomes excruciatingly monolithic. With Rails, the idea is that you have more
code reuse, but then this becomes booting the whole of the universe to do
something simple. Most of the time, your feature only needs a model, or a tiny
part, of the application to do it's thing.

With Tir, you have a bunch of small parts working together. You can reuse the
code, but the process only needs to load the parts it needs to work with. The
implicit nature of rails really hurts it's ability to scale a particular part
of the application without having to install the entire application.

An example, you scrape twitter for mentions of your app and shove them on your
homepage. Twitter rate limits, so you background job this and run it in an
interval. In the rails world, this means a resque / utility server, running
the same code, each working booting up the full app, same deps, same model.

In Tir, there's no reason to do that. Create workers, have them load only the
needed bits to access twitter and your model, make updates. Very light weight.

However: PUB/SUB for workers? Really? Can't we get mongrel2 style work N:M
(PUSH <\- PULL, PUB <\- SUB) distribution? This way we at least have an
assurance that only one worker will get the job.

~~~
zedshaw
You can make the workers do whatever you want, that's just the default setting
since it's the most common.

------
j2labs
Python folks might be interested in Brubeck. It too pulls messages directly
from mongrel2 and provides coroutines for its concurrency abstraction.

<https://github.com/j2labs/brubeck>

------
rufugee
So....this has been posted about a few times in the past
([http://www.hnsearch.com/search#request/all&q=tir](http://www.hnsearch.com/search#request/all&q=tir)).
Where's the news here?

~~~
batista
The news, to you at least, might be that HN readers don't read each and every
article religiously on the front page, day in and day out.

Thus, a large subset of us can discover and discuss an article after multiple
postings.

------
chaostheory
This description in the title would help: "A Simple Lua Web Framework For
Mongrel2"

~~~
danso
Agree. Though I clicked mostly for the "Zedshaw" in the title.

~~~
alphakappa
Same here. The framework is interesting, but having zedshaw in the title makes
it more so since many of us are interested in knowing what he comes up with.

------
egonschiele
This would have been cleaner with Moonscript:
<https://github.com/leafo/moonscript>

~~~
zedshaw
No, just different. And Klimt is better.

------
vph
I would be nice to see Zed created a framework in Python. I am not happy with
any of the existing ones.

~~~
draegtun
Have a look at Nagare - <http://www.nagare.org/>

~~~
apoirier
Yes, Nagare (<http://www.nagare.org>) is a continuation-aware Web framework
with the same components model than Seaside.

Python Stackless is used to take continuations and also to serialize all the
states, which can be stored, by configuration, in memory or to an external
Memcached server. With the later setting, all the continuations can freely
migrate across the machines of a cluster.

------
namidark
Why is something not updated in 4 months big news?

------
zedshaw
Warning folks: Since I've been working on my books I haven't had time to hack
on this lately. I will be picking it back up when I have a break from the
books to code up a few ideas I have.

~~~
shawndumas
I know this is off topic but are there plans for a learn lua the hard way.

~~~
bsg75
Its time for a new (non-game specific) Lua book.

------
jes5199
How is the state stored for "natural style" functions? Is this continuation
style something that Lua supports natively?

~~~
jmaygarden
Lua has built-in support of this functionality through coroutines [1].
Serializing the coroutines to a database does requires a library [2].

[1] <http://lua-users.org/wiki/CoroutinesTutorial>

[2] <http://lua-users.org/wiki/PlutoLibrary>

