Clojure at a Bank – Clojure Code Immaturity

1. Bootstrapping. Some functions are defined somewhat verbosely because the higher order functions are defined later.

2. Performance. By definition, everyone uses core, so core is on everyone's critical path. Therefore, core must sacrifice idiomatic code and brevity for performance. You should make the same tradeoffs only after measuring.

3. Evolution. Clojure has gained features and, since stability is valued, core doesn't get revamped to utilize them without greater justification.

The thing I experienced is this - once you outgrow the primary use-cases for a monolithic framework, all of that nice packaging and conventions and modules that play well with each other - start getting in your way, soon to be replaced by custom implementations of whatever you need and all that time you saved initially will be extra time you have to spend to strip out those functionalities, in addition to the time take for building those same things from scratch.

I also worked with Rails btw - for instance you can find like a gazillion plugins for authentication and yet none of them did what I wanted on one project I had, so I had to implement my own authentication logic, after spending hours trying to tweak such a plugin first. That same project needed storage of files on S3, including pictures. Again, there are like a gazillion plugins for that, but none of them did what I wanted. So again, I had to implement it by myself. After trying endlessly to tweak Paperclip or others.

For this project I'm working on the admin interface was initially bootstrapped on top of Django's Admin. Which eventually became a liability and had to be replaced completely. The Django's ORM is also becoming a liability - because it couldn't handle queries for complex scenarios that were unrelated to "objects", so right now the project also makes use of SQLAlchemy - and I'll probably have to pull Django's ORM completely from the project, because the project is also doing sharding right now and I want to expand that to most tables and I can't work with a connection object that's a singleton, not to mention that the "objects" exposed will end up being completely different than the schema used in the DB table, so the object-mapping that Django's ORM does will stay in my way.

In the end, if I need to sum up the things that are still from Django in this project, there are surprisingly few things left.

So if you think about it, for small projects frameworks like Django/Rails are too heavy and for large projects they kind of get in the way and it's better off to start from scratch, importing components as needed, because that way you'll build abstractions that are suited for your domain and that will last longer.