Our experience is that Clojure is a very good language for newcomers to programming as a profession.
In fact, we almost exclusively hire new computer science graduates. None of them had heard of Clojure before joining, and the vast majority of them became useful in 2 weeks, and become productive in a few months. What you described as barriers are the things that got sorted out in the first day when they join.
We do not hire veterans unless they already know Clojure. These people need to unlearn stuff, some of them are resistant to changes, so we don't bother with them.
We have backouts two days in a roll now at south bay. Both lasted over 6 hours, right at the honest hours of the day. My bedroom temperature reached 90 degree last night. This is maddening.
Rust and Clojure address completely different domains of problems.
Rust is competing with C++ for writing low level systems, whereas Clojure is designed for writing business applications.
Low level systems tend to have stable and well understood requirements, whereas the same cannot be said for business applications. Efficiency is not a primary concern of business applications, but flexibility is. The efficiency of Clojure is often "good enough" for business application, and there is no peer in flexibility. This explains the many fintech companies using Clojure, as well as many other B2B companies.
Clojure is intended as a hosted language and embracing the host is the philosophy, so interop with the host is never a bandage.
Again, I am curious where you get all these impressions that are contrary to most people in the community take for granted, such as:
* Clojurians prefer libraries over framework, but you said we spent too much effort in developing "big web framework".
* Clojure is intended to be a hosted language, so seamless interop with the host is the norm, but you thought interop is a bandage until Clojure matures.
I have a little trouble remembering all the details, and I'm not sure I can speak to where things are now. Maybe it's more helpful to mention where I thought we got off-the-rails with building our own stuff?
- unit tests with ephemeral dbs
- db migrations
- ORM library
Many of these things exist in Java and in retrospect, were probably the way to go. One other pain point was that Clojure libraries would stop being updated, lag too far behind the java libs, or lack features. I remember this being the case with Google Cloud and AWS, and I think Elastic Search. I remember a number of times just completely swapping out the Clojure wrapper lib for the java lib.
Most of these things do have Clojure libraries. For example:
- unit tests with ephemeral dbs: we use com.opentable.components/otj-pg-embedded for postgres.
- db migrations: there are Migratus and many others, we also just use flyway in app startup shell script
Some are not relevant if you write proper Clojure.
- ORM library: I am not sure you need these in Clojure. Clojure is data-oriented, not object-oriented, so you don't need to map data to objects. Clojure is good at transforming data. Just keep data as data.
I don't recall us spent too much effort in building Clojure libraries of our own for something missing.
For my over a decade of Clojure career, I only built two Clojure libraries of my own. Both were not missing, just that I didn't like the existing ones. One is a Clojure data diff library (Editscript), and another is a database (Datalevin).
In general, if one cannot find a Clojure library (very rare), we tend to use Java interop. As mentioned repeatedly, Clojure is a hosted language and we embrace the platform.
reply