This is a wonderful language I've only just started paying attention to, watching the talks from Rich on YouTube have ruined things I loved (like Either types.) I'm struggling with how to introduce it into my company without recommending my colleagues follow my path of working through 3 books and then watching most of the conj talks from the last 12 years on 1.75x speed, while building a personal project and re-implementing a couple of services I work with every day in it... but the lessons around simplicity I think are so critical, I'm going to find a way.
I've been at an organization that went from Java to Clojure about 12 years ago. I think there were two main things that allowed us to make the move:
* No one was in love with Java. It was fine but we were doing the whole spring style super verbose Java and it felt like a lot of ceremony to get anything done. There had been an experiment with Scala previously but that hadn't taken off.
* We had a service-oriented architecture which meant we could try Clojure out on a few new services and see how it felt.
We ended up going from 2 services to moving the whole org over really quickly. A lot of excitement built up and people didn't want to be left out. At the end of things only 2 people decided they didn't want to learn Clojure.
A few other things we did:
* Bought loads of books and left them lying around
* Started a Clojure club where we booked an hour a week and did some exercises in Clojure
* Had a big meeting where we convinced everyone that Clojure was worth an experiment
* Brought in 3 consultants to do some Clojure training for everyone
* Probably strong armed everyone into watching simple made easy - it helped that lots of people had already seen it live that year
There are a few talks about it floating around although they are very very old now and I'm not sure they're worth the time!
Find the least important project that one person can take on, and have that be the prototype for the clojure stack.
Ideally, use someone well versed in the tech stack - otherwise, you're taking on double risk of a new tech stack plus unfamiliarity. This prototype needs to demonstrate the value of the clojure stack - which has to have a business value (aka, speed/ease of maintenance etc).
Convince the decision makers to use clojure after the above prototype showed value, and use it to extrapolate value for other projects. This will then require a transition from doing the project, to teaching others (who might not know clojure at all). You cannot rely on just telling people to watch videos or read books - they won't do it, and it will cause failure in subsequent projects.
You will have to hand hold, until the newbie "clicks". Unfortuantely, this is an uphill battle, because management will always want to hire for the "regular/normal" tech stack, and will have trouble finding clojure-ready people. So the company will continue to have to invest in teaching it to new hires, which is a drain that could tank the clojure move.
It's funny because I went the opposite direction - from clojure to Rust, and I feel my programs are more maintainable, easier to re-read code written by myself and others, and runs without needing to bring along a virtual machine.
I do like Rich's talks and agree that static typing can be taken a bit too far though.
ClojureScript in particular is much nicer to work with compared to JavaScript
Honestly, maybe don’t. You love Clojure, that’s awesome. But introducing it at your company if it does not have a lisp culture already might not go so well. You say so yourself: lisp dialects like Clojure come with a steep learning curve, and not everyone will appreciate the shift, especially if they're comfortable with the current stack.
Forcing it on your team could create frustration, confusion, and a lot of resentment, not just toward the language, but possibly toward you. Sure, you might convert a person or two, but most will likely see it as unnecessary complexity.
If you really want to write Clojure every day, you might be better off finding a company that already embraces it instead of trying to turn your current team into Clojurists. Sometimes it’s better to enjoy something for yourself than to make it everyone else’s problem.
I'll second this. Many people are happily complacent with mainstream languages.
A minority ventures out in $lang of the day for the fun of it, with functional languages being an even smaller minority.
At a minimum, build some strong clojure skills first, such that when you introduce it to anyone else, you can do so with confidence
I spent a lot of time in my early career jumping from company to company looking for the next better thing, be it tech stack, job title, pay package. It worked quite well for me early on, until I interviewed for a principal engineer role at Branch and the VP said something that struck right to my core… that I had a good interview and good experience but my work history showed someone who wouldn’t be there in two years, and they were hiring for a long term role.
I’ve vowed since then to stick it out, to work hard building something better at the companies I work at, and to make it obvious from my resume and day to day that I care about being somewhere long term. I take the idea of leaving my campsite better than I found it seriously, and if Clojure was just a fun hobby for me I wouldn’t try to introduce it at work. I think my colleagues can learn a lot from the language and paradigms that are at the core of the language, my hope isn’t that we re-write our stack in Clojure, or even that the services I write in it persist past when I leave. My hope is that I can use it as an example to show the other engineers I work with a better way, even if we do it with go in most of the stack.
It’s not too hard to point to NuBank’s success and say we can be like that, my C-suite is already on board. Hopefully we’ll be +1 hiring for Clojure in the next year if I’m successful
Every company likes to hear about increased productivity and less bugs, and that's what Clojure/Script gives you. The trade-off is you get less resumes when hiring. The plot twist is the resumes are much higher quality.
I personally have sat in a meeting where a clojure enthusiast was explaining how he had quickly built a system.
He could not explain the code he had written only three weeks before.
Clojure suffers heavily from a “less code is good code, write clever code not verbose code” culture.
For newcomers this creates dumpster fires that are quick to create and impossible to maintain.
Anywaaay, long story short: no. It doesn’t.
Specifically, I’ve seen it be a dumpster fire three times.
Perhaps your experience has been different; but you are flat out wrong in your generalisation; and that arrogant attitude has been the root cause of all three failures I have personally had to clean up after.
People who complain about verbosity and boilerplate in Java generally fall in 1 of 2 categories: people who haven't used Java for anything non-trivial in a very long time, or people who are bad at designing abstractions.
Less code can be good code, but they largely are orthogonal axes. Without good abstractions, it doesn't matter whether code is dense or verbose, it will be bad and difficult to grok.
Having done substantial work in both Java and Clojure, my experience with abstraction in both is that in Java, making things more abstract almost always involves making the code larger (adding more interfaces, extending existing types to those interfaces, etc) whereas in Clojure making things more abstract typically means they get smaller.
Over time and at scale, this matters quite a lot. Java code grows and grows at a super linear rate as it handles new and changing requirements. This is ultimately not sustainable. Clojure code typically grows at a more linear rate (accretion of attributes in data or operations on data), but has more tools to create abstraction that can actually (if wielded well), be sub linear instead. This kind of change is not free or easy in any language, but in Clojure it is at least possible.
The way is to drop Clojure and adopt it's principles. Teach your colleagues the functional engineering principles.
You can write code that looks a lot like Clojure in any modern language now, a lot of the functional primitives have been adopted in mainstream. e.g. Async/await => channels.
I started my career as a Clojure/Clojurescript developer 12 years ago. And now I do python for ML research and Typescript for prototyping all day.
Clojure honestly help me back a lot of the time because the tooling is so far behind the large programming communities. Functional programming has a lot of good ideas, but none good enough to leave behind all the packages on pip/npm.
I would only ever advise niche programming languages for small sub-teams that are highly technical were it makes a lot of sense. Something like compiler teams, webgl/triton for GPU programming, etc...
Dont. It wont be appreciated because nobody but you can work on it, and one day you wont work there anymore and the company is stuck with a few projects in Clojure while the rest is on their regular tech stack. You are creating a major company risk just for your own personal benefit.
My goal isn’t personal happiness, it’s improving the code quality in our code base, without telling my colleagues “you’re doing it wrong” or other obnoxious things. I’ll let Rich do it.
I see nil panics a couple times a week, in prod. We could learn the methods and apply them in other languages, like other people said they did in this thread.
