I Chose Common Lisp

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Nutrient - The #1 PDF SDK Library
Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.
nutrient.io
featured
CodeRabbit: AI Code Reviews for Developers
Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
coderabbit.ai
featured
  1. graal-build-time

    Initialize Clojure classes at build time with GraalVM native-image

    Graalvm native image for Clojure is a solved problem. Just add this library to the project and add a flag to native image command line.

    https://github.com/clj-easy/graal-build-time

    This initializes Clojure classes at build time and it mostly works for pure Clojure code.

    Doing complicated things (e.g. depending on native library, etc.) requires some tweaking. For example, a few packages may need to be declared as initialized at build time or run time, depending what they are doing. And any unresolved classes need to be added to reflection-config.json.

    All these are easily discoverable if one talks to people in the Clojurian slack channel.

  2. Nutrient

    Nutrient - The #1 PDF SDK Library. Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.

    Nutrient logo
  3. lem

    Common Lisp editor/IDE with high expansibility

    >Looks like vim-slime is essential to how you work with CL

    slime has some issues and I am not convinced lisp and vim are a good pair. lem is getting pretty good and improving by the day, find it much better to work with than vim when it comes to lisp and vim is my primary editor.

    https://github.com/lem-project/lem

  4. methodical

    Functional and flexible multimethods for Clojure. Nondestructive multimethod construction, CLOS-style aux methods and method combinations, partial-default dispatch, easy next-method invocation, helpful debugging tools, and more.

    I have been working with Clojure for 5+ years now. For CLI applications babashka has worked quite well for us.

    Would love to know more about the problems you faced.

    In my experience whenever I faced such issues - it has been because I am not using it well.

    For CLOS kind of things I have found https://github.com/camsaul/methodical library quite well and the performance is better than default multimethods in core clojure implementation.

  5. julia

    The Julia Programming Language

  6. CIEL

    CIEL Is an Extended Lisp. Scripting with batteries included.

    Not standard, but hopefully worth mentioning: the thing that's clicked best for me is the docs on https://ciel-lang.org/ ("batteries included" Common Lisp image). The examples for how to use it's curated libraries matches how I try to integrate a new language into my toolbox.

    It hit the front page a while ago too:

  7. podman

    Podman: A tool for managing OCI containers and pods.

    And there's no REPL for the editor--so I can't actually find out details, let alone fix anything.

    I had thought emacs DX was bad--but I've revised my opinion now: compared to vscode DX, emacs DX is great. You live with VSCode if you want to.

    And note, vscode was made after emacs was made. There's no excuse for this.

    I think this now was about all the time that I want to waste on this thing, again.

    How is this a problem in 2025? shakes head

    >VS Code managed to by-pass the qualitiy and amount of extensions/plugins in a fraction of time Emacs took decades.

    Yeah? Seems to me these vscode extensions are written in crayon. Bad quality like that would never make it into emacs mainline. And it's not even strictly about that! I wonder who would write a developer tool that the developer can't easily debug its own extensions in. That flies about as well as a lead balloon.

    For comparison, there's emacs bufferenv that does dev containerization like this and it works just fine. Configuration: 1 line--the names of the containerfiles one wants it to pick up. Also, if I wanted to debug what it did (which is rare) I could just evaluate any expression whatsoever in emacs. ("Alt-ESC : «expression»" anywhere)

    PS. manually running "podman-compose up" in an example project as a regular user works just fine--starts up the project and everything needed. So what are they overcomplicating here? Pipes too hard?

    PPS. I've read some blog article to make socket activation work for rootless podman[1] but it's not really talking about vscode. Instead, it talks how one would set up "linger" so that the container stays there when I'm logged out. So that's not for dev containers (why would I possibly want that there? I'm not ensuring Heisenbugs myself :P).

    [1] https://github.com/containers/podman/blob/main/docs/tutorial...

  8. vim-slime

    A vim plugin to give you some slime. (Emacs)

  9. CodeRabbit

    CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

    CodeRabbit logo
NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts