1. 20

  2. [Comment removed by author]

    1. 5

      I’ve been working with Clojure for around a decade, and I find it’s far easier to step in and maintain Clojure projects than comparable scope projects written in languages like Java. There are a few tangible reasons for this.

      • There tends to be at least an order of magnitude less code.
      • The code that is there tends to be far more declarative, largely talking about the problem being solved as opposed to implementation details.
      • The language is small and people tend use a small number of common patterns.
      • Vast majority of code is pure meaning that you can reason about it in isolation, side effects generally live in a small layer at the edges. This gives the same benefit as using microservice architecture without additional orchestration headache of running multiple processes. Each namespace can be reasoned about as its own standalone program.
      • Interactive development with the REPL means I can run any code I don’t understand and see what it’s doing.
      1. 4

        I feel like lack of static typing would be a pain for a large project

        1. 3

          I haven’t found that to be a problem myself, but if you find static typing to be essential to your workflow then Clojure is probably not a language for you. The approach in Clojure is to use runtime contracts with libraries like Spec and Malli. I find this approach works better because it allows adding specifications where they’re meaningful, which tends to be around APIs, and contracts let you encode semantics of what the code is meant to be doing which can be trickier to do via the type system.

          It’s also worth noting that any large project can, and in my opinion should, be broken down into smaller projects. This is basically the whole premise behind microservices. Small projects are easier to reason about, they’re easier to maintain, and they can be reused and replaced as needed. I see no advantages to structuring software in monolithic fashion.

        2. [Comment removed by author]

          1. 7

            Speaking from 4.5 years of experience at a company with 250 engineers who write mostly Clojure, if you make training and investing in your people a priority it hasn’t been a problem for us. Experienced engineers who have been writing functional code in JS tend to catch on really quickly. Learning the quirks of our codebases is more of an issue than learning the language. Of course, if you don’t invest in training your people then it won’t work, but if you’re at a company that doesn’t invest in their people you have bigger problems to deal with than what language your code is in!

            1. 2

              I can obviously only go by my personal experience here, but having worked on many Clojure projects over the years I haven’t found this to be a problem. It’s also worth noting that many large companies use Clojure nowadays, and seem to be maintaining their projects just fine as well. Here’s an experience report from one company that’s been using Clojure long term. Other notable companies include CircleCI, Kira Systems, Atlassian, and even Walmart where tech isn’t even their core business.

        3. 1

          Far as runtime, author could test it again mature CL’s or Schemes. That might give an idea.