One of the things I would have liked to see on the article is how do they handle the deployment itself. Do they build an executable with build app? To they used sb-daemon? An home-grown solution using sb-posix:fork?
Running Lisp in Production
41–50 of 119 posts
Re: Running Lisp in Production
#42Is it worthwhile to explore Clojure for web-dev seriously or more as a toy?
It's extremely serious. The deployment is the very well understood JVM and standard web servers. There's a common HTTP middleware framework (Ring), lots of choices for HTML generation and ClojureScript allows some code-sharing with your client side (compiles to JS). On the back-end, you could use any Java library. On the front-end, you could use any JS framework (e.g. see https://github.com/omcljs/om )
I suspect swannodette (dnolen)'s talk at EuroClojure should be a pretty compelling showcase of how Clojure is quickly blossoming in the web-dev space.
Re: Running Lisp in Production
#43> but we value choice and freedom over rules and processes.
Which I exactly why I feel Lisp doesn't see much use elsewhere :(
Re: Running Lisp in Production
#44[deleted]
So you would pick a different language based on the lack of an existing Jenkins interface library? They would lack 90% of Common Lisp then. Not a good trade if you ask me. Edit: I assume you are down-voted because most of your post is wrong information.
Huh? I said nothing about picking a language only based on a Jenkins interface library.
I just noted that every problem they had which they noted in this post seems to arise from the gnarliness of the CL ecosystem, and wouldn't happen with Clojure. Jeez. Where is the "wrong information" in that.
Re: Running Lisp in Production
#45Is it worthwhile to explore Clojure for web-dev seriously or more as a toy?
I vote that it's worthwhile as well. We've been using Clojure full-time at ReadyForZero for over 3 years now (for web-dev as well as other tasks), and are very happy with our choice.
Re: Running Lisp in Production
#46[deleted]
Well, the HDF5 problem was actually not on the Lisp side ;) But, in general, do you really believe that there are no issues with libraries in other languages? I've had my share in Python or on the JVM, as well. The whole point in the article was to show that there are some challenges, but they didn't become critical to our operation.
[deleted]
Re: Running Lisp in Production
#47[deleted]
I assume they have their reasons. Speaking of which, it would be interesting to hear why they chose the particular flavour that they did.
Re: Running Lisp in Production
#48[deleted]
Well, the HDF5 problem was actually not on the Lisp side ;) But, in general, do you really believe that there are no issues with libraries in other languages? I've had my share in Python or on the JVM, as well. The whole point in the article was to show that there are some challenges, but they didn't become critical to our operation.
All right, i'm deleting my comment. I don't want to start a Clojure vs CL flame war. That wasn't the intent and I thought I'd made it very clear.
Re: Running Lisp in Production
#49One of the things I would have liked to see on the article is how do they handle the deployment itself. Do they build an executable with build app? To they used sb-daemon? An home-grown solution using sb-posix:fork?
I don't know how they do it, but I have run several Lisp production systems. I use CCL, which has a really fast compiler. So I just load the code from source. The deployment process then becomes: git pull, quit and restart Lisp. (The ccl-init file loads the code.)
Re: Running Lisp in Production
#50Good lord, I would go insane if I ran into a bug like this: "We've built an esoteric application (even by Lisp standards), and in the process have hit some limits of our platform. One unexpected thing was heap exhaustion during compilation. We rely heavily on macros, and some of the largest ones expand into thousands of lines of low-level code. It turned out that SBCL compiler implements a lot of optimizations that a…
You can write C++ template metaprogramming code that will send your compiler into coma, if you're not careful. Code that pushes the boundaries is bound to push through them occasionally.