We've also been using Lisp in production. It has gone wonderfully, and has allowed some of the most simultaneously maintainable, resilient, and efficient code I've seen in my career. It's also attractive differentiator to some programmers who don't want to drone away writing bulk-Java day-in and day-out.
A key to running Lisp in production is to step away from thinking of it as a lone-wolf bionic-suit hacker language, and to invest in developing a style guide, code review guidelines, CI/CD, and a culture of training new programmers to write Lisp. I've found that you typically don't have to hire Lisp specialists. As long as you find good programmers, they pick up Lisp just fine in just a few short weeks.
The sibling comments are right though: Lisp's reputation is unfortunately affected by so, so many myths that it actually stunts the ecosystem in certain ways. The most rampant myth these days is that (somehow) macros automatically imply doom of a codebase after a certain size or contributor count. Classic myths from decades ago, like "Lisp is interpreted and slow", still echo from time to time too. Lisp's extensive, half-century history is a strength but also clearly a (social) weakness.
A lot of myths come from good-intentioned speculation of the supposed consequences of certain features or aspects of Lisp, and not from actual experience using it.
I tried to get it out to as many channels as possible, all the ones I knew about -- the common Lisp subreddit, discord, irc, the fediverse, telegram cl group, and matrix. I also sent two reminders in those places :) I'm sorry if I didn't reach you though. What channel did I miss?
Let me preface this by saying, Jeff owes Red Hat nothing and he's free to stop "supporting" RHEL for any or no reason at all.
That said, "grab a copy of Linux" seriously, gloriously, hilariously handwaves away so many things that Red Hat does to create a RHEL release.
Red Hat pulls together hundreds or thousands of upstreams to create RHEL, participates in many of them, tests all that together, helps partners certify software against it, etc. etc. etc.
It's true, Red Hat doesn't "own" the Linux kernel, but it's done a ton to help develop it over the years. But RHEL is not merely the kernel nor any single upstream. RHEL is a product that comprises thousands of packages all tested together and then released as a supported product.
What Red Hat is trying to guard is not the source code to any single or even groups of projects. It's trying to preserve and capture the value it created from all those parts. Coincidentally, that value is what businesses, competitors, and the community are clamoring for and not the source code alone.
They want that single point-in-time snapshot that everybody agrees on as a de facto standard because the overall community has never been able to agree on another workable standard that would allow targeting applications across the board. And that standard has a name, and it's RHEL. And it belongs to Red Hat.
You can have all the pieces and assemble them yourselves if you like. But nobody is entitled to certify it as (officially or unofficially) RHEL except Red Hat.
If that angers you, I heartily encourage folks to build Debian up as the standard we all certify against. Or start your own business that overtakes Red Hat and earns the place RHEL has today.
Mark Shuttleworth took potshots at Red Hat's business model with RHEL for years, and it seems to me that they're doing a very similar thing now with Ubuntu Pro by holding back updates to packages after 5 years and charging for updates to the Universe and Main repos.
Long Covid sucks. It has had a detrimental effect for sure. I was lucky to have it early at a young age and being physically healthy. I am now mostly recovered 2 years later. I could not imagine having it being older.
The studies on the effectiveness of nattokinase, Bromelain + NAC, and nitric oxide are seriously worth considering if you suspect you have it. I wish I knew about those earlier.
All that stuff still exists, it just exists in the multiplexer instead of the editor. That's my point. I don't need it in the editor. I just need it.
Even better! It's not useful for just Lisp! It works for python, bash, whatever. That's not a bug, that's a feature. It's simple, lets the editor be the editor and the multiplexer be the multiplexer. It's much more "vim zen" than importing an entire repl process into the editor.
I've always known about slimv, I just like vim-slime better. My only complaint is that when it copies and paste texts around it's slower using interprocess communication than it is using TCP. But the nice thing I can see exactly what's happening instead of having it all hid from me. Makes debugging problems much easier.
Even describing slimv as a "mode" belies its emacs-ness. Vim doesn't have major and minor modes. It has insert mode and normal mode, that's it.
I don't even use fugitive. Why do it when the git CLI is faster? I've already learned the cli, why do I have to learn an entirely new set of commands to do the same things I already know how to do? Especially when I'm using vim inside GNU screen? C-a 2, boom, I'm in a CLI. Switching back and forth is a breeze. I have a few key bindings in vim that allow me to see the git blame line of a particular line, that's it.
Don't turn vim into a user interface for $x. Embed vim into other user interfaces. Vim plugin for intellij, vscode, vim inside a multiplexer, ... This works much better in my opinion.
Because SQL has so many opinionated style guides rather than the One True Way I really enjoy spending time, if I have it, on making my SQL as Uniform and legible as I can. Sadly this is all closed source code nowadays. But my SQL files look almost like a table with clear 'rivers' along keywords. It makes my OCD brain go a little fuzzy inside when I finish :) Also having worked on a MONSTER of a financial system powered by stored procs and autogenerated SQL, I'm talking million line SQL files you can't load in a GUI, I am very fond of legible small SQL scripts nowadays.
AGPL does nothing to protect commercial projects from AWS. Look at MongoDB: they had been AGPL for a loooong time, but moved to a non-FOSS license specifically because of AWS.
AWS has no problems with giving away the code for any managed-X service they. The magic that they charge for is the managed part - deployment, autoscaling, upgrade management, and other Operations stuff that no FOSS license can compel them to make public.
But there is syntax highlighting - what editor and language combination are you using? I know for a fact that SQL is highlighted inside Python and PHP strings in Sublime Text 4..
A key to running Lisp in production is to step away from thinking of it as a lone-wolf bionic-suit hacker language, and to invest in developing a style guide, code review guidelines, CI/CD, and a culture of training new programmers to write Lisp. I've found that you typically don't have to hire Lisp specialists. As long as you find good programmers, they pick up Lisp just fine in just a few short weeks.
The sibling comments are right though: Lisp's reputation is unfortunately affected by so, so many myths that it actually stunts the ecosystem in certain ways. The most rampant myth these days is that (somehow) macros automatically imply doom of a codebase after a certain size or contributor count. Classic myths from decades ago, like "Lisp is interpreted and slow", still echo from time to time too. Lisp's extensive, half-century history is a strength but also clearly a (social) weakness.
A lot of myths come from good-intentioned speculation of the supposed consequences of certain features or aspects of Lisp, and not from actual experience using it.