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
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
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
.. and, finally, you realise that Common Lisp is an acceptable Lisp (because when you learn it well enough you start to understand how to tune it to make it acceptable for you personally ;)
But that's not the reason. Personally I find Lisp superior in most respects, but I don't think it's a good place and time to argue on Lisp vs Racket and similar topics.
Yes, we're in the process of moving to docker-based deployments now. In fact, we already have ClozureCL running inside docker, but haven't yet done the same for SBCL. TBD soon :)
Can you also point to the particular version of SBCL that fixed for long-running compilation? We have recently upgraded to one of the latest version, but I think I've missed this change - I'm interested to check it in more detail.
We played with sb-ext:bytes-consed-between-gcs, but couldn't find the right balance. That's why we were surprised with the result of the oversized heap experiment
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.
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.
As for me, adaptability is one of the important traits of a senior engineer. Surely, you don't have to be an expert in every platform, but you also shouldn't go mad if you need to do some work outside of your comfort zone occasionally. Besides, every language has its strong and weak points: if you're putting arbitrary limits here, you're just limiting what you can do and the people you're going to get in a team. At Grammarly, we always erred on the side of more freedom and it worked not so bad for us so far. Although, there are different companies, each with a unique story...
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
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)
I'm also teaching an OS class, and IMHO using some new shiny thing is not the right way to approach it, because the students will be put in an ideal imaginary world, and neither will face the real-world practice, nor understand how it all came to be the way it is now. I think, it may be a good follow-up course (like "System Programming in Rust") after the "normal" C-based course.
I also don't agree with the notion that other option is "to teach students to write C code riddled with security vulnerabilities, memory leaks, and race conditions". This is exactly what such kind of course should teach them not to do, clearly pointing these problems and explaining how to deal with them. But not having exposure to that in the learning environment will only make them repeat these mistakes in the real world.
Lisp-2 is much saner. What it adds is just funcall, and it's not such a big deal in practice, because most of the times in the situations of higher-order function you would use apply, reduce or map, which likewise should be used in Lisp-1. What it brings instead is that you have to worry about name clashes much much less. The classic is list vs lst.
What I personally like is that you always know what are you referring to in a higher-order function call: a variable name or a function name. So it just removes the need for some additional intellectual effort of remembering this (i.e. #' is a nice annotation)
Currently, I develop in Clozure and SBCL alongside, and it's true that SBCL compilation speed (and memory consumption) can be prohibitive at times, but in return it may give up to 3-4 times execution speed increase. So it's a real trade-off worth considering. We now use CCL for interactive development and SBCL on the server.
I don't think, that the question "Which Lisp should I use: Clojure or Common Lisp?" is quite correct. As they are really so different in very basic concepts: mutable vs immutable, OO vs non-OO, bootstrapped vs JVM-based, and the list can go on and on. This question is of the same sort of "Should I use Lisp (I mean Common Lisp) or Python?" And it can be reduced t "Which dynamic language should I use?" Or "Should I use Lisp or Java?" - "Which memory-managed system programming language should I use?" Likewise "Should I use Lisp or Clojure?" can be reduced to "Which s-expression based language should I use?"