9 ms·

I like lisp as a programming language. But, this article gives one of the reasons for avoiding its use in a high performance production environment. Provisioni

I like lisp as a programming language. But, this article gives one of the reasons for avoiding its use in a high performance production environment. Provisioning a VM with over 25GB RAM for an application which requires about 4GB of it is a huge waste of resources. While the common wisdom on HN is that for most applications, developer costs more than physical resources. Physical resources still cost money. Initially list might be a good option for development velocity. But, over time as the application matures, adding features becomes more complicated and the velocity goes down anyway. Shifting to something which reduces costs by upto 6x might be worth it.

fao_ 8y ago
I wonder if Chicken Scheme has the same memory problems as SBCL. It seems to me that it shouldn't.
- tsm 8y ago
  It also has a fraction of the features
  - pmoriarty 8y ago
    In Chicken, those features might not be in the core language but in the libraries. It really depends on which features you need. If they're not in Chicken or its libraries, ask yourself if they're really worth the bloat of SBCL? Also, Chicken offers a number of other advantages apart from a much smaller footprint, like elegance, a less crufty and more modern syntax, and the ability to compile down to C.
    - kazinator 8y ago
      > to compile down to C. This HN submission's referenced article ("Running Lisp in Production" (2015)) is about SBCL which compiles down to native code. There are CL implementations that compile to C, if you think that is better for some reason. For instance, derivatives of Kyoto Common Lisp, such as GNU Common Lisp. Or ECL: https://common-lisp.net/project/ecl/static/manual/ch34s02.html https://common-lisp.net/project/ecl/static/manual/ch34s02.ht... "The other type of compilation is the so-called "native" compilation. This process consists on translating the lisp source file to C language. The intermediate file is later compiled using a C compiler."
    - lispm 8y ago
      That the syntax of Scheme (from 1975) is more modern than the syntax of CL (from 1984) is a myth. It's more primitive. Later people added lots of features to Scheme, which were already in CL. Take keyword arguments... In essence Scheme is actually less elegant due to its too small design and the many bolted on features. Chicken: ((lambda (x y #!optional z #!rest r #!key i (j 1)) (list x y z i: i j: j)) 3 4 5 i: 6 i: 7) => (3 4 5 i: 6 j: 1) CL: ((lambda (x y &optional z &rest r &key i (j 1)) (list x y z :i i :j j)) 3 4 5 :i 6 :i 7) => (3 4 5 :I 6 :J 1) Is the CL code more crufty compared to the almost equivalent Scheme code? Sure not. or is #!optional now more modern than &optional? Guess where the Chicken feature originally came from ... The difference: the CL code works in every CL implementation. > and the ability to compile down to C. There are many implementations which do that. SBCL has the ability to compile to optimized native code with a type-inferencing compiler... Chicken is a great implementation with a nice ecosystem, but that it is more elegant than CL - while it copies lots of features from CL (like COOPS copies from CLOS) - is an illusion. http://wiki.call-cc.org/eggref/4/coops http://wiki.call-cc.org/eggref/4/coops > COOPS provides classes, generic functions and methods, similar in style and use to the classic Lisp object systems like Flavors, Loops or CLOS. For general information about object-oriented programming in the context of Lisp, consult one of the various books and guides available to the subject. Example: Chicken: (define-method (pop (stack <stack>)) (let* ((c (slot-value stack 'content)) (x (car c))) (set! (slot-value stack 'content) (cdr c)) x)) Let's see how it's in Common Lisp: (defmethod pop ((s stack)) (let* ((c (slot-value s 'content)) (x (car c))) (setf (slot-value s 'content) (cdr c)) x)) Which is more modern? To me it looks the same. The difference: the CLOS code runs in every CL implementation.
      - kazinator 8y ago
        Also: (defmethod popm ((s stack)) ;; don't clash with cl:pop macro (pop (slot-value s 'content))) ;; speaking of which, use it. I think you have to write your own pop macro in Scheme or find some lib.
- outworlder 8y ago
  Chicken itself is very lightweight. Applications built on it may or may not be.
cag_ii 8y ago
I don't necessarily disagree with you, but provisioning 16-32gb for a production server doesn't seem to be unusual these days and the cost negligible... <Insert electron/slack joke here>
- sacheendra 8y ago
  The cost is negligible for 1 server. For 100s to 1000s of servers. The cost starts mattering. I'm not saying new applications shouldn't be built on lisp. Most applications don't have huge scaling requirements. But, if you expect the application to grow, have a plan in place for migration.
  - coldtea 8y ago
    >For 100s to 1000s of servers. The cost starts mattering. If you need 100s to 1000s of servers you presumably already have customers and money to spend.
    - jimbokun 8y ago
      To spend on rewriting the application in another language.
      - coldtea 8y ago
        AKA a "nice problem to have" ("oh, we're now so successful we have to rewrite the app in another language to lower our infrastructure costs". Most of the time you aren't gonna need it (because you wont go far anyway as a company). And when you do -- like Twitter and Facebook did, you'll be swimming in users and money already anyway...
orthecreedence 8y ago
I wrote some high-performance lisp applications in production. My main was was a threaded queue worker, driven off beanstalkd, that processed large volumes of data. This was highly successful and didn't require overly-provisioned servers (was using CCL/linux x64/linode VPS). That said, I don't think I'll ever use lisp for front-facing web stuff again. I wrote cl-async, and afterwards and used it in production in a few places, then a bit later started using node heavily. The tooling for CL is just not there. Quicklisp is great, but not being able to pick and choose package versions is limiting, and having to rewrite every single thing for async was a pain (since CL doesn't have continuations, any sort of async that avoids CPS is impossible). I was hoping I would get more community support on cl-async, and I did get many hands helping, but eventually it just became too much to maintain. So if you're doing network stuff on CL, it's probably best to just use threaded, which IMO just doesn't handle the same amount of load evented does, at least when dealing with web APIs. One thing I used lisp for briefly which I want to do again soon is game dev. Being able to redefine/fix portions of your program while it's running is fantastic, especially when you have huge amounts of state to deal with like you do in games. I wouldn't exactly call that running CL in production, though.
- fiddlerwoaroof 8y ago
  I'm a little bit disappointed that you've decided to stop maintaining cl-async, although I appreciate the difficulty of maintaining such a project.
  - orthecreedence 8y ago
    Hopefully it's still useful! The nice thing about CL is that it never fucking changes so you can write something and 25 years later it still runs. Really, the only moving targets are the bundled ASDF version implementations ship with and libuv itself. I've had some reports of cl-libuv not compiling against the latest libuvs, but that shouldn't be too hard to fix (I still merge PRs =]). All in all, I think I just hit one too many problems using cl-async/wookie in production to justify using it vs Node which just kind of works and has a plethora of maintained packages.
- 8y ago
wildster 8y ago
Yes, when Elixir runs amazing on a $5 a month digitalocean account.
- gmfawcett 8y ago
  From the article: > Our Lisp services are conceptually a classical AI application that operates on huge piles of knowledge created by linguists and researchers. It’s mostly a CPU-bound program, and is one of the biggest consumers of computing resources in our network. CPU-intensive processing is exactly the kind of work that the BEAM is lousy at handling. Elixir would be a terrible implementation language for this kind of thing.
- Grue3 8y ago
  My Lisp web-app does too. I barely get any traffic, but still.
outworlder 8y ago
What would that something be? Most "mainstream" languages aren't any better.
- bitwize 8y ago
  Something with a large ecosystem and community that has ready-made solutions for tuning, deployment, and integration with other products and workflows. Java and JavaScript are front-runners. Python is good too. If you have to build rather than buy all the infrastructure that's not your core product, you lose. That's a huge yak to shave, and startups can't -- and mature businesses won't -- absorb the upfront costs of doing all that work.
  - vseloved 8y ago
    you misunderstand the meaning of startups. Startups, at core, are not about rebuilding the same stuff by combining existing solutions but about building novel solutions to solve yet unsolved problems. The other things are really secondary to that
    - bitwize 8y ago
      Indeed. As a startup ypu want to build as little as possible tgat's already been built -- so you want the language/framework that has the biggest most accessible ecosystem, so that you can focus on building things unique to your line of business.
      - vseloved 8y ago
        That's not unique to startup - I'd say it's even more relevant to regular "corporate" software development, no? What's unique to real startups (for my definition of "real": the ones that solve yet unsolved technically challenging problems) is: even though you may be better off using a good ready-made infrastructure, that doesn't change the game for you as your competitors also have access to it. While using a conceptually different (more powerful?) toolset might give you an edge over the competitors and a chance to indeed solve the problem you're after. Just yesterday I talked about this: https://www.slideshare.net/vseloved/lisp-in-a-startup-the-good-the-bad-and-the-ugly https://www.slideshare.net/vseloved/lisp-in-a-startup-the-go...
cmrdporcupine 8y ago
> Provisioning a VM with over 25GB RAM for an application which requires about 4GB of it is a huge waste of resources. Like pretty much every JVM-based application ever? For the last 15 years?
- ken 8y ago
  Not according to the article. They say that SBCL's GC is not in the same league as the JVM's GC, based on experience running other services on the JVM. Are you saying that's not true, and that the JVM is actually no better than SBCL? I'd love to read a counterpoint.
  - vseloved 8y ago
    JVM's GC is surely better (actually, is there any other platform that has a better-developed GC infrastructure?) But the point, I guess, was not about the GC but about the usual size of Java applications
  - cmrdporcupine 8y ago
    I am not saying that, and that's not implied by what I was replying to, either. The comment is about allocated heap sizes differing from the application's actual memory usage. That's pretty typical of JVM applications, and a source of consternation for my sysadmin friends.
ruricolist 8y ago
This is not so much a Lisp problem as an SBCL problem. SBCL just doesn't have a very good garbage collector. I nearly gave up on Lisp fighting with it, but ultimately switched to Clozure instead, and never regretted it: Clozure has a fantastic garbage collector. I run Clozure and Postgres side by side on one 4G Linode without a peep.
- cup-of-tea 8y ago
  I thought you misspelled Clojure initially (I guess it does also benefit from decent gc). I didn't know about Clozure but will investigate when I next use CL.
  - TeMPOraL 8y ago
    Also referred to as CCL. It's a good implementation. The compiler doesn't generate as efficient code as SBCL does, and AFAIK doesn't do as much type inference as SBCL, but you get much faster compilation, and the generated code is still quite performant - I used CCL for hobby-level gamedev ~6 years ago, back when CCL was the only implementation that would run on Windows reliably and fast enough for games. These days, SBCL works on Windows too, so that's what I use most of the time - but then, CCL becomes helpful on Raspberry Pi to use all CPU cores, as SBCL (AFAIK, as of 1-2 years ago) still doesn't do proper threading on ARM.
eecc 8y ago
You've never run a Tomcat from 2009 haven't you?
vseloved 8y ago
well, those 25 GB come bundled with the number of hyperthreads that we used (i.e. 8 for an AWS xlarge server), so we didn't bother to optimize for memory usage

fao_ 8y ago

I wonder if Chicken Scheme has the same memory problems as SBCL. It seems to me that it shouldn't.

tsm 8y ago
It also has a fraction of the features
- pmoriarty 8y ago
  In Chicken, those features might not be in the core language but in the libraries. It really depends on which features you need. If they're not in Chicken or its libraries, ask yourself if they're really worth the bloat of SBCL? Also, Chicken offers a number of other advantages apart from a much smaller footprint, like elegance, a less crufty and more modern syntax, and the ability to compile down to C.
  - kazinator 8y ago
    > to compile down to C. This HN submission's referenced article ("Running Lisp in Production" (2015)) is about SBCL which compiles down to native code. There are CL implementations that compile to C, if you think that is better for some reason. For instance, derivatives of Kyoto Common Lisp, such as GNU Common Lisp. Or ECL: https://common-lisp.net/project/ecl/static/manual/ch34s02.html https://common-lisp.net/project/ecl/static/manual/ch34s02.ht... "The other type of compilation is the so-called "native" compilation. This process consists on translating the lisp source file to C language. The intermediate file is later compiled using a C compiler."
  - lispm 8y ago
    That the syntax of Scheme (from 1975) is more modern than the syntax of CL (from 1984) is a myth. It's more primitive. Later people added lots of features to Scheme, which were already in CL. Take keyword arguments... In essence Scheme is actually less elegant due to its too small design and the many bolted on features. Chicken: ((lambda (x y #!optional z #!rest r #!key i (j 1)) (list x y z i: i j: j)) 3 4 5 i: 6 i: 7) => (3 4 5 i: 6 j: 1) CL: ((lambda (x y &optional z &rest r &key i (j 1)) (list x y z :i i :j j)) 3 4 5 :i 6 :i 7) => (3 4 5 :I 6 :J 1) Is the CL code more crufty compared to the almost equivalent Scheme code? Sure not. or is #!optional now more modern than &optional? Guess where the Chicken feature originally came from ... The difference: the CL code works in every CL implementation. > and the ability to compile down to C. There are many implementations which do that. SBCL has the ability to compile to optimized native code with a type-inferencing compiler... Chicken is a great implementation with a nice ecosystem, but that it is more elegant than CL - while it copies lots of features from CL (like COOPS copies from CLOS) - is an illusion. http://wiki.call-cc.org/eggref/4/coops http://wiki.call-cc.org/eggref/4/coops > COOPS provides classes, generic functions and methods, similar in style and use to the classic Lisp object systems like Flavors, Loops or CLOS. For general information about object-oriented programming in the context of Lisp, consult one of the various books and guides available to the subject. Example: Chicken: (define-method (pop (stack <stack>)) (let* ((c (slot-value stack 'content)) (x (car c))) (set! (slot-value stack 'content) (cdr c)) x)) Let's see how it's in Common Lisp: (defmethod pop ((s stack)) (let* ((c (slot-value s 'content)) (x (car c))) (setf (slot-value s 'content) (cdr c)) x)) Which is more modern? To me it looks the same. The difference: the CLOS code runs in every CL implementation.
    - kazinator 8y ago
      Also: (defmethod popm ((s stack)) ;; don't clash with cl:pop macro (pop (slot-value s 'content))) ;; speaking of which, use it. I think you have to write your own pop macro in Scheme or find some lib.
outworlder 8y ago
Chicken itself is very lightweight. Applications built on it may or may not be.

cag_ii 8y ago

I don't necessarily disagree with you, but provisioning 16-32gb for a production server doesn't seem to be unusual these days and the cost negligible... <Insert electron/slack joke here>

sacheendra 8y ago
The cost is negligible for 1 server. For 100s to 1000s of servers. The cost starts mattering. I'm not saying new applications shouldn't be built on lisp. Most applications don't have huge scaling requirements. But, if you expect the application to grow, have a plan in place for migration.
- coldtea 8y ago
  >For 100s to 1000s of servers. The cost starts mattering. If you need 100s to 1000s of servers you presumably already have customers and money to spend.
  - jimbokun 8y ago
    To spend on rewriting the application in another language.
    - coldtea 8y ago
      AKA a "nice problem to have" ("oh, we're now so successful we have to rewrite the app in another language to lower our infrastructure costs". Most of the time you aren't gonna need it (because you wont go far anyway as a company). And when you do -- like Twitter and Facebook did, you'll be swimming in users and money already anyway...

orthecreedence 8y ago

I wrote some high-performance lisp applications in production. My main was was a threaded queue worker, driven off beanstalkd, that processed large volumes of data. This was highly successful and didn't require overly-provisioned servers (was using CCL/linux x64/linode VPS). That said, I don't think I'll ever use lisp for front-facing web stuff again. I wrote cl-async, and afterwards and used it in production in a few places, then a bit later started using node heavily. The tooling for CL is just not there. Quicklisp is great, but not being able to pick and choose package versions is limiting, and having to rewrite every single thing for async was a pain (since CL doesn't have continuations, any sort of async that avoids CPS is impossible). I was hoping I would get more community support on cl-async, and I did get many hands helping, but eventually it just became too much to maintain. So if you're doing network stuff on CL, it's probably best to just use threaded, which IMO just doesn't handle the same amount of load evented does, at least when dealing with web APIs. One thing I used lisp for briefly which I want to do again soon is game dev. Being able to redefine/fix portions of your program while it's running is fantastic, especially when you have huge amounts of state to deal with like you do in games. I wouldn't exactly call that running CL in production, though.

fiddlerwoaroof 8y ago
I'm a little bit disappointed that you've decided to stop maintaining cl-async, although I appreciate the difficulty of maintaining such a project.
- orthecreedence 8y ago
  Hopefully it's still useful! The nice thing about CL is that it never fucking changes so you can write something and 25 years later it still runs. Really, the only moving targets are the bundled ASDF version implementations ship with and libuv itself. I've had some reports of cl-libuv not compiling against the latest libuvs, but that shouldn't be too hard to fix (I still merge PRs =]). All in all, I think I just hit one too many problems using cl-async/wookie in production to justify using it vs Node which just kind of works and has a plethora of maintained packages.
8y ago

wildster 8y ago

Yes, when Elixir runs amazing on a $5 a month digitalocean account.

gmfawcett 8y ago
From the article: > Our Lisp services are conceptually a classical AI application that operates on huge piles of knowledge created by linguists and researchers. It’s mostly a CPU-bound program, and is one of the biggest consumers of computing resources in our network. CPU-intensive processing is exactly the kind of work that the BEAM is lousy at handling. Elixir would be a terrible implementation language for this kind of thing.
Grue3 8y ago
My Lisp web-app does too. I barely get any traffic, but still.

outworlder 8y ago

What would that something be? Most "mainstream" languages aren't any better.

bitwize 8y ago
Something with a large ecosystem and community that has ready-made solutions for tuning, deployment, and integration with other products and workflows. Java and JavaScript are front-runners. Python is good too. If you have to build rather than buy all the infrastructure that's not your core product, you lose. That's a huge yak to shave, and startups can't -- and mature businesses won't -- absorb the upfront costs of doing all that work.
- vseloved 8y ago
  you misunderstand the meaning of startups. Startups, at core, are not about rebuilding the same stuff by combining existing solutions but about building novel solutions to solve yet unsolved problems. The other things are really secondary to that
  - bitwize 8y ago
    Indeed. As a startup ypu want to build as little as possible tgat's already been built -- so you want the language/framework that has the biggest most accessible ecosystem, so that you can focus on building things unique to your line of business.
    - vseloved 8y ago
      That's not unique to startup - I'd say it's even more relevant to regular "corporate" software development, no? What's unique to real startups (for my definition of "real": the ones that solve yet unsolved technically challenging problems) is: even though you may be better off using a good ready-made infrastructure, that doesn't change the game for you as your competitors also have access to it. While using a conceptually different (more powerful?) toolset might give you an edge over the competitors and a chance to indeed solve the problem you're after. Just yesterday I talked about this: https://www.slideshare.net/vseloved/lisp-in-a-startup-the-good-the-bad-and-the-ugly https://www.slideshare.net/vseloved/lisp-in-a-startup-the-go...

cmrdporcupine 8y ago

> Provisioning a VM with over 25GB RAM for an application which requires about 4GB of it is a huge waste of resources. Like pretty much every JVM-based application ever? For the last 15 years?

ken 8y ago
Not according to the article. They say that SBCL's GC is not in the same league as the JVM's GC, based on experience running other services on the JVM. Are you saying that's not true, and that the JVM is actually no better than SBCL? I'd love to read a counterpoint.
- vseloved 8y ago
  JVM's GC is surely better (actually, is there any other platform that has a better-developed GC infrastructure?) But the point, I guess, was not about the GC but about the usual size of Java applications
- cmrdporcupine 8y ago
  I am not saying that, and that's not implied by what I was replying to, either. The comment is about allocated heap sizes differing from the application's actual memory usage. That's pretty typical of JVM applications, and a source of consternation for my sysadmin friends.

ruricolist 8y ago

This is not so much a Lisp problem as an SBCL problem. SBCL just doesn't have a very good garbage collector. I nearly gave up on Lisp fighting with it, but ultimately switched to Clozure instead, and never regretted it: Clozure has a fantastic garbage collector. I run Clozure and Postgres side by side on one 4G Linode without a peep.

cup-of-tea 8y ago
I thought you misspelled Clojure initially (I guess it does also benefit from decent gc). I didn't know about Clozure but will investigate when I next use CL.
- TeMPOraL 8y ago
  Also referred to as CCL. It's a good implementation. The compiler doesn't generate as efficient code as SBCL does, and AFAIK doesn't do as much type inference as SBCL, but you get much faster compilation, and the generated code is still quite performant - I used CCL for hobby-level gamedev ~6 years ago, back when CCL was the only implementation that would run on Windows reliably and fast enough for games. These days, SBCL works on Windows too, so that's what I use most of the time - but then, CCL becomes helpful on Raspberry Pi to use all CPU cores, as SBCL (AFAIK, as of 1-2 years ago) still doesn't do proper threading on ARM.

eecc 8y ago

You've never run a Tomcat from 2009 haven't you?

vseloved 8y ago

well, those 25 GB come bundled with the number of hyperthreads that we used (i.e. 8 for an AWS xlarge server), so we didn't bother to optimize for memory usage