Building a product with Clojure: Lessons Learned

Building a new product can be a lot of fun and you have to choose what technology stack will give you a good head start. Initially, the team chose Ruby on Rails to build a prototype which was great until our users started to grow significantly.

In this talk, I'll share our team's journey with Clojure, what worked for us and what didn't work so well.

We also tried to make Clojure more approachable, so I'll finish by sharing my thoughts on how Clojure could be advocated to appeal to the broader programming community.

Video: https://skillsmatter.com/skillscasts/12228-building-a-product-with-clojure-lessons-learned

Transcript

1. GROWING A PRODUCT WITH CLOJURE
 THE GOOD, THE NOT SO GOOD AND WHAT CAN WE DO BETTER? Łukasz Korecki http://lukasz.korecki.me
 https://nomnominsights.com
2. WHO IS THIS PERSON ANYWAY? ➤ I'm Łukasz Korecki ➤ Programming computers professionally for over 10 years ➤ My first real text editor was Emacs 21 running on Windows 2000 ➤ Co-founded NomNom in early 2015, launched in late 2016 ➤ Prior to that I worked mostly with Ruby on different SaaS products ➤ I like all things DevOps
 (whatever that means)
3. Not a food thing! "All your customer feedback and user research in one place" NOMNOM
4. IN THE BEGINNING ⏱
6. IN THE BEGINNING
10. -XMX200M
14. THE GOOD PARTS
15. THE GOOD PARTS ➤ JVM is really good! 
 ➤ Stability: some services just run for weeks if not months and require no baby sitting ➤ Ecosystem: there's a library for just about anything, and quality is usually higher than in some other ecosystems, just because of scale of use (Java!) ➤ VisualVM is pretty neat
16. THE GOOD PARTS ➤ Tooling: Leiningen is really solid, ability to create uberjars simplified day1 and day 2 stuff a lot (deployment especially) ➤ Libraries: single-purpose, the good ones are really good (Aleph, Ring, clj-http) ➤ Easy to read code: especially newer open source libs, older Clojure code has a bit of a macro-fever.
17. THE GOOD PARTS ➤ Simplicity: only 3 concepts to think about: data, functions, operations. In the whole codebase (~80k lines, according to cloc) we have 12 macros ➤ A lot of our pull request discussions are concentrated on practical discussion about solving the problem at hand, design and architecture, less about bike shedding ➤ Component was/is a game changer 
 (more on that later)
18. THE NOT SO GOOD PARTS
19. THE NOT SO GOOD PARTS ➤ JVM: some prior knowledge is required (logging, tuning, more esoteric features of Maven) ➤ There are times when some Java knowledge is required to decipher error messages ➤ Slow startup time
 Had to mention this
20. THE NOT SO GOOD PARTS ➤ Ecosystem: lack of consensus. Four different variants of Component, each with philosophical differences. Four Kafka clients (all unfinished). Four configuration libraries which use tag literals... ➤ Building Rails-inspired systems in Clojure is possible but it's definitely a bad idea ➤ Component saved us - it adds just enough structure, helps with REPL driven workflow, and is incredibly useful in production
21. WHAT CAN BE DONE BETTER?
22. MAKING THE WORLD A BETTER PLACE ➤ Focus on day two experience ➤ Less jargon and more success stories ➤ I feel like the whole language is not advertised in the right way ➤ REPL-powered workflow was not sold and explained in the right way for a very long time
 https://clojure.org/guides/repl/introduction is a must read!
23. MAKING THE WORLD A BETTER PLACE ➤ A lot of cool things are happening right now: clj tool, deps looking really cool, clojure.org improvements, clojureverse.org seems to be alive again ➤ We need to graduate from "look how cool this is" and move on to "this was the best tool for the job and here's why" ➤ More experience reports
24. THANK YOU!