Live data from Hacker News

Running Lisp in Production

tech.grammarly.com

51–60 of 119 posts

Re: Running Lisp in Production

#51

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…

You know, starting a paragraph by "We've built an esoteric application", would you expect what followed to be a simple bug?

Write an "esoteric" app and you'll start hitting the limits of your platform.

Re: Running Lisp in Production

#52

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…

It'd be a Hell of a lot more interesting than the millionth time looking into a bug caused by invalid input into a non-validated form in an ancient CRUD intranet app.

Re: Running Lisp in Production

#54
post #42
post #9

Earlier quoted context omitted.

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.

It was a cool talk, but it didn't really address adoption.

It featured (to the best of my memory):

A new data model for om next. Instead of cursors, components have a composable datomic style DSL to locate their data, which is pluggable and can be from local memory or a cached server side query.

Using this approach you can request data in new ways from the client without adding server side code.

An update on cljs in cljs (small example but showing lots of plumbing work done)

The path to react native, repls and dynamic code loading on the device (was demoed) via ambly

Re: Running Lisp in Production

#55
Great article, and good reminder on using trace. Every time I rediscover trace, I can't remember how I ever forgot to use it in the first place for most of my problems.

I used CL in a production environment a while back for a threaded queue worker and nowadays as the app server for my turtl project, and I still have yet to run into problems. It seems like you guys managed to push the boundaries and find workable solutions, which is really great.

Thanks for the writeup!

Re: Running Lisp in Production

#56

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?

While a Single Language to Rule Them All would be cool, I ultimately prefer using the "best" language for the job based on specific requirements. The "best" might change over time, too. It can be a headache to manage massively-polyglot environments. At the same time, it's also pretty great for a variety of reasons. I mean, we regularly use different data stores, messaging solutions, frameworks, etc. and I don't see w…

> I ultimately prefer using the "best" language for the job based on specific requirements.

Most shops don't think like that. Using too many languages often quickly becomes unmanageable.

I wouldn't use 6 different languages into the same project UNLESS they are part of different server/cli tools that work in isolation. I don't need to have a deep understanding of Go to use Docker, I don't need to be a PHP expert to deploy Drupal or Wordpress , I don't need to know Ruby to use vagrant,nor Java to use Cassandra. So using these tools in isolation is fine inside the same project.

Re: Running Lisp in Production

#57
post #33

Earlier quoted context omitted.

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

So how do you start using this example?

I would do something like this on my macbook:

git clone blah && cd blah && brew install leiningen && lein figwheel

I don't know what is you operating system and other details.

You need leiningen, that is the make of Clojure, the repository cloned and you are good.

Re: Running Lisp in Production

#58

Earlier quoted context omitted.

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.

Gnarly CL ecosysten? That seems a tad manichean, Clojure certainly has more libraries but CL has its fair share as well. And if you want to tap into the Java ecosystem there is always ABCL.

Clojure is a language with diferent design sensibilites than CL.

Re: Running Lisp in Production

#59
post #33

Earlier quoted context omitted.

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

So how do you start using this example?

You need leiningen (it's in most package managers):

https://github.com/technomancy/leiningen

Clone the repo, `lein figwheel`, http://localhost:3449/index.html

Re: Running Lisp in Production

#60

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?

There's a reference to upstart in the article. We have played with demonizing SBCL (there are a couple of projects out there), but then Grammarly as a whole moved to upstart-based deployments. They are really easy to manage: basically, you just give it a normal (Lisp) script.
Post reply on HN