Congratulations to Cognitect. Hopefully the acquisition will help Rich's retirement funding. (see 'History of Clojure' for the not-so-insider joke here)
I have had the pleasure of "using Clojure in anger" and for a few years was very dedicated to learning how to use it effectively. This was a significant step up for my general programming skills and the simplicity of the language often saved me from myself with respect to bad design or choices in code. Whatever programmer "maturity" I can claim is probably due to Clojure and teaching introductory programming and databases (not with Clojure and Datomic to be clear).
This acquisition is more abstractly interesting to me in that a VERY dedicated Clojure/Datomic company made it. We didn't see here, for lack of a better example, a FAANG company grabbing Cognitect. That may have been a choice! Maybe Cognitect went with an acquisition where they retain a high degree of autonomy with the benefits of being acquired.
I never made the leap into a larger organization with Clojure at its core. I was able to use Clojure only in my small shop where I have a small degree of autonomy on development language choice. For a few years, I was somewhat actively seeking an opportunity to join a larger Clojure-oriented team but struggled to gain much traction when applying to openings. It seems possible to build a Clojure career, but I've not been very good at that.
(for anyone who doesn't get it, Rich funded Clojure development via his retirement savings from 2005 until he ran out in 2009 https://dl.acm.org/doi/pdf/10.1145/3386321)
He did a community drive in 2009/2010 or so and a lot of us pitched in a little. Then he joined forces with Relevance to create Cognitect and that has funded his Clojure development since. Hopefully he gets a nice payday from this acquisition too.
Nubank has a very inspiring story, both for engineers that are fans of Clojure & Datomic and for entrepreneurs that want to do "crazy" things like entering the bank sector.
This must be very validating and exciting for both Cognitect and Nubank.
I'm excited of the future impact on Clojure and Datomic. I get the impression that _all_[0] involved parties deeply care about what made them great so far.
[0] I'm getting that vibe based on some talks I saw of Lucas Cavalcanti and Edward Wible, available on Youtube.
Yeah, I saw the Nubank folks present in person in NYC just prior to COVID. I am a Clojure fan, to be sure, and also a banking/money dweeb. Soup to nuts it was one of the most impressive presentations / achievements I have seen. They were clearly operating in the future. Congrats to both and looking forward to growing the community.
Plans to release a SAAS banking core in the US? Pretty please?
He makes mention of 2,300 Datomic databases. Can anyone shed some light on how a company maintains (or requires?)... 2,300 databases? What business needs lead to something like this? What kind of reporting pipeline possibly could pull so many dbs with cross concerns together under one roof?
Let’s say the company has four databases and 500 technical employees. That could get you to 2k personal development instances. Take your non-development instances and multiple for failover, blue-green deployments, multiple data centers. It doesn’t necessarily sound nice but it’s conceivable.
My entire business is built on Clojure and ClojureScript, and it would not have been possible without these languages. I am always slightly worried by this kind of news, because it means that the main Clojure team is now dependent on a single institution. But it could be good news as well, depending on how things go.
Until now, I've been getting nothing but excellence from the Clojure team: not just great tools, but also great thinking behind them. I appreciate what I've gotten (for free!) until now, and hope that the trend will continue :-)
Would love to hear what you learn from engaging on any expectations you have for roadmap. I wrote separately that I see a bright (very bright, complete game changer) future for the toolchain in finance, but finance is a special ecosystem where general purpose languages with goofy syntax become niche- sometimes very large niche, but still niche.
Niche is fine. I don't know why people are obsessed with languages becoming dominant, or enjoy calling languages "dead". I don't need everyone to use Clojure. In fact, I'd rather prefer that my competitors use something else, because it gives me an edge over them.
I don't have "expectations", I think "hopes" is a better word here. I hope to continue to profit from the core team's thinking and be able to use the tools they create and ideas they generate.
Platform war phenomenon (like Xbox vs Playstation) emerge from winner-take-most effects with a high upfront investment, so you want to make sure you pick a winner and then once invested you want to help them win. A good example of what happens when you lose is the Nintendo Wii U which had like 8 games made for it.
I mean, that may be true to a point in the long run/true outside of webdev.
But the dev who intimately knows Spring & Java/Kotlin is gonna be far ahead of you for the first 9 months, given that there's so much out of the box functionality. They'll be going through a nice paint by numbers scenario for most of the heavy lifting whilst you have to expound effort in creating what's done.
Understand the argument- it's language vs ecosystem- but Clojure leverages the JVM ecosystem in a first class manner. Spring is very productive, to be sure, but I still find that in terms of LOC, Clojure requires less for simple cases, and much less for hard cases, and Clojure practices- like REPL-driven development- themselves are more productive/faster iteration.
Your comment misses alot of nuances about Clojure. Most Clojure devs I know were already senior devs in one or more languages, and were very capable of dealing with any missing "out of the box" functionality.
Besides, by sitting on top of the JVM you have access to alot of mature libraries, and it's extremely easy to do a wrapper in clojure.
What the spring & other frameworks have as an advantage is a predefined set of opinionated choices about logging, error handling, validation and so on that would give you a couple of weeks advantage at top. What they don't have is an expressive language as clojure.
If what you're comfortable with is Spring or Drupal or Rails and those work for your use case then more power to you
At the same time it's true there are products like roam research that are fundamentally harder to achieve in a cookie cutter environment
This talk kind of eludes to why that is https://youtu.be/rI8tNMsozo0 but it's worth learning there's many mature pieces of tech in this community that are astounding
If you need boring.lib then reach into Java/JavaScript with the easiest interop I've ever used
Interesting view. What are the 'out of the box functionalities' which Clojure is lacking? Keep in mind Clojure provides Java interop and with clojurescript js interop. The clojure ecosystem has also pretty great libraries to work with.
For example take a look at fulcro or re-frame, also metosin works on some really great libraries and there is much more.
> What are the 'out of the box functionalities' which Clojure is lacking?
None, because for anything Clojure doesn't have, you just lean on the JVM (or JS for Clojurescript). Sure, the syntax isn't as pretty and there are some abstraction mismatches, but in my experience, you create thin wrappers to hide this and move on.
ClojureScript with shadow-cljs has really good error messages
Clojure's errors require getting used to because they can be verbose but the patterns emerge after some use, that said most beginner errors can be caught before runtime with clj-kondo
Usually you hear skepticism the other way around (that Clojure's productivity advantage over Java style languages in a project could diminish over time as static typing advantages can be more pronounced in the twilight years of the apps lifespan).
I suppose a question for you would be how has your business supported clojure(script)? It seems to me to be a case of a business that has benefited from clojure - and wants to be invested in its future - doing something about it. It cost something to provide what you built your business on :)
A while ago I started to set aside an R&D budget that goes towards developers writing open source, specifically Clojure and ClojureScript libraries, and tools like magit or CIDER. The amounts are still small (this is not an enterprise business), but I'm increasing them regularly.
I want to see a stable, long-term ecosystem with maintainers that are getting paid for their work.
I am about to (next two or three months) launch a company/product that is heavily built on Clojure(script) too and I was actually thinking about this exact thing just this week! There are a number of libraries that I rely on that I would love to give back to, both as a thanks for the work so far, and to fund future development. I'm not in a position to do so yet, but its something I very strongly hope to do in the not-too-distant future, if things go generally well.
I founded operatr.io. Our product, static site, and licensing systems are entirely built in CLJ/CLJS. JVM, brower, lambda, etc.
Like JWR I feel there's absolutely zero chance we could have built this product as effectively in my previous primary JVM languages. Clojure is just a better toolset, no comparison.
We recently enquired with Github about sponsoring as an organisation (rather than me using my personal account) and have been added to the waitlist for the alpha of organisation-sponsoring. Once that starts we'll contribute financially to the developers in our space who enable our business.
Also as a habit I send personal emails to open source contributors simply to thank them in person.
Good luck with your launch!
P.s. I'm very excited for the team at Cognitect. It's hard to start a consultancy, hard to launch a product, there are no guarantees of success, and they deserve all of it.
You could sign up at https://www.clojuriststogether.org/ They do a pretty good job sponsoring both new-ish and critical projects within the clojure ecosystem
Yes, I do plan to! Thanks for reminding me. I do want to look into contributing to a few specific projects that I rely on too, though. Or at least look into hiring the authors for a contracting gig (at least one author of well known libraries does this). I’m not yet financially in a position to do this, but I’m hopeful.
I think even small contributions make a lot of sense, especially if you gradually increase them over time. This is not to gain fame, it's to contribute and support sustainable development. My contributions are spread thin and the amounts sometimes look silly ($5 or $10 per month for a developer), but I believe they do make a difference and I intend to slowly increase them all as finances allow.
I'd suggest looking at Clojurists Together, Github Sponsors and direct sponsorships through PayPal subscriptions.
I look at it as an R&D expenditure (and it goes into my financials as such).
From my standpoint as a one man show, it's invaluable to be able to write the web client and backend in the same language, to share code between them... and have that one language NOT be JS. Clojurescript with Rum/Citrus or Reagent/Reframe deliver on the promise of React/Redux with much less fuss and overhead.
Editing JSX is a pain in comparison to the Hiccup syntax used more often in CLJS, e.g. [:div {:class shiny} "some stuff" [:button "OK"]] - with the structural editing in any good Clojure editor you can cut, paste, entire blocks of tags, or slurp a tag from outside your div into it, or spit one out, all with a few keystrokes, never stopping to find some closing </div> tag.. I guess some JSX IDEs might do this, but it's really nice that the HTML is represented as just another piece of data, not some weird chimerical syntax bolt on.
With Figwheel or ShadowCLJS hot reloading is instantaneous and doesn't even interrupt your webapp. If they're written properly, functions and the app state are not conflated at all, so you can modify any function in your app's rendering or behavior and as long as they aren't incompatible with the runtime state, it will just pop right into your browser. Illustrated well in this video where the author is interactively re-implementing Flappy Bird: https://youtu.be/KZjFVdU8VLI?t=277
I feel particularly strongly about this having started out doing front end work primarily in cljs but recently being falling into using React/Redux for a contract and being REALLY strung out by the tedium of working with them.
My opinion is that clojure has a confluence of just right abstractions and language choices that allows you to be very very succint while still very readable which in turn makes the language very expressive. I can name a few features: immutability, multimethods, protocols, transducers, lazy sequences, macros, and a very small and sturdy core. All of these features exist in some other language, but the combination of them together is what makes clojure great IMHO.
Besides, experienced clojure devs just see things differently and end up writing lots of nice libs that capture the essence of the feature the lib is providing. Think datomic (immutable database), reagent (interface to react), honeysql (data-as-sql), "dependency injection" (mount/component & others), pull/query-based UIs (om.next and its spiritual successor, fulcro) and so on.
Most things in Clojure can be found in other languages. However, Clojure has an especially stable and coherent design story, and is quite a bit better thought out than the other languages I've programmed in professionally. The pieces just work together really well, and there isn't a lot of "extra stuff" that only a die-hard specialist would know, or need to. (I currently work at a financial institution, not Nubank, that uses Clojure heavily.)
A few other high points:
- macro-based metaprogramming, familiar to any Lisp-er; macros are essentially functions which write code for you, which allow one to create extremely concise constructs to reduce repetition in code;
- functional programming: probably the hardest thing to get one's head around if coming from a more mainstream language, FP reduces mutable state to a minimum, eliminating one of the biggest source of programming defects and making programs significantly easier to reason about. Additional concurrency-safe state primitives in Clojure makes concurrency a trivial addition to many programs;
- hosted on the JVM, giving interoperability with Java libraries and significant ease of deployment compared to other dynamic languages (I recently went back to Python to roll out a small web service and was amazed at how much more painful the deployment/devops story was compared to our Clojure services).
These are some of the benefits we leverage; other people here more qualified than me have enumerated others. (Plus Datomic, whose philosophy aligns fully with Clojure, though I have yet to use it in production.)
On a personal note, one final attribute I appreciate is structural editing: as a Lisp, Clojure code is data, a feature which one's editor can make use of to allow operations that would be alien to non-Lispers, such as: absorbing nearby expressions or expelling them; splitting them; sorting and reordering; and writing your own automated refactorings without having to write parsers for the language in question. Treating code as data structures rather than strings of characters allows for speed in writing and refactoring code that is hard to give up once you get used to it.
Lisp + immutability is the right foundation for symbolic/logic programming, datalog, declarative programming, graph programming. None of this is really feasible in other langs due to bad ergonomics and no coordinated ecosystem buyin. Haskell lacks platform portability and Scala 2 is just too complicated to think clearly about anything high level.
I hope at least some of those languages get enough adoption to become viable production choices. I feel, apart from Elixir, Gleam has the most “popularity potential” right now.
In video compression, the advantage of a new standard over an old one is never a single "critical feature". It's a combination of small gains, single percentage points that accumulate to make a huge difference. If you look at H.264 vs MPEG-2, there is no single defining "critical feature", and yet you can get roughly twice as much video into the same bandwidth.
It's similar with Clojure. Are transducers "critical" or revolutionary? Not at all. And yet they facilitate building composable and reusable pipelines, which helps me with modeling a complex problem domain. Is core.async "critical"? Hardly. And yet it allows me to build reliable asynchronous data flows.
Clojure is a practical language, designed by someone with decades of experience in building complex systems.
I used to enjoy programming in Common Lisp, then saw a talk by Rich Hickey which intrigued me. I gave Clojure a try (this was about 8 years ago I think) and (much to my surprise) it turned out it works really well. It also turned out that a coherent concurrency story is important, and that programming with mutable data is not a very good idea after all, so I abandoned CL completely.
Over the years, I got many fantastic gifts: ClojureScript, transducers, core.async, spec — and more. I'm very happy with the choice. I also think my business would not have been possible without Clojure and ClojureScript: the leverage I have because of them lets me run a single-founder self-funded business.
That’d have been 11 years ago. I know because my earliest Clojure project on GitHub hearkens back to July 2009, and I jumped onto the bandwagon after hearing enthusiastic opinions of yours.
Not sure whether I ever had the opportunity to properly thank you, but let me say so now. Thank you, jwr.
It's very simple: it's a solo-founder business. I would not have been able to tackle the complexity of modeling the problem domain, writing server-side code, writing client-side code, and maintaining the whole thing. I would have needed a team, and this SaaS has a growth curve (line, to be precise), which isn't fast enough to get to a team quickly.
This particular business really would not be possible without the reduction in incidental complexity that Clojure+ClojureScript brought.
It is nature of the problem space which requires you to produce high quality code. If you have a small error in your program, the financial market participants will use it against you to profit. What you loose, others win! Google "fat finger" for examples.
In banking you have to keep track of every transactions, see "double accounting". You never delete a transaction, you only retract! Mutablity can cause you a lot of trouble there. SQL DELETE and UPDATE are extremly dangerous! Clojure and datomic solves this through immutibilty.
Lastly time is relativistic, meaning that every IT system has a slightly different time. Normaly you never notice this. But they are the cause of tricky race conditions and cost you real money. Think about bank transactions, where you have a transaction date (date you send money) and valuta date (date your friend receives money). One transaction 2 different dates, depending which perspective you take (perspective is relativistic, Einstein is right even in IT!). Datomic linerialies transactions thus this problem does not occure on database level.
I love immutability and Datomic as much as the next Clojure programmer. But this sounds quite a lot like post-hoc reasoning.
For example, there's quite a few situations where you require mutability in bank data (e.g. with government requirements, or when you want to rollback fraudulent trading). Sure, both are solvable with Datomic, but they don't scream "huge advantage with an immutable datastore".
And there are plenty of highly competitive industries where code quality matters, but they're not flocking to functional programming.
Don't get me wrong, I think functional programming is an absolutely great way to structure and think about programming (and have coded professionally in Clojure for the last 5 years or so). But I suspect the prevalence of FP in some industries is as much chance/social reasons than it is for some inherit superiority in the approach.
small note: Banks do not want to forget fraud, the rollback would be akin to a git revert. Even if the history presented to the customer makes the fraud vanish it won't be forgotten by the bank.
With government requirements I'm assuming you mean something like gdpr. Datomic supports actually removing data via excision. it's just not the default behaviour. I personally prefer a system that doesn't forget by default whilst preserving the option to do so.
you can also support destruction of personal data via other means such as key shredding.
Not really a Clojure user, but I made a small API with it once and it blew my mind, especially the design patterns involved. An interesting one is the ports-and-adapters (a.k.a. hexagonal architecture) [1][2] . Basically, all the business logic will be kept at a layer, and all of the functions there should be pure (i.e. they will always return the same information according to your input, and these functions won't cause side effects [3]). Then you would have layers where you can plug databases and REST handling.
And Nubank take testing really seriously. REPL and pure functions makes it very easy to use TDD.
It takes the will and discipline to use it, but what Clojure Spec (and other schemata libs) offer is, in a lot of ways, more powerful and flexible than traditional type systems.
A spec can be thought of more as a contract with the data, one with enough detail that it can be used to auto-generate conformant example data even.
If, for instance, you have a function, that needs to work on either, integers, or numeric strings, and textual fractions like '1/5'. Enforcing this constraint on input, and getting informative exceptions on bad data is easy with a spec, and the function code does not need to contain all of the noise to validate or coerce data.
Sure, you don't see the problem at compile time, but if you can auto-generate test data, the tests that you should already have become easier to write.
this is perhaps controversial but i actually think datomic is so powerful, it's worth using clojure for. in other words, the database is driving the choice of programming language.
the idea of viewing a database as an immutable state of the world at a given instant t0, and time becoming a parameter on that state of the world (in order to show changes as time goes forwards [or backwards!]), is extremely, extremely attractive for things like finance, whose first class citizens are among others:
- capability for audits e.g. show me the history of transactions from any particular account. since datomic is basically a collection of immutable facts over time, this is "free"
- distributed computing - datomic runs nicely across your own internal compute (often needed for financial stuff)
- transactions are no longer strings, but are actual data structures - this makes the gnarly steps of things like transferring assets across instruments a lot easier (i'd imagine). think about how you'd implement a shopping cart with transactions in postgres vs. how you'd do it with access to raw data structures
Moreover, transactions are reified and can have arbitrary metadata, so you can query the transaction log itself (for example, "show me all transactions issued by person X").
I do not think so. The regulation is constantly changing and the meaning of names change frequently. Thus a "Verified Account" can mean different things over the years. The problem with types and object orientation is, that the names used in the domain diverge from the name used in source code (class name, types). Think about a class diagram with class names relating to each other. To represent the domain language better, you need to change a lot in a class diagram. Dynamic languages reduce the problem, as a lot less names are needed. Clojure spec is used for specification of data instead of types, but there is also clojure typed (which uses javas type system).
Standard Chartered, Mercury, Tsuru Capital (Haskell), Jane Street (OCaml) don't seem to have a problem with using a statically typed language in the financial space.
Especially in that industry where your domain is changing all the time, where regulations are changing all the time, where the ability to reason about your domain at different points in time is essential.
Having more flexible types like maps is one of the building blocks to avoid complexity (there are more, more important ones)
It sounds counter-intuitive, but it certainly is working out for companies embracing clojure.
I wouldn't think that strong types are an advantage. They may be in classic software with long compile times and complex builds. However, the current landscape for financial institution doesn't require that. Immutability and functional paradigms seem to be much more in line with the needs of the business.
There's a ton of problems with empirical studies about software in general. Very hard to conduct reliable experiments. In particular, I think analyzing public GitHub projects is pretty much the worst corpus possible.
For example, almost all of the projects in this study are infrastructure projects (I'm not familiar with all of them so I can't say that it's definitely all). I'm much more interested in application projects, and even if you (general you) aren't, you have to admit that an infrastructure project has a totally different set of characteristics than your average business application.
I think anything we can do to get more empirical data related to software the better, as we have devolved into strong personalities and conviction making pretty much all of the major decisions in our industry, which is really deeply sad. But we have to do better than just mining open source Github projects.
Yeah, I wasn't necessarily trying to get into an argument with the person who responded, but there's so many factors not being accounted for in that study that it might as well be measuring nothing at all.
Choosing Github projects and measuring defects on them has almost nothing to do with the quality of closed-source code (as we were discussing, functional programming languages in the wild). I also briefly started down the path of mapping that study's measurements to overall language popularity (as I think they're related - more C++ code available = more bugs), but gave up as I remembered that A.) Nobody's opinion changes as a result of a reasonable argument on the internet, and B.) Convincing this person nets me nothing at all.
You get higher quality code by hiring people capable of producing higher quality code. A great way to find people that are capable of producing higher quality code is by hiring for languages with extremely small talent pools - nobody got there because it was easy or the odds of getting hired were good. Functional programming might seem popular on HN, but in the wild is really not popular at all. Clojure developers probably care a great deal more about the quality of their work than, say, some random J2EE developer, as the Java dev might not care at all about anything other than staying employed.
I guess my argument summarizes down to "Functional programmers care more about their work", which, to my original point, has nothing at all to do with the languages they're using (as the person I responded to was saying). To assert that "Functional programming languages produce higher quality code" is like saying "This brand of hammer hammers better." It's just nonsense.
That's oversimplification. Good programmers care about their work, doesn't matter which language.
Also, use the right tool for the job.
A language that forces you to think about values rather than mutable objects, will produce higher quality code as the number of ways you can shoot yourself in the foot are drastically reduced.
Clojure will make you run your code constantly in the REPL. Paired with a dead-simple testing library, the desire to keep your majority of functions pure, it is not hard to see why Clojure code has higher quality.
> Good programmers care about their work, doesn't matter which language.
Yes, but the whole purpose of my post is to point out the difficulty in _finding_ the good programmers.
> Also, use the right tool for the job.
Not sure how this applies. You can build banking software in literally any programming language.
> A language that forces you to think about values rather than mutable objects, will produce higher quality code as the number of ways you can shoot yourself in the foot are drastically reduced.
Again, this is just totally unsubstantiated. You're using "higher quality code" to mean "code I like more".
> Clojure will make you run your code constantly in the REPL. Paired with a dead-simple testing library, the desire to keep your majority of functions pure, it is not hard to see why Clojure code has higher quality.
Where have we demonstrated that clojure has implicit higher quality? Also, where have we demonstrated that all clojure devs keep their functions pure? Or test them? And how does clojure enforce that?
Your last bit kinda proves my whole point, I think. You like a language a lot, and you make good use of its tools. But again, when you're looking at large groups of programmers, they're going to drastically lower the bar on what you "should" do - talking about "strong desire" and "dead simple" is totally unrelated to whether people will _actually do_ something in the wild. And what's the best way to keep a codebase good? Well first, tooling, but second, not letting bad devs get ahold of it.
Mainly because of the problem space. Banking/finance is a complex field with many moving parts: card processing, validation, encryption, currency exchange and tons of certification stuff (I believe Nubank's primary focus is card processing). Didn't even touch other financial fields like investing, credit handling, or any kind of trading.
The software is always expected to be correct, never fail and fast. Otherwise, someone will lose the money, and usually, you (bank or institution) will have to recoup that, plus penalties, plus name damage.
I think the answer to both of your questions is yes. I think the related concepts of immutability and pure functions without mutable state allow for cleaner analytical modeling (and in some cases in strong functional languages, mathematical proof) of what that the code is actually going to do in production. That kind of predictability is essential for dealing with financial computations.
Immutability is a very powerful idea when record keeping and dealing with transactions. I know of at least one major bank whose ledgers are written Haskell.
Sounds like a broken hiring process right there. Anything you care to share about why that didn't work out? I can't imagine a company having an opportunity to hire you and choosing not to.
I don't mind sharing about that. Standard Charter has the reputation for being a great Haskell shop and I have been trying for years to up my Haskell skills.
I simply didn't have enough background in Haskell. The interview was fun. The interviewer did his PhD in Haskell and compiler theory.
Around the same time, I applied to Facebook's Haskell group, and I got to interview with Simon Marlow, which was great. He also said that I didn't have enough Haskell experience and suggested that I do more Haskell consulting work, and re-apply in a year.
Anyway, I love coding in Haskell but my skills need improvement.
It's Walmart and not a financial institution but this is a great talk about immutability applied to the backend services using F#: https://youtu.be/FskIb9SariI
Coincidentally, Walmart also maintains a lot of clojure libraries now, including the go-to graphql implementation in clojure: https://github.com/walmartlabs/lacinia
Never discount networking effects. I think it's good for the problem, but better languages are better for all problems, so that doesn't explain it enough.
Considering that finance is decently geographically distributed, I'd say it's more SV has become javascript hell than finance is especially FP oriented.
Functional languages and databases seem to be a natural fit.
Given you have a basic grasp of bookkeeping, accounting and financial statements: Would you rather program these things in a functional or imperative language? Would you rather store the transactions in a accreting, value oriented database or one that has no inherent notion of these concepts?
Or more generally, if your application has a temporal reporting feature, then you need to be able to ask questions like: "What were these values at date X and what are they going to be at Y?" etc.
I think the best argument is that there are a lot of small financial institutions (small referring mainly to the tech groups at them, that is, so you might hear that some big bank uses eg Haskell but really it’s just some group within their IB arm. I’m sure google has some Haskell around too), and often the kind of people they employ tend to like weird languages.
Plenty of financial institutions use lots of c++ or java and plenty use cobol too.
Pretty strange how no one else sees that banks are very very fragile institutions, plus this one is heavily VC-ed, which makes everything they claim in public irrelevant (this is if we want to trust what any bank says at all).
What is relevant is that Cognitect will now have 100% of income coming from the single (and fragile) source, they now do not have to compete and survive on their own, they can't say "no" when having a choice between having to conform or quit the only money source.
I am not discussing personalities here - people are free to choose how to sell their products or themselves. Just thinking what this means to me as a software consultant who makes 100% of money from Clojure (yes, a fragile single choice because of sort of falling in love)
How is a bank a fragile institution? Banks are the most heavily insured and protected institutions in any modern country.
In the US for example, banks not only contribute to federal insurance but also have built joint private reserves to weather economic turmoil. In the modern world banks rarely go bankrupt because if they did that would tank any confidence in the economy and create incredible chaos.
Even in failed states like Venezuela banks are still a major pillar of economy confidence.
Well I’m talking about present time. Past your cynical take, the reality is that the last crisis was exactly the reason why banks in the US have been growing their cash on hand the last decade faster than they did the two decades before that, while putting aside money on other reserves.
This is simply false - banks are not insured against failure and not protected unless some political move "too big to fail" is made, and this only makes systemic financial system failures worse.
I'm not. I was trying to point to the OP that banks aren't as fragile as he think they are. When the very nature of your business, which is handling people's money, is federally insured, you have mitigated a lot of risk.
Yes banks can fail and they can go bankrupt, and if that happens to Nubank then this acquisition goes to hell which makes the Clojure ecosystem weaker. I give that to OP.
But saying that banks are "very very" fragile institutions I think is fundamentally wrong.
The fact that deposits are insured has nothing to do with bank solvency. People just get some of the money back when the bank blows up. Arguably this makes banks to be even more reckless and to hide more dangerous risks under the deposit insurance claims.
And the function of the regulator is to stop and DISSOLVE the bank BEFORE it goes potentially too deep into the pocket of deposit insurance fund in case of running astray.
So this is a social instrument but again does not solve the institutional risk problem. Maybe, just maybe makes some banks more paranoid, but they still blow up at very high pace.
Whether this is false depends on particular country laws. For example in the EU you can't call yourself a "bank" without being subject to regulation, and in Poland for example, if you are a "bank", your money is actually protected against failure, up to €100,000.
That billion is not a charity, but comes with some people pursuing some things. Most of the time that "things" are to make a PR stunt, inflate and sell.
With respect, I see where you are coming from, but would argue it isn't necessarily the right read, either in terms of banks, or in terms of Clojure, though there is nuance.
Banks are systemic actors in the financial system. They have privileges granted only to them, requirements that only they have to meet. It is HARD to build and operate a bank, whether in the US or in another country.
From a "fragility" perspective- there are a lot of definitions of fragility, but when looking at attributes like- may fail at any time; may lose customer assets; may take on inappropriate risks given their systemic position; have negative systemic impact on larger financial system operations- whatever attributes you think of, the amount of energy that goes into oversight around those attributes is significantly larger for banks than any other "systemic" industry (real estate, health, whatever).
The number of health oversight agencies in the US is, like, 5. The number of financial oversight agencies is in the dozens, just at the federal level. (This is why in the US you sue for medical malpractice but not financial malpractice, and why there is government backed financial insurance of various kinds and much less health insurance. You are on your own in the health industry. In finance there are armies around).
Banks have like 10 different kinds of risk that they and their supervision are monitoring for. Yes, banks fail, but that's because people suck and are bad at things and the second law of thermodynamics and so forth. It isn't necessarily the same in other countries but banking, like many other industries, is increasingly global, and banking core systems are increasingly international.
Nubank is clearly doing a LOT of things right- I saw a presentation in person from them in February and it blew my mind the level of capability and abstraction they were working at. They are a solid entity with a strong growth path.
Cognitect, in contrast, is a tiny consulting firm. Maybe 50 employees? Technical consulting at scale is an incredibly hard business, particularly when your solution domain is limited to a particular toolchain. There was really no chance Cognitect was ever going to become Thoughtworks, or Deloitte, or anyone like that. That's an infinitely more fragile financial situation for Clojure than living under the roof of a business with a valuation in the billions.
The way to think about this is that all technologies have a sponsor. Clojure moves from basically being sponsored by a guy in his backyard to, like PHP (Etsy has a market cap of around $10B and employs the PHP leader). That's huge.
Beyond that, having what should become a more well known and reputable player in the financial industry backing it- you could well see A LOT MORE adoption from enterprises playing copycat. It's not going to happen right away, but it is a seminal step in COMPLETELY changing the enterprise adoption calculation.
However, everything is a tradeoff. If you aren't working with Datomic, or in finance- this move is a stronger statement that maybe Clojure doesn't have the strongest future for you. It isn't going to become a lot of other things that it could become. The finance industry has a fondness for languages with weird syntax, and those languages often stay in the finance industry niche. That's probably where Clojure stays. There are all sorts of wicked cool JVM things like LMAX and Azul that are also financial industry specific, and Clojure and Datomic get to become one of those. Very successful, very cool, but niche.
Anyway- hope that's helpful, happy to continue the conversation.
“If you aren't working with Datomic, or in finance- this move is a stronger statement that maybe Clojure doesn't have the strongest future for you.”
I don’t follow. The company the python BDFL last worked for was a storage outfit with a valuation roughly equal to Nubank. The Rails BDFL is at a pretty small software shop in Chicago. Ruby BDFL was at a division of Salesforce last I checked.
Seems a bit reductive to say that Clojure creator being employed by a bank makes Clojure a worse choice outside finance.
a. ruby and especially python (and PHP for that matter) are top 15 languages with very wide adoption, following, name recognition, use cases. Great documentation, lots of books, conferences, blogs. Robust business and consulting ecosystem. etc. Lots of onramps and growth curves for individuals. And communities still growing steadily. Clojure is substantially younger (10 years vs 30 for py, 25 for php and ruby) but it is comparatively tiny and niche and arguably its rate of growth is lower
b. syntax is part of the story here. Clojure is a better language than kotlin, but kotlin is seeing explosive general purpose use case growth that Clojure can only dream about. Clojure syntax is niche.
c. there are a very large number of technologies, including languages, that have wide usage within finance and banking and zero use outside. No matter how neat k is, there is no market for tutorials, no community growth (well, maybe modulo data sci world). No one is ever going to use jbase rather than postgres. Many of these also have niche syntax.
d. I think the Nubank news on balance is terrific, but I don't think it helps Clojure's community growth story at all, which is a chicken/egg problem in the context of general purpose use outside of finance. Nubank committing to that outcome...seems doubtful to me, compared to Nubank wanting to have more control over what it considers to be its strategic differentiator.
This last could well be wrong, and what we'll get from Nubank-owned Cognitect is developer experience, onboarding, a completed Spec, a comprehensible REPL-based developer onboarding, error messages, documentation- all the UX things where Clojure's superior design ergonomics are undone by nits in the experience.
My understanding is that Nubank is concerned about these things for its internal people, that their hiring rate has forced them to solve for onboarding. We will see. The Clojure team itself likes the sharp tools for experts model. There would need to be a funded change in that emphasis for the acceptability of Clojure solutions in areas where it wasn't already known to grow.
An excellent assessment - Rich, Stu and team clearly must have assessed the option similarly. Congratulations to Cognitect and here's wishing them well.
I have no issues with financial things per se - I have built several financial systems (from crypto to funds management) with Datomic and Clojure myself.
And this is also one of the reasons I think having sole bank as your owner is a really really bad thing.
Say more? Would be helpful for others to further articulate your observations and opinions. No one has all the answers. For all who have a stake a full diversity of views is best.
I'll be really short: the bank lends money in Brazilian real to credit card holders and, in addition, keeps half of that in financial derivatives. The last real slide (3x in value) was in 2011-2016.
Current world situation is.. interesting, to say at least, and 1 billion of VC money are not charity.
Are their financial reports available and published in English? Would be interesting to read.
I don't know details of their financial model, but will say:
* there is a long bootstrap process for a bank that involves being selective with what customers they can serve with what products at what margins in what order
* debt is a hard game, though in many niches now is the best of times
* currency is also a hard game
* in general, banks are valued at a small multiple of assets and do not attract VC
* in general, SAAS businesses are valued at a large multiple of revenue and do attract VC
So my assumption would be that they are using equity to build the ability to get into the banking core business as a SAAS, which is both lucrative and exploding as an opportunity (see recent nCino news). If they succeed, that's an extremely durable business, and not a bad place for Clojure to be. There are a number of languages that still only "exist" because they form the basis of a banking core.
Good for them, well deserved success for the principles, Clojure, and Datomic!
I donated to the Clojure dev fund early on, and I had two consulting customers over a few year period who mandated Clojure. I stopped using Clojure when the paid work stopped because I really like Common Lisp better for my use cases. I have on my radar for sometime this year to update my cooking website [1] that is written in Clojure, so I will at least get a small opportunity to kick the tires on modern day Clojure.
Clojure has many free IDEs. Many people currently use Emacs w/CIDER, Atom w/Chlorine, Visual Studio w/Calva, Vim w/Fireplace, etc. For that matter, Cursive also has a free non-commercial edition.
I've found CIDER superior to Cursive for Clojurescript, specifically. I use a combination of IntelliJ (with the emacs keybindings) and emacs depending on which language I'm working with. Most of my projects involve two or more languages, so I'll usually have both editors open all day :)
As an aside, I'm starting to become a fan of Kotlin for backends (with some Clojure sprinkled in where it offers a big advantage), and Clojurescript (re-frame) for the frontend (because it offers a big win over javascript there). I've taken a step back from full Clojure for everything, being that I have to work with others who aren't as in to "alternative" languages as I am.
Datomic is something I probably won't mess with until (and if) it becomes open source.
Are there any screen casts out there showcasing the utility of CIDER? I guess I have just never been a big emacs guy so it felt sort of clumsy to me but I am probably just missing something. Could also be that I am just too familiar with the Cursive workflow.
Yea, spring boot. When 90% of what you're doing on the backend is gluing a bunch of different Java technologies together, Clojure becomes hard to justify. Fortunately, mixing JVM languages together on the same project isn't a big deal so you can bring in some targeted Clojure where needed.
Kotlin is great because it's the closest thing to a general-purpose Java replacement I've seen. The interop support between Kotlin and Java is outstanding.
It sounds like Nubank might have the biggest Datomic installation in the world (2000 servers). This is exciting news for people like me who think Datomic is the most interesting database out there. Putting more resources behind Datomic might finally allow it to go mainstream.
I was unable to bring Datomic in-house. Mainly because our organization has a huge agreement with Oracle and all our database servers are essentially "free" to teams.
So I cheated. I created some schema designs that were immutable. I added a GUID, timestamp, and a deleted flag (value of 'Y' or 'N') to tables. Basically, all selects are against views that are defined over the tables to select the tuple associated with the max(timestamp) for that tuple along with the tuple having a deleted flag value of 'N'. This means that any select only sees the most recent tuple value for a GUID if it hasn't been "deleted".
There was a little bit more hiding in there to handle dirty writes.
But this worked very well for my requirements. By really only doing inserts, I was able to do similar "point in time" looks at the db as an immutable value.
Would you be willing to have an email chat about that? I'm thinking about doing a similar strategy with our relational database and wanted to get your experiences with that.
The bull case here is if Nubank goes full Amazon and uses banking as a beachhead to create the next layer up from AWS, which Clojure/Datomic is amazingly perfect for – data all the things
Ha! I was going to reply to this comment - "If you're interested in data-all-the-things, then you should take a look at Hyperfiddle" - until I recognized the user handle and realized that you already knew about Hyperfiddle.
(for those reading along, dustingetz built Hyperfiddle)
still building! we killed the saas thing for now and are releasing a web framework soon - declarative crud apps from nothing but function defs, specs, and datomic! All IO is managed and composes like Datomic Peer fns compose. Userland has no async, error handling etc. Complex pickers with typeahead search, query params etc are declared in one LOC
Nubank is one of the biggest startups in Brazil and I am a Nubank customer and I must say they have the best service available. Treating customers as customers.
The customer support is the best! No waiting, no pre-recorded messages, no muzak, no menu. A real person picks the phone and talks to you. Oh and the app is a delight!
> Nubank has grown to 600 Clojure developers, running 2.5 million lines of Clojure code in 500 microservices
Wow, that's enormous especially for a concise language like Clojure. Very happy about this announcement as a Clojure user. Sounds like it's going to be viable for at least another decade.
Are there any technical posts from Nubank on how they manage such a large Clojure codebase (I guess it must be Clojure's largest user in the industry).
I'm looking for things like how to refactor safely in the absence of static typing, for example. Do they make use of spec?
I'm a big fan of static typing, but when using a dynamic language with immutable values and pattern matching, like Erlang, I don't miss it that much. Maybe with Clojure is the same?
Not sure we have any talks about that specifically, but what I can say is that on the Clojure codebases:
- We rely heavily on testing (unit tests, property-based/generative and integration)
- We adopt a micro-services architecture, so most codebases are small enough that refactoring is easy, or sometimes we just replace the service altogether
- We have static checking of data schemas across boundaries (e.g. checking data producers did not break consumers over HTTP or Kafka), which is where we found the most value (replaced complicated end-to-end tests)
I believe micro-services change the trade-offs, and it's a matter of what you value more.
We certainly have to invest more on infra-structure, monitoring, standardisation, and we have been doing since day one - by now it's pretty robust, to the point our internal tooling allowed us to migrate from raw EC2 to kubernetes (https://www.cncf.io/case-study/nubank/) and it was a transparent change to all services and teams.
On the other hand, failures are more localised and we gain robustness and speed to do certain kind of changes.
Your point about getting domain boundaries wrong is true, but IMO it's a pain orthogonal to micro-services. The solution is the same as if you defined a sub-optimal class interface on a big mono-repo: relentless refactoring. We are often strangling (https://martinfowler.com/bliki/StranglerFigApplication.html) and replacing legacy services.
Questions: transactions are really important in banking systems. If you have 100s of Microservices how do you manage transactions across them? Or maybe all of your microservices run on top of a monolith database with transaction safety?
It's probably a misconception that database-level transactions are the primary way to implement business transactions - many business processes w/ customers or 3rd parties rely on ACKs and/or compensating transactions, escaping the scope of a single database-level transaction.
In practice, if the services are loosely-coupled enough, transactional boundaries will be local in scope and transactions spanning multiple services are unnecessary. Downstream services can be eventually consistent if idempotency is guaranteed and retries/replays are free.
Thanks! Can you talk a bit more about the static checking of cross-boundaries schemas? Any relation to tools that allow a schema to evolve without breaking compatibility, like protobuf?
It's not based on protobuf. There's some in-house tooling that checks the schemas of producers against consumers against known versions (aka the versions in production), and we run it as part of the CI.
Since services implement standard components/protocols there are standardised hooks to extract these schemas definitions from each HTTP endpoint or Kafka consumer.
I've watched a number of Clojure centric talks from Nubank employees. Actually, I think it was one particular employee, but I don't remember his name. One was on how they do testing. The others were about Fulcro, which is a very interesting web frontend library/framework.
It was more of an aquahire and Jose Valim the creator of Elixir left Plataformatec to start his own consultancy. All assets related to Elixir were transferred to the community. The rest of the core contributors are not affiliated to Plataformatec therefore the acquisition had no effect on Elixir.
I'm just remembering the sad collapse of RethinkDB...
The task of making a viable commercial database in 2020 is herculean and I can really empathize with the team's need to both keep cashflow and have a sufficiently sized deployment to debug against.
Can also say that everyone I've met at nubank are really passionate about the ecosystem and seem like they'll be excellent partners
Datomic is 8+ years old and by all accounts has a healthy customer base, it's not like they are in the takeoff stage. But of course they have to keep up like everyone else, especially now that there is competition from the OSS side (Crux).
I remember being very excited by RethinkDB, it was a huge shame to see that go down. I feel like they signed their own death warrant by making a product that was super easy to use and was well documented.. so no support contracts, because simply not needed. Such a shame.
"Explicitly constraining and mitigating certain categories of complexity was likely to pay off in the medium and long term."
100 million % correct. It boggles my mind when I am hired onto projects to help "bring them to prod" only to find out the past several years the coding was primarily done by college grads and relative beginners.
Ideally you get to rely on experts for the entirety of a project, but if your budget doesn't allow for it, at minimum I think it's early in the project that you want EXPERTS. You don't bring in experts and expect miracles after all the bad decisions have already been made and committed to.
I am genuinely curious. I haven't heard the name Cognitect before. I checked the website and they seem like another software consultancy firm. Anything I am missing? HN is very picky, so they must be doing something special.
I am a bit worried that a startup has acquired two companies that have extremely deep experience in specialised languages Platformatec (Elixir) and now Clojure (Cognitect)
Disclaimer: I am a Nubank employee, so there might be bias.
Regarding the future of Clojure, I believe that not much will change actually. Before Clojure was sponsored by Cognitect and had Rich's / Stu's and Alex's stewardship and that's gonna continue to be the case just swapping the sponsoring company behind it. IMHO it's only on Nubank's best interest to have a strong community around Clojure and Datomic as well.
About Platformatec I think that was a very different thing, it was more an acqui-hiring, and before Elxir's stewardship was under the company (but having very different development dynamics compared to Clojure) and after the agreement, it was transferred to the community. So the company was pretty much dissolved after the contract, and back then, that was clear and transparent, as it was announced to happen.
I think the history of large companies hiring maintainers/authors of programming languages/libraries they use has so far gone good.
Take for example php, perl(booking.com, bbc, craigslist), js(fb etc).
The language needs to be supported financially though. Companies are not living beings, typically its some SVP making decisions. Sometimes they do support, but sometimes big shots do feel programmers are spending too much time working for greater good, while they should be working for company profits.
So it depends on the bosses you report to. There is no easy answer to this question, because many times it just comes to down to one person making decisions.
The answer is in the blog post ("Nubank understands the unique value of Clojure and Datomic, and is committed to continuing both without disruption." and the bullet points that follow.)
What would somewhat worry me somewhat is what the situation would be if Nubank went pop, and Cognitect were no longer in a position to step back in as sponsors.
I do wonder about datomic, though, as people I’ve spoken to at Clojure conferences seem to have made use of Cognitect’s consulting as a kind of more advanced support mechanism and they say that they will stop the consulting work.
I friend of mine hired the principles at Cognitect to kick off a Clojure/Datomic project. They were like a force of nature, really, and very quickly got things set up and helped with architectural decisions, etc. I would imagine that they have helped hundreds of customers this way.
From the blog post, I think that the answer to your question is yes: they will stop general consulting services.
Here's hoping they release a getting started project now that they've dipped out of general consulting.There must have been a standard-ish template in use.
Does this mean Closure will continue to become more and more server/web focused?
I could have the wrong impression, but from all the dead libraries I've come across it feels like it used to be all over the place with people doing math, visualizations/art, music, people trying to run on Android (seemingly the only JVM language that has no Android ecosystem/workflow.. crazy) etc.. Now a lot of that has atrophied and looks like it's mostly all about web. Though there are still interesting nonweb things going on - it just feels like a shrinking fraction
Either way, a big congrats to the people involved. Happy for you guys. That you for all your hard work, the beautiful language that has made me enjoy programming more than ever, and all for free :)
I disagree that people are not doing those things now or that this has changed at all. We have a decade of yearly Clojure surveys that show people continue to do all those things (and lots more).
Most (70-80%) of Clojure developers work on web apps because most programmers work on web apps.
People that like Clojure use it for everything you can think of and I expect them to keep doing so.
Web is of course kinda dominant everywhere, but there's great stuff happening in other domains. For example, have a look at what the Scicloj folks are doing for data science https://github.com/scicloj/ as well as the Tech Ascent libraries https://github.com/techascent/
This is great for nubank, but how is this supposed to work for other users of Clojure and Datomic? Who is really going to be interested in building on top of tech owned by a (new, unknown, regional) bank?
Someone said that this is just like Amazon (who would build on top of tech from a bookstore??), but I hope it's obvious the two situations are very different.
I expect that I'll have to be looking for a new job in a year's time :-(
If you asked me that 15 years ago, I'd say "no". In hindsight, it sort of makes sense given their objective of increasing time spent online and the quality of the experience.
The proposition here is that nubank will be the first bank to successfully turn into a software vendor. Maybe my worries will be nothing in 10 years, but no one can say its an obvious outcome.
Nubank already ships software, Cognitect is already a healthy consultancy, no particular reason to kill either one. Surely we can agree that banks also care about good UX? Nubank in particular is known for it.
(I appreciate that you may not have heard of Nubank but I don't think calling them "unknown" is fair. They have attracted a literal billion in funding in a little over a year. They have over 10 million users.)
Bloomberg has sponsored BuckleScript in the beginning, but now it is sponsored by Facebook. Other than that their influence on OCaml development is minimal (and technically BuckleScript is a fork of the OCaml compiler).
We all know the history of acquihires. Key tech and products inevitably are swallowed, never seen outside again.
Besides that, datomic really is a great solution for banks and fintech....are other firms like that going to buy from another bank, maybe a competitor?
Per https://building.nubank.com.br/welcoming-cognitect-nubank/, "Nubank does not own Clojure, just as Cognitect never owned Clojure. Nubank will take over Cognitect’s role as a corporate sponsor for Clojure, funding the core development effort".
I am pretty sure that whoever owns Cognitect is in no position to boss Rich around regarding Clojure. Besides, Clojure is rather simple and stable. No need to change it dramatically...
Yes? What incentive exactly are you implying banks have that make them less suitable than other mega-corporations for the purposes of developing a programming language?
Banks and fintech often view their in-house tech as competitive advantages, and they usually don't care a whit about building cred in dev communities (a common reason why projects are OSS in the first place, to drive recruitment or promote a complimentary platform).
A good outcome isn't impossible, but it might be unprecedented
Nubank has presented their tech several times at a number of conferences and I believe they often sponsor those conferences. It's not a traditional bank, like Airbnb is not a traditional travel agency, and Amazon is not a traditional bookstore. This is not your local neighborhood credit union or ancient behemoth running COBOL mainframes.
Nubank is a company valued at over $10 billion, with investing from major Silicon Valley firms. It is not unknown to millions of people, and is expanding internationally so I don't think they'll be regional much longer. Clojure and datomic being such a good fit for their tech stack of hundreds of microservices and thousands of databases should really encourage people to use clojure like Erlang's history in telecommunications encouraged people to adopt Elixir.
The company I work for has 7+ open remote roles, all Clojure/Script engineers. Clojure is mind-expanding but doesn't necessarily take long to become proficient in - we've hired many developers with no prior experience who've learned Clojure in no time. If you're curious, my email address is in my profile
I think this a much more nuanced question than a yes-or-no answer can cover.
Looking at LinkedIn or indeed.com with just a simple search for Clojure with no geographic qualifier (in the US), we see a very small number of listed openings - 252 over the last month at LinkedIn or 44 in the last 14 days at indeed. A plain google job search on Clojure jobs in the US returns an even smaller number.
Some of those job listings will almost certainly have Clojure listed as part of a "laundry list" of technologies and the actual job will probably not be Clojure oriented.
So just from a raw numbers perspective, the job sites to suggest that there aren't a huge number of opportunities. Comparatively speaking, there are like 60,000 Java job postings on LinkedIn in the last month.
However, if you attend a Clojure/conj (one of the "primary" Clojure programming conferences), you will find that many attendees are part of some (not super-large?) number of companies that use Clojure.
My best advice on building a Clojure career (that I failed to follow) is that a programmer who wants to make a Clojure career path is to be prepared to spend a significant amount of time trying to make connections inside the Clojure community. On top of that, you probably need to build a portfolio of project experience that you at minimum blog about and preferably speak at Clojure conferences, user groups, or meetups.
<edit: removed off-topic thought>
I would gently observe that long-time Clojure developers are maybe too close to the tree to see the forest when it comes to judging Clojure career opportunities.
But I would love to be wrong about my impression of Clojure job opportunities! Perhaps fellow-HN readers could post (anonymous?) numbers of Clojure job openings for their company to give us a better idea?
But, usually better to weight technology quite low when picking what to work on. Product and company culture has much bigger impacts on your quality of life in my opinion.
I don't want to work with Spring, TYPO3, or OOUI, and all of those things have made me sad in the past. But, I really don't want to work at a company where people micro-manage, run around like headless chickens, get stressed at each-other, schedule endless meetings, or where the product is something pointless that no-one wants. Any of that stuff is bad.
I haven't used Clojure before but I have worked mostly with Elixir another niche functional language. In my experience because of the limited talent pool, most companies tend to prefer experienced candidates and if they are to take you on as a junior, you probably have to be significantly experienced in another mainstream language. It's very hard for someone to take a punt on a junior Elixir or Clojure developer who has little or no experience in any other language. Generally, niche languages are not a great bet if you are just starting out. You can of-course build the experience by working on side projects, blogging or speaking at conferences. In short its a labour of love. If you learn Clojure or in my case Elixir for the explicit reason of getting a job you might become very frustrated and disappointed. This is my experience.
Full-time in Clojure since early 2014; the jobs found me even before I had professional Clojure experience. There is definitely work out there... we have been hiring nearly continuously in Chicago for the past few years: junior, midlevel and senior alike. This took a pause for COVID-19 but I expect that to end soon.
Your mileage may vary, and I don't think the language is for everyone, but it is very satisfying to work with and it's putting groceries on the table for lots of people. (I'm happy to discuss more; contact info is in my profile.)
I work full-time in the healthcare industry writing mostly Clojure(script). I wouldn't base my entire career off it (or any one language for that matter), but there are career opportunities out there using Clojure.
It sure would be funny if Nubank was the company from Neal Ford's story about someone sneaking Clojure into an enterprise years ago by claiming it was "just a Java library".
i actually did this at a large enterprise, when i left the person taking up my mantle asked 'so this is just java right' I said 'uh ya you just include the jar and write the code like this' :D
Why don't they take on the name Cognitect? It is a much better brand than Nubank and that would distinguish this from the many stories where a no brand or bad brand big co buys a good brand.
Nubank has over ten million customers and undoubtedly many more people in their target market that know their brand. The only people that would recognize Cognitect are clojure developers or particularly hardcore fans.
> From their start in 2013, Nubank has grown to 600 Clojure developers, running 2.5 million lines of Clojure code in 500 microservices on over 2000 Datomic servers.
Yikes that sounds like hell. Let's stop bragging about costs as a succeess store? Headcount? LoC? microservices? These are all to be minimized.
I have had the pleasure of "using Clojure in anger" and for a few years was very dedicated to learning how to use it effectively. This was a significant step up for my general programming skills and the simplicity of the language often saved me from myself with respect to bad design or choices in code. Whatever programmer "maturity" I can claim is probably due to Clojure and teaching introductory programming and databases (not with Clojure and Datomic to be clear).
This acquisition is more abstractly interesting to me in that a VERY dedicated Clojure/Datomic company made it. We didn't see here, for lack of a better example, a FAANG company grabbing Cognitect. That may have been a choice! Maybe Cognitect went with an acquisition where they retain a high degree of autonomy with the benefits of being acquired.
I never made the leap into a larger organization with Clojure at its core. I was able to use Clojure only in my small shop where I have a small degree of autonomy on development language choice. For a few years, I was somewhat actively seeking an opportunity to join a larger Clojure-oriented team but struggled to gain much traction when applying to openings. It seems possible to build a Clojure career, but I've not been very good at that.