5 ms·

Is there anyone here using CL in production? If so, why -- compared to more mainstream solutions -- and how's your experience been?

by vmsp 5y ago

smegsicle 5y ago
No reason not to, unless you can't trust your developers with high-power footgun features like.. multiple dispatch ??
fiddlerwoaroof 5y ago
These people are: https://www.itasoftware.com https://www.itasoftware.com
rjsw 5y ago
I am, it is easier to write than C or C++ and faster than Python or Ruby.
mmmm2 5y ago
Grammarly, at least as of November, 2020: https://www.grammarly.com/blog/engineering/running-lisp-in-production/ https://www.grammarly.com/blog/engineering/running-lisp-in-p...
diskzero 5y ago
Yes. I have deployed mobile applications using native UI (SwiftUI, etc.) with all the shared logic in Lisp. To me, this was a better alternative than the usual C/C++ shared logic approach. My current application is a music hardware device that is mostly Lisp. As to why, this could be a lengthy post, and I am sure I have made one elsewhere on HN. It is a very good language, has many of the features that are being re-discovered and implemented in other languages, has an interactive model of development (REPL driven) that I find very productive and I can deploy an application across multiple platforms with little to no modifications. I do pay for LispWorks and it is more than worth it. I make a living developing applications and devices that use Lisp and the cost is covered by a fraction of a percentage of sales. Some people may try to use SBCL, CCL or other free implementations. I just don't have the time or risk tolerance to be dependent upon the lack of predictability for bug fixes or modifications needed to run on new architectures. The M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly.
- moonchild 5y ago
  > M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly SBCL supports the M1; lispworks and allegro still do not.
  - diskzero 5y ago
    > SBCL supports the M1; lispworks and allegro still do not. I have been using LW on the M1 for months. Why do you think Apple Silicon is not supported?
    - moonchild 5y ago
      It runs the x86 version under rosetta. I expect most lisps will run the same way.
      - diskzero 5y ago
        You did mention above that 8.0 is now native M1, but you may still be quite right about the 7.1 version that is available for free download works using Rosetta 2 on the M1.
    - diskzero 5y ago
      It looks native Apple Silicon to me, but maybe you have information I don't. >>> file lispworks-8-0-0-macos64-universal lispworks-8-0-0-macos64-universal: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] lispworks-8-0-0-macos64-universal (for architecture x86_64): Mach-O 64-bit executable x86_64 lispworks-8-0-0-macos64-universal (for architecture arm64): Mach-O 64-bit executable arm64
      - moonchild 5y ago
        Ah, right you are; looks like my information was out of date. http://www.lispworks.com/news/news39.html http://www.lispworks.com/news/news39.html says: > Native support for Apple silicon Macs
varjag 5y ago
We do, in the context of a distributed embedded system. It's great way to achieve high development velocity without compromises on runtime efficiency. I'm substantially proficient in C (we've had a bunch of systems done in it too) and there is no question we'd have missed our budget/time/features target had we chose it instead. That said we don't use SBCL but LispWorks for delivery and CCL for development.
- patrec 5y ago
  Interesting, I'd have assumed that LispWorks would be a much nicer development environment than CCL. Are you trying to save license fees, or do you actually find CCL nicer to work with?
  - varjag 5y ago
    No the license cost is fairly marginal in overall development costs. Rather it's an embedded system of numerous (hundreds) networked devices so it limits what kind of development and tests you can do on your laptop†. In the end you have to attach to remote images for debug sessions. CCL happened to have threading support on Arm32 target we use so that's how the development historically started. LW license was procured later: we gave it a run and turned out the tree-shaked binaries it produces use much less memory. We're comfortable running it on a 128Mb RAM (single core) SoM as a part of embedded Linux build. † That said we do have a simulator for the product running on a 64c/128t server. It however mostly tests deployment/procurement/networking part of the thing rather than physical component it operates on.
    - patrec 5y ago
      But doesn't lispworks also have threading support on arm and would allow you to attach to a remote image?
      - varjag 5y ago
        The threading support was lacking on SBCL, that's the reason we started on CCL. It is of course there on LW or we wouldn't be able to deliver. Point is if I have to attach to remote hosts anyway I might just as well continue to use Emacs Slime rather than learn the ropes of LW's own remote debugger. Also LW license allows for unlimited redistribution of deliverables (that you can't however attach to) but the compiler itself is licensed per seat.
juanre 5y ago
I do, the star mapping sofware at the core of my company is Common Lisp run by sbcl. I use it because it is fast, reliable, and a pleasure to develop with. Actually, that is true, but the actual reason I use it is that many many years ago I read PG's "On Lisp", and was blown away by it. So I had to find a project to try Lisp out. It ended up being my livelihood.
- medo-bear 5y ago
  this is awesome! do a showhn for valentines, or similar in lisp reddit :)
vindarel 5y ago
See: https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ (to everyone answering: is your company listed there?? Thanks in advance) See also this recent interview: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ (and I also do for a DB-management script and a simple webapp)
reikonomusha 5y ago
Yes, have been using it in production and hiring Lisp programmers for over 5 years.
wglb 5y ago
I've used SBCL in production (75k lines of Lisp) and it worked very nicely on Linux.

Is there anyone here using CL in production? If so, why -- compared to more mainstream solutions -- and how's your experience been?

by vmsp 5y ago

Is there anyone here using CL in production? If so, why -- compared to more mainstream solutions -- and how's your experience been?

smegsicle 5y ago

No reason not to, unless you can't trust your developers with high-power footgun features like.. multiple dispatch ??

fiddlerwoaroof 5y ago

These people are: https://www.itasoftware.com https://www.itasoftware.com

rjsw 5y ago

I am, it is easier to write than C or C++ and faster than Python or Ruby.

mmmm2 5y ago

Grammarly, at least as of November, 2020: https://www.grammarly.com/blog/engineering/running-lisp-in-production/ https://www.grammarly.com/blog/engineering/running-lisp-in-p...

diskzero 5y ago

Yes. I have deployed mobile applications using native UI (SwiftUI, etc.) with all the shared logic in Lisp. To me, this was a better alternative than the usual C/C++ shared logic approach. My current application is a music hardware device that is mostly Lisp. As to why, this could be a lengthy post, and I am sure I have made one elsewhere on HN. It is a very good language, has many of the features that are being re-discovered and implemented in other languages, has an interactive model of development (REPL driven) that I find very productive and I can deploy an application across multiple platforms with little to no modifications. I do pay for LispWorks and it is more than worth it. I make a living developing applications and devices that use Lisp and the cost is covered by a fraction of a percentage of sales. Some people may try to use SBCL, CCL or other free implementations. I just don't have the time or risk tolerance to be dependent upon the lack of predictability for bug fixes or modifications needed to run on new architectures. The M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly.

moonchild 5y ago
> M1 architecture has been a big problem for some of these Lisps. CCL has no timeline for adoption and some commercial products are suffering as a result. GNU Scheme will probably never be able to run on the M1. LispWorks stays current and will fix reported bugs rapidly SBCL supports the M1; lispworks and allegro still do not.
- diskzero 5y ago
  > SBCL supports the M1; lispworks and allegro still do not. I have been using LW on the M1 for months. Why do you think Apple Silicon is not supported?
  - moonchild 5y ago
    It runs the x86 version under rosetta. I expect most lisps will run the same way.
    - diskzero 5y ago
      You did mention above that 8.0 is now native M1, but you may still be quite right about the 7.1 version that is available for free download works using Rosetta 2 on the M1.
  - diskzero 5y ago
    It looks native Apple Silicon to me, but maybe you have information I don't. >>> file lispworks-8-0-0-macos64-universal lispworks-8-0-0-macos64-universal: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] lispworks-8-0-0-macos64-universal (for architecture x86_64): Mach-O 64-bit executable x86_64 lispworks-8-0-0-macos64-universal (for architecture arm64): Mach-O 64-bit executable arm64
    - moonchild 5y ago
      Ah, right you are; looks like my information was out of date. http://www.lispworks.com/news/news39.html http://www.lispworks.com/news/news39.html says: > Native support for Apple silicon Macs

varjag 5y ago

We do, in the context of a distributed embedded system. It's great way to achieve high development velocity without compromises on runtime efficiency. I'm substantially proficient in C (we've had a bunch of systems done in it too) and there is no question we'd have missed our budget/time/features target had we chose it instead. That said we don't use SBCL but LispWorks for delivery and CCL for development.

patrec 5y ago
Interesting, I'd have assumed that LispWorks would be a much nicer development environment than CCL. Are you trying to save license fees, or do you actually find CCL nicer to work with?
- varjag 5y ago
  No the license cost is fairly marginal in overall development costs. Rather it's an embedded system of numerous (hundreds) networked devices so it limits what kind of development and tests you can do on your laptop†. In the end you have to attach to remote images for debug sessions. CCL happened to have threading support on Arm32 target we use so that's how the development historically started. LW license was procured later: we gave it a run and turned out the tree-shaked binaries it produces use much less memory. We're comfortable running it on a 128Mb RAM (single core) SoM as a part of embedded Linux build. † That said we do have a simulator for the product running on a 64c/128t server. It however mostly tests deployment/procurement/networking part of the thing rather than physical component it operates on.
  - patrec 5y ago
    But doesn't lispworks also have threading support on arm and would allow you to attach to a remote image?
    - varjag 5y ago
      The threading support was lacking on SBCL, that's the reason we started on CCL. It is of course there on LW or we wouldn't be able to deliver. Point is if I have to attach to remote hosts anyway I might just as well continue to use Emacs Slime rather than learn the ropes of LW's own remote debugger. Also LW license allows for unlimited redistribution of deliverables (that you can't however attach to) but the compiler itself is licensed per seat.

juanre 5y ago

I do, the star mapping sofware at the core of my company is Common Lisp run by sbcl. I use it because it is fast, reliable, and a pleasure to develop with. Actually, that is true, but the actual reason I use it is that many many years ago I read PG's "On Lisp", and was blown away by it. So I had to find a project to try Lisp out. It ended up being my livelihood.

medo-bear 5y ago
this is awesome! do a showhn for valentines, or similar in lisp reddit :)

vindarel 5y ago

See: https://github.com/azzamsa/awesome-lisp-companies/ https://github.com/azzamsa/awesome-lisp-companies/ (to everyone answering: is your company listed there?? Thanks in advance) See also this recent interview: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ (and I also do for a DB-management script and a simple webapp)

reikonomusha 5y ago

Yes, have been using it in production and hiring Lisp programmers for over 5 years.

wglb 5y ago

I've used SBCL in production (75k lines of Lisp) and it worked very nicely on Linux.