5 ms·

It should interact pretty well with JRuby on Rails, but I'm not sure you would get any benefit from using rails over a Clojure web framework like Noir.

playing_colours 14y ago
I had a look at it but it's pretty young. I would prefer more mature framework.
- klaruz 14y ago
  Look at torquebox.org and immutant.org. You can run ruby and clojure on the same JVM and they can interop in a few ways.
- michaelsbradley 14y ago
  It's possible to get quit a lot accomplished by loosely coupling Ring+Compojure, Enlive/Hiccup, and datastore modules like Clutch, Korma, clj-orient, etc. I began my journey into Clojure about a month ago (after poking at it since last Sept) by diving into the "Clojure Programming" book recently published by O'Reilly. After finishing the book, I reached for Noir to fill my web-dev needs, as the idea of a "batteries included" framework appealed to me. But I ended up dropping Noir and adopting the approach explained in the book, i.e. loosely coupling the modules mentioned above. Noir itself is built from some of those same modules, and it seems like a fine open source project, but I've found that I'm better off connecting the "lego blocks" together manually -- it's not a complex exercise and gives you a lot of freedom to experiment, learn and fine tune.
astine 14y ago
I've used Rails and Noir and they're not really comparable. Noir is much more minimalist and doesn't cover nearly the same ground as Rails. Noir is more like Sinatra as I understand it. The Clojure mentality so far has eschewed all encompassing frameworks like Rails in favor of smaller interfitting libraries anyway.
pbiggar 14y ago
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 https://github.com/circleci/cljr. My cofounder Allen talked about the experience at ClojureConj/west: https://github.com/arohner/clojurewest2012-slides/blob/master/Rohner-JRuby.pdf?raw=true https://github.com/arohner/clojurewest2012-slides/blob/maste...
- Estragon 14y ago
  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?
  - pbiggar 14y ago
    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.
- deleted 14y ago
  [deleted]
puredanger 14y ago
There is actually another talk from Clojure/West on this topic that will be posted later on...

playing_colours 14y ago

I had a look at it but it's pretty young. I would prefer more mature framework.

klaruz 14y ago
Look at torquebox.org and immutant.org. You can run ruby and clojure on the same JVM and they can interop in a few ways.
michaelsbradley 14y ago
It's possible to get quit a lot accomplished by loosely coupling Ring+Compojure, Enlive/Hiccup, and datastore modules like Clutch, Korma, clj-orient, etc. I began my journey into Clojure about a month ago (after poking at it since last Sept) by diving into the "Clojure Programming" book recently published by O'Reilly. After finishing the book, I reached for Noir to fill my web-dev needs, as the idea of a "batteries included" framework appealed to me. But I ended up dropping Noir and adopting the approach explained in the book, i.e. loosely coupling the modules mentioned above. Noir itself is built from some of those same modules, and it seems like a fine open source project, but I've found that I'm better off connecting the "lego blocks" together manually -- it's not a complex exercise and gives you a lot of freedom to experiment, learn and fine tune.

astine 14y ago

I've used Rails and Noir and they're not really comparable. Noir is much more minimalist and doesn't cover nearly the same ground as Rails. Noir is more like Sinatra as I understand it. The Clojure mentality so far has eschewed all encompassing frameworks like Rails in favor of smaller interfitting libraries anyway.

pbiggar 14y ago

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 https://github.com/circleci/cljr. My cofounder Allen talked about the experience at ClojureConj/west: https://github.com/arohner/clojurewest2012-slides/blob/master/Rohner-JRuby.pdf?raw=true https://github.com/arohner/clojurewest2012-slides/blob/maste...

Estragon 14y ago
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?
- pbiggar 14y ago
  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.
deleted 14y ago
[deleted]

puredanger 14y ago

There is actually another talk from Clojure/West on this topic that will be posted later on...