28 ms·

The Future of Clojure

246 points by simonpure 6y ago

tharne 6y ago
I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it would be great if clojure replaced Python and Scala as the defacto language used to interact with Apache Spark. That's probably not likely, though. It's hard enough to get a lot of folks past spark's weirdness without throwing a lisp into the mix. But it does seem like a functional JVM language that's not Scala would be the optimal way to use spark.
- lmilcin 6y ago
  See... I work for one of the largest banks in the world and in vicinity of me there is a Clojure project. The guys are trying to figure out how to get rid of it. Original developers left the company or advanced to management roles and now nobody is able to figure out what this convoluted, obfuscated, undefined, unstructured mass of code does or how to modify it so that it doesn't blow up more that it already is. As much as I love Clojure I see the problem is you need really good (not just intelligent but also wise) developers to reap benefits. Otherwise you can run into huge problems. "With great power..." Clojure has so bad rep here that even I think I made a mistake that I let on that I use it for my projects.
  - tharne 6y ago
    That's unfortunate, but I see your point. It's a real catch-22. If you build everything in Java it's harder to attract good devs, but if you use something like Clojure you need to attract those good devs.
    - Pet_Ant 6y ago
      > Clojure you need to [keep] attract[ing] those good devs. This isn't one and don, people move on even from the best jobs. You know need to keep replacing them, explain to HR why this "req" (requisition - aka job opening) needs them to look at resumes differently. Why they can't pull from their Java pool of resumes, explain to your director why you aren't like all the other teams. It's a lot of friction.
    - jjtheblunt 6y ago
      perfectly said
  - sambe 6y ago
    I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.
    - lmilcin 6y ago
      The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired. Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem. At least with Java you get Spring and this is how you do endpoint, this is how you connect to the database, and so on. The structure is suboptimal and redundant but at least they are getting some guidance which are most likely already familiar with. In Clojure, as a lead of the project, you would have to do the same but now it would be up to you to define all of that guidance. The question is, are you better at this than entire organization that supports Spring? The only situation I see where Clojure would realistically be beneficial is when you only get like world class developers who know what they are doing and can work together. I can't work on a Clojure project with a person that is unable to go through something like Let over Lambda with full understanding of the code examples and trust they will be able to make good decisions when building abstractions with macros.
      - Bootvis 6y ago
        I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?
        lgessler 6y ago
        I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.
  - pinchhit 6y ago
    This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.
    - deleted 6y ago
      [deleted]
    - burnthrow 6y ago
      Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.
      - pinchhit 6y ago
        This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.
        kazinator 6y ago
        > it's actually convinced me on the virtue of regular OO/procedural languages over lisp. This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure. You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.
  - hotcrossbunny 6y ago
    Maybe if you make it known that you have some Clojure projects and that it might have even a possibility of a future with you, you might be able to attract and hire some good devs
    - lmilcin 6y ago
      But we do. There are publicly advertised open Clojure positions and I have been cold called or contacted on LinkedIn because I let on that I know Clojure. To which I must politely say I am already working for this company.
      - hotcrossbunny 6y ago
        Yep, I guess that is pretty ironic. If your roles are open to London/remote, I would be happy to take a look
        deckeraa 6y ago
        Same here. I've got current availability to do contract work and could take on some Clojure dev if that's what they need.
  - dustingetz 6y ago
    What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for middle managers, it makes their department headcount grow, and they get to pretend the project is succeeding because nobody can tell otherwise.
    - lmilcin 6y ago
      With Java, your convoluted mess can be parsed by IDE and you can figure out what it is doing. Also, most of it looks the same and is Ctrl+c, Ctrl+v of something else. With Clojure the mess is still 100k to millions LOC because the guys did not know how to make worthwhile abstractions, but now it can't be parsed by IDE and you are screwed trying to figure out what happens at runtime. ALso, if you think if there is less code then it is easier to understand, go and read any advanced Common Lisp book (like Let over Lambda) and try to really understand what some of the more advanced macros do, exactly. It is definitely not the same as reading pages upon pages of redundant code.
      - taeric 6y ago
        This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is developers refusing to use libraries it external programs and instead taking a ridiculous "first principals" approach. Even if they get it working, it is typically not search friendly, as everyone else is using some other tool. Basically, the same trap I see in build systems,
        jimbokun 6y ago
        > I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?
  - clusterhacks 6y ago
    I am also a long-time Clojure user and have production projects built in Clojure. I think your observation that you need really good developers is the key insight to problems that come about from using Clojure. Stu Halloway even mentions it in the interview: "And what we would quite often see is that people would write a Java app in Clojure, or people would write a Ruby on Rails app in Clojure. And not surprisingly, it would have weaknesses that you associate with idiomatic Java apps or idiomatic Ruby on Rails apps" Clojure, as a language, makes it very easy to do stuff and sometimes that stuff means making code look like code that only makes sense in other languages. This is a terrible mistake but one that is easy to understand. Very few developers have any real background in functional programming and it is too easy to start hacking things together. As a longtime Clojure user (dating back to attending the very first Clojure conference in Durham, North Carolina), I think there has been a little bit of "ego-driven" developer syndrome with projects in the language. There is definitely a tendency for new Clojure programmers to get too fancy. This is not a problem with Clojure the language though. I made the mistake myself in early projects. The more I have used Clojure, the more I have realized that when I am doing it right, I am spending significantly more time understanding the problem I am solving than throwing code together . . .
  - didibus 6y ago
    > and now nobody is able to figure out Ok, but how much of that is just them not knowing Clojure? I've found people that get handed down a code base in a different language tend to hack their way around it, instead of like, pausing for a minute, take some time to learn the language, and then come back to it. Maybe in your case it was a terrible code base of low quality, but I'm just curious.
    - lmilcin 6y ago
      The problem isn't knowing or not knowing Clojure. The worst codebases (and that is true of other languages just as for Clojure) that I have seen are ones done by people who are intelligent enough to learn every feature of their language and any little trick available on the internet but haven't yet had the chance to acquire the wisdom on when to use them or what to use them for.
      - thisiszilff 6y ago
        I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.
  - nnp7000 6y ago
    Citi?
    - deleted 6y ago
      [deleted]
  - dustingetz 6y ago
    Re any large Clojure projects needing modernization or migration to new stack – I would be happy to take care of projects like this, tech debt is not a problem for us, email me dustin@hyperfiddle.net
  - appletrotter 6y ago
    I also work at a large bank, I can see why clojure wouldn't work for a bank. I would blame the bank for being incompatible with clojure more than the other way around though.
- naringas 6y ago
  Nubank (a Brazilian based startup-style fintech company) does everything with clojure (on AWS). They bought Plataformatec makers of the Elxir lang.
  - mst 6y ago
    The entire interview is with a Nubank employee, who talked about more clojure in finance as a result. I think OP was riffing on that.
  - Scarbutt 6y ago
    Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.
    - dgb23 6y ago
      Can you substantiate that claim?
      - tincholio 6y ago
        If you look at his post history, you can see he has a thing for trolling in any thread about Clojure.
    - simongray 6y ago
      Why this obvious bait?
- wokwokwok 6y ago
  ? You can already use clojure with spark[1]. ...but just as pyspark is not “pythonic”, clojure spark is super unidomatic to use. ...which is why its languished unused. I mean, an idiomatic library isn’t impossible; see how databricks has wrapped the pandas api up with its koalas project; you just have invest the time and effort and actually make it.... for what, fundamentally, is a total absence of demand. or do you mean like first party support for clojure? Thats never going to happen... [1] https://github.com/gorillalabs/sparkling/ https://github.com/gorillalabs/sparkling/
  - hotcrossbunny 6y ago
    Does this framework speak to the mismatch in idiomatics? https://github.com/zero-one-group/geni https://github.com/zero-one-group/geni Not asking from any point of expertise mind you, having only stumbled across this literally this morning
- ashtonkem 6y ago
  I used Clojure in financial services, specifically at a trading firm. When I left we’d stopped writing new Clojure services, and had started to replace existing ones with Java. Finance, at least in our area, turned out to be a pretty tough place for Clojure’s style of dynamic typing. For those that don’t know, Rich Hickey (and by extension, Clojure) is really big on data-first dynamic typing. So idiomatically you’re supposed to do most of your work in Clojure using their first-rate immutable collections library, primarily maps and their sequence abstraction. Clojure provides some mechanisms for specialized domain objects, but it’s fair to say that this is typically considered non-idiomatic. This works great if one of the following conditions are true: 1) All data flows through your system on separate tracks. Foo’s come in from foo endpoints and go to the foo database, and very rarely do data sets cross paths. Differences in business logic can be separated by API endpoint, kafka topic, or some other difference that lets you separate the call paths thoroughly. 2) Every type of data in your system looks different, so that you can easily determine whether or not a given piece of data is a foo or a bar once and send it down the right call path in one place. 3) In any case where similar types of data must be treated differently, it’s possible to organize your code in such a way that you only have to build up the cond-tree once, and you can use different call paths to treat the data differently. All of these were often false for us. We ended up in situations where we had lots of data that looked very similar entering from common endpoints that required different business logic at multiple points in the pipeline. If you’re writing idiomatic Clojure this is the toughest case possible, as you end up littering your code with extremely similar cond-trees, which makes extension and verification unnecessarily hard. In most other languages, even dynamic ones, you’d solve this via sub-classing to both group common behavior and allow specialization. Clojure provided some tools to make this work, but they were both maintenance nightmares in their own separate ways. My favorite is how the results of defrecord (which makes class-like maps in Clojure) could be treated like a map, except certain map operations could accidentally turn it back from a record to a regular map. That’s quite the foot gun, trust me. For our team, we decided that pure Java was the way to go. Java by that point had started adding a lot of boilerplate eliminating niceness, including lambdas and streams, and the ability to make honest-to-god subclasses really helped out in our specific domain.
  - raspasov 6y ago
atdixon 6y ago
A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need of being more productive and writing more robust code. Yes, you can write functional, immutable, dynamic, code in Java and do meta-programming in Java! It's just somewhat cumbersome and prickly. Enter: Clojure. I've seen many an 'unwise' programmer make just as much a mess of Java systems as people are suggesting they've seen in Clojure projects. It may be simply that Java slows you/your team down enough so that the messes of unwise programmers are just made more slowly. But one wonders if this is really a win: you're probably also delivering your business value more slowly, as well. :thinking-face:
- throwaway92938 6y ago
  > The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in our industry, outside of language/chip design and correctness proofs, are being worked on in relatively boring languages (C, C++, Java etc.). Most of the niche language users I've met are working on basic CRUD web applications.
  - bambataa 6y ago
    I suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. But you are correct that doing so doesn't necessarily mean they are good. However, I don't think it follows that great developers work on hard problems. Why can't you be a great developer working on CRUD apps and occasionally finding ways to do them better?
    - 6y ago
keithasaurus 6y ago
Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then the code archaeology is just more difficult than it would be where types exist as guard rails. I think Clojure looks favorable in comparison to Java still (though perhaps less so). But with Kotlin and Scala as mature alternatives -- and Clojure without a real niche -- it's not what I would reach for.
- paultopia 6y ago
  Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refugees from Java working at big companies who have a will to massively overengineer everything. I'm thinking of libraries like mount and such which everyone uses for everything, and which I experience as, like, "did you want to inject your dependencies in your injected dependencies? Well first you have to do a quadruple axel inversion of control at the fifth abstraction layer out and use the fooflarb design pattern to delegate your inheritance and you thought you could even find the place in the code where it talks to the database? Good luck, sucker." Like, I always thought the point of a functional language was to not have to do any of that stuff... Like, I vividly remember the first time I used a clojure web framework that brought in all that stuff, and I literally, I'm serious here, could not find where in the code it was actually talking to the database. Just indirection on top of indirection on top of indirection. And when the application I was building on top of that, which was supposed to be quick and dirty, started mysteriously losing data, the only thing I could do was just tear it down and rewrite with Python and flask.
  - raspasov 6y ago
    Using a functional language doesn’t make reality and the complexity of state go away (unless you are writing a compiler or a program/system that fully and purely mathematically controls its inputs and outputs).
mumblemumble 6y ago
Tangentially: I recently decided to give Pharo a try. I'm still pretty early on in it, but, so far, I've really been having fun. If you look at it the right way, Smalltalk can almost be seen as more Clojure than Clojure. It's even more dynamic, and the live programming environment gives even tighter, more integrated feedback loops than REPL-driven development. Smalltalkers aren't exaggerating when they say you can literally program from inside the debugger. A lot of familiar programming idioms from Clojure (and other functional languages) are present in Smalltalk, and have been for years. And, while objects in Smalltalk are nearly as dynamic as maps in Clojure, the fact that they're discrete, named entities makes it a lot easier to inspect and grok someone else's code. It's not all perfect, of course. Some of the usual criticisms of Smalltalk are legitimate (though Pharo is making progress on addressing many of them), and I would like to see more of a culture of discipline around mutability. But, all in all, it's largely been a joy to learn.
- truculent 6y ago
  What are you writing with it? I've been wanting to give it a try too, but I'm unsure what kind of project is best suited.
  - deleted 6y ago
    [deleted]
  - mumblemumble 6y ago
    Sorry it took me so long to answer, but I'm still learning it, so I was hoping someone else would pop in. My impression/hope is that this is another spot where Smalltalk is like lisp. As a clean language with a simple syntax and clean semantics, it seems like where it shines is malleability. It's a substrate on top of which you build a domain-specific language that's tailor-made to whatever problem domain you happen to be working in. There's https://github.com/pharo-open-documentation/awesome-pharo https://github.com/pharo-open-documentation/awesome-pharo
  - dunefox 6y ago
    You could have a look at https://adventofcode.com https://adventofcode.com. I've been solving every puzzle so far and it's a fun way to play around with a new language (at least for the first couple of days).
moomin 6y ago
The Future of Clojure is 39 minutes and 11 seconds. Sounds about right.
talkingtab 6y ago
This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.
- aprdm 6y ago
  Which one was the least productive language, Java or Clojure ?
  - dgb23 6y ago
    Java, which is why they grew an aversion towards the JVM.
    - aprdm 6y ago
      I thought Clojure also required a JVM! Maybe to both haha
      - dgb23 6y ago
        Yes, that was the point. They don't want to use Clojure because Java made them hate the JVM.
        aprdm 6y ago
        Gotcha, thanks! bad reading from my part
  - talkingtab 6y ago
    It was Java. I was intrigued by some of the things with Clojure, especially transducers as described in the post by Rich Hickey https://cognitect.com/blog/2014/8/6/transducers-are-coming https://cognitect.com/blog/2014/8/6/transducers-are-coming.
- 6y ago
nojito 6y ago
Reverse engineering a Clojure codebase after the devs maintaining it leave is an experience I wouldn't wish on anyone. Because of the difficulties of sharing knowledge, Clojure will have an extremely difficult time growing.
- beders 6y ago
  A bad codebase is a bad codebase. I can show you quite a few bad Java ones. I just started to work on a quite large Clojure codebase and I had no trouble making meaningful contributions within a couple weeks. Having mostly pure functions makes it especially easy to understand what is going on. I had similar concerns, and this myth is hard to kill - for any dynamically typed language - but the REPL is your secret weapon.
deleted 6y ago
[deleted]
bird_monster 6y ago
> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?
- hangonhn 6y ago
  Until recently, I would have said Java because it has so many guard rails and good frameworks. But then I've recently encountered bugs caused by code that basically disabled all those guard rails. Had any one of them been left in place, the bug wouldn't have happened. It's kind of amazing how clever some unwise bad engineers can be. There's just no replacement for good, wise engineers.
  - bird_monster 6y ago
    That's interesting. In my experience, Java is one of the easiest languages to turn the best of intentions into actual unusable code. I personally have never seen or heard about a large Java application being easy to work with or having good guard rails. It all kinda just becomes a big mess. I think that Java might have benefited the most from the industry hellbent on making microservices, in that Java applications are less frequently built as gigantic unmaintainable messes, but instead much smaller more easily digestible messes. I am clearly biased against Java, but having worked with it at several jobs I just don't think it's a good idea.
    - deleted 6y ago
      [deleted]
    - The_Colonel 6y ago
      Interesting but I have the opposite experience. Java is weak in small scope and gets stronger with larger applications as it scales quite well in maintainability. In that sense adoption of microservice has hurt Java since you still need to do a lot of Java ceremony, tomcat + spring boot still starts up slow, you can't leverage superior IDEs to refactor interfaces across services etc. For thin microservices I would probably tend to use something like node.js, for traditional monoliths (IMHO still have their place) with a lot of complex logic I would use Java (or Kotlin, C#).
submeta 6y ago
Reading the comments I get the impression that Clojure is competing with Java, and it seems that it cannot win against Java, for various reasons, and I am saddened by that. What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)?
- puredanger 6y ago
  Clojure was designed to be applicable where Java is applicable. Fortunately that space of programs is enormous and the market is enormous. Clojure does not need to "win" against Java (or anything). It is unlikely (for many reasons that have nothing to do with its value as a language) to ever be more than a fraction as popular as Java, but that's irrelevant. It has a thriving sustainable ecosystem with 10k's of devs in 100's of companies. That is sufficient to call it a success.
- simongray 6y ago
  > What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)? I think this sentiment ("Clojure is dying") has kind of become a Hacker News meme at this point. Clojure basically came out of nowhere and pretty much displaced all other Lisps in about a decade. It is definitely not dying, it's just an opinionated, fairly niche language - it's not Go or TypeScript. It solves certain problems well and has some uses where it really shines. It's not a silver bullet, though, and it definitely requires serious learning/unlearning to get really good at it if all you know is the mainstream imperative/OOP style. Clojure works well for those who buy its rationale: https://clojure.org/about/rationale https://clojure.org/about/rationale
  - dunefox 6y ago
    How did it displace all other Lisps if a) they're still going string and b) they weren't mainstream in the first place?
nanomonkey 6y ago
It's interesting to see so many people complain that it's hard to hire Clojure engineers, when I've had the exact opposite problem...trying to find a Clojure shop to join. They are few and far between, and the few that are hiring say that they will take folks that are new to Clojure, but then are baffled when you don't know how to idiomatically solve whiteboard problems. Clojure remedies all of my problems with previously used languages (Basic, C, Java, ObjC, Javascript, Python), in that it allows me to remove boilerplate and create layers of abstraction that are appropriate for problem solving. It's also a fairly opinionated language, preferring functional programming methods that work with how I like to solve problems. This is refreshing, as it feels like I can bypass all of the style wars that I encountered with Python., and the verbosity of C/Java/Obj-C. No longer being told to rewrite functional code as an object, by an engineering manager that only ever writes imperative scripts. Lastly I now love writing front end code in Clojurescript...something I never would have expected. Reagent and Re-frame are a dream for large complex SPAs, which while I dislike in principle, seem to be the trend in cross-platform GUIs. And it makes programming fun again!
- puredanger 6y ago
  Both devs and jobs exist but they are mismatched in terms of geography and experience expectations. I don't think it's specific to Clojure, it's common to any narrow technology. Certainly things have gotten far better over the last 10 years and there are more companies hiring in Clojure more actively now than I've ever seen. Fixing it requires a feedback cycle that takes a long time to grow into an active market. When I first started in Java in 1997, there were few companies doing Java and few devs who knew it and it was much the same. Sun spent like a billion dollars marketing Java to create that ecosystem.
  - newcrobuzon 6y ago
    > Sun spent like a billion dollars marketing Java I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective. It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might need just a little nudge :) Within the JVM ecosystems it seems that basically Kotlin (as nice as it is) has been stealing some market share that might have belonged to Clojure. And all that just by selling some cheap cut syntax sugar on the corner. There definitely is a huge desire within Java/JVM community to innovate and if approached correctly Clojure could actually shine - there are just few misconceptions and fears that could be put to sleep by some smart marketing strategy. Nubank is great first step in that direction, because it gives an example of a mature large yet innovative company relying on Clojure in production.
dzonga 6y ago
are there people who used both clojure and scala. And decided to use Scala ? if so why ? I'm new to Scala that's why
- dyadic 6y ago
  There are people that used both including me. But I fell squarely on the Clojure side and haven't written Scala for 7-8 years now.
  - dustingetz 6y ago
    Same, 2010-era FP in Scala was a disaster and also very angry, but I'd say in about 1-2 years FP Scala will be about at the maturity that they imagined they were at in 2010. Still kind of angry though.
- keithasaurus 6y ago
  Yes. In general, I would choose Scala. Better tooling, (pretty good) type system; not without its warts. Main concern I'd see ahead is the 2 -> 3 transition, which has the potential to be as difficult as the Python 2 -> 3 transition. That said, Scala 3 looks nicer to me as a language, with top-level functions, significant whitespace (more concise code), and better ADTs.
- eeperson 6y ago
  I've used both and end up writing much more Scala. There are a few reasons why this was the case for me: - Scala is much closer to Java making it an easier sell to other Java programmers. - I think static typing makes a lot more sense for larger projects - I found a rich static type system easier to use and more generally applicable than macros.
- aweiland 6y ago
  I played with both Clojure and Scala, but ended up on Kotlin. I've been very happy there.
jakebasile 6y ago
I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture interviews / homework / tests, but that's really a bigger thing that just Clojure. I think more could be done to market Clojure to the non-believers, but I don't have specific ideas on how that could be done. You can take my parentheses from my cold, unemployed hands.
- Scarbutt 6y ago
  Did Clojure made you unemployed?
  - jakebasile 6y ago
    No, I am currently employed. It's a play on the "from my cold, dead hands" phrase. https://en.wikipedia.org/wiki/From_my_cold,_dead_hands https://en.wikipedia.org/wiki/From_my_cold,_dead_hands
- bit_logic 6y ago
  I'm a bit surprised to hear this, I thought Clojure shops would be better than this. It was must hard to find any candidates and they're still doing the stupid leetcode interview style? Are these companies putting any thought into their hiring process? That process was created by FANG because they can abuse their candidates and still get a lot of applicants (although I think this is less true than it used to be) But to use that same hazing ritual at a smaller company with the hiring funnel further reduced by a niche language? Really stupid.
  - deleted 6y ago
    [deleted]
  - jakebasile 6y ago
    I agree, but it's definitely still common enough even among Clojure shops. I think it's an insight wide plague but despite so many of us hating it, it persists.
moocowtruck 6y ago
gimme smalltalk or gimme death
pinchhit 6y ago
As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something, and in practice you only have 1 smart person focused on your business. As the other 9 continue to reinvent wheels, the nature of clojure being small relative to other open-source communities means that eventually your shiny new clojure tools get replaced by better community offerings, except you don't have the bandwidth to switch over and start using them. Overall, velocity would be improved if you had hired 1 super smart engineer and 9 mediocre ones. It's important to note here that while technically clojure can interoperate with java or javascript, in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. This effect is 10 times worse for clojurescript in the browser, although it's pretty bad for clojure targeting the JVM as well.
- beders 6y ago
  > poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?
  - Scarbutt 6y ago
    Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compilation.html https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...
    - fulafel 6y ago
      The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.
lninyo 6y ago
I think the future of Clojure is not much different from the present of Common Lisp. If you go look at supposedly 'workhorse libraries', work has been abandoned. Some of the projects that Clojure's own page points to haven't seen updates for 6,7, 8 years. Some people who were super active in the community have moved on to other pastures. This is not a good sign. If you look at Clojure problems being solved by beginners on Exercism, you'd see problems categorized as "easy", but to solve them idiomatically, you need to know quite a bit of the language and its library ecosystem. The problems that do get solved, are mostly not idiomatic and most people are just trying to write C/JS/Java in Clojure (maybe because they want to appear to be 'wise' because you know, once you can conj two vectors together, your poopoo basically doesn't smell anymore.) This indicates a major disconnect between what "experienced" Clojure dev's think is "easy" for beginners to solve and what actually might be easy given the nature of a language. If you can't solve the problem idiotmatically without knowing obscure functions in the clojure core, and also of ways to apply those functions just in the right way (the functional part) you shouldn't categorize them as 'easy' but they do, which is odd and counter productive, yet there they are. So a lot of genuinely curious people abandon learning clojure simply because the learning curve is a lot like the "emacs learning curve" in one of those XKCD pieces. Rich Hickey joining Cognitect was beginning of the end IMO. It's like Chuck Moore and his lady friend starting up Forth Inc. I hate to say it but I see Clojure going the way of Forth. It will increasingly become niche and it will eke out its days just like other niche languages tend to do. It has already begun to do so. Hickey is super smart, and this language is for him and super smart people like him for problem domains he operates in, not for mere mortals. You can't have long term viability when you're not attracting new people, and most new people come into a language by way of wanting to do simple stuff like webdev. Clojure/Script ecosystem just doesn't offer that (despite the claims). If it did, you'd see people leaving JS frameworks and going to Clojure/Cljs in large numbers but they just aren't and the ship has sailed on that because the time to do that was around 2012-2015 . Python has won the AI glue wars, and JS has won the web war. This is brushed aside as "well they're mostly stupid people anyway and who needs them in this refined atmosphere of clojure zen that WE all have?" Thoughtworks made a lot of hay during the RoR sunshine in the mid 2000's onwards, and they did the same with Clojure starting around 2012. One or two successful companies does not an expanding eco system make. And they and even cognitect to some extent are more in maintenance phase rather than expansion phases. Clojure programmers (some) may be commanding six figure salaries, but you can do the same if you're any good at COBOL, and believe me, there are a lot more COBOL jobs out there right now than there are Clojure jobs. As of this writing, Thoughtworks' career page has 14 openings for ReactJS, 5 for Java and ZERO for Clojure. That should tell you something about the future of Clojure. I do not write these things as a 'hater.'
pacomerh 6y ago
kind of a side note but, why don't professional engineers and podcasters in general use better mics when recording podcasts? You can hear they're just using the mic from the laptop, sometimes it sounds like they're talking from their bathroom. Not only does it sound bad, If you're listening this in a room that already ads acoustic this is twice the reverb, which is pretty bad.
coltnz 6y ago
This was a little bit disappointing for me to be honest, as someone who loves the language and runs Clojure teams. Obviously not aimed at the hardcore Clojure crowd but still I hoped for more on the actual future. There was a mention of more resources with no specifics and reassuring comments on things not fundamentally changing as before [as in earlier announcements]. Things I'd ask: - What are the new resources (for Clojure? or just Datomic?), how are they being used? Does Nubank have opinions / direction on these resources. - Has an open sourced Datomic been discussed? It wouldn't seem to be strategic for Nubank and could be a big boost to the Clojure ecosystem. I'd read every line.. - Who owns the Clojure trademarks and IP going forward. Any talk of a Clojure Foundation? - Alex Miller does an awesome job but boy he has a lot to cover. It suits Rich to have a small team of trustees for core (though boy its got small) but the community stuff could surely be advanced quicker. Old tickets in contrib and key libs etc.. - There was talk a few years ago of facilitating community involvement with a PEP type process, https://www.python.org/dev/peps/pep-0001/ https://www.python.org/dev/peps/pep-0001/? Any further thoughts? - Clojurescript has left Core. Is Nubank likely to want to get involved here? I have no right to these answers, some may be commercially sensitive and of course Clojure doesn't belong to me. However there is no harm in asking when answers to the questions are important to me in my future uses of Clojure. Indeed I think it would be superior - in terms of Clojure's continued acceptance into industry - to know more of it's future direction than has traditionally been the case. Hopefully Nubank provides the confidence needed for this to happen.
- puredanger 6y ago
  Lots of good questions here. https://building.nubank.com.br/welcoming-cognitect-nubank/ https://building.nubank.com.br/welcoming-cognitect-nubank/ from Ed Wible, CTO at Nubank is a good read that answers many of them btw. Also see https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank. > What are the new resources (for Clojure? or just Datomic?), how are they being used? Does Nubank have opinions / direction on these resources. Since Cognitect joined Nubank, several people have joined the Datomic team, both new hires and internal moves from Nubank and the rate of development has increased. We are also looking at expanding the Clojure team in the near future. > Has an open sourced Datomic been discussed? No changes planned. > Who owns the Clojure trademarks and IP going forward. Any talk of a Clojure Foundation? Clojure was and is an independent project and Rich Hickey is a joint owner (along with contributors) to the Clojure copyrights. From Rich's announcement on the Clojure mailing list: "Clojure remains independent, and development and stewardship will continue as it has, with more resources and a much larger sponsoring organization in Nubank." > Alex Miller does an awesome job but boy he has a lot to cover. Thanks and indeed! As above, we are likely to expand the Clojure team in the future. > There was talk a few years ago of facilitating community involvement with a PEP type process We created https://ask.clojure.org https://ask.clojure.org as a way for Clojure users to discuss problems important for them and to allow voting on those problems for their importance. We use that information to inform decisions about what to work on so I encourage all Clojure users to express their needs there! > Clojurescript has left Core. Is Nubank likely to want to get involved here? Cognitect was, and Nubank now is, the primary sponsor for ClojureScript (funding both David Nolen and Mike Fikes).
f2000 6y ago
Clojure. I wanted to love you. But at the end of the day types matter (to me at least) and spec just feels like an afterthought.
titanix88 6y ago
Clojure is a great language for small creative teams to achieve great(relatively) things. It's difficult to understand that from a startup mindset of hacker news where money is no problem and peace of mind is an after thought. If you are a budget constrained individual living in a third world country with nothing to invest but your intellect and time, Clojure is a very good language. It lets you to - 1. Create relatively large systems without pulling your hair out. 2. Juggle between different projects with relative ease. Great for managing a projects in maintenance mode. Great for contractors with long term support contracts. 3. Realize your vision of a complete product with relatively low time and money. Overall, it's a way of doing effective programming. It's probably not a good way of making money if the focus is to siphon investor money with a large team and millions of lines to show for.
- zrkrlc 6y ago
  How did you get started in Clojure contracting work?
geospeck 6y ago
One thing that I would like to mention as a Clojure newbie is the community. I am super impressed by how much friendly they are. I mainly use /r/clojure on Reddit and the Clojurians on Slack.
amw-zero 6y ago
I love writing Clojure, I just can’t live without static types.

246 points by simonpure 6y ago

I'd love to see clojure take a bigger role in the financial services sector. The fact that it runs on the JVM, gives it a nice foot in the door. Ideally, it would be great if clojure replaced Python and Scala as the defacto language used to interact with Apache Spark. That's probably not likely, though. It's hard enough to get a lot of folks past spark's weirdness without throwing a lisp into the mix. But it does seem like a functional JVM language that's not Scala would be the optimal way to use spark.

lmilcin 6y ago
See... I work for one of the largest banks in the world and in vicinity of me there is a Clojure project. The guys are trying to figure out how to get rid of it. Original developers left the company or advanced to management roles and now nobody is able to figure out what this convoluted, obfuscated, undefined, unstructured mass of code does or how to modify it so that it doesn't blow up more that it already is. As much as I love Clojure I see the problem is you need really good (not just intelligent but also wise) developers to reap benefits. Otherwise you can run into huge problems. "With great power..." Clojure has so bad rep here that even I think I made a mistake that I let on that I use it for my projects.
- tharne 6y ago
  That's unfortunate, but I see your point. It's a real catch-22. If you build everything in Java it's harder to attract good devs, but if you use something like Clojure you need to attract those good devs.
  - Pet_Ant 6y ago
    > Clojure you need to [keep] attract[ing] those good devs. This isn't one and don, people move on even from the best jobs. You know need to keep replacing them, explain to HR why this "req" (requisition - aka job opening) needs them to look at resumes differently. Why they can't pull from their Java pool of resumes, explain to your director why you aren't like all the other teams. It's a lot of friction.
  - jjtheblunt 6y ago
    perfectly said
- sambe 6y ago
  I have noticed that people often use such criticisms against anything they aren't familiar with. If you can find an enthusiastic polyglot who says the same then it becomes a bit more believable. And - of course - the fact that it is so unfamiliar to most is probably a valid criticism anyway.
  - lmilcin 6y ago
    The truth is that the candidates we are receiving are barely able to code in Java. Not all know differences between linked lists and arrays and if they know what a breakpoint is they are hired. Now, imagine giving the people environment that imposes no structure on your project and gives hyper powerful tools like macros and you are in a big problem. At least with Java you get Spring and this is how you do endpoint, this is how you connect to the database, and so on. The structure is suboptimal and redundant but at least they are getting some guidance which are most likely already familiar with. In Clojure, as a lead of the project, you would have to do the same but now it would be up to you to define all of that guidance. The question is, are you better at this than entire organization that supports Spring? The only situation I see where Clojure would realistically be beneficial is when you only get like world class developers who know what they are doing and can work together. I can't work on a Clojure project with a person that is unable to go through something like Let over Lambda with full understanding of the code examples and trust they will be able to make good decisions when building abstractions with macros.
    - Bootvis 6y ago
      I don’t understand why you can’t get better candidates. I understand that things go wrong with bad developers but how is it that you can’t get those folks that can write somewhat good Clojure independently?
      - lgessler 6y ago
        I don't know what sector GP is in but there are plenty of programming jobs (maybe even most?) where the company (usually one where tech generally is incidental to their operations) really isn't in a position to offer a salary that's competitive enough to hire this way. I'd say most programming jobs at US hospitals are this way, for instance.
- pinchhit 6y ago
  This absolutely matches my experience as a full time Clojure dev at multiple companies. Leadership is desperate to replace the code with something more maintainable. It's gotten bad enough that I will switch languages for my next job, the headaches are not worth it.
  - deleted 6y ago
    [deleted]
  - burnthrow 6y ago
    Clojure is quite maintainable, a well-written Clojure program is small and clear, easy to modify. Pervasive immutability is a huge win; Clojure programs are big on referential integrity. There's some doublespeak going on here. When "leadership" says "maintainable" what they mean is that the project is recoverable after they frog march the project lead out the door, or lay off the team, or the team quits because the job blows. Their view of maintainability is dominated by Bus Factor and similar existential concerns, rather than agility experienced by the project's authors. They actually want the opposite of maintainable: Rigid and heavily specified.
    - pinchhit 6y ago
      This is not what I meant by maintainable. The companies I've programmed clojure in were sizable and bet on it for their entire stack, and hired very sharp senior people to work on them. Even there, the projects suffered so much to hit release dates and stay understandable as the system grew that velocity suffered relative to peers doing experiments in traditional OO languages. In fact, the maintenance burden (for code composed by smart senior people!) is so high that it's actually convinced me on the virtue of regular OO/procedural languages over lisp.
      - kazinator 6y ago
        > it's actually convinced me on the virtue of regular OO/procedural languages over lisp. This is an example of the problem of Clojure being promoted as Lisp. There are now people whose idea of what is "Lisp" is represented by Clojure. You might like coding in a normal, procedural Lisp with OOP, but due to a bias induced by Clojure, you don't suspect that's even a thing.
- hotcrossbunny 6y ago
  Maybe if you make it known that you have some Clojure projects and that it might have even a possibility of a future with you, you might be able to attract and hire some good devs
  - lmilcin 6y ago
    But we do. There are publicly advertised open Clojure positions and I have been cold called or contacted on LinkedIn because I let on that I know Clojure. To which I must politely say I am already working for this company.
    - hotcrossbunny 6y ago
      Yep, I guess that is pretty ironic. If your roles are open to London/remote, I would be happy to take a look
      - deckeraa 6y ago
        Same here. I've got current availability to do contract work and could take on some Clojure dev if that's what they need.
- dustingetz 6y ago
  What % of Java projects fail again? With Java, your convoluted mess is 100k to millions LOC. With Clojure, the same devs make the same convoluted mess but in 10k to 100k LOC, and you've left the door open for an inspired "true Scotsman" to come in and do the whole thing in 5k. But management has to understand that, and of course the principle agent problem, peter principle, politics, conways law ... Java is great for middle managers, it makes their department headcount grow, and they get to pretend the project is succeeding because nobody can tell otherwise.
  - lmilcin 6y ago
    With Java, your convoluted mess can be parsed by IDE and you can figure out what it is doing. Also, most of it looks the same and is Ctrl+c, Ctrl+v of something else. With Clojure the mess is still 100k to millions LOC because the guys did not know how to make worthwhile abstractions, but now it can't be parsed by IDE and you are screwed trying to figure out what happens at runtime. ALso, if you think if there is less code then it is easier to understand, go and read any advanced Common Lisp book (like Let over Lambda) and try to really understand what some of the more advanced macros do, exactly. It is definitely not the same as reading pages upon pages of redundant code.
    - taeric 6y ago
      This doesn't match my experience. I've had to deal with some Java code that the ide was useless to help figure out. Usually made worse by some over optimized build system that was non Google friendly to see what was supposed to happen. Worse, the abstractions made it so that even a simple feature would require about six files. Not counting the tests. Not to say that clojure has been a breeze. Worst I see there is developers refusing to use libraries it external programs and instead taking a ridiculous "first principals" approach. Even if they get it working, it is typically not search friendly, as everyone else is using some other tool. Basically, the same trap I see in build systems,
      - jimbokun 6y ago
        > I've had to deal with some Java code that the ide was useless to help figure out. Spring annotations, maybe?
- clusterhacks 6y ago
  I am also a long-time Clojure user and have production projects built in Clojure. I think your observation that you need really good developers is the key insight to problems that come about from using Clojure. Stu Halloway even mentions it in the interview: "And what we would quite often see is that people would write a Java app in Clojure, or people would write a Ruby on Rails app in Clojure. And not surprisingly, it would have weaknesses that you associate with idiomatic Java apps or idiomatic Ruby on Rails apps" Clojure, as a language, makes it very easy to do stuff and sometimes that stuff means making code look like code that only makes sense in other languages. This is a terrible mistake but one that is easy to understand. Very few developers have any real background in functional programming and it is too easy to start hacking things together. As a longtime Clojure user (dating back to attending the very first Clojure conference in Durham, North Carolina), I think there has been a little bit of "ego-driven" developer syndrome with projects in the language. There is definitely a tendency for new Clojure programmers to get too fancy. This is not a problem with Clojure the language though. I made the mistake myself in early projects. The more I have used Clojure, the more I have realized that when I am doing it right, I am spending significantly more time understanding the problem I am solving than throwing code together . . .
- didibus 6y ago
  > and now nobody is able to figure out Ok, but how much of that is just them not knowing Clojure? I've found people that get handed down a code base in a different language tend to hack their way around it, instead of like, pausing for a minute, take some time to learn the language, and then come back to it. Maybe in your case it was a terrible code base of low quality, but I'm just curious.
  - lmilcin 6y ago
    The problem isn't knowing or not knowing Clojure. The worst codebases (and that is true of other languages just as for Clojure) that I have seen are ones done by people who are intelligent enough to learn every feature of their language and any little trick available on the internet but haven't yet had the chance to acquire the wisdom on when to use them or what to use them for.
    - thisiszilff 6y ago
      I guess the appeal of clojure in that case is that the language is a lot simpler than other languages.
- nnp7000 6y ago
  Citi?
  - deleted 6y ago
    [deleted]
- dustingetz 6y ago
  Re any large Clojure projects needing modernization or migration to new stack – I would be happy to take care of projects like this, tech debt is not a problem for us, email me dustin@hyperfiddle.net
- appletrotter 6y ago
  I also work at a large bank, I can see why clojure wouldn't work for a bank. I would blame the bank for being incompatible with clojure more than the other way around though.
naringas 6y ago
Nubank (a Brazilian based startup-style fintech company) does everything with clojure (on AWS). They bought Plataformatec makers of the Elxir lang.
- mst 6y ago
  The entire interview is with a Nubank employee, who talked about more clojure in finance as a result. I think OP was riffing on that.
- Scarbutt 6y ago
  Yep,and they were forced to buy Cognitect too to deal's with their Clojure/Datomic mess.
  - dgb23 6y ago
    Can you substantiate that claim?
    - tincholio 6y ago
      If you look at his post history, you can see he has a thing for trolling in any thread about Clojure.
  - simongray 6y ago
    Why this obvious bait?
wokwokwok 6y ago
? You can already use clojure with spark[1]. ...but just as pyspark is not “pythonic”, clojure spark is super unidomatic to use. ...which is why its languished unused. I mean, an idiomatic library isn’t impossible; see how databricks has wrapped the pandas api up with its koalas project; you just have invest the time and effort and actually make it.... for what, fundamentally, is a total absence of demand. or do you mean like first party support for clojure? Thats never going to happen... [1] https://github.com/gorillalabs/sparkling/ https://github.com/gorillalabs/sparkling/
- hotcrossbunny 6y ago
  Does this framework speak to the mismatch in idiomatics? https://github.com/zero-one-group/geni https://github.com/zero-one-group/geni Not asking from any point of expertise mind you, having only stumbled across this literally this morning
ashtonkem 6y ago
I used Clojure in financial services, specifically at a trading firm. When I left we’d stopped writing new Clojure services, and had started to replace existing ones with Java. Finance, at least in our area, turned out to be a pretty tough place for Clojure’s style of dynamic typing. For those that don’t know, Rich Hickey (and by extension, Clojure) is really big on data-first dynamic typing. So idiomatically you’re supposed to do most of your work in Clojure using their first-rate immutable collections library, primarily maps and their sequence abstraction. Clojure provides some mechanisms for specialized domain objects, but it’s fair to say that this is typically considered non-idiomatic. This works great if one of the following conditions are true: 1) All data flows through your system on separate tracks. Foo’s come in from foo endpoints and go to the foo database, and very rarely do data sets cross paths. Differences in business logic can be separated by API endpoint, kafka topic, or some other difference that lets you separate the call paths thoroughly. 2) Every type of data in your system looks different, so that you can easily determine whether or not a given piece of data is a foo or a bar once and send it down the right call path in one place. 3) In any case where similar types of data must be treated differently, it’s possible to organize your code in such a way that you only have to build up the cond-tree once, and you can use different call paths to treat the data differently. All of these were often false for us. We ended up in situations where we had lots of data that looked very similar entering from common endpoints that required different business logic at multiple points in the pipeline. If you’re writing idiomatic Clojure this is the toughest case possible, as you end up littering your code with extremely similar cond-trees, which makes extension and verification unnecessarily hard. In most other languages, even dynamic ones, you’d solve this via sub-classing to both group common behavior and allow specialization. Clojure provided some tools to make this work, but they were both maintenance nightmares in their own separate ways. My favorite is how the results of defrecord (which makes class-like maps in Clojure) could be treated like a map, except certain map operations could accidentally turn it back from a record to a regular map. That’s quite the foot gun, trust me. For our team, we decided that pure Java was the way to go. Java by that point had started adding a lot of boilerplate eliminating niceness, including lambdas and streams, and the ability to make honest-to-god subclasses really helped out in our specific domain.
- raspasov 6y ago

atdixon 6y ago

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..." The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. What I mean by this: I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need of being more productive and writing more robust code. Yes, you can write functional, immutable, dynamic, code in Java and do meta-programming in Java! It's just somewhat cumbersome and prickly. Enter: Clojure. I've seen many an 'unwise' programmer make just as much a mess of Java systems as people are suggesting they've seen in Clojure projects. It may be simply that Java slows you/your team down enough so that the messes of unwise programmers are just made more slowly. But one wonders if this is really a win: you're probably also delivering your business value more slowly, as well. :thinking-face:

throwaway92938 6y ago
> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure. HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure. Great developers have to be working on hard problems and almost all of the hard problems in our industry, outside of language/chip design and correctness proofs, are being worked on in relatively boring languages (C, C++, Java etc.). Most of the niche language users I've met are working on basic CRUD web applications.
- bambataa 6y ago
  I suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. But you are correct that doing so doesn't necessarily mean they are good. However, I don't think it follows that great developers work on hard problems. Why can't you be a great developer working on CRUD apps and occasionally finding ways to do them better?
  - 6y ago

keithasaurus 6y ago

Having worked at a company with a large Clojure codebase, I just don't see Clojure growing. It's not well-suited to large projects. The dynamic-ness of it and awkward parts of the language (macros, protocols, ambiguity of laziness, etc) end up inevitably getting used in ways they aren't intended. The idea that you need "wise programmers" is a really big problem. People leave, institutional knowledge is lost, and then the code archaeology is just more difficult than it would be where types exist as guard rails. I think Clojure looks favorable in comparison to Java still (though perhaps less so). But with Kotlin and Scala as mature alternatives -- and Clojure without a real niche -- it's not what I would reach for.

paultopia 6y ago
Maybe a broader version of this point: clojure tries to be something suited both for industry use at scale and for hobbyists wanting to do freaky-deaky stuff at the same time, but those are fundamentally incompatible. I say this as someone squarely in the latter category who has exactly the opposite problem from you: I love clojure the language and its features, but all the major libraries seem to be written by refugees from Java working at big companies who have a will to massively overengineer everything. I'm thinking of libraries like mount and such which everyone uses for everything, and which I experience as, like, "did you want to inject your dependencies in your injected dependencies? Well first you have to do a quadruple axel inversion of control at the fifth abstraction layer out and use the fooflarb design pattern to delegate your inheritance and you thought you could even find the place in the code where it talks to the database? Good luck, sucker." Like, I always thought the point of a functional language was to not have to do any of that stuff... Like, I vividly remember the first time I used a clojure web framework that brought in all that stuff, and I literally, I'm serious here, could not find where in the code it was actually talking to the database. Just indirection on top of indirection on top of indirection. And when the application I was building on top of that, which was supposed to be quick and dirty, started mysteriously losing data, the only thing I could do was just tear it down and rewrite with Python and flask.
- raspasov 6y ago
  Using a functional language doesn’t make reality and the complexity of state go away (unless you are writing a compiler or a program/system that fully and purely mathematically controls its inputs and outputs).

mumblemumble 6y ago

Tangentially: I recently decided to give Pharo a try. I'm still pretty early on in it, but, so far, I've really been having fun. If you look at it the right way, Smalltalk can almost be seen as more Clojure than Clojure. It's even more dynamic, and the live programming environment gives even tighter, more integrated feedback loops than REPL-driven development. Smalltalkers aren't exaggerating when they say you can literally program from inside the debugger. A lot of familiar programming idioms from Clojure (and other functional languages) are present in Smalltalk, and have been for years. And, while objects in Smalltalk are nearly as dynamic as maps in Clojure, the fact that they're discrete, named entities makes it a lot easier to inspect and grok someone else's code. It's not all perfect, of course. Some of the usual criticisms of Smalltalk are legitimate (though Pharo is making progress on addressing many of them), and I would like to see more of a culture of discipline around mutability. But, all in all, it's largely been a joy to learn.

truculent 6y ago
What are you writing with it? I've been wanting to give it a try too, but I'm unsure what kind of project is best suited.
- deleted 6y ago
  [deleted]
- mumblemumble 6y ago
  Sorry it took me so long to answer, but I'm still learning it, so I was hoping someone else would pop in. My impression/hope is that this is another spot where Smalltalk is like lisp. As a clean language with a simple syntax and clean semantics, it seems like where it shines is malleability. It's a substrate on top of which you build a domain-specific language that's tailor-made to whatever problem domain you happen to be working in. There's https://github.com/pharo-open-documentation/awesome-pharo https://github.com/pharo-open-documentation/awesome-pharo
- dunefox 6y ago
  You could have a look at https://adventofcode.com https://adventofcode.com. I've been solving every puzzle so far and it's a fun way to play around with a new language (at least for the first couple of days).

moomin 6y ago

The Future of Clojure is 39 minutes and 11 seconds. Sounds about right.

talkingtab 6y ago

This will probably earn me lots of negative points, but I used Java for eight years and after much initial enthusiasm came to despise it. It was the least productive language I have ever used. I have twice tried to learn Clojure and each time I have to install the JVM, I simply quit, despite being intrigued by Clojure itself. Sigh.

aprdm 6y ago
Which one was the least productive language, Java or Clojure ?
- dgb23 6y ago
  Java, which is why they grew an aversion towards the JVM.
  - aprdm 6y ago
    I thought Clojure also required a JVM! Maybe to both haha
    - dgb23 6y ago
      Yes, that was the point. They don't want to use Clojure because Java made them hate the JVM.
      - aprdm 6y ago
        Gotcha, thanks! bad reading from my part
- talkingtab 6y ago
  It was Java. I was intrigued by some of the things with Clojure, especially transducers as described in the post by Rich Hickey https://cognitect.com/blog/2014/8/6/transducers-are-coming https://cognitect.com/blog/2014/8/6/transducers-are-coming.
6y ago

nojito 6y ago

Reverse engineering a Clojure codebase after the devs maintaining it leave is an experience I wouldn't wish on anyone. Because of the difficulties of sharing knowledge, Clojure will have an extremely difficult time growing.

beders 6y ago
A bad codebase is a bad codebase. I can show you quite a few bad Java ones. I just started to work on a quite large Clojure codebase and I had no trouble making meaningful contributions within a couple weeks. Having mostly pure functions makes it especially easy to understand what is going on. I had similar concerns, and this myth is hard to kill - for any dynamically typed language - but the REPL is your secret weapon.

deleted 6y ago

[deleted]

bird_monster 6y ago

> The downside of Clojure is that you need good, wise developers... Is there a language that, for a sufficiently large application, you don't need wise developers? What is it? How?

hangonhn 6y ago
Until recently, I would have said Java because it has so many guard rails and good frameworks. But then I've recently encountered bugs caused by code that basically disabled all those guard rails. Had any one of them been left in place, the bug wouldn't have happened. It's kind of amazing how clever some unwise bad engineers can be. There's just no replacement for good, wise engineers.
- bird_monster 6y ago
  That's interesting. In my experience, Java is one of the easiest languages to turn the best of intentions into actual unusable code. I personally have never seen or heard about a large Java application being easy to work with or having good guard rails. It all kinda just becomes a big mess. I think that Java might have benefited the most from the industry hellbent on making microservices, in that Java applications are less frequently built as gigantic unmaintainable messes, but instead much smaller more easily digestible messes. I am clearly biased against Java, but having worked with it at several jobs I just don't think it's a good idea.
  - deleted 6y ago
    [deleted]
  - The_Colonel 6y ago
    Interesting but I have the opposite experience. Java is weak in small scope and gets stronger with larger applications as it scales quite well in maintainability. In that sense adoption of microservice has hurt Java since you still need to do a lot of Java ceremony, tomcat + spring boot still starts up slow, you can't leverage superior IDEs to refactor interfaces across services etc. For thin microservices I would probably tend to use something like node.js, for traditional monoliths (IMHO still have their place) with a lot of complex logic I would use Java (or Kotlin, C#).

submeta 6y ago

Reading the comments I get the impression that Clojure is competing with Java, and it seems that it cannot win against Java, for various reasons, and I am saddened by that. What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)?

puredanger 6y ago
Clojure was designed to be applicable where Java is applicable. Fortunately that space of programs is enormous and the market is enormous. Clojure does not need to "win" against Java (or anything). It is unlikely (for many reasons that have nothing to do with its value as a language) to ever be more than a fraction as popular as Java, but that's irrelevant. It has a thriving sustainable ecosystem with 10k's of devs in 100's of companies. That is sufficient to call it a success.
simongray 6y ago
> What does it mean to see a rather promising Lisp-like language not getting traction, for the the future of Lisp(s)? I think this sentiment ("Clojure is dying") has kind of become a Hacker News meme at this point. Clojure basically came out of nowhere and pretty much displaced all other Lisps in about a decade. It is definitely not dying, it's just an opinionated, fairly niche language - it's not Go or TypeScript. It solves certain problems well and has some uses where it really shines. It's not a silver bullet, though, and it definitely requires serious learning/unlearning to get really good at it if all you know is the mainstream imperative/OOP style. Clojure works well for those who buy its rationale: https://clojure.org/about/rationale https://clojure.org/about/rationale
- dunefox 6y ago
  How did it displace all other Lisps if a) they're still going string and b) they weren't mainstream in the first place?

nanomonkey 6y ago

It's interesting to see so many people complain that it's hard to hire Clojure engineers, when I've had the exact opposite problem...trying to find a Clojure shop to join. They are few and far between, and the few that are hiring say that they will take folks that are new to Clojure, but then are baffled when you don't know how to idiomatically solve whiteboard problems. Clojure remedies all of my problems with previously used languages (Basic, C, Java, ObjC, Javascript, Python), in that it allows me to remove boilerplate and create layers of abstraction that are appropriate for problem solving. It's also a fairly opinionated language, preferring functional programming methods that work with how I like to solve problems. This is refreshing, as it feels like I can bypass all of the style wars that I encountered with Python., and the verbosity of C/Java/Obj-C. No longer being told to rewrite functional code as an object, by an engineering manager that only ever writes imperative scripts. Lastly I now love writing front end code in Clojurescript...something I never would have expected. Reagent and Re-frame are a dream for large complex SPAs, which while I dislike in principle, seem to be the trend in cross-platform GUIs. And it makes programming fun again!

puredanger 6y ago
Both devs and jobs exist but they are mismatched in terms of geography and experience expectations. I don't think it's specific to Clojure, it's common to any narrow technology. Certainly things have gotten far better over the last 10 years and there are more companies hiring in Clojure more actively now than I've ever seen. Fixing it requires a feedback cycle that takes a long time to grow into an active market. When I first started in Java in 1997, there were few companies doing Java and few devs who knew it and it was much the same. Sun spent like a billion dollars marketing Java to create that ecosystem.
- newcrobuzon 6y ago
  > Sun spent like a billion dollars marketing Java I guess now the question is if Nubank could/will also promote Clojure and to what extent (or if they will support Cognitect enough to do that). I would wonder if they went through that thought process and what RoIs for that are from their perspective. It might even take much lesser investment than equivalent of $1bil from 90s... The Java/JVM market is huge so it might need just a little nudge :) Within the JVM ecosystems it seems that basically Kotlin (as nice as it is) has been stealing some market share that might have belonged to Clojure. And all that just by selling some cheap cut syntax sugar on the corner. There definitely is a huge desire within Java/JVM community to innovate and if approached correctly Clojure could actually shine - there are just few misconceptions and fears that could be put to sleep by some smart marketing strategy. Nubank is great first step in that direction, because it gives an example of a mature large yet innovative company relying on Clojure in production.

dzonga 6y ago

are there people who used both clojure and scala. And decided to use Scala ? if so why ? I'm new to Scala that's why

dyadic 6y ago
There are people that used both including me. But I fell squarely on the Clojure side and haven't written Scala for 7-8 years now.
- dustingetz 6y ago
  Same, 2010-era FP in Scala was a disaster and also very angry, but I'd say in about 1-2 years FP Scala will be about at the maturity that they imagined they were at in 2010. Still kind of angry though.
keithasaurus 6y ago
Yes. In general, I would choose Scala. Better tooling, (pretty good) type system; not without its warts. Main concern I'd see ahead is the 2 -> 3 transition, which has the potential to be as difficult as the Python 2 -> 3 transition. That said, Scala 3 looks nicer to me as a language, with top-level functions, significant whitespace (more concise code), and better ADTs.
eeperson 6y ago
I've used both and end up writing much more Scala. There are a few reasons why this was the case for me: - Scala is much closer to Java making it an easier sell to other Java programmers. - I think static typing makes a lot more sense for larger projects - I found a rich static type system easier to use and more generally applicable than macros.
aweiland 6y ago
I played with both Clojure and Scala, but ended up on Kotlin. I've been very happy there.

jakebasile 6y ago

I've said it before, and I'll say it again. I will continue to write Clojure for a living as long as I am able to find a job willing to pay me to do so. I have never encountered a more pleasant environment to do my work. I think Clojure isn't going to "go away" any time soon as long as there are other people like me still around. I do think that Clojure shops (like all software shops) need to dial back the torture interviews / homework / tests, but that's really a bigger thing that just Clojure. I think more could be done to market Clojure to the non-believers, but I don't have specific ideas on how that could be done. You can take my parentheses from my cold, unemployed hands.

Scarbutt 6y ago
Did Clojure made you unemployed?
- jakebasile 6y ago
  No, I am currently employed. It's a play on the "from my cold, dead hands" phrase. https://en.wikipedia.org/wiki/From_my_cold,_dead_hands https://en.wikipedia.org/wiki/From_my_cold,_dead_hands
bit_logic 6y ago
I'm a bit surprised to hear this, I thought Clojure shops would be better than this. It was must hard to find any candidates and they're still doing the stupid leetcode interview style? Are these companies putting any thought into their hiring process? That process was created by FANG because they can abuse their candidates and still get a lot of applicants (although I think this is less true than it used to be) But to use that same hazing ritual at a smaller company with the hiring funnel further reduced by a niche language? Really stupid.
- deleted 6y ago
  [deleted]
- jakebasile 6y ago
  I agree, but it's definitely still common enough even among Clojure shops. I think it's an insight wide plague but despite so many of us hating it, it persists.

moocowtruck 6y ago

gimme smalltalk or gimme death

pinchhit 6y ago

As a person who has and currently does work professionally in clojure (at multiple all-clojure shops): The smart engineer effect is extremely overblown. You will hire smarter-than-average engineers, but with a caveat that no one talks about: they are all self-selected for being people who enjoy tinkering on computer science problems to a fault, and not necessarily your business. So the breakdown is that you get 10 super-smart people, but 9 of them are focused on myopic bits of code plumbing or reinventing APIs or something, and in practice you only have 1 smart person focused on your business. As the other 9 continue to reinvent wheels, the nature of clojure being small relative to other open-source communities means that eventually your shiny new clojure tools get replaced by better community offerings, except you don't have the bandwidth to switch over and start using them. Overall, velocity would be improved if you had hired 1 super smart engineer and 9 mediocre ones. It's important to note here that while technically clojure can interoperate with java or javascript, in practice everyone expects you to use poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. This effect is 10 times worse for clojurescript in the browser, although it's pretty bad for clojure targeting the JVM as well.

beders 6y ago
> poorly-maintained clojure-ish libraries to paper over the java/javascript bits, which get out of date quickly. Care to elaborate? For example, re-frame, reagent have been stable, reliable libraries for years. In contrast to many JS libraries. JS interop has been virtually unchanged for years. What am I not seeing here?
- Scarbutt 6y ago
  Clojurescript relies on the closure compiler which doesn't play well with the Javascript ecosystem. Too much "busy work" https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compilation.html https://dev.solita.fi/2020/06/25/taming-cljs-advanced-compil...
  - fulafel 6y ago
    The gains from the advanced optimizations mode under discussion there are nice and the setup is known to be a little finicky wrt dependencies. But it's opt in and rarely necessary.

lninyo 6y ago

I think the future of Clojure is not much different from the present of Common Lisp. If you go look at supposedly 'workhorse libraries', work has been abandoned. Some of the projects that Clojure's own page points to haven't seen updates for 6,7, 8 years. Some people who were super active in the community have moved on to other pastures. This is not a good sign. If you look at Clojure problems being solved by beginners on Exercism, you'd see problems categorized as "easy", but to solve them idiomatically, you need to know quite a bit of the language and its library ecosystem. The problems that do get solved, are mostly not idiomatic and most people are just trying to write C/JS/Java in Clojure (maybe because they want to appear to be 'wise' because you know, once you can conj two vectors together, your poopoo basically doesn't smell anymore.) This indicates a major disconnect between what "experienced" Clojure dev's think is "easy" for beginners to solve and what actually might be easy given the nature of a language. If you can't solve the problem idiotmatically without knowing obscure functions in the clojure core, and also of ways to apply those functions just in the right way (the functional part) you shouldn't categorize them as 'easy' but they do, which is odd and counter productive, yet there they are. So a lot of genuinely curious people abandon learning clojure simply because the learning curve is a lot like the "emacs learning curve" in one of those XKCD pieces. Rich Hickey joining Cognitect was beginning of the end IMO. It's like Chuck Moore and his lady friend starting up Forth Inc. I hate to say it but I see Clojure going the way of Forth. It will increasingly become niche and it will eke out its days just like other niche languages tend to do. It has already begun to do so. Hickey is super smart, and this language is for him and super smart people like him for problem domains he operates in, not for mere mortals. You can't have long term viability when you're not attracting new people, and most new people come into a language by way of wanting to do simple stuff like webdev. Clojure/Script ecosystem just doesn't offer that (despite the claims). If it did, you'd see people leaving JS frameworks and going to Clojure/Cljs in large numbers but they just aren't and the ship has sailed on that because the time to do that was around 2012-2015 . Python has won the AI glue wars, and JS has won the web war. This is brushed aside as "well they're mostly stupid people anyway and who needs them in this refined atmosphere of clojure zen that WE all have?" Thoughtworks made a lot of hay during the RoR sunshine in the mid 2000's onwards, and they did the same with Clojure starting around 2012. One or two successful companies does not an expanding eco system make. And they and even cognitect to some extent are more in maintenance phase rather than expansion phases. Clojure programmers (some) may be commanding six figure salaries, but you can do the same if you're any good at COBOL, and believe me, there are a lot more COBOL jobs out there right now than there are Clojure jobs. As of this writing, Thoughtworks' career page has 14 openings for ReactJS, 5 for Java and ZERO for Clojure. That should tell you something about the future of Clojure. I do not write these things as a 'hater.'

pacomerh 6y ago

kind of a side note but, why don't professional engineers and podcasters in general use better mics when recording podcasts? You can hear they're just using the mic from the laptop, sometimes it sounds like they're talking from their bathroom. Not only does it sound bad, If you're listening this in a room that already ads acoustic this is twice the reverb, which is pretty bad.

coltnz 6y ago

This was a little bit disappointing for me to be honest, as someone who loves the language and runs Clojure teams. Obviously not aimed at the hardcore Clojure crowd but still I hoped for more on the actual future. There was a mention of more resources with no specifics and reassuring comments on things not fundamentally changing as before [as in earlier announcements]. Things I'd ask: - What are the new resources (for Clojure? or just Datomic?), how are they being used? Does Nubank have opinions / direction on these resources. - Has an open sourced Datomic been discussed? It wouldn't seem to be strategic for Nubank and could be a big boost to the Clojure ecosystem. I'd read every line.. - Who owns the Clojure trademarks and IP going forward. Any talk of a Clojure Foundation? - Alex Miller does an awesome job but boy he has a lot to cover. It suits Rich to have a small team of trustees for core (though boy its got small) but the community stuff could surely be advanced quicker. Old tickets in contrib and key libs etc.. - There was talk a few years ago of facilitating community involvement with a PEP type process, https://www.python.org/dev/peps/pep-0001/ https://www.python.org/dev/peps/pep-0001/? Any further thoughts? - Clojurescript has left Core. Is Nubank likely to want to get involved here? I have no right to these answers, some may be commercially sensitive and of course Clojure doesn't belong to me. However there is no harm in asking when answers to the questions are important to me in my future uses of Clojure. Indeed I think it would be superior - in terms of Clojure's continued acceptance into industry - to know more of it's future direction than has traditionally been the case. Hopefully Nubank provides the confidence needed for this to happen.

puredanger 6y ago
Lots of good questions here. https://building.nubank.com.br/welcoming-cognitect-nubank/ https://building.nubank.com.br/welcoming-cognitect-nubank/ from Ed Wible, CTO at Nubank is a good read that answers many of them btw. Also see https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank https://cognitect.com/blog/2020/07/23/Cognitect-Joins-Nubank. > What are the new resources (for Clojure? or just Datomic?), how are they being used? Does Nubank have opinions / direction on these resources. Since Cognitect joined Nubank, several people have joined the Datomic team, both new hires and internal moves from Nubank and the rate of development has increased. We are also looking at expanding the Clojure team in the near future. > Has an open sourced Datomic been discussed? No changes planned. > Who owns the Clojure trademarks and IP going forward. Any talk of a Clojure Foundation? Clojure was and is an independent project and Rich Hickey is a joint owner (along with contributors) to the Clojure copyrights. From Rich's announcement on the Clojure mailing list: "Clojure remains independent, and development and stewardship will continue as it has, with more resources and a much larger sponsoring organization in Nubank." > Alex Miller does an awesome job but boy he has a lot to cover. Thanks and indeed! As above, we are likely to expand the Clojure team in the future. > There was talk a few years ago of facilitating community involvement with a PEP type process We created https://ask.clojure.org https://ask.clojure.org as a way for Clojure users to discuss problems important for them and to allow voting on those problems for their importance. We use that information to inform decisions about what to work on so I encourage all Clojure users to express their needs there! > Clojurescript has left Core. Is Nubank likely to want to get involved here? Cognitect was, and Nubank now is, the primary sponsor for ClojureScript (funding both David Nolen and Mike Fikes).

f2000 6y ago

Clojure. I wanted to love you. But at the end of the day types matter (to me at least) and spec just feels like an afterthought.

titanix88 6y ago

Clojure is a great language for small creative teams to achieve great(relatively) things. It's difficult to understand that from a startup mindset of hacker news where money is no problem and peace of mind is an after thought. If you are a budget constrained individual living in a third world country with nothing to invest but your intellect and time, Clojure is a very good language. It lets you to - 1. Create relatively large systems without pulling your hair out. 2. Juggle between different projects with relative ease. Great for managing a projects in maintenance mode. Great for contractors with long term support contracts. 3. Realize your vision of a complete product with relatively low time and money. Overall, it's a way of doing effective programming. It's probably not a good way of making money if the focus is to siphon investor money with a large team and millions of lines to show for.

zrkrlc 6y ago
How did you get started in Clojure contracting work?

geospeck 6y ago

One thing that I would like to mention as a Clojure newbie is the community. I am super impressed by how much friendly they are. I mainly use /r/clojure on Reddit and the Clojurians on Slack.

amw-zero 6y ago

I love writing Clojure, I just can’t live without static types.