Bringing Clojure programming to Enterprise (2021) (blogit.michelin.io)
176 points by smartmic 11 hours ago
killme2008 10 hours ago
I wrote Clojure for about five years. Left when I changed jobs, not because I wanted to. It's genuinely one of the most productive languages I've used, and I still miss the REPL-driven workflow.
One thing I built: defun https://github.com/killme2008/defun -- a macro for defining Clojure functions with pattern matching, Elixir-style. Still probably my favorite thing I've open sourced.
tombert 3 hours ago
Clojure is such a fun language to write; it has great concurrency tools from the get go, and since it has access to the entire Java ecosystem you're never hurting for libraries.
I find myself missing Clojure-style multimethods in most languages that aren't Clojure (or Erlang); once multimethods clicked for me, it seemed so blatantly obvious to me that it's the "correct" way to do modular programming that I get a little annoyed at languages that don't support it. And core.async is simply wonderful. There are lots of great concurrency libraries in lots of languages that give you CSP-style semantics (e.g. Tokio in Rust) but none of them have felt quite as natural to me as core.async.
I haven't had a chance to touch Clojure in serious capacity in awhile, though I have been tempted to see if I can get Claude to generate decent bindings for Vert.x to port over a personal project I've been doing in Java.
dgb23 9 hours ago
I like it! Really nice API.
I had an idea about writing something similar, but for multimethods, but never got around thinking it through and trying it out.
The way defmulti and defmethod work is that they do a concurrency safe operation on a data structure, which is used to dispatch to the right method when you call the function.
My hunch is that it should be possible to do something similar by using core match. What I don't know is whether it's a good idea or a terrible one though. When you're already doing pattern matching, then you likely want to see everything in one place like with your library.
LouDNL 10 hours ago
It's good to read that Clojure is getting more and more exposure. I write Clojure fpr my day job and wouldn't want to swap it for anything. The community is small but very helpfull and easy reachable. The learning curve is steap indeed, but very much worth it!
thunky 8 hours ago
Clojure has some pretty big downsides last i looked:
- syntax is hard to read unless you spend a lot time getting used to it
- convention for short var names makes it even harder
- function definition order makes it even harder
- too dynamic for most people's taste
- no type safety
- the opposite of boring
- no clear use case to show it clearly beating other languages
- niche with small community and job market
- JVM
For all those reasons its a hard sell for most imo.
manoDev 4 hours ago
These might be theoretical issues that people without experience worry about, but let me share what I've witnessed in practice working almost a decade with Clojure at Nu.
We mostly hired people with no previous Clojure experience. Majority of hires could pick up and get productive quickly. People fresh out of college picked it up faster. I even had a case of employee transitioning careers to S.E., with no previous programming experience, and the language was a non issue.
I can't remember an instance where the language was a barrier to ship something. Due to reduced syntax surface and lack of exotic features, the very large codebase followed the same basic idioms. It was often easy to dive into any part of the codebase and contribute. Due to the focus on data structures and REPL, understanding the codebase was simply a process of running parts of a program, inspecting its state, making a change, and repeat. Following this process naturally lead to having a good test suite, and we would rely on that.
Running on the JVM is the opposite of a problem. Being able to leverage the extensive JVM ecosystem is an enormous advantage for any real business, and the runtime performance itself is top tier and always improving.
The only hurdle I could say I observed in practice was not having a lot of compile time guarantees, but since it was a large codebase anyway, static guarantees would only matter in a local context, and we had our own solution to check types against service boundaries, so in the end it would've been a small gain regardless.
asa400 7 hours ago
> the opposite of boring
I have to push back on this one, respectfully.
Clojure is easily the most boring, stable language ecosystem I’ve used. The core team is obsessed with the stability of the language, often to the detriment of other language values.
This attitude also exists among library authors to a significant degree. There is a lot of old Clojure code out there that just runs, with no tweaks needed regardless of language version.
Also, you have access to tons of battle tested Java libraries, and the JVM itself is super stable now.
I won’t comment on or argue with your other points, but Clojure has been stable and boring for more than a decade now, in my experience.
thunky 6 hours ago
Oreb 7 hours ago
> syntax is hard to read unless you spend a lot time getting used to it
That’s pretty much exactly the opposite of how I always felt. Perhaps because I’m not a programmer by education, I always struggle to remember the syntax of programming languages, unless I’m working in them all the time. After I return to a language after working in other languages for a while, I always have difficulties remembering the syntax, and I spend some time feeling very frustrated.
Clojure and Lisps more generally are the exception. There is very little syntax, and therefore nothing to remember. I can pick it up and feel at home immediately, no matter how long I’ve been away from the language.
tombert 3 hours ago
I don't think the syntax is hard to read in any kind of objective sense, it's just different than most mainstream languages. Greek would be hard for me to read too, but that's not because it's necessarily harder to read than English, just that I don't really know Greek.
I agree with the short variable name convention, that's annoying and I wish people would stop that.
Everyone complains about a lack of type safety, but honestly I really just don't find that that is as much of an issue as people say it is. I dunno, I guess I feel like for the things I write in Clojure, type issues manifest pretty early and don't really affect production systems.
The clearest use-case I have for Clojure is how much easier it is to get correct concurrent software while still being able to use your Java libraries. The data structures being persistent gives you a lot of thread safety for free, but core.async can be a really nice way to wrangle together tasks, atoms are great for simple shared memory, and for complicated shared memory you have Haskell-style STM available. I don't remember the last time I had to reach for a raw mutex in Clojure.
Good concurrency constructs is actually how I found Clojure; I was looking for a competent port of Go-style concurrency on the JVM and I saw people raving about core.async, in addition to the lovely persistent maps, and immediately fell in love with the language.
Also, I really don't think the JVM is a downside; everyone hates on Java but the fact that you can still import any Java library means you're never blocked on language support. Additionally, if you're willing to use GraalVM, you can get native AOT executables that launch quickly (though you admittedly might need to do a bit of forward-declaration of reflection to get it working).
Antibabelic 7 hours ago
The JVM is one of the major selling points of Clojure. You can "write once, run anywhere" and benefit from Java's massive ecosystem, all without having to use a Blub language. Modern JVM implementations are also incredibly fast, often comparable in performance to C++ and Go.
thunky 7 hours ago
dgb23 6 hours ago
> no type safety
That's fair if you're looking at it from a performance perspective.
Not entirely fair if you look at it from a perspective of wanting fast feedback loops and correctness. In Clojure you get the former via the REPL workflow and the latter through various other means that in many cases go beyond what a typical type system provides.
> the opposite of boring
It's perhaps one of the most "boring in a good way" languages I ever used.
thunky 6 hours ago
epgui 4 hours ago
This comment is like saying you can appreciate wine, but you think it should have less grapes.
hombre_fatal 3 hours ago
You also need to learn a new tool to write lisp, like paredit.
While it's amazing once you've learned it, and you're slurp/barfing while making huge structural edits to your code, it's a tall order.
I used Clojure for a long time, but I can't go back to dynamic typing. I cringe at the amount of time I spent walking through code with paper and pencil to track things like what are the exact keyvals in the maps that can reach this function that are solved with, say, `User = Guest | LoggedIn` + `LogIn(Guest, Password) -> LoggedIn | LogInError`.
Though I'm glad it exists for the people who prefer it.
midnight_eclair 3 hours ago
jimbokun 8 hours ago
Most of those seem very subjective with many people having the exact opposite opinion.
thunky 7 hours ago
IBCNU 5 hours ago
JVM + Syntax is upside for me.
Type's are for compilers ;) jk. I'm fully lover or type's but removing the constraint is easy in clojure. teams resist.
<3 the opposite of boring.
rockyj 7 hours ago
I am a Clojure fan and would love to use it. But you are right, we live in a real world where money talks and most organizations want to see developers as cheap, replaceable commodities.
Not to mention in a post AI world, cost of code generation is cheap, so orgs even need even fewer devs, combine all this with commonly used languages and frameworks and you need not worry about - "too valuable to replace or fire".
Having said that - there may be a (very) small percentage of orgs which care about people, code crafting and quality and may look at Clojure as a good option.
virgil_disgr4ce 5 hours ago
> - syntax is hard to read unless you spend a lot time getting used to it
This is only true if you assume C-like syntax is the "default."
But regardless of that, I'd argue that there's much less syntax to learn in LISPy languages. The core of it is really just one single syntactic concept.
gorjusborg 5 hours ago
hrmtst93837 3 hours ago
Clojure on the JVM adds niche-language overhead to old deployment pain, so you get bleeding-edge bugs and mid-90s release rituals in the same stack. If you want to onboard new hires to Clojure expect to spend time on editor config and build tooling before they can even trust a stack trace. You still inherit Java's GC quirks without much type-driven tooling.
greekrich92 7 hours ago
Moby Dick is too hard to read. They should make it shorter with a limited vocabulary.
Cthulhu_ 7 hours ago
bitwize an hour ago
> It's good to read that Clojure is getting more and more exposure.
I nominate this sentence for "best inadvertent freestyle rap on Hackernews".
IBCNU 5 hours ago
AI augmented Repl driven dev has got me back into Clojure and it's been changing my life (full on JVM nerd: Kotlin mostly on the backend).
The syntax is the best in the world (how computer's really operate?) but it's always been a pain to setup the tooling for me. I'm dumb like that. Now with AI it's become super easy to get back into the REPL and I'm in heaven.
Totally moving it back into workflow and proposing to bring it back into the dayjob.
packetlost 4 hours ago
> how computer's really operate?
I don't know exactly what you mean by this, but Clojure syntax is not really anywhere close to how computers actually process instructions.
Clojure is very nice though.
nmil 5 hours ago
May I ask what your workflow actually looks like? There's been a fair bit of clojureposting over the last few days, and I've decided to jump in and learn.
I love the idea of an AI integrated repl (like what Jeremy Howard and team have done with solveit), it's far more in line with my preferred vision of the AI augmented future of coding. Less "swarm of agent" more, "learn with the agent".
IBCNU 5 hours ago
Sure!
Setup is:
- nvim --listen /tmp/nvim — starts Neovim with a socket Claude can connect to
- /mcp in Claude Code — enables the Neovim MCP server, gives Claude direct control of Neovim
- lein repl in the nvim terminal
- Claude reads .nrepl-port, runs :ConjureConnect — REPL is live!
The loop is so dope:
- Claude writes code directly into my .clj files
- Then evals it into the running process via Conjure
- Sees the result in the REPL, iterates if wrong, all in the same conversation turn
- wrap-reload middleware means the web server hot-reloads changed namespaces on the next request
zingar 4 hours ago
IBCNU 5 hours ago
Also I love your take.
Feel like a holy grail to me to back in the hot seat with repl driven but I can drop in and figure things out... all on the JVM. Madness!
InvOfSmallC 2 hours ago
My pain point (which I admit didn't recheck if someone did something about it), is an interoperable example of how to use Spring (n.1 framework for many enterprises) with Clojure.
Something where I feel Kotlin did better.
For me the best way to introduce something like this is that I can actually start with small software increments on a Spring Java project.
midnight_eclair 8 hours ago
every time i go back to writing non-clojure code outside of repl-driven environment i feel like a cave man banging rocks against each other
no amount of ide smartness or agentic shenanigans is going to replace the feeling of having development process in sync with your thought process
jimbokun 8 hours ago
You just made me wonder if REPL driven development and LLMs can be better combined somehow.
SatvikBeri 2 hours ago
I use a REPL in tmux. That lets Claude code read/write to it easily, as well as letting me take manual control to investigate.
thom 7 hours ago
This is already a strong theme in the Clojure ecosystem, e.g.:
laszlojamf 8 hours ago
Slightly off topic, but I find it to be a testament of how software has already eaten the world when friggin Michelin has a tech blog. What's next? General Electric releasing a frontend framework?
brabel 8 hours ago
Toyota has an open source game engine written in Flutter!
chii 8 hours ago
> general electric releasing a frontend framework
or toyota releasing a game engine: https://www.theverge.com/games/875995/toyota-fluorite-game-e...
Cthulhu_ 7 hours ago
You'd be surprised: https://www.ethosdesignsystem.com/
(okay it's a design system, not so much a framework, but still)
user3939382 8 hours ago
Funny example since they’re known for automotive parts and their food guide. It’s almost on brand.
jimbokun 8 hours ago
I mean how else are you going to get people to drive long distances and buy more tires without giving them yummy destinations to eat at?
sswezey 10 hours ago
honkcity 7 hours ago
I'd love to work with Clojure. I have the misfortune of working on something that is stuck on java1.8 and Groovy, part of the issue is the code quality is a disaster (json and xml parsed with regex...). At least with Clojure I'd get to enjoy the repl workflow and usable text editor (emacs). I also just enjoy working with sexps.
dkarl 5 hours ago
Honestly, if I could quit my job for six months and work in a codebase like yours, I'm extremely curious what I could accomplish with AI.
We have a codebase at work that was "stuck." We've consistently done minor library upgrades, but no major upgrades in several years, and was recognized as a major piece of technical debt / minor disaster for almost two years, in that we urgently needed to dedicate an engineer to it for a month or more to bring it up to date. We also suspected that framework upgrades would improve performance enough to save us a little bit in operating costs. I got curious, created a branch, and threw Claude at it. Claude knocked it out in a couple of days while I mostly worked on other things. Then we dedicated several engineer days to doing extra manual testing. Done and deployed. Now we're ready to experiment with giving it less resources to see if the performance improvement holds up in practice.
This codebase was only about 200k lines of code, so probably smaller than yours. Really curious how it would go with a larger codebase.
EDIT: Claude may only have taken a couple of days because I was only checking in occasionally to give it further instructions. I don't know how fast it would have been with my complete attention.
eduction 4 hours ago
The latest clojure still works with Java 8 fwiw... Although I believe they are looking at moving to 17 soon as minimum.
erfgh 7 hours ago
Can someone enlighten me about the REPL that lispers keep raving about? Isn't it more-or-less the same as the Python REPL?
thom 6 hours ago
Almost exactly, it's mostly how you use the REPL that differs, and then only because of what different editors prioritise. When I'm in Emacs, all my work happens against a running REPL - when I open or save a file, it's reloaded. Any tests loaded in the REPL rerun on every save, within that live instance. If I drop into the debugger, it's against that live instance. I can swap in mock components to a running system, go check stuff in a browser (even jack into a live webpage with ClojureScript), all in one long running instance. I have struggled to recreate this kind of setup as smoothly in Python with any editor (pytest doesn't want to run this way, and IPython's autoreload doesn't feel as reliable), but I do probably write more REPLy code in Python than most, so all my model training and optimisation runs during development happen in pausable background threads in IPython etc.
All that said, 90% of the time you still just eval a bit of a code to see what happens and that's the same between the two languages.
never_inline 4 hours ago
I don't know what you meant by pausable background threads in IPython, but if anyone is trying out - I have had some success with VSCode + IPython: https://mahesh-hegde.github.io/posts/vscode-ipython-debuggin... -
(you can theoretically pass "reload": true (or similar option) in launch.json for auto reload, tho I haven't felt the need to use that in my workflows.)
arafeq 5 hours ago
simplest way to think about it: the python repl is a scratch pad next to your code. the clojure repl IS your running application. you're rewiring the plane mid-flight instead of landing, making changes, and taking off again. once you experience that feedback loop you genuinely can't go back.
stephbook 4 hours ago
Doesn't sound too different from Typescript breakpoints attached to a running website with "Hot Module Replacement."
joshlemer 4 hours ago
midnight_eclair 3 hours ago
the benefit of lisp in an editor with integrated repl environment is that you get to see immediate feedback by easily evaluating chunks of your code as you navigate it, without copying stuff back and forth between the editor and the repl
and the benefit of lisp comes from the fact that every expression is fully delineated by parentheses, so you don't need to select any text, find the start or the end of any syntactic construction, you just eval the form you're standing at and see the result
or just as easily you can wrap that form, bind the locals to test values and eval that to see what changes
fredrikholm 7 hours ago
You evaulate code within your editor against the REPL, seeing the output in the same window you're writing in (perhaps in a different buffer).
The cycle is:
1. Write production code.
2. Write some dummy code in the same file (fake data, setup).
3. Evaluate that dummy code. See what happens.
4. Modify code until satisfied.
embedding-shape 7 hours ago
Indeed. For people used to the "typical REPL" from Ruby, Python and alike, the best comparison I've found is this:
"Typical REPL" workflow: Have one editor open, have one REPL open, have one terminal open that runs the application. One change is typically: Experiment in the REPL window, copy-paste into your editor, write tests, restart application (lose all state), setup reproduction state, test change. Or something like this.
In a Clojure REPL workflow, you'd do something like: Have one editor open, this starts the REPL and often the application in the background too. One change is typically: Edit code, evaluate that snippet of code (which sends it to the REPL and the running application), write tests, evaluate them too in the editor, if you're happy, hit CTRL+S and you're done. Application still has the existing state, no restarts needed and you essentially never have to leave the editor window/pane.
Of course, others might have slightly different workflows, but for myself and many (most?) other Clojure developers I've observed in the wild, this is pretty much the standard.
wwweston 6 hours ago
norir 3 hours ago
You don't need a repl for this workflow and it can be easily implemented in any language. `ls *.MY_LANG | entr -c run.sh` You get feedback whenever you save the file.
Personally, I find waiting more than 200ms unacceptable and really < 50ms is ideal. When the feedback is very small, it becomes practical to save the file on every keystroke and get nearly instantaneous results with every input char.
rienbdj 7 hours ago
Is this similar to Unison scratch file driven development?
LandR 6 hours ago
https://www.youtube.com/watch?v=5HHLT2_a1tI
An example of me solving an Advent of Code with clojure and repl. You can see i never interact with the repl directly, I just send code to it via my editor and get results inline.
neutronicus 5 hours ago
The two big things are:
1. REPL is automatically compiled into running systems 2. Great hot-reloading support
So it's generally very easy to "poke" at a running system, and the whole dev process assumes you will do this.
TBH, these days it is largely possible in a C++ debugger. Less so 10 years ago, though.
sammy0910 7 hours ago
it is very similar, but it is easier to evaluate sub-expressions thanks to the unique syntax of lisp.
there's a detailed explanation here: https://youtu.be/Djsg33AN7CU?t=659
whalesalad 7 hours ago
More or less, yes. It's more about the approach to the repl and how it is leveraged in development, or even jacking in to a running system and modifying it as it is running.
0x1ceb00da 11 hours ago
What is the y axis in first chart? What is the data source?
dgb23 10 hours ago
They publish their yearly surveys on their official website. The graph seems to be from State of Clojure 2020:
https://clojure.org/news/2020/02/20/state-of-clojure-2020
The most recent report:
VMG 10 hours ago
503