Bringing Clojure programming to Enterprise (2021)(blogit.michelin.io)
blogit.michelin.io
Bringing Clojure programming to Enterprise (2021)
https://blogit.michelin.io/clojure-programming/
92 comments
Never heard a lang-feature describe as "calming" but now that I think about it, you are very much right :D
Several Clojure/Datomic design decisions are directly inspired by RDF.
They are also interned such that there is only one keyword by that name. It is created atomically. You can use it to create synchronized blocks in the rare case you would have to
> But one of the unsung heroes of Clojure is the namespaced keyword:
Sounds intriguing, can you say more?
Sounds intriguing, can you say more?
I'll do my best but there might be better explanations around the web.
I think an illustrative example would be this repo:
https://github.com/cognitect-labs/anomalies
These are basically re-usable, namespaced keywords. You might decide to use them or something similar in your program/system and some people do. Pretty neat: Their semantics are documented in the readme and the little bit of code in the repo defines a spec here https://github.com/cognitect-labs/anomalies/blob/master/src/....
You can read it as: any map that has these keywords as defined in the spec is an "anomaly".
Specs are open, non-exclusive so you can add more stuff to your structure and they still conform. (Note that the double colon before the keywords just mean "the current namespace defined at the top".)
Note that you don't need to define a spec for namespaced keywords. It's just a utility that leverages them. By themselves they already say "I can be used in a global context".
---
These keywords can be used from anywhere and by themselves. You don't need to carry around their context for them to work or have meaning. To contrast: for example a JSON field in a nested context might only make sense in that specific nesting context. Clojure namespaces are by convention globally unique.
Some examples:
- `:my.domain.accounting/refnumber`
- `:my.domain.ui/color` defined as `(or :my.domain.ui/rgb :my.domain.ui/hsl)` etc.
- `:my.domain.person/name` defined as a string if at all
- `:my.domain.event/type`
I think an illustrative example would be this repo:
https://github.com/cognitect-labs/anomalies
These are basically re-usable, namespaced keywords. You might decide to use them or something similar in your program/system and some people do. Pretty neat: Their semantics are documented in the readme and the little bit of code in the repo defines a spec here https://github.com/cognitect-labs/anomalies/blob/master/src/....
You can read it as: any map that has these keywords as defined in the spec is an "anomaly".
Specs are open, non-exclusive so you can add more stuff to your structure and they still conform. (Note that the double colon before the keywords just mean "the current namespace defined at the top".)
Note that you don't need to define a spec for namespaced keywords. It's just a utility that leverages them. By themselves they already say "I can be used in a global context".
---
These keywords can be used from anywhere and by themselves. You don't need to carry around their context for them to work or have meaning. To contrast: for example a JSON field in a nested context might only make sense in that specific nesting context. Clojure namespaces are by convention globally unique.
Some examples:
- `:my.domain.accounting/refnumber`
- `:my.domain.ui/color` defined as `(or :my.domain.ui/rgb :my.domain.ui/hsl)` etc.
- `:my.domain.person/name` defined as a string if at all
- `:my.domain.event/type`
Thanks!
Very interesting, as something along these lines is a direction I've been meaning to extend Polymorphic Identifiers, both to have partial trailing paths and also to have bundles of paths that can be treated a bit like a data structure, but without actually being one.
Very interesting, as something along these lines is a direction I've been meaning to extend Polymorphic Identifiers, both to have partial trailing paths and also to have bundles of paths that can be treated a bit like a data structure, but without actually being one.
Informative, no-nonsense account. Would be cool to have more such contributions from 'non-tech' industries as a counterbalance to the drama and hyperbole and hidden agendas of the usual suspects
I’m sure this is a recruitment effort at the heart of it. It’s good though - working with thoughtful Clojure devs is quite appealing :)
Tyre manufacturing very much is not “non-tech”…
I suspect they mean from use cases that aren't so centered around software for its own sake. Use cases where the rubber meets the road, as it were.
Yep, "tech" and "engineer" regularly used (also on HN) to mean software/information technology and programmer/developer respectively.
Not very accurate use at all, the whole sector has actually more a social science than a hard sciences bend. Information is a very culturally defined concept and the silicon tech and the true white coat engineers designing and making chips a very small fraction of what happens (or gets discussed).
This is probably title inflation that makes people feel better. The same dynamic that created "Data Science" to mean data cleaning, and AI to mean statistical fitting. But in Rome like the Romans :-)
Not very accurate use at all, the whole sector has actually more a social science than a hard sciences bend. Information is a very culturally defined concept and the silicon tech and the true white coat engineers designing and making chips a very small fraction of what happens (or gets discussed).
This is probably title inflation that makes people feel better. The same dynamic that created "Data Science" to mean data cleaning, and AI to mean statistical fitting. But in Rome like the Romans :-)
Joke aside, yeah, hearing about interesting tech being used outside of breathless, infinitely scalable, VC funded tech bubble companies is usually quite compelling
Like your namesake for instance :-)
I started a company that deals primarily with "cyber-physical systems" use cases in-part because I ceased to find anything remotely resembling "software for its own sake" to be compelling anymore (in an existential sense).
Also, if you do happen to work in solar farm tech, I'd love to chat. [email protected]
I started a company that deals primarily with "cyber-physical systems" use cases in-part because I ceased to find anything remotely resembling "software for its own sake" to be compelling anymore (in an existential sense).
Also, if you do happen to work in solar farm tech, I'd love to chat. [email protected]
I don't think he means that literally zero technology is used in tire manufacturing. What he's saying is that it's interesting to see these languages and concepts applied to old economy industries, which tire manufacturing certainly is.
Makes total sense once you learn that parentheses are all little tyre cutouts bouncing around.
The bibemdum himself should be clojure's mascot !
There is nothing specific to tyre manufacturing in this article. The original title was more informative: "Bringing Clojure programming to Enterprise"
It's really nice to see Clojure being adopted more and more by large companies, showing big results not only for statups. Clojure has been designed with this in mind, to let the old Lisp mindset behind.
The same author also publish a introductory article about datalog. Check it out!
The same author also publish a introductory article about datalog. Check it out!
>This use-case has been achieved using a single Clojure variable.
Can you expand more on how the business rules are executed with the variable ? Maybe a simple example ? Clojure-newbie looking to learn more :)
Can you expand more on how the business rules are executed with the variable ? Maybe a simple example ? Clojure-newbie looking to learn more :)
Eventually you want non-developers to develop business rules, so you come up with pseude-code like
However, effectively clojure itself is most often the smallest representation:
In the end it's like a code snippet that non-developers can write without having to set up a compiler, run-time, syntax-checker
when X then do Y
[:rule [:when X] [:then Y]]
[:rule [:when [:< amount 100]] [:then [:send-email-to-boss]]]
However, effectively clojure itself is most often the smallest representation:
(when (< amount 100) (send-email-to-boss))
In the end it's like a code snippet that non-developers can write without having to set up a compiler, run-time, syntax-checker
from my experience im very sceptical each time when someone says that business people will write these rules. on paper it looks nice but at the end if rule is a bit more complicated developers end up writing or updating the rule while someone standing behind their back :)
I’ve seen business people write rules in excel. A. lightweight dsl with a quick feedback loop (provided by a REPL in Clojure, and the UI of excel) seems to be key features to avoid ending up in the scenario you describe
[deleted]
I wonder if Groovy doesn't allow one to produce a more user-friendly DSL, whilst retaining the benefits of integration with the java ecosystem? No strong personal opinion here, but have been coincidentally reading up on Groovy and mentally retrofitting to DSL I did in Ruby a while back.
I haven't really looked at clojure since 2015? maybe. Nice to see that it's still around. I've never worked with a LISP in a professional setting, but like Haskell it's fun to play around with once and a while.
(2021)
Looks like they were still using it in December last year.
https://blogit.michelin.io/an-introduction-to-datalog/
https://blogit.michelin.io/an-introduction-to-datalog/
How well would Clojure fit into a Spring Boot centric environment?
Actually ... it works. I'm calling Clojure from Kotlin in Spring Boot and it integrated very nicely.
You have to export the code to make it callable, and I had to write some adapters on the Kotlin end. But very doable for integrating if you need to.
This code is quite specific, but you get the idea. Export symbols:
https://gitlab.com/crossref/rest_api/-/blob/main/src/cayenne...
Convert Clojure structures to Kotlin classes:
https://gitlab.com/crossref/manifold/-/blob/main/src/main/ko...
You have to export the code to make it callable, and I had to write some adapters on the Kotlin end. But very doable for integrating if you need to.
This code is quite specific, but you get the idea. Export symbols:
https://gitlab.com/crossref/rest_api/-/blob/main/src/cayenne...
Convert Clojure structures to Kotlin classes:
https://gitlab.com/crossref/manifold/-/blob/main/src/main/ko...
You can call into Clojure code from that code and vice versa, if you want to start that way. But best to first dev and test the code separately so you can use the normal Clojure dev workflows. Or I guess you can start a nrepl from your Clojure code and do live dev in that scenario, maybe someone has done it and can report?
Mostly, people using Clojure want. to get away from Java.
Mostly, people using Clojure want. to get away from Java.
> Mostly, people using Clojure want. to get away from Java.
I understand that, but Spring Boot already offers support for Koltin (yikes) and Groovy (double-yikes). Would supporting Clojure templates that use the underlying Java classes be difficult or cumbersome? Would it yield Clojure code that's not idiomatic?
I don't mind the underlying tooling that much, but I'd love to be able to use a more elegant language for the business logic.
I understand that, but Spring Boot already offers support for Koltin (yikes) and Groovy (double-yikes). Would supporting Clojure templates that use the underlying Java classes be difficult or cumbersome? Would it yield Clojure code that's not idiomatic?
I don't mind the underlying tooling that much, but I'd love to be able to use a more elegant language for the business logic.
I don't have the experience in Java or Spring to say, sounds like it could possibly be interesting to try building as a path to Clojure.
It'll work fine, but you won't be able to gain much benefit from it. Spring Boot systems are flaky and incomprehensible because of Spring Boot, adding another language can't help with that.
Clojure can fit quite well into Spring Boot-centric environments!
I've added Clojure to several legacy Spring Boot apps, and the fact that it can be introduced as "just a library" made that portion a snap. If you're not trying to access resources related to Spring Boot's dependency injection, it's pretty straightforward to call into Clojure from Java. If you _do_ want access to DI resources, there's a small amount of code required to wire things up, though it took me a while to find out what that code was, mostly because it requires access to portions of Spring Boot that are not typically user-facing.
Since I had hooked Clojure up to the Spring apps, I also set things up so I could SSH onto application servers, then get a REPL via a socket server into the applications themselves. Being able to check and sometimes change the state of the application live at runtime was like a superpower. This proved extremely valuable, often for debugging errors in the Java portions of the code, but also for situations like final design tweaks live with a client in a development environment. Client asks to bump a font size or change a color or adjust a border or change some copy, then I make the change in my editor, send it over the socket REPL, tell the client to refresh, and repeat. When done, I would simply save, commit, and would be confident that it's what the client was after. The only downside is that I'm no longer at a shop that uses Clojure, and feedback loops for production debugging or letting clients see their decisions are measured in days or weeks when possible at all, not seconds or minutes.
I will admit that connecting to a running application is dangerous, but so is what many surgeons do, and we are certainly not going to ask them to turn in their scalpels. By being conscious of the "great power; great responsibility" bit, I was able to come out mishap-free.
On the other hand, when I had to create new projects where I thought Clojure would be a good fit, I just went all-in with the Clojure ecosystem rather than start with Spring Boot and add Clojure, and I found going all-in with Clojure to be incredibly productive. With that being said, I made the decisions with a decent understanding of both Spring Boot and Clojure, so my experience would likely vary from that of someone who is experienced with Spring Boot and knows nothing of Clojure.
I've added Clojure to several legacy Spring Boot apps, and the fact that it can be introduced as "just a library" made that portion a snap. If you're not trying to access resources related to Spring Boot's dependency injection, it's pretty straightforward to call into Clojure from Java. If you _do_ want access to DI resources, there's a small amount of code required to wire things up, though it took me a while to find out what that code was, mostly because it requires access to portions of Spring Boot that are not typically user-facing.
Since I had hooked Clojure up to the Spring apps, I also set things up so I could SSH onto application servers, then get a REPL via a socket server into the applications themselves. Being able to check and sometimes change the state of the application live at runtime was like a superpower. This proved extremely valuable, often for debugging errors in the Java portions of the code, but also for situations like final design tweaks live with a client in a development environment. Client asks to bump a font size or change a color or adjust a border or change some copy, then I make the change in my editor, send it over the socket REPL, tell the client to refresh, and repeat. When done, I would simply save, commit, and would be confident that it's what the client was after. The only downside is that I'm no longer at a shop that uses Clojure, and feedback loops for production debugging or letting clients see their decisions are measured in days or weeks when possible at all, not seconds or minutes.
I will admit that connecting to a running application is dangerous, but so is what many surgeons do, and we are certainly not going to ask them to turn in their scalpels. By being conscious of the "great power; great responsibility" bit, I was able to come out mishap-free.
On the other hand, when I had to create new projects where I thought Clojure would be a good fit, I just went all-in with the Clojure ecosystem rather than start with Spring Boot and add Clojure, and I found going all-in with Clojure to be incredibly productive. With that being said, I made the decisions with a decent understanding of both Spring Boot and Clojure, so my experience would likely vary from that of someone who is experienced with Spring Boot and knows nothing of Clojure.
Clojure w/ Spring Boot? No.
It would do fine as part of a microservices architecture where some of the other services are Java/Spring. I've done exactly that in fact - wrote a few Clojure services to rip through and ingest some data as part of a system where we had Java/Spring and Python services mixed in.
If you're looking for a Java alternative in a "Spring Boot" shop, Kotlin has excellent Spring support and is definitely more pleasant to use than Java.
It would do fine as part of a microservices architecture where some of the other services are Java/Spring. I've done exactly that in fact - wrote a few Clojure services to rip through and ingest some data as part of a system where we had Java/Spring and Python services mixed in.
If you're looking for a Java alternative in a "Spring Boot" shop, Kotlin has excellent Spring support and is definitely more pleasant to use than Java.
clojure can be used to create a library/jar which could be called from a java app: https://stackoverflow.com/questions/2181774/calling-clojure-...
[deleted]
[deleted]
I don't use Clojure and I probably never will, but I love seeing the way it's been kind of a jailbreak moment for Java programmers trapped in enterprise practices. It was laser-focused to give specifically those people access to a whole lot of highly-productive and pleasant language features, wrapped up in a package that enterprise management could be amenable to. It seems like it succeeded in liberating a bunch of people at their real jobs, which is cool to see
You just described the last decade of my career more succinctly than I could.
Only extension being I applied the momentum boost to bootstrapping a startup and escaped the enterprise world entirely (other than sales back to that world).
Good times, lots of programming. A++ would buy again.
Only extension being I applied the momentum boost to bootstrapping a startup and escaped the enterprise world entirely (other than sales back to that world).
Good times, lots of programming. A++ would buy again.
I've had a couple of jobs doing Clojure full-time, the problem is that Java jobs pay better.
There's good reason to doubt that claim.
https://survey.stackoverflow.co/2022/#section-top-paying-tec...
https://survey.stackoverflow.co/2022/#section-top-paying-tec...
Usual response to that is that there's a skew in Clojure related data as its community consists of mostly experienced devs.
I know it's anecdotal evidence but I'm doing Java right now because I couldn't find a Clojure job that pays nearly the same (and I already used Clojure for 5 years in production environment).
I know it's anecdotal evidence but I'm doing Java right now because I couldn't find a Clojure job that pays nearly the same (and I already used Clojure for 5 years in production environment).
I think there are lots of problems with relying on this. As others have pointed out it could mean that Clojure devs skew more senior. An other issue with these surveys is that this factoid from Stack Overflow is a highly celebrated and oft-reposted part of the Clojure cultural canon and so Clojure developers may be motivated to fill out the survey more than others, especially if they have high income, and may even be tempted to exaggerate their income. For me, all of this is moot. In my country of Canada, there are currently 34 job postings on LinkedIn which even mention Clojure and among those, almost all of them just mention Clojure in passing, such as "nice to have: a functional language like Scala, Clojure or Haskell". Maybe among these 34 postings like 4 are actual jobs looking for people to write Clojure. For comparison, there are about 37,000 postings mentioning Python. With a ratio of more than 1000 to 1, it is impossible to argue that knowing Clojure will be more beneficial for a developer's career than Python, for instance.
Lol, love how high Crystal is on that list. You can get Crystal jobs now?
Once you get experienced enough, you can include a "only program in X" and still get hired :)
Same experience here. And the irony is many of these clj jobs are from understaffed startups. So basically you end up doing like 3 men's job for 80% pay of a normal java dev. And I'm not counting cljs, most likely you'll deal with cljs as so called 'fullstack' engineer and doing like 4 men's job with one salary. Clojure is fun to program, but as a day job, that really depends..
> I've had a couple of jobs doing Clojure full-time, the problem is that Java jobs pay better.
That sounded to me as if someone said: "I had gigs working as a crane operator, the problem is that working as a bricklayer pays better..."
Not only your statement is wrong, typically Clojure devs get paid more, but you're also missing the fact that these aren't comparable trades, on many facets.
That sounded to me as if someone said: "I had gigs working as a crane operator, the problem is that working as a bricklayer pays better..."
Not only your statement is wrong, typically Clojure devs get paid more, but you're also missing the fact that these aren't comparable trades, on many facets.
> It was laser-focused to give specifically those people access to a whole lot of highly-productive and pleasant language features, wrapped up in a package that enterprise management could be amenable to.
On the contrary, Clojure was not focused on satisfying business managers, but on satisfying programmers. It's a good thing that it
also
suits business managament, but that's not its purpose.
On the contrary, Clojure was not focused on satisfying business managers, but on satisfying programmers. It's a good thing that it
also
suits business managament, but that's not its purpose.
It was designed to be a practical insert into existing Java codebases and orgs. If it hadn't been, it wouldn't have gained the adoption that it has.
Can you back that up? Clojure was sold by Rich Hickey as an alternative to Java which he hated working with for more than a decade. If some companies managed to integrate it as you suggest fine but that was not what it was designed to be.
Here's a relevant excerpt about the cultural roots, from the recent Clojure Turns 15 panel: https://youtu.be/exSRG-iL74Q?t=191
But most shops using Java would be resistant to adopting a whole new language, especially an audacious lispy language.
So Clojure worked really hard on having good interop support for Java, which meant you could adopt it incrementally into an existing JVM codebase; you don't have to do a ground-up rewrite (scary to cost-cutting stakeholders)
It also meant they didn't have to bootstrap a fresh, immature library ecosystem from scratch (also scary to stakeholders)
They took a very practical approach that acknowledged the existing landscape and introduced idealism into it, instead of trying to create a whole new, blessed island that nobody would ever visit outside of hobby projects. Which is the same thing other successful new languages have done- Kotlin (also with Java), Rust (with C/C++), Zig (with C), TypeScript (with JavaScript).
I'm not sure further reference is needed, it just feels really obvious that this was the strategy. Of course Clojure can and has grown beyond just that use-case, but you need to get a foothold first.
But most shops using Java would be resistant to adopting a whole new language, especially an audacious lispy language.
So Clojure worked really hard on having good interop support for Java, which meant you could adopt it incrementally into an existing JVM codebase; you don't have to do a ground-up rewrite (scary to cost-cutting stakeholders)
It also meant they didn't have to bootstrap a fresh, immature library ecosystem from scratch (also scary to stakeholders)
They took a very practical approach that acknowledged the existing landscape and introduced idealism into it, instead of trying to create a whole new, blessed island that nobody would ever visit outside of hobby projects. Which is the same thing other successful new languages have done- Kotlin (also with Java), Rust (with C/C++), Zig (with C), TypeScript (with JavaScript).
I'm not sure further reference is needed, it just feels really obvious that this was the strategy. Of course Clojure can and has grown beyond just that use-case, but you need to get a foothold first.
[deleted]
I’m noticing a lot of clojure posts recently. Has the language become more popular lately? Is there any reason behind it?
Not sure on relative popularity. If you haven't already, you should try it! Here's why I like it:
- Very consistent, easy to keep the whole language in your head
- Stable, core rarely changes ("accretive only" mindset).
- REPL
- Focus on a handful of data structures which will solve 95% of the problems you face, rather than a deluge of complicated abstractions.
- Excellent concurrency primitives
- Access to Java libraries if a Clojure equivalent doesn't exist
- Macros
Very accurate ! and x1000 about the error message !
>easy to keep the whole language in your head
Is that not all programming languages. Practically have identical syntax for the problem they are solving. The thing which differs is “standard” libraries, which is not part of the language but a side effect of.
Is that not all programming languages. Practically have identical syntax for the problem they are solving. The thing which differs is “standard” libraries, which is not part of the language but a side effect of.
Python:
- functions
- classes
- list comprehensions
- generators
- inheritance
- operators
- string interpolation (a handful of syntaxes)
- module system hard to wrap your head around
- async (I think async is a workaround for getting more done with one thread because of the GIL). Pointless on machines with increasing number of cores. Just get multithreading right (and I want to learn Clojure's model - focusing on immutability) and you will not need async. Python can barely share memory across threads. I'm not sure you can get by without serialization.
- functions
- classes
- list comprehensions
- generators
- inheritance
- operators
- string interpolation (a handful of syntaxes)
- module system hard to wrap your head around
- async (I think async is a workaround for getting more done with one thread because of the GIL). Pointless on machines with increasing number of cores. Just get multithreading right (and I want to learn Clojure's model - focusing on immutability) and you will not need async. Python can barely share memory across threads. I'm not sure you can get by without serialization.
- dozens of built-in functions/reserved words
My head didn't have enough space to keep C++ in it. Clojure is on the different end of the spectrum
My last job was mostly C++, my current job is mostly Clojure but I still do a lot of C++ stuff on the side as it is appropriate for some of my side projects.
Clojure is so much nicer to work with and this really resonates with me; I'm always still having to check language docs for C++ stuff but only very rarely for Clojure. Being able to keep almost all of it in my head is a huge benefit as I don't have to break my "flow" nearly as much.
Clojure is so much nicer to work with and this really resonates with me; I'm always still having to check language docs for C++ stuff but only very rarely for Clojure. Being able to keep almost all of it in my head is a huge benefit as I don't have to break my "flow" nearly as much.
Python, Java, JavaScript, R are all insanely complicated compared to clojure.
It was the 15 year anniversary recently.
But I think it's just general hackernews language waves. Someone posts something, it does well, other people get interested, find things post them and onwards.
But I think it's just general hackernews language waves. Someone posts something, it does well, other people get interested, find things post them and onwards.
My take is that more and more people are "rediscovering LISP" or are at least open to the idea of learning about them, and Clojure (this is going to wipe out my karma points) is a very good place to start your LISP-like journey.
When I started learning LISP+Clojure (yea ok purist Clojure might not be a perfect LISP or deserving of the name). There were a lot more Clojure tutorials and help out there than there was for CL (Common Lisp).
I usually start my new language journey by watching lots of Youtube tutorials, it gives you a broad-overview of landscape, before I dig into the code.
The other opinion why it's getting trendy again might be that, "the modern coding landscape" is not much "fun":S
Learning JavaScript(the modern guide), js-frameworks, Rust (yea it's good, but not fun).
Clojure is really fun :) Once you are used to an "interactive workflow" like evaluating and testing a function right then and there it's hard to go back to coding function in a file and running the whole program to test.
And I've said it in a few comments yesterday as well, anyone starting out with Clojure just tell yourself "It's Maps All The Way Down".
When I started learning LISP+Clojure (yea ok purist Clojure might not be a perfect LISP or deserving of the name). There were a lot more Clojure tutorials and help out there than there was for CL (Common Lisp).
I usually start my new language journey by watching lots of Youtube tutorials, it gives you a broad-overview of landscape, before I dig into the code.
The other opinion why it's getting trendy again might be that, "the modern coding landscape" is not much "fun":S
Learning JavaScript(the modern guide), js-frameworks, Rust (yea it's good, but not fun).
Clojure is really fun :) Once you are used to an "interactive workflow" like evaluating and testing a function right then and there it's hard to go back to coding function in a file and running the whole program to test.
And I've said it in a few comments yesterday as well, anyone starting out with Clojure just tell yourself "It's Maps All The Way Down".
I would be _very_ surprised if it had. The limited observations I have suggest a very stable community. Not growing, not shrinking.
> Not growing, not shrinking.
HN commenters love using anecdata. So please allow me to use one and speculate on this phenomenon. So we have a product. Three devs wrote the initial prototype. Then over time, they hired five more. For three years we've organically grown our codebase, adding more and more integrations. The business expanded and grew enormously. We had to deal with a lot of pain, trying to grapple with enormous amounts of data and constantly changing requirements. In addition to tons of back-end services, we also had to build three different web apps. The company had to hire two additional PMs and two more designers. But we've managed to hold the fort with the small team as we were. Occasionally, the question about hiring more devs would come up, and we interviewed people. A person one day left (for some fabulous offer) and we had to quickly hire a replacement. I no longer work there and they hired only two more after I left.
I mean, I can keep going with the story, but I think you get the gist of it. Clojure allows building enormously big operations with a handful of developers. I just can't imagine building and maintaining all that in other stacks. And as it turns out, even when we needed to add new product features, we didn't have to hire a new team for that. And the business was not restricted by the pace of our development. We continued adding new features and kept supporting the existing ones.
This is a very subjective example case, of course. But it makes me want to ask: if we didn't have to hire more developers, and I don't think I ever heard of any company massively trying to expand their Clojure teams, how would then Clojure grow? Is creating new Clojure-based startups the only answer?
HN commenters love using anecdata. So please allow me to use one and speculate on this phenomenon. So we have a product. Three devs wrote the initial prototype. Then over time, they hired five more. For three years we've organically grown our codebase, adding more and more integrations. The business expanded and grew enormously. We had to deal with a lot of pain, trying to grapple with enormous amounts of data and constantly changing requirements. In addition to tons of back-end services, we also had to build three different web apps. The company had to hire two additional PMs and two more designers. But we've managed to hold the fort with the small team as we were. Occasionally, the question about hiring more devs would come up, and we interviewed people. A person one day left (for some fabulous offer) and we had to quickly hire a replacement. I no longer work there and they hired only two more after I left.
I mean, I can keep going with the story, but I think you get the gist of it. Clojure allows building enormously big operations with a handful of developers. I just can't imagine building and maintaining all that in other stacks. And as it turns out, even when we needed to add new product features, we didn't have to hire a new team for that. And the business was not restricted by the pace of our development. We continued adding new features and kept supporting the existing ones.
This is a very subjective example case, of course. But it makes me want to ask: if we didn't have to hire more developers, and I don't think I ever heard of any company massively trying to expand their Clojure teams, how would then Clojure grow? Is creating new Clojure-based startups the only answer?
It's been growing ever so slightly all this time if Maven downloads are to be believed, but it has also been on a downward trend in the hype cycle for the past few years ever since Rich Hickey stepped back from the limelight.
[deleted]
A reason other than it being awesome?
[deleted]
I’ll note this article could have been written ten years ago without changing a word. If you’ve already made your mind up about Clojure, there’s very little going on that’s going to move that needle.
Time and staying power actually are actually prime movers of the needle. Ten years ago it was a 5 year old language, hadn't seen the 15 years of dev community evolution, ClojureScript was just out of the oven and relatively unproven, and unlike then Clojure now seems to clearly pull ahead in mindshare over Scala, etc.
Clojure ahead of Scala? In which universe? Go to any jobs site such as Indeed.com and you'll find Scala jobs outnumber Clojure by about 10 to 1.
A couple of unscientific measures of Clojure vs Scala:
- First couple of screenfuls worth of HN Algolia search stories by date covers 7 months of scala, vs 3 months of Cloure stories - score 1 for cloure
- on Lobsters, 2 pages of Clojure is 9 months, for Scala 3 years - score 1 for clojure
- in StackOverflow dev survey, Scala respondent count is ~50% higher than Clojure (~1800 vs ~1200) - though Clojure is "loved" significantly more. Score 1 for Scala.
I'll admit it seems more of a draw than I thought and you could reasonably weight the SO case a bit more than the first 2...
- First couple of screenfuls worth of HN Algolia search stories by date covers 7 months of scala, vs 3 months of Cloure stories - score 1 for cloure
- on Lobsters, 2 pages of Clojure is 9 months, for Scala 3 years - score 1 for clojure
- in StackOverflow dev survey, Scala respondent count is ~50% higher than Clojure (~1800 vs ~1200) - though Clojure is "loved" significantly more. Score 1 for Scala.
I'll admit it seems more of a draw than I thought and you could reasonably weight the SO case a bit more than the first 2...
I spoke at a Clojure conf a bunch of years ago, I remember thinking “Wow this is a big room.” But afterwards I got talking to an event organiser about what they had to do for the Scala version of the same event…
I remember going to monthly "Hack The Tower" Clojure and Scala events at one of the big London financial institutions back in 2014. Both were hot languages but you could see by the presence of recruiters that employers were only interested in Scala.
malli, specter, and calva are all less than ten years old. Clojure has seen a lot of progress in tooling and libraries.
And now you get Clojure Babashka scripts too, which starts in milliseconds (thanks to Babashka being compiled using GraalVM).
So with Clojure you get ClojureScript and "shell" scripts too now!
So with Clojure you get ClojureScript and "shell" scripts too now!
I just recently started using Babashka and it is great, excellent productivity boost for text manipulation scripting tasks.
[deleted]
I actually quitted a job in 2017 because I was so hyped around my discovery of clojure in 2016 and wanted to write some piece of code that was gonna parse some JS code and spit out some other JS code. (I quitted cuz I never got the project done and my manager was like hey man it's been 5 months do you have any updates and I'm like hey I've been rewriting the same thing over and over again while hopping between 5 different editors and 3 different build tools and to be honest all I've done is learning emacs for the past month).
I don't know if things have improved but back then everything felt either a WIP or obsolete. You wanna use lein to build but apparently that's ancient and you really should be using this other build tool that's not fully integrated with any editor other than emacs and hey while you are at it the Clojure team has released their own dependency management tool and you really should be using that instead. By the way who uses intellij when there is VS Code?
Clojure boasts about it's strong Java interop and ability to use the existing Java ecosystem but it has one of the worst intellij integrations, using a 3rd party plugin that is either broken or not working with your build tooling.
Oh did you say you wanna use Gradle or Maven to build your Clojure stuff? You could actually do it, funny guy.
The language is probably the most practical lisp out there, but it also brings all the artificial lisp superiority syndrome with it (and forces you into submitting the rest of your life to emacs in praise of lisp culture).
You think you'll pick it up quickly and be productive but juggling between learning all the build tooling, the language itself, editing lisp and integrating all those 1-man libraries that are scattered all over github, you end up losing weeks if not months on fixing boilerplate.
I would give it another go but now that I think about debugging a Clojure app in runtime and making sense of a reflection-based, dynamic language on top of JVM, I'm like naaah I already have enough stress-induced grey hairs...
Haskell gives me the pure functional kick that I want, and the rest I can deal with in Kotlin or even Java 11.
I don't know if things have improved but back then everything felt either a WIP or obsolete. You wanna use lein to build but apparently that's ancient and you really should be using this other build tool that's not fully integrated with any editor other than emacs and hey while you are at it the Clojure team has released their own dependency management tool and you really should be using that instead. By the way who uses intellij when there is VS Code?
Clojure boasts about it's strong Java interop and ability to use the existing Java ecosystem but it has one of the worst intellij integrations, using a 3rd party plugin that is either broken or not working with your build tooling.
Oh did you say you wanna use Gradle or Maven to build your Clojure stuff? You could actually do it, funny guy.
The language is probably the most practical lisp out there, but it also brings all the artificial lisp superiority syndrome with it (and forces you into submitting the rest of your life to emacs in praise of lisp culture).
You think you'll pick it up quickly and be productive but juggling between learning all the build tooling, the language itself, editing lisp and integrating all those 1-man libraries that are scattered all over github, you end up losing weeks if not months on fixing boilerplate.
I would give it another go but now that I think about debugging a Clojure app in runtime and making sense of a reflection-based, dynamic language on top of JVM, I'm like naaah I already have enough stress-induced grey hairs...
Haskell gives me the pure functional kick that I want, and the rest I can deal with in Kotlin or even Java 11.
…it has one of the worst intellij integrations, using a 3rd party plugin that is either broken or not working with your build tooling.
Meanwhile, the OP is quietly using Cursive to get his work done. It’s used in the screenshots.
(Disclaimer, I develop Cursive)
Meanwhile, the OP is quietly using Cursive to get his work done. It’s used in the screenshots.
(Disclaimer, I develop Cursive)
I can twist your entire argument around, but honestly, why even bother? You use Java and Kotlin as (good) examples, leaving the fact that these are heavily IDE-centric PLs. And if you haven't noticed, Kotlin actually is a marketing tool, created by an IDE tool-maker, to sell more IDE features. Try writing Java in Vim or Emacs - expect a world of pain. Whereas Clojure with its minimal syntax doesn't have that problem. In my team, we have engineers writing Clojure and Clojurescript in Emacs, Vim, VSCode and IntelliJ, and we don't do that for some hobby projects. I also, personally know people who use Sublime and Atom.
try elixir. It has a lot of the same semantics but the tooling is great and consistent. the libraries are descent and the developer experience is one of the best I've ever used.
You can model a lot of problems similarly to clojure. you get immutable structures, agents and a very freestyle ecosystem for getting things done while havign enough opinions laid down to be able to get started pretty quickly
You can model a lot of problems similarly to clojure. you get immutable structures, agents and a very freestyle ecosystem for getting things done while havign enough opinions laid down to be able to get started pretty quickly
If you are going to reach for a language that runs on the Erlang VM, and you like Lisp, LFE (Lisp Flavoured Erlang)[1] is a nice choice. And one of Erlang's creators, Robert Virding, created LFE.
[1] https://lfe.io/
[1] https://lfe.io/
[deleted]
>artificial lisp superiority syndrome
I giggled at this. Regularly, and in this thread, whenever some DSL req or LISP is mentioned you get these holier than thou comments about how LISP is the best thing since sliced tomatoes.. similarly with diehard vim/emacs users.
I giggled at this. Regularly, and in this thread, whenever some DSL req or LISP is mentioned you get these holier than thou comments about how LISP is the best thing since sliced tomatoes.. similarly with diehard vim/emacs users.
Also, regularly, on almost every post mentioning Clojure, there's at least one person who comes with some emotionally charged, unsubstantiated anecdotes, ranting about how bad it is.
"I tried looking at Clojure code once, around 2015, and I wish I went blind..."
They can't live knowing that many people enjoy writing Clojure. This dystopian world makes them feel really sad. "These schmucks don't even know how miserable their days are. I need to tell them that they are so damn wrong, and maybe I can heal their heresy and fallacious excitement..."
People get excited about Clojure not because it has a cool logo or because of Rich Hickey's terrific hairstyle. There are many good, objective reasons why they like it and prefer it to other tools. Because of those objective reasons, Clojure is used in big corporations and small startups.
Usually, there's nothing wrong with excitement about a good tool you like. Almost always, everything is wrong with hating a tool and hating people who like it.
"I tried looking at Clojure code once, around 2015, and I wish I went blind..."
They can't live knowing that many people enjoy writing Clojure. This dystopian world makes them feel really sad. "These schmucks don't even know how miserable their days are. I need to tell them that they are so damn wrong, and maybe I can heal their heresy and fallacious excitement..."
People get excited about Clojure not because it has a cool logo or because of Rich Hickey's terrific hairstyle. There are many good, objective reasons why they like it and prefer it to other tools. Because of those objective reasons, Clojure is used in big corporations and small startups.
Usually, there's nothing wrong with excitement about a good tool you like. Almost always, everything is wrong with hating a tool and hating people who like it.
Not every engineer is subject to learned helplessness. Some engineers never gave up on finding better tools, and have done just that.
They seem to have a very good use case for Clojure adoption. The article mentions many of the affordances Clojure gives you for data oriented, information processing problems.
But one of the unsung heroes of Clojure is the namespaced keyword:
If you’re already working in a FP, data oriented style but in a language that doesn’t have them, I recommend you have a go with Clojure and explore them.
It’s such a simple construct that gives you a lot of leverage in terms of semantics, code organization, flexibility and validation.
Think of them as having characteristics of uuids, URLs, URNs etc. they stand on their own and have meaning across system boundaries.
It’s very nice and calming to have that in-built as an everyday construct.