The greatest benefit of SBCL is that it's got great performance and the REPL jack in allows you to debug any application state. Building CL software is just amazing.
So as the company is growing really fast, and I never want to talk to a VC, I need to add those reliability into the system as I can't spend a lot of time training people.
That can only be done by having the highest performance to simplest code ratio (since we lose the repl jack in).
Go is the clear winner here after trying a bunch of them.
It is also easy for people to learn and the amount of tutorials and resources online is great.
It is a bit sad, but the Lisp hacker bucket is a really small pool if you want to hire from so at the end of the day I had to compromise.
Having said that Go is quite a workhorse and has the simplicity of C so it is actually not that bad.
What about having a core of a few people, and leverage that Lisp productivity potential? If you need a lot more "bulk" work (say, for customer integrations/customizations), is it something that the core people can make easier? Such as with APIs or DSLs, and recipes, so that this other set of programmers doesn't have to all be CL experts?
You'll probably have to pay good money for that core of great CL hackers, though. Go programmers are more numerous, and maybe easier to find competent ones at commodity rates.
And is the number of CL hackers available on the job market decreasing? ITA found a lot of them, at one point. There are many Scheme/Racket programmers than there are jobs.
If you have some great Lisp hackers who are also experienced in industry team software engineering, you step back and let them use whatever they decide is best to use. :)
Yes I wrote all the first images. I love Lisp and think it is amazing if you approach it in the right way.
Now the company is growing at a rate that I need to hire people and build teams.
That is where Lisp is a hard bargain. The bucket of people who can write a new system from scratch without falling for the common traps is really small.
As someone who dabbles in common lisp I would love to know some examples of common traps are in designing a system in cl, since I am probably bound to fall into many :)
A lot of my software which earns a $4 million profit per year has SBCL sub systems though that is slowly decreasing as we are moving away from Lisp.