6 ms·

Aleph: A new event-driven web server for Clojure

86 points by saikat 16y ago

adamilardi 16y ago
Clojure runs on the JVM. If there is one thing the JVM has to much of it's application servers. Jetty(non blocking), Glassfish for enterprise apps. Tomcat, websphere, weblogic, apache geronimo...etc. Why not just conform to those standards and make the clojure applications deploy to them. What is the advantage of this server over jetty?
- jdminhbg 16y ago
  This is a wrapper around the Java Netty server: http://www.jboss.org/netty http://www.jboss.org/netty
- kunley 16y ago
  While Java world doesn't lack appserver infrastructure (though they're not as good as they're marketed but that is another point), it lacks web programming paradigms which wouldn't be a PITA.
  - adamilardi 16y ago
    What PITA features does the java app server have?
    - DeusExMachina 16y ago
      I think that the Java language is, for some people. If you choose some language like Clojure it usually means you don't want to deal with Java or any of its derivatives. At least this holds for me. Moreover I'm looking at Clojure mainly for web development, so this is really something I'm happy they are addressing.
      - adamilardi 16y ago
        Java is "verbose" and I'm real happy to see other languages target the JVM. It will make it very easy to convince "corporate america" to adopt them in the future. In no way is Java a PITA. It's got it's quirks but it remains one of the best platforms for building anything. The community support is great and it has years of development libraries and experience for you to leverage.
        kunley 16y ago
        While I spared my comments on Java on this thread, I was specially referring to the fact that Java's classloaders are braindead. You'll know some years in operations; as a dev you can be hidden from its ugly influence for quite a time.
    - kunley 16y ago
      Many kinds; Java itself, and lack of stable dynamic redeploying without bringing the services down, despite being marketed otherwise. I'm talking about real life production configurations, not about what's possible on Joe R. Hacker's machine under special circumstances. Of course it's not the fault of appservers themselves but rather of JVM architecture esp. classloaders. Still the RL situation is that today's complicated stacks of libraries, dependency injection frameworks and code using it can make life of admins and change management folks miserable. Add to it a monstrosity from the deepest ends of Moria: maven (hint: google for 'maven sucks') and you have the world lots of people want to forget about. Today's Clojure webservers being usually wrappers around existing solutions won't cure all these wounds, but at least it's a step in a refreshing direction.
      - brown9-2 16y ago
        What does a build tool (Maven) really have to do with using any of the app servers?
        kunley 16y ago
        You could say nothing, technically, but that wouldn't reflect real life situations and existing "best" practices. It's usually used to build deployments, CI, autodeploying and stuff. In fact for many operations tasks Maven cannot be decoupled, because it's used for almost everything. When using Makefile, to copy a compiled archive to a destination you'd use shell commands; in Maven you cannot leave the Java world so you pick up a plugin to do the same, usually of poor quality. This way you introduce even more code, which is hardly manageable at some point, and contrary to the maxim "every line of code not written is a correct one". Short answer: Pick a job in operations or change management at a large Java shop, then you'll know.
        brown9-2 16y ago
        This still has nothing to do with using a Java app server. You could be using other tools to handle those tasks just as easily. Even if you have developers that love Maven and use it to build and package their applications, this certainly doesn't mean you need to use the tool for other tasks in which you find it to be a poor fit.
- lukev 16y ago
  Why the downvotes? This is a decent question. All other things being equal, having a "standard" Java webapp is preferable to a server-specific app. Of course, the correct answer is (IIRC) that standard Java web servers don't support the NIO asynchronous request paradigm - the standard Java servlet spec is thread-per-request. But not everyone knows that.
  - ant5 16y ago
    The 3.0 servlet spec fortunately includes support for async processing, so you can give your thread back mid-handling the request; No more thread-per-request required. Jetty has also supported their own async handling extension for quite some time now (but they're moving to the 3.0 standard). I've used it to build 'Comet' servers before, and it does the trick.
    - lukev 16y ago
      Cool. In that case, someone should write a Clojure library that utilizes the 3.0 standard. That'd be even cooler.
    - hannesw 16y ago
      We use Jetty's ability to do both sync and async HTTP in RingoJS. I've written about it here: http://hns.github.com/2010/07/02/versatility.html http://hns.github.com/2010/07/02/versatility.html I think Netty is great if you want fine grained control over each aspect of your network stack and/or ultimate performance. But having a full featured web server that does sync and async equally well is a value that shouldn't be dismissed either.
- dkersten 16y ago
  I imagine the idea is to have it better integrated with the Clojure language, especially Clojures concurrency mechanisms. I see that that Aleph implements Ring, so you can use it with a bunch of existing Clojure web frameworks, such as Compojure.
joubert 16y ago
I've implemented servlet-based solutions with Clojure on top of Tomcat (e.g. at http://elev.at http://elev.at), and although it wasn't too bad, there is still cruft to deal with. This looks like an interesting option indeed.
c00p3r 16y ago
Why not? CPU and RAM are cheap enough and we even would see NIO2 implementation some day.

86 points by saikat 16y ago

Clojure runs on the JVM. If there is one thing the JVM has to much of it's application servers. Jetty(non blocking), Glassfish for enterprise apps. Tomcat, websphere, weblogic, apache geronimo...etc. Why not just conform to those standards and make the clojure applications deploy to them. What is the advantage of this server over jetty?

jdminhbg 16y ago
This is a wrapper around the Java Netty server: http://www.jboss.org/netty http://www.jboss.org/netty
kunley 16y ago
While Java world doesn't lack appserver infrastructure (though they're not as good as they're marketed but that is another point), it lacks web programming paradigms which wouldn't be a PITA.
- adamilardi 16y ago
  What PITA features does the java app server have?
  - DeusExMachina 16y ago
    I think that the Java language is, for some people. If you choose some language like Clojure it usually means you don't want to deal with Java or any of its derivatives. At least this holds for me. Moreover I'm looking at Clojure mainly for web development, so this is really something I'm happy they are addressing.
    - adamilardi 16y ago
      Java is "verbose" and I'm real happy to see other languages target the JVM. It will make it very easy to convince "corporate america" to adopt them in the future. In no way is Java a PITA. It's got it's quirks but it remains one of the best platforms for building anything. The community support is great and it has years of development libraries and experience for you to leverage.
      - kunley 16y ago
        While I spared my comments on Java on this thread, I was specially referring to the fact that Java's classloaders are braindead. You'll know some years in operations; as a dev you can be hidden from its ugly influence for quite a time.
  - kunley 16y ago
    Many kinds; Java itself, and lack of stable dynamic redeploying without bringing the services down, despite being marketed otherwise. I'm talking about real life production configurations, not about what's possible on Joe R. Hacker's machine under special circumstances. Of course it's not the fault of appservers themselves but rather of JVM architecture esp. classloaders. Still the RL situation is that today's complicated stacks of libraries, dependency injection frameworks and code using it can make life of admins and change management folks miserable. Add to it a monstrosity from the deepest ends of Moria: maven (hint: google for 'maven sucks') and you have the world lots of people want to forget about. Today's Clojure webservers being usually wrappers around existing solutions won't cure all these wounds, but at least it's a step in a refreshing direction.
    - brown9-2 16y ago
      What does a build tool (Maven) really have to do with using any of the app servers?
      - kunley 16y ago
        You could say nothing, technically, but that wouldn't reflect real life situations and existing "best" practices. It's usually used to build deployments, CI, autodeploying and stuff. In fact for many operations tasks Maven cannot be decoupled, because it's used for almost everything. When using Makefile, to copy a compiled archive to a destination you'd use shell commands; in Maven you cannot leave the Java world so you pick up a plugin to do the same, usually of poor quality. This way you introduce even more code, which is hardly manageable at some point, and contrary to the maxim "every line of code not written is a correct one". Short answer: Pick a job in operations or change management at a large Java shop, then you'll know.
        brown9-2 16y ago
        This still has nothing to do with using a Java app server. You could be using other tools to handle those tasks just as easily. Even if you have developers that love Maven and use it to build and package their applications, this certainly doesn't mean you need to use the tool for other tasks in which you find it to be a poor fit.
lukev 16y ago
Why the downvotes? This is a decent question. All other things being equal, having a "standard" Java webapp is preferable to a server-specific app. Of course, the correct answer is (IIRC) that standard Java web servers don't support the NIO asynchronous request paradigm - the standard Java servlet spec is thread-per-request. But not everyone knows that.
- ant5 16y ago
  The 3.0 servlet spec fortunately includes support for async processing, so you can give your thread back mid-handling the request; No more thread-per-request required. Jetty has also supported their own async handling extension for quite some time now (but they're moving to the 3.0 standard). I've used it to build 'Comet' servers before, and it does the trick.
  - lukev 16y ago
    Cool. In that case, someone should write a Clojure library that utilizes the 3.0 standard. That'd be even cooler.
  - hannesw 16y ago
    We use Jetty's ability to do both sync and async HTTP in RingoJS. I've written about it here: http://hns.github.com/2010/07/02/versatility.html http://hns.github.com/2010/07/02/versatility.html I think Netty is great if you want fine grained control over each aspect of your network stack and/or ultimate performance. But having a full featured web server that does sync and async equally well is a value that shouldn't be dismissed either.
dkersten 16y ago
I imagine the idea is to have it better integrated with the Clojure language, especially Clojures concurrency mechanisms. I see that that Aleph implements Ring, so you can use it with a bunch of existing Clojure web frameworks, such as Compojure.

joubert 16y ago

I've implemented servlet-based solutions with Clojure on top of Tomcat (e.g. at http://elev.at http://elev.at), and although it wasn't too bad, there is still cruft to deal with. This looks like an interesting option indeed.

c00p3r 16y ago

Why not? CPU and RAM are cheap enough and we even would see NIO2 implementation some day.