Render realtime RethinkDB results in React • Hacker News Board

Re: Render realtime RethinkDB results in React

#21

Post by tinco » Sat, Jul 04, 2015, 4:30 PM UTC

15155 wrote: post #15

tinco wrote: post #14

I've got a toy RethinkDB+React stack too, here's an example application: https://github.com/tinco/celluloid-rethinkdb-chat It's Ruby+Celluloid doing subscriptions on RethinkDB, and it uses Meteor's DDP protocol to talk to the React client side. Was pretty easy to build. All the modern technologies fit really well together. Unfortunately in the Ruby world live webservices like this haven't really taken off much yet, s…

> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style.

That they never will has more to do with the general attitude of Rails programmers, and their commitment to the REST request/response model. Libraries that offer more flexible interactions are simply not very visible yet.

Slightly related but not relevant now, Ruby 3.0 is expected to have some concurrency construct fundamentally integrated into the language.

Re: Render realtime RethinkDB results in React

#22

Post by [deleted] » Sat, Jul 04, 2015, 5:24 PM UTC

veb wrote: post #11

applecore wrote: post #4

Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.

I'm not sure that grabbing yourself a slice of the hype-pie is necessarily a bad thing. Learning is good for the soul, right? I do get your point, if you had one. It does feel like there's a must-have new shiny thing to prod every other day. However, React seems to be even shinier than others as of late -- I know this because I even read the documentation and played with the tutorial! I do admit that I can't really c…

[deleted]

Re: Render realtime RethinkDB results in React

#23

Post by nothrabannosir » Sat, Jul 04, 2015, 5:32 PM UTC

tinco wrote: post #21

15155 wrote: post #15

Earlier quoted context omitted.

> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style. That they never will has more to do with the general attitude of Rails pro…

Never did any Ruby, nor Node.js, so take this with a grain of salt.

What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't).

Because Node.js has no threading, async I/O is the only choice. Result: 100% of the libraries are async I/O.

Because Go has M-N threading, all I/O is inherently async for the OS, even if it's sync for the semantic threads. Result: 100% of the libraries are async I/O.

Scala and Java have Futures and all the other goodness you would theoretically need to make async HTTP requests. But, as an example, the official AWS access library (a wrapper around the AWS REST API) is synchronous. Result: communicate with AWS in your backend during a request? Block an OS thread, or write your own AWS library.[1]

Even having async I/O as an option at all splits your language in two. Most libraries will fall in the sync category, and their mere existence lowers the incentive to write an async one. E.g.: if there were no AWS library for Java / Scala, I would be much more keen to write an async one myself. But now? Ah well, // TODO: async, and continue.

This is the beauty of Go and Node.js on the server.

[1] Or choose an unofficial and, I'm rudely assuming, less complete / audited / reliable library.

Re: Render realtime RethinkDB results in React

#24

Post by 15155 » Sat, Jul 04, 2015, 6:02 PM UTC

tinco wrote: post #21

15155 wrote: post #15

Earlier quoted context omitted.

> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style. That they never will has more to do with the general attitude of Rails pro…

You're right, Node.js has no concurrency primitives, but it has true first-class functions.

Ruby lambdas are an afterthought and far too expensive to use in the same expansive capacity as you would in JS (or literally any functional programming language).

Couple that with the fact that the community just doesn't care, and again, I ask why bother?

The actor model isn't superior to callbacks in any technical capacity, and understand, callbacks are only a (perceived) problem when you don't have something like a language-level async/await to transform them for you.

edit: Add in the (MRI) GIL, and you've got yourself a fairly serious impediment to writing efficient, concurrent code.

Re: Render realtime RethinkDB results in React

#25

Post by 15155 » Sat, Jul 04, 2015, 6:09 PM UTC

andrewmutz wrote: post #17

15155 wrote: post #15

Earlier quoted context omitted.

> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.

The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven model, there are good options for most languages.

It has everything to do with Ruby.

With Go, Node.js, Erlang/Elixir, you don't enter the stage assuming that every operation you do is actually going to block others.

Concurrency is not a first-class concept in Ruby (nor Python).

Yes, EventMachine exists. Ok, it's not the standard nor norm, and I would wager most Ruby programmers have heard of it but haven't actually used it.

Even if you're using EventMachine or Twisted, those technologies are infectious (by necessity, not complaining here)- everything you build or use needs to utilize those primitives to work successfully.

In Node.js, the assumption is that nothing will block a calling thread (in favor of asynchronous callbacks).

In Go, the assumption is that goroutines (via a semi-preemptive scheduler) will not block their caller.

In Erlang, the assumption is that processes will not block one another (with a fully preemptive scheduler).

As a fan of Node.js- I will state, not having a widely-accepted, standard interface for building concurrent programs (vs. the soup of callbacks/Promises, associated async/await implementations, coroutines via generator functions) has been a severe detriment to the community.

Re: Render realtime RethinkDB results in React

#26

Post by 15155 » Sat, Jul 04, 2015, 6:13 PM UTC

nothrabannosir wrote: post #23

tinco wrote: post #21

Earlier quoted context omitted.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style. That they never will has more to do with the general attitude of Rails pro…

Never did any Ruby, nor Node.js, so take this with a grain of salt. What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't). Because Node.js has no threading, async I/O is the only choice. Result: 10…

This is exactly my experience as well.

If you provide synchronous, blocking interfaces and no concurrency primitives or expectation of non-blocking functions, IO, etc., people will use them.

In languages where concurrency is a built-in, understood pattern (Go, Erlang/Elixir, Haskell*, to name a few) people don't need to care.

Ruby has the worst of many worlds (sync I/O by default, incredibly expensive memory model, incredibly expensive lambdas, first-class functions aren't normally used beyond the "do block"-- nobody is passing them around, chaining, etc.)- I just don't see the reason to keep trying to squeeze blood from this turnip.

Re: Render realtime RethinkDB results in React

#27

Post by jsprogrammer » Sat, Jul 04, 2015, 6:13 PM UTC

nothrabannosir wrote: post #23

tinco wrote: post #21

Earlier quoted context omitted.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style. That they never will has more to do with the general attitude of Rails pro…

Never did any Ruby, nor Node.js, so take this with a grain of salt. What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't). Because Node.js has no threading, async I/O is the only choice. Result: 10…

>Because Node.js has no threading, async I/O is the only choice. Result: 100% of the libraries are async I/O

All async I/O functions have a corresponding sync version.

E.g.

  const buffer = fs.readFileSync(path);

Re: Render realtime RethinkDB results in React

#28

Post by 15155 » Sat, Jul 04, 2015, 6:17 PM UTC

nothrabannosir wrote: post #23

tinco wrote: post #21

Earlier quoted context omitted.

I'm not sure where your opinion comes from and what concurrency primitives you are missing in Ruby, but Node.js simply no concurrency primitives at all and it's doing just fine. The I/O framework I use in that RethinkDB example is Celluloid, which implements actors, a concurrency model that is widely regarded as superior to the callback style. That they never will has more to do with the general attitude of Rails pro…

Never did any Ruby, nor Node.js, so take this with a grain of salt. What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't). Because Node.js has no threading, async I/O is the only choice. Result: 10…

> All async I/O functions have a corresponding sync version.

They do, but they're widely frowned upon in most applications.

They're completely frowned upon in server-related applications.

I've only really seen them used in cheap build scripts, and now with async/await (via Babel's regenerator transformation), I don't even see that much anymore.

Re: Render realtime RethinkDB results in React

#29

Post by jsprogrammer » Sat, Jul 04, 2015, 6:41 PM UTC

veb wrote: post #11

applecore wrote: post #4

Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.

I'm not sure that grabbing yourself a slice of the hype-pie is necessarily a bad thing. Learning is good for the soul, right? I do get your point, if you had one. It does feel like there's a must-have new shiny thing to prod every other day. However, React seems to be even shinier than others as of late -- I know this because I even read the documentation and played with the tutorial! I do admit that I can't really c…

React is so shiny that it sucks your entire application (HTML and CSS included) up into it's non-standard JavaScriptified web-page format.

Re: Render realtime RethinkDB results in React

#30

Post by crucialfelix » Sat, Jul 04, 2015, 6:44 PM UTC

zachallaun wrote: post #16

crucialfelix wrote: post #9

Interesting approach. I would still rather connect to RethinkDB with a frontend service and push those to stores and have the component watch the store. Because while this might work for a small use case, a real world usage will quickly outgrow that and you will wish you hadn't stuffed such functionality in a display component. So this is probably most useful for quick sketches and debugging stuff.

Could you elaborate on this? This project seems to be moving in the same direction the React team is with Relay and GraphQL – the component describes the query it requires to render itself, and a query/caching layer executes the query automatically.

What I described as a Service would be what this query/caching layer is. I would just rather not have it embedded in the Component, making it harder to follow what a Component does. The beauty of them is that they are simple to read and understand. The more mixins you use, the more esoteric it gets and you have to read a bunch of code to understand why the render function magically has these properties to display with.

Another point would be that the service or store could be re-used in more than just react, and it can be tested without having to consider the UI.