Hacker News new | past | comments | ask | show | jobs | submit login

I think "not Rails" should be expanded a bit, because it risks someone saying "ok, so... sinatra?"

Web applications have some very distinct profiles. Most requests:

1. Parse HTTP

2. Parse the request body (likely JSON), build ruby objects from the data.

3. Load data from a datastore, builds ruby objects from the data.

4. Do some manipulation of data.

5. Serialize Ruby objects into a response.

Basically, because of the stateless nature of a web request, most of the work done (ignoring IO) is serializing and deserializing data. By not having Ruby be responsible for the state of our application, we make Ruby responsible for fetching and sending the state.

Now think about a stateful system (like we would have with embedded Ruby). The state is kept within Ruby for the most part. We don't have to hit a data store to restore state every time we want to do something. This significantly changes the operating profile of the application, and therefore the optimization strategy changes.

That. I have a full talk based on that coming for the Elixir community.

Are you able to share where or when I should be on the lookout for this talk? This is my exact area of interest.

Not accepted yet, CFP decisions are at the end of the week.

If it is not accepted, i will do it at the London Elixir meetup.

Does CodeNode publicly release recordings that they make of meetup talks?


Doesn't this create extreme state synchronization and scaling issues?

In an embedded system? No.

Even in distributed systems, coordination of data from stateless systems can be a nightmare. Requiring a bit of stickiness simplifies a lot of things.

For example, I've worked on a few large scale adserving auction platforms. One of them had the auction and impression events recorded statelessly (ie each event was generated on a random machine). This required a big hadoop job to match up all the events from a single auction. Another system used sticky events, where all events for an auction would hit the original server that ran the auction. It would store all events for an auction in memory and then flush it to the billing system when the data was finalized. Was it perfect? If the one machine crashed, all pending ad info wad lost. But that didn't happen often so the cost was negligible.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact