I'm a "Rails guy" who now uses Clojure for all new web development, so don't take what I'm about to say as disagreeing with Justin.
As someone with a foot firmly in both worlds, a couple of Justin's points aren't really marks in Clojure's favor, at least compared to Ruby/Rails (I can't say as much about Python/Django). I also have a few other benefits to bring up that Justin didn't: Clojure provides execution efficiency that Ruby or Python cannot match. > This translates to lowered hosting costs. > Agreed. This is a huge point. And not just in lowered hosting costs, but also potentially a better user experience (lower latency). > The lein tool provides very clean and isolated dependency management, that > makes setting up dev environments and deployment very straightforward. > The pair of Bundler/rake does this very effectively for Ruby. Targeting the JVM means that each deploy can be a single jar or war file > that you upload to the server. > True. Clojure offers potentially much simpler deployment schemes, but if this is important to you, there's JRuby. > The ring middleware system is a very clean way of including functionality > in an app. > Rack is every bit as clean in the Ruby world. > Working with immutable data structures and threadsafe bindings as a > pervasive default does a lot for stability, and rules out many of the round > about ways one of heisenbugs end up in the system. > True, but this comes up less frequently than you might expect with the typical web app. With the stateless nature of HTTP, and the MVC (of a sort) convention of Rail/Django, typical web app code in these frameworks ends up being more short lived, imperative, and object based in nature rather than long running, object-oriented, and stateful. Here are several additional points to consider: Conciseness. Terseness. Or to put a more positive spin on it, expressiveness. Idiomatic Clojure is more concise than idiomatic Ruby or Python. I find that having 2x or less code to implement the same functionality to be very refreshing and empowering. Big Rails/Django apps suffer entropy much faster than comparable Clojure apps. Full-stack with ClojureScript. The ability to code all in one language, and to share code between client and server, is quite nice compared to Ruby/JavaScript, Ruby/CoffeeScript. It's one small reason node.js has gained momentum so quickly. Neither Rails nor Django has a robust, mature threading story. Both achieve concurrency primarily through many processes. This can eat through memory on your hosts quickly as the footprint for Rails and Django themselves is not small and is replicated in each process. This comes up as you end up serving web requests to multiple processes to concurrently, and end up with a many processes model for working background requests. This has gotten a bit better in the Ruby/Rails world as Rails is now thread safe and so can be run multithreaded in alternative Ruby implementations (other than MRI), and Sidekiq has come on the scene for background work, and it leverages Celluloid's actor implementation, borrowed from Erlang, to provide multi-threaded Rails workers. Django has celery but I think that's still process based like resque is in the Ruby world. Not positive, but I don't think Django is threadsafe though. Framework vs. ecosystem of interoperable libraries. The monolithic framework (see Rails and Django) is not the way web development is done in Clojure. Instead imagine the Clojure world as a set of legos. You get to build whatever you want with your legos, selecting just the blocks you need, in the colors and sizes you want, and they all snap together [1]. The benefit to this approach is simplicity. There is a LOT to know about the Rails and Django frameworks, as they are big, mature things that have grown to solve all the common web development needs, and you start your development with ALL of that framework. Your starting point with Clojure on the other hand is much simpler. It will seem too simple... at first you'll be wondering... where is all the "stuff"? You start with maybe just ring and compojure (web middleware and routing) and a few lines of your code and your first couple of stories are already complete. You add libraries as you find you need them as you build out your app over time, but at all times your app is as simple as it can be, and only has the "stuff" it needs. It's therefore much easier to understand and less a "big ball of mud". The magic of meta-programming (Ruby) vs. magic of macros (Clojure) vs. no magic (Python). This probably comes down to personal preference, and so is a potential benefit of any of them, depending on your preference, but it's a significant difference, so it's worth pointing out. By "magic" I just mean when the system seems to be more doing something much more powerful than you can readily see just by looking at the code. A simple few lines of code are doing all these wondrous things that aren't spelled out completely in the code (unless you peek under the covers and can understand the black arts that lie there). In Ruby/Rails this is the result of a lot of metaprogramming happening, based on conventions (that must be learned). In Clojure this happens through macros that implement powerful DSLs. In Python, it doesn't happen nearly as much. Code tends to be more transparent. I hope that was helpful. Good luck convincing your team Marcus! Cheers, Sean [1] a robust set of immutable data structures, sequences and maps, and conventions about how they are used in libraries are the uniformity of the lego blocks that makes them snap together easily. With Ruby and Python you've always had some of this with hashes and dicts and arrays, but they aren't used as consistently in libraries, and you have a lot of custom objects in libraries too, so you end up with a lot more library glue code. > On Wednesday, November 13, 2013 2:38:49 PM UTC-8, Marcus Blankenship wrote: >> >> Hi Folks, >> >> We’re a Python / Django shop, and some folks are getting excited about >> using Clojure for building web apps. Certainly there are numerous >> open-source options to assist us (Pedastal, Ring, Compojure, Caribou, etc), >> but I think it begs a larger question: *as a rule, do web applications >> need the power that Clojure brings to the table?* >> >> Other folks on my team are telling me that solutions built with Python / >> Django (or even RubyOnRails) fully satisfy the needs of 99% of the web apps >> we have built, and that Clojure offers nothing new to this problem space. >> >> So, here’s the question: *How are you are actually using Clojure, and >> why did you choose to use it, particularly in the “web application” space? * >> >> >> Thanks, >> Marcus >> >> >> >> marcus blankenship >> \\\ Partner, Problem Solver, Linear Thinker >> \\\ 541.805.2736 \ @justzeros \ skype:marcuscreo >> >> -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
