[Qerub]

I might be damaged from years of Java, but my main imagined issue with Clojure is the lack of a component system. Call it OCaml functors or OOP classes, but instantiating a component with replaceable components as input is what I personally need for large scale programming. To make things more concrete, let's say you are writing an integration to another system using HTTP. On the surface you'll have functions like `fetch-album-information` and they will internally use a HTTP client. How do you handle TLS configuration, HTTP connection pooling, etc. and make the function testable and lifecycle-managed to allow clean shutdown? The easy answer is to parameterise the function with another function that takes care of all of that. But that function will need to come from somewhere and I imagine threading these kind of functions explicitly through your entire program will make it less than palatable. The alternative of using globals that can be replaced in testing carry all the usual problems that global variables have but seems to be what many settle with judging from Clojure code on GitHub. It seems like others are feeling this pain and have invented band-aid solutions like https://github.com/stuartsierra/component but this is something I think needs a first-class solution to encourage this kind of programming.

[iLemming]

What do you mean "the lack of a component system"? There's Mount, Component, Integrant. The last thing any language needs is to "encourage" some kind of programming. And Clojure is just that - it has small, stable core. The rest can be done with libraries.

[hcarvalhoalves]

Why is a library a "band-aid", and why is it necessary to have such feature in the core language?

[yakshaving_jgt]

I think it’s an argument about ergonomics. Threading state throughout your control flow is bad. Implicits like in Scala are bad. Global variables are worse. Something like a Reader monad is less bad.