I feel the same, except with Common Lisp, whose interactivity is maybe only rivaled by Smalltalk, and whose performance can be made close to that of C for real-world applications.

Yes, in fact Common Lisp was what I almost started investing my energy in before Julia. I almost referenced Common Lisp in the parent post alongside Julia but didn't because I never learned it very well and didn't want to speak from ignorance.

My understanding though is that most of the statements I made also apply in CL though my impression at least from the point of view of scientific computation is that Julia's community is more energetic than CL's. Certainly Julia still has lessons to learn from CL though.

I get the impression that the communities are different. Not that Julia's is "more energetic" (there's actually quite a bit of activity around CL too), but that it's simply a different crowd. The Julia people seem to me to be coming more from the application side of things - computational scientists who want to do a certain job - while the CL people are more interested in CL as a language, without a specific application field in mind. So although neither of the communities are especially large, the Julia bunch have been more focused on good libraries for scientific computation, which is why their ecosystem is better in that respect. (Also, the "Lisp curse": scientists are more likely to choose Julia as a new language, because it looks more like the languages they already know.)

Source: I do computational biology with Julia, hobby projects in Common Lisp.

True, if I was more careful I’d say Julia’s scientific / numerical community is more energetic. I definitely don’t want to sound like I’m dissing CL as I have great respect for it and want to be better acquainted one day.

Julia is influenced by the Common Lisp Object System. But it made it fast for numerical computing. So there is a Julia lesson for CLOS...

http://p-cos.blogspot.com/2014/07/a-lispers-first-impression...

Indeed, and that actually played into my path to using Julia. I had fallen down the lisp rabbit hole and was super interested in the ideas it advocates and was trying to decide on a dialect to try to commit to for my physics numerical work. After spending some time in decision paralysis (even though in hindsight, CL was probably the clear dialect to choose), I discovered that Julia actually inherited a lot of good ideas from the lisp family and that it had its fair share of cool ideas of its own. Eventually, I made up my mind and settled on Julia as my main language, though I screw around with elisp every now and then for my emacs config.

I’d like to come back to CL at some point though and gain some proficiency as I think there’s a lot in CL left for Julia to learn from.

I don't think interactivity and performance are enough to make a good production language. For example, I find Java painful to write without a good IDE, because of all the boilerplate, however it's that boilerplate that makes it very easy to read and refactor.

Agreed. They have to have a good way to write it (an IDE), a good debugger, a good profiler, a good library ecosystem, a good community, a good deployment story, reproducibility, portability across platforms, etc. I find commercial support helpful as well. Common Lisp has all of that.

Do you now find that doing both the prototype and full implementation in Julia the better option?

Sorry, couldn't figure this out from your comment whether you prefer Julia or some other language for doing the prototype and full implementation. If you can clarify this explicity, it would be helpful.

Apologies for the lack of clarity. Yes, I find I really like using Julia from start to finish and really admire that I can do so without compromise.

I find this approach to be straight up superior to the usual pattern where one starts out in a slow dynamic language to build the prototype and then either replaces certain functions with interop calls to a fast language (losing all the features that brought you to your dynamic language in the first place!) or straight up replacing your entire prototype with a production version written in your fast language and providing bindings to your slow language.