It's becoming more like... GASP JavaEE GASP
Yes, I can see how Rails evolving to match the evolving needs of its users can give that impression... /s
Why Rails 4 Live Streaming is a Big Deal
31–40 of 60 posts
Re: Why Rails 4 Live Streaming is a Big Deal
#32Earlier quoted context omitted.
"Why your web framework should not adopt Rack API" by José Valim http://blog.plataformatec.com.br/2012/06/why-your-web-framew... "This blog post is an attempt to detail the limitations in the Rack/CGI-based APIs that the Rails Core Team has found while working with the streaming feature that shipped with Rails 3.1 and why we need better abstractions in the long term."
Broken middlewares won't be any less broken now that before.
They are less broken now. The Rails team put a lot of effort into fixing them in the past three releases.
Re: Why Rails 4 Live Streaming is a Big Deal
#33It's becoming more like... GASP JavaEE GASP
Rails: reinventing Java one feature at a time (and that's not necessarily a bad thing)
Re: Why Rails 4 Live Streaming is a Big Deal
#34Earlier quoted context omitted.
I'm actually quite excited about this, because I think it makes a lot of sense for this to be in Rails, for a couple of reasons. First of all, there aren't really any decent solutions for the problem in Ruby. There's a few projects with great potential, but nothing really mature - when I needed to do this, I went with cramp.in, which hasn't been updated in over 6 months now sadly. Node.js would unequivocally have bee…
> First of all, there aren't really any decent solutions for the problem in Ruby. Uh? Rack has supported streaming since the beginning, and Sinatra has had special support on top of that since 1.3. > Secondly, even if there were mature Ruby equivalents to Node.js http://rubyeventmachine.com/ > I can still see a lot of benefit to doing this in Rails. Don't dismiss the drawbacks. Such as self-DOS-ing. Your Rails applic…
Rack 1.x doesn't have end-to-end streaming, and certainly not with a socket-style API. The Rack specification mandates buffering and rewinding input, and while it's possible to write a rewindable input stream (I've actually seen it done) nobody has ever written a stable one.
EventMachine is poorly maintained and doesn't have the same level of community support as Node.js, not to mention an ugly API. Of course, Node.js doesn't have the same level of maturity as Twisted Python but Twisted doesn't get any hype whatsoever.
Re: Why Rails 4 Live Streaming is a Big Deal
#35"Cons: If a thread crashes, the entire process goes down."
I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
"Good luck debugging concurrency bugs."
Good luck debugging concurrency bugs in a callback-driven system!
Re: Why Rails 4 Live Streaming is a Big Deal
#36"Cons: If a thread crashes, the entire process goes down." I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false. "Good luck debugging concurrency bugs." Good luck debugging concurrency bugs in a callback-driven system!
> I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false.
I'm talking about CPU instruction level crashes, not language level crashes. Things like writing to an invalid memory address or heap corruption.
> Good luck debugging concurrency bugs in a callback-driven system!
Actually I already mentioned concurrency bugs in evented systems in the article.
Re: Why Rails 4 Live Streaming is a Big Deal
#37Earlier quoted context omitted.
Ajax requires long polling, this PUSHES the response to the server, thus obviating the need for long polling.
> this PUSHES the response to the server Erm... it pushes the response to the client, not the server, and only pushes after a normal HTTP request. And of course, it also ties up a huge amount of server resources (total number of clients = total number of workers, since each client permanently ties up a connection forever). Phusion Passenger's docs recommend 8 workers/GB RAM, hope you expect users.
> total number of clients = total number of workers, since each client permanently ties up a connection forever
Totally up to your application server. Actual formula is number of clients = total number of threads. It is up to app server to handle parallel requests.
Re: Why Rails 4 Live Streaming is a Big Deal
#38Rails is turning into a framework that includes everything, including the kitchen sink. Personally, I prefer to use the best tool for the job and node.js seems to be a much saner choice when doing realtime communication, since everything in node.js is non-blocking. There are so many ways to shoot yourself in the foot if you develop large realtime systems in Ruby (or any other language that includes a lot of blocking…
I think the problem is that Rails was designed to solve the web problems of 2005 and a lot has changed since then. The shift to single-page, JS-driven applications and large numbers of dynamic updates requires a different set of design priorities and the performance characteristics of Ruby itself are more problematic in this environment. In many cases it makes more sense to use something like Go or Node or Erlang tha…
"Shift"? I'd go for "emergence." The classic use cases are still alive and well.
Re: Why Rails 4 Live Streaming is a Big Deal
#39Earlier quoted context omitted.
> When Rails starts including a messaging stack, job server, and more, then I'd be right behind you in your complaint. Actually, Rails 4 does include a job queue: https://github.com/rails/rails/commit/adff4a706a5d7ad18ef053... However, I'm not complaining. ;)
Well to be more accurate: it includes a job queue API with the actual implementation being pluggable. It does not do job queuing by itself. It's just like the cache API, actual implementation depends on the cache store.
True, thanks for the correction. The person I responded to said "job server" and I'm not 100% clear on what that would cover - perhaps job queue API would fit that description, perhaps it wouldn't.
Re: Why Rails 4 Live Streaming is a Big Deal
#40"Cons: If a thread crashes, the entire process goes down." I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false. "Good luck debugging concurrency bugs." Good luck debugging concurrency bugs in a callback-driven system!
> I wrote this thing called Celluloid and I can assure you this isn't true. Ruby has "abort_on_exception" for threads, but the default is most assuredly false. I'm talking about CPU instruction level crashes, not language level crashes. Things like writing to an invalid memory address or heap corruption. > Good luck debugging concurrency bugs in a callback-driven system! Actually I already mentioned concurrency bugs…
"Things like writing to an invalid memory address or heap corruption."
So what you're trying to say is if the entire virtual machine crashes, you lose all running threads.