Zedshaw/Tir • Hacker News Board

Re: Zedshaw/Tir

#21

Post by sigil » Mon, May 21, 2012, 7:44 PM UTC

gcr wrote: post #17

sigil wrote: post #8

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. Ca…

(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 s…

Sorry, you seem to know all this.

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

Re: Zedshaw/Tir

#22

Post by wetbrain » Mon, May 21, 2012, 7:46 PM UTC

sigil wrote: post #8

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. Ca…

Check out http://sheddingbikes.com/posts/1289384533.html,

>Instead of one gigantic process that has to handle all of an application, you'd have a handful of little ones. Instead of scaling massive applications across a cluster, you just scaled each interface out as needed. Instead of upgrading the whole enchilada at once, you just upgraded each interface only if it needed it. Instead of worrying about migrating user's coroutines across upgrades you just did the "Erlang trick" and moved them over to the new deployments.

He goes on to describe Tir, the natural style, and Lua's coroutines. Great intro to a fun framework.

Re: Zedshaw/Tir

#23

Post by sigil » Mon, May 21, 2012, 7:54 PM UTC

wetbrain wrote: post #22

sigil wrote: post #8

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. Ca…

Check out http://sheddingbikes.com/posts/1289384533.html , >Instead of one gigantic process that has to handle all of an application, you'd have a handful of little ones. Instead of scaling massive applications across a cluster, you just scaled each interface out as needed. Instead of upgrading the whole enchilada at once, you just upgraded each interface only if it needed it. Instead of worrying about migrating user…

Instead of worrying about migrating user's coroutines across upgrades you just did the "Erlang trick" and moved them over to the new deployments.

I'd like to hear how this works in detail. Suppose a user is exercising a multi-request handler, say pagination of personalized results.

At what point do you kill the coroutine and let the next request start a new handler in the new, upgraded process? What about state that the coroutine may have that hasn't been persisted anywhere else?

Re: Zedshaw/Tir

#24

Post by draegtun » Mon, May 21, 2012, 7:59 PM UTC

vph wrote: post #7

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

Have a look at Nagare - http://www.nagare.org/

Re: Zedshaw/Tir

#25

Post by davidhollander » Mon, May 21, 2012, 8:59 PM UTC

sigil wrote: post #8

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. Ca…

> Can this eliminate the callback hell that plagues the explicitly async frameworks (node.js, jquery, twisted, etc)? But what about the downside? Can you migrate the suspended coroutine to another process

No, Lua coroutines only provide language or syntax level concurrency. They make routines more stateful, which can be a benefit if you want to refer to the same local variables and scope in between yields, but do have the downside of incentivizing routines to be larger in size (although you rely on fewer of them).

Also, the use case for coroutines is really limited to expressing lists of serially occurring tasks. This can work well for request-response style applications. But if for instance, you need to be able to read from, write to, and wait for timeouts on the same socket simultaneously (say a chat room), it would be a bit silly to spawn 3 coroutines per client (or 1 with heavily branching code), and use unnecessary overhead than simply binding and dispatching function calls for events without using a coroutine.

Regarding dispatching function calls for events, this can also be done in a variety of ways without creating a soup of nested lambdas. For instance, local functions or object methods. This also avoids the instantiation of additional function values (lambdas) for each client, which doesn't really slow things down in Lua but uses up more memory.

Re: Zedshaw/Tir

#26

Post by zedshaw » Mon, May 21, 2012, 9:19 PM UTC

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.

Re: Zedshaw/Tir

#27

Post by zedshaw » Mon, May 21, 2012, 9:32 PM UTC

sigil wrote: post #8

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. Ca…

Scaling isn't so much the problem, since you can do various things to keep users on specific servers. In my setup, I also solve a lot of the state issues since there isn't a single state for the entire app, but instead for each process that runs a small part of the app. That means you can scale and change up the application easier if you need without impacting the other parts.

The real problem with coroutines for storing state is simply that upgrading the code requires you to either kill all the old state, or trickle users off on A/B paired processes. Because the state is tied to the code, you can't just change the code and hope it works. Everything will be off and the coroutines won't continue.

Since Tir uses tiny processes, it's easier to do these upgrades in one part without killing the other parts, and since users are never in any one process for very long by design the risk is smaller.

But, you definitely have to be more careful than the other models.

Re: Zedshaw/Tir

#28

Post by zedshaw » Mon, May 21, 2012, 9:36 PM UTC

stcredzero wrote: post #6

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…

That used to be a problem before luarocks, but now with luarocks you don't have to worry about it. You get fragmentation anywhere you go in every langauge no matter what. The problem in other "batteries included" languages is the core team dictate to everyone else the primary libraries, and then many times they refuse to update them and you have to work around them.

In Lua, you don't have to do any of that. Lua gives you the kernel, then you add everything else you need.

Re: Zedshaw/Tir

#29

Post by sashahart » Mon, May 21, 2012, 9:38 PM UTC

vph wrote: post #7

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

Would you mind saying a little about what kind of thing you are looking for? I am curious.

Re: Zedshaw/Tir

#30

Post by zedshaw » Mon, May 21, 2012, 9:38 PM UTC

dinedal wrote: post #5

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

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