[closeparen]

When you’re charged with making product iteration in your org more efficient (as a senior dev might be), a lot of what you end up doing is lifting certain things from hard-coded to config and DSL driven. Carefully and selectively introducing dynamism to overall statically typed and compiled codebases. These are almost always interpreted by our statically typed codebase though. We would never run a dynamic language runtime by itself in prod.

I use Go at work but mostly Python for personal projects currently, and am pushing towards Clojure for personal projects in the future. But that’s because personal programming for me is a cathartic escape from the straitjacket of zero abstraction power and the tedium of manual error handling; I care about my own satisfaction more than I care about scalability to a team of varying skill levels in that context.

[didibus]

This is a constant dilemma of mine. In Clojure I can trivially build such dynamic applications that lift part of the problem from static hard-coded logic for each use-case all the way to first-class, reified dynamic constructs that can be created from config, DSLs or from API calls for self-service use.

But with constant attrition, only being able to mostly hire juniors, with the mid/senior hires lacking knowledge of Clojure, there's a risk in doing so with Clojure. If there's half the team familiar and knowledgeable in it it can sustain onboarding, but Pandemic has caused a 90% refresh, so we lost our pipeline for training people to Clojure.

Doing the same with statically typed languages is possible, Java + JSON will get you there for example, but it's a lot more tedious and roundabout, and simply less pleasant. On the other hand, people unfamiliar with a language and generally still with lots to learn about proper abstractions, code structure, meta-models, and dynamism will struggle to ramp-up and produce good code, a catch 22.