picardo

For an outsider, Rust is still barely usable. I tried building a simple demo using the beta release today, and regretted right away. Lots of "unstable feature" errors that I can't figure out how to get rid of. Many useful features are unstable. I don't think I'm going to touch it again for a few months.

You're exactly right. It's sad that a lot of people in the community cannot keep an open mind when they evaluate a technology.

I'd be interested in seeing a solution in Prolog.

This might need some updating. I did a quick run through and it recommended me to use a table-cell for vertical centering. You might be able to do that more easily with flexbox.

Does it write to a disk or to a log? If it writes to disk, it may still not be completely fail-safe unless it also writes to a log before writing to disk. Postgres for example has a write ahead log and it writes to disk before acknowledging the write.

Writing to memory before writing to disk can be safe if you do it right. You need to deploy multiple instances in a replica set with a quorum threshold to guarantee safety. This is what Cassandra provides off the box. I don't think MongoDB made it clear at the start to its users that you should never work with a single database instance if you don't want to lose data.

I just discovered that. They're using building polyfills to simulate the browser behavior, too. Very cool.

React Native is only the view layer. There is a ton more to an app than just the view layer.

Are you familiar with the psychological research about bias in decisionmaking?[0]

It sounds like you have come to the same conclusion psychologists are coming to. Under stress, the human mind uses mental shortcuts, or heuristics, while making important decisions, and act irrationally.

I don't often come across a post that takes on these biases so systematically, and translates them into one of the most important decisions a startup has to make, i.e. the hiring decision, and you even invent useful ways to mitigate their effects. Kudos for that!

Every company should be doing this. Overcoming bias should be a top priority at all HR departments.

-------

[0] http://en.wikipedia.org/wiki/Heuristics_in_judgment_and_deci...

Don't forget that Relay means replacing your RESTful routes. If you still want to work with RESTful endpoints, you are going to work with Flux.

This is so beautiful! I can see this being used for building canvas based web applications as well!

I've been looking into that myself, but then I found Elm[0] and stopped looking. :)

-------------------

[0] elm-lang.org

CoffeeScript syntax is better and cleaner than the ES6 syntax. It's a fun language, and I've been using it everyday since it came out. On small projects, it's top-notch.

But the future of CoffeeScript is bleak because many software designers are beginning to understand the value of type systems, e.g. TypeScript and Flow, for building maintainable Javascript code bases, and this means CoffeeScript is out of the picture for good because its long term design goal is to remain a minimalistic language, and doesn't intend to support these ideas. There have been attempts[0] to fork it to add a legitimate type system to it so it can scale, but they have faltered. Aside from that, the way CS deals with variable shadowing[1] makes it risky to use in large codebases.

So when ES6 syntax is tolerable and stable, I will pack my bags and move over to the ES6 land with great regret. I wish I could stay in CS land for longer, but you have to put away childish things eventually.

------------

[0] https://www.npmjs.com/package/typed-coffee-script

[1] http://stackoverflow.com/questions/15223430/why-is-coffeescr...

Is there build of this that lets me require a single function?

I could also use a jackhammer, but that's not what jackhammers are for.

You're right about the boilerplate. I use a wrapper around React.createClass to take care of that. Kinda similar to Marty.createStateMixin, but it's just a component factory.

The Chrome plugin looks very nice, but you can do the same thing with console.log() outputs in your store. It's a nice to have, but not filling a need for me.

Nice documentation. But I don't see anything groundbreaking here. The whole rationale for Flux is to unidirectional state flow, and it does that quite well. A lot of library creators have focused on the tiny quibbles with "ease of use" around stores and constants –– "state management" is a good euphemism for this need –– but that's not really a bottleneck for me. I can manage my constants manually with Flux, and add listeners myself. If I need to indicate a dependency between to stores, I can use a waitFor in the switch/case block. It's that simple. Why should I learn a bunch of abstractions that make only an incremental difference?

My only pet peeve with Flux is that it does not let me dispatch from within an ongoing dispatch, which is not a huge deal yet because you can just defer the callback to the next event loop, but it's not allowing me to pipeline actions as I thought it should. I have to wait for the stack to empty out before I can dispatch a new action, which sucks. Also, there is no indication as to when a dispatch is over, so I am deferring dispatches by instinct –– or wrapping them in a promise might be the same thing.

Can you elaborate on why you group Rust and Ruby together, and group Go with Python?

I had a dream about one of these papers tonight (seriously), so I come to HN and find this post. Pretty amazing coincidence. :)

It doesn't make sense to replace Rails views completely in my view. There are parts of the app that are still being served by Rails views because they are not mission critical or have a great solution already in-place. Where React comes handy is when you have an interactive one-page app with a lot of moving parts. I have 2-3 React apps in this current project. Webpack is a great solution for packaging your css, js and other assets in logical units. I think it's much better than Sprockets, but it requires some configuration.

That's just PR.

Yeah, I do use Flux, and I love it. I use a mixture of both Rails and a clientside routers, but Rails does most of the work for sure.

The view rendering doesn't need to be done by Rails. I've been using React and Webpack to build the clientside of my Rails apps and have been very happy with that approach. There is nothing that this architecture does that a clientside framework like React cannot do better.

This "architecture" changes so much about Rails that I don't know why it's trying to build on Rails at all. If you don't like the Rails Way, just create another framework.

Isn't this essentially the same thing as One Today?

https://onetoday.google.com/

Really sad. They must have been very desperate.

Is it just me or is this page entirely blank? I poked through the source for quite a long time, but couldn't undo it. The text is there. There is something in the CSS that obscures it in Chrome. So annoying.

I haven't seen it mentioned how you would do composition in Swift. I assume it has a feature like Scala's traits –– hopefully with a better syntax? Does anyone know?

Only two transportation icons have been added: automobile and cab. Where is bus, train, or the subway?

Very cool. Is the source code available? Which libraries did you use?