3 ms·

Thanks for sharing your thoughts. Since NUBank literally built a billion dollar business because of Clojure, I would have thought the adoption in fintech at le

Thanks for sharing your thoughts. Since NUBank literally built a billion dollar business because of Clojure, I would have thought the adoption in fintech at least would have been bigger. Maybe it's because CTOs are just not sure and feel safer for adopting a 'nobody got fired for choosing IBM' mindset. Maybe it's not important that Clojure needs to grow its ecosystem.

_bypa 6mo ago
And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. That's a cost added that may not always be justified, because anything related to Clojure and/or Datomic is going to require bespoke integrations. Not to mention that hiring is a problem because the Clojure market is relatively small. But that's not the reason the language never caught on. Perhaps only a reason companies rarely choose it.
- deleted 6mo ago
  [deleted]
- perrygeo 6mo ago
  As I tried to explain above, Clojure is made for a specific set of problems. Your problem seems to be interop with the SDK of the month and hiring. My problem is mutable state. It's logical that we'd choose different solutions.
  - _bypa 6mo ago
    A pure Clojure stack is extremely rare in most organizations. And integrating data from microservices with data lakes and observability platforms is not "SDKs of the month" but a normal business concern. What I am trying to say is that immutable state may be one aspect of something much larger that did not factor into Nubank's original decision to use Clojure for microservices. It may have clear benefits there (and in your case - I don't deny that), but downstream you pay for that rarity by having to build every integration yourself.
    - uxcolumbo 6mo ago
      Couldn’t LLMs help with writing those glue components? Read the doc for the SDK of the month and then write the Clojure interface for it? The same goes for existing micro services, no?
  - deleted 6mo ago
    [deleted]
- asa400 6mo ago
  > And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. But Java almost certainly is. Why not just use the Java stuff? All of the Clojure I've worked on (especially in the data space) has made use of a ton of Java SDKs and libraries.
deleted 6mo ago
[deleted]

_bypa 6mo ago

And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. That's a cost added that may not always be justified, because anything related to Clojure and/or Datomic is going to require bespoke integrations. Not to mention that hiring is a problem because the Clojure market is relatively small. But that's not the reason the language never caught on. Perhaps only a reason companies rarely choose it.

deleted 6mo ago
[deleted]
perrygeo 6mo ago
As I tried to explain above, Clojure is made for a specific set of problems. Your problem seems to be interop with the SDK of the month and hiring. My problem is mutable state. It's logical that we'd choose different solutions.
- _bypa 6mo ago
  A pure Clojure stack is extremely rare in most organizations. And integrating data from microservices with data lakes and observability platforms is not "SDKs of the month" but a normal business concern. What I am trying to say is that immutable state may be one aspect of something much larger that did not factor into Nubank's original decision to use Clojure for microservices. It may have clear benefits there (and in your case - I don't deny that), but downstream you pay for that rarity by having to build every integration yourself.
  - uxcolumbo 6mo ago
    Couldn’t LLMs help with writing those glue components? Read the doc for the SDK of the month and then write the Clojure interface for it? The same goes for existing micro services, no?
- deleted 6mo ago
  [deleted]
asa400 6mo ago
> And consequently the company needs to continue building its own adapters and SDKs to use existing commercial and open-source solutions (e.g. in data and observability), because Clojure and Datomic are almost never supported out of the box by any tools. But Java almost certainly is. Why not just use the Java stuff? All of the Clojure I've worked on (especially in the data space) has made use of a ton of Java SDKs and libraries.

deleted 6mo ago

[deleted]