Nubank acquires Cognitect
cognitect.com
cognitect.com
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.
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.
Plans to release a SAAS banking core in the US? Pretty please?
This is great! Languages need strong laser-focused vision to avoid becoming a soup of ideas.
Things get byzantine fast in Brazil.
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 :-)
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.
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.
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.
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
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
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.
I want to see a stable, long-term ecosystem with maintainers that are getting paid for their work.
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.
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).
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.
Not sure whether I ever had the opportunity to properly thank you, but let me say so now. Thank you, jwr.
No company depends any new language to succeed, depends on customers.
This particular business really would not be possible without the reduction in incidental complexity that Clojure+ClojureScript brought.
What critical features Clojure has, which don't exist in other platforms/languages?
Have you seen Lumen, a Beam implementation in Rust that targets Wasm?
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.
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.
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.
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.
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.
Is it due to the nature of the problem space? Is it because finance people tend to be more analytical? Something else?
I tried unsuccessfully to get a job with them about 4-5 years ago. They are a huge Haskell shop.
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.
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.
Wouldn’t a strongly-typed language be a better choice here?
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
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.
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.
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.
Would love to see any actual data or studies showing that functional programming implicitly produces "high quality code".
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.
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.
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.
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.
And Nubank take testing really seriously. REPL and pure functions makes it very easy to use TDD.
[1] https://github.com/nubank/basic-microservice-example#ports-a...
[2] http://wiki.c2.com/?PortsAndAdaptersArchitecture
[3] https://practicalli.github.io/clojure/thinking-functionally/...
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.
Source: worked there.
Then again, Wirecard happened. But perhaps that wasn’t exactly banking.
Considering that finance is decently geographically distributed, I'd say it's more SV has become javascript hell than finance is especially FP oriented.
Plenty of financial institutions use lots of c++ or java and plenty use cobol too.
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)
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. Except they are. In the US not only at the federal level but also at the state level:
- https://en.wikipedia.org/wiki/Deposit_insurance
- https://www.fdic.gov/deposit/
- https://en.wikipedia.org/wiki/Federal_Deposit_Insurance_Corp...
- https://www.cnn.com/2020/04/17/business/bank-earnings-defaul...
Here's the list of banks that have failed in the US and for which their deposits entered receivership managed by the FDIC; looks like a handful every year: https://www.fdic.gov/Bank/individual/failed/banklist.html
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.
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.
did you miss how the banks all had to be bailed out a few years back?
https://www.cnn.com/2020/04/17/business/bank-earnings-defaul...
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.
Cheers.
And this is also one of the reasons I think having sole bank as your owner is a really really bad thing.
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.
Cheers. Thanks for the engagement.
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.
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.
Not sure what their license revenue is but hard to imagine it would be significant to a major fintech
Clojure deserves an IDE for larger adoption.
Wishing you and your team many congratulations and kudos on this occasion.
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.
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.
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.
Fun stuff.
sam at havenconnect dot com
This could be great for the clojure community. One idea, if done, could step function the community: open source datomic... Oh ma gad if that happens!
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.
http://blog.plataformatec.com.br/2020/01/important-informati...
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?
- 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 leverage Schema (https://github.com/plumatic/schema) and/or clojure.spec (https://clojure.org/guides/spec) to annotate functions and data schemas, but it's opt-in
- 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)
Since services implement standard components/protocols there are standardised hooks to extract these schemas definitions from each HTTP endpoint or Kafka consumer.
The downsides can be so tremendous -- I wonder if nubank would have done better to services in the low digit range.
(context: my thoughts on it -> https://stopa.io/post/236)
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.
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.
Inside the scope of a single service, when needed, we use Datomic, which provides ACID guarantees for that (https://docs.datomic.com/on-prem/acid.html) and also helps w/ idempotency guarantees by allowing time-travel (https://docs.datomic.com/on-prem/getting-started/see-histori...).
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
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 a bit worried that a startup has acquired two companies that have extremely deep experience in specialised languages Platformatec (Elixir) and now Clojure (Cognitect)
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.
Cognitect will continue to offer professional services for Datomic customers, but will transition out of general consulting development.
Does this mean your general consulting services are going away?
From the blog post, I think that the answer to your question is yes: they will stop general consulting services.
Sounds good to me, congratulations!
EDIT: I guess my confusion was between professional services for Datomic and general consulting, since both were mentioned in the context of Datomic.
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.
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.
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 :)
Mike Fikes and the team at Vouch.io are doing some interesting work there, using cljs for IOT.
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.
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 :-(
A good outcome isn't impossible, but it might be unprecedented
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.
(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.)
Now do datomic :-)
As opposed to building on top of tech "owned" by a small software consultancy? Perhaps I simply lack imagination, but how is this worse?
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?
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?
(luckily, extra mile != extra 100 miles)
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.
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.)
So why did they acquire Plataformatec?
Anyone know what language qldb is built on ?
I doubt it is but would be a pretty funny tie in.
In what way is it proprietary? Do Clojure programs depend on a runtime distributed with a restrictive license?
I wonder, would this lead to open source Datomic in one day?
https://docs.datomic.com/cloud/getting-started/start-system....
Yikes that sounds like hell. Let's stop bragging about costs as a succeess store? Headcount? LoC? microservices? These are all to be minimized.