Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Lisp in Production

tech.grammarly.com

Post reply on HN
Print view View original

11–20 of 119 posts

Re: Running Lisp in Production

#11

Post by lkrubner »

Good 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 allow us to enjoy quite fast generated code, but some of which require exponential time and memory resources. "

Re: Running Lisp in Production

#12

Post by istvan__ »

dfischer wrote: post #6

Is it worthwhile to explore Clojure for web-dev seriously or more as a toy?

I think it is one of the best stacks out there for web.

Check out this:

https://github.com/bhauman/flappy-bird-demo

It uses figwheel for the dynamic changes of state when you change to code, and it renders it without reload ala Bret Victor style. The first time I saw it I was amazed. It speeds up prototyping so much.

The out of the box performance is decent as well, Ring and Hiccup is pretty lean but you can go for more heavy frameworks (I don't have any experience with those).

I personally use Reagent + Ring, found it easy to use and get productive in a day.

If you haven't used LISP or any homoiconic language before it might look little weird at first but I found it easy to explain to people.

About the toy part, what is your definition of toy?

Re: Running Lisp in Production

#13

Post by vseloved »

lkrubner wrote: post #11

Good 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…

Yeah, but that's something you need to be prepared for. Such bugs happen in literally every platform (for instance, I had similar trouble with the JVM). So the question is not how to avoid them, but how to cope. Usually, there are 2 ways:

- workaround

- investigation (and in this case, if you're on a closed platform you're busted)

Re: Running Lisp in Production

#14

Post by jon-wood »

Apparently they use "JVM languages", JavaScript, Python, Go, Lisp and Erlang in production.

I may be in the minority, but that would drive me mad. I assume they're not routinely jumping between those stacks multiple times a day, but even so is there really that much benefit that it's worth keeping track of how to do things in that many different environments?

Re: Running Lisp in Production

#15

Post by apalmer »

lkrubner wrote: post #11

Good 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…

I dont really understand the downvotes... I agree with you would go nuts.

My two cents, if your macro is expanding to thousands of lines of code, your doing something wrong I think. I would expect Macros to expand out to a few lines of code which might have function calls that themselves may contain however many lines of code... but expanding to thousands of lines INLINE via macros seems wrong.

Re: Running Lisp in Production

#17

Post by jwr »

dfischer wrote: post #6

Is it worthwhile to explore Clojure for web-dev seriously or more as a toy?

I've been using Clojure in production systems for 5 years now. Average of 15req/s over 5 years - I'd say that's pretty serious.

Re: Running Lisp in Production

#18

Post by jessaustin »

jon-wood wrote: post #14

Apparently they use "JVM languages", JavaScript, Python, Go, Lisp and Erlang in production. I may be in the minority, but that would drive me mad. I assume they're not routinely jumping between those stacks multiple times a day, but even so is there really that much benefit that it's worth keeping track of how to do things in that many different environments?

Since "proper service encapsulation" is mentioned, it may be that each team uses whatever they like, and as long as your component speaks http you don't have to look at what other components are doing.

Re: Running Lisp in Production

#19

Post by vqc »

dfischer wrote: post #6

Is it worthwhile to explore Clojure for web-dev seriously or more as a toy?

Is there a Clojure/Clojurescript tutorial similar to the Hartl Rails tutorial? I have amassed quite a few Clojure books, but find the easiest way to learn is to build.

Re: Running Lisp in Production

#20

Post by vseloved »

apalmer wrote: post #15
lkrubner wrote: post #11

Good 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…

I dont really understand the downvotes... I agree with you would go nuts. My two cents, if your macro is expanding to thousands of lines of code, your doing something wrong I think. I would expect Macros to expand out to a few lines of code which might have function calls that themselves may contain however many lines of code... but expanding to thousands of lines INLINE via macros seems wrong.

I have pointed to the call-with-* style which is a general "best practice" for that (it's even mentioned in Google CL Style guide). However, expanding to low-level stuff also has it's benefits for a clearly delimited space (mainly, performance) if you know what you're doing
Post reply on HN