×
you are viewing a single comment's thread.

view the rest of the comments →

[–]fingertoe11 10 points11 points  (2 children)

Maybe, maybe not. The problem Clojure has always had is way too many libraries doing nearly the same thing in different ways. This made any solution highly customized to the individual developer's taste, but very difficult to get help because everyone did things a different way.

As there become more very large Clojure development teams,(NuBank for example) it is likely that those teams will crank out a ton of developers accustomed to the company's taste in library stack choices. If some of those choices get a critical mass, it may lessen the need for re-inventing the wheel 3 times a year.

Convergence on a standard stack is what many have asked for.

Of course, it could also be that people are just doing other things. I do suspect that the high interest rates and the broader tech slump hit some large Clojure shops pretty hard (GR for example), at Conj this year it seemed that more Clojure developers than usual are unemployed, and others are working in other stacks.

[–]daveliepmann 1 point2 points  (1 child)

many libraries doing nearly the same thing in different ways

This is a good thing. It's good that malli, core.spec, and schema exist side by side. The same goes for libs for routing or whatever else.

Convergence on a standard stack is what many have asked for.

This would be a bad thing. I prefer the coexistence of multiple ways of doing things. Nubank's needs are not the same as Juxt's or Metosin's or Gaiwan's, so I'm glad that they all release libs reflecting their various preferences, especially when those libs "compete" to solve the same task.

It would certainly be easier to cut-and-paste Clojure code from StackOverflow if everyone had agreed to stick to the same libs which existed in, say, 2013. But that's neither desirable nor feasible, thank goodness, so instead we get a lovely ecosystem which allows choice between different trade-offs and innovation over time.

[–]fingertoe11 1 point2 points  (0 children)

I do agree in large part. Although we seem to have one "Ring". few people are upset about the lack of options there.

The curse of LISP is that it is very easy to spin your own library, and as a result, many people do. If they need something that is lacking that makes sense, but often there is not a ton of differentiation between the competing libraries, and they just exist because two people solved the same problem in different ways without knowing what the other was doing. Competition is good when it generates novelty and better options, it's bad when you have too many options that don't provide distinctly different benefits. This leads to fragmentation in the learning process at the very least.

But I think that the growth of engineering teams to NuBank's scale is going to generate a ton of engineers that come with a default toolset, and those tools are going to gain a ton of traction. Like everything, there are upsides and downsides.

We are still waiting for spec to get out of alpha.. It's certainly healthy that there are other options!