Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I honestly think you should avoid this. We did this, and it's a nightmare, and we had to get rid of it.

Rails works very well if you stick to defaults. Each time you veer a little bit further from the defaults, things start to break (or at least require a lot more advanced knowledge to keep working).

We had a front-end in in JRuby-on-Rails, backend in clojure, in the same app/process. We had a "middle-end" which translated clojure->ruby and ruby->clojure, allowing us principally to use futures for parallelism and queuing. It worked really well at the start, but had tons of bugs. A nasty example was that we did email in SimpleMailer in Rails, but it was triggered from some backend functions, which in turn were triggered from the front-end. That meant that Ruby objects were being used in two different Ruby runtimes! Bugalicious.

Here's the library we extracted, if you really want to use this: https://github.com/circleci/cljr. My cofounder Allen talked about the experience at ClojureConj/west: https://github.com/arohner/clojurewest2012-slides/blob/maste...



Thanks for the correction, good to know. In the example you describe, the main mismatch seems to have been getting the two Ruby runtimes to communicate effectively. Was that a common theme?


I think the most important thing is "complexity is multiplicative". Every slight deviation from normal led to subtle errors that took days to fix, and kept coming back in different ways. The runtimes was just the most WTF way this happened.




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

Search: