Bringing Clojure programming to Enterprise (2021)

https://blogit.michelin.io/clojure-programming/

by jgrodziski • 3 years ago

190 84 3 years ago

blogit.michelin.io

thih9• 3 years ago

I’m noticing a lot of clojure posts recently. Has the language become more popular lately? Is there any reason behind it?

lebski88• 3 years ago

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.

solaxun• 3 years ago

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

The only blemish for me was horrifically bad error messages.. other than that it's near perfect.

japanman4253• 3 years ago

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.

rawoke0836004• 3 years ago

Very accurate ! and x1000 about the error message !

moomin3• 3 years ago

I would be _very_ surprised if it had. The limited observations I have suggest a very stable community. Not growing, not shrinking.

simongray2• 3 years ago

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.

iLemming4• 3 years ago

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?

epgui4• 3 years ago

A reason other than it being awesome?

rawoke0836004• 3 years ago

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".

moomin3• 3 years ago

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.

john-shaffer• 3 years ago

malli, specter, and calva are all less than ten years old. Clojure has seen a lot of progress in tooling and libraries.

TacticalCoder• 3 years ago

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!

fulafel4• 3 years ago

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.

cutler3• 3 years ago

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.

college_physics2• 3 years ago

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

japanman4253• 3 years ago

Tyre manufacturing very much is not “non-tech”…

missedthecue• 3 years ago

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.

im_down_w_otp2• 3 years ago

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.

pharmakom• 3 years ago

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 :)

brundolf3• 3 years ago

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

jcadam3• 3 years ago

I've had a couple of jobs doing Clojure full-time, the problem is that Java jobs pay better.

ARandomerDude• 3 years ago

There's good reason to doubt that claim.

https://survey.stackoverflow.co/2022/#section-top-paying-tec...

epgui4• 3 years ago

I would take a pay cut to work in a sane language like clojure.

I do python now :(

conan111• 3 years ago

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..

iLemming4• 3 years ago

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.

d_t_w• 3 years ago

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.

hummus_bae• 3 years ago

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.

brundolf3• 3 years ago

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.

notamy• 3 years ago

(2021)

danuker2• 3 years ago

Looks like they were still using it in December last year.

https://blogit.michelin.io/an-introduction-to-datalog/

rbanffy2• 3 years ago

How well would Clojure fit into a Spring Boot centric environment?

jcadam3• 3 years ago

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.

whalesalad• 3 years ago

clojure can be used to create a library/jar which could be called from a java app: https://stackoverflow.com/questions/2181774/calling-clojure-...

lmm• 3 years ago

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.

fulafel4• 3 years ago

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.

rbanffy2• 3 years ago

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.

afandian• 3 years ago

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...

joe-user• 3 years ago

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.

n-gt• 3 years ago

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.

japanman4253• 3 years ago

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.

epgui4• 3 years ago

Not every engineer is subject to learned helplessness. Some engineers never gave up on finding better tools, and have done just that.

iLemming4• 3 years ago

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.

cultofmetatron• 3 years ago

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

eggy• 3 years ago

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/

lemming• 3 years ago

…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)

iLemming4• 3 years ago

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.

speed_spread• 3 years ago

Makes total sense once you learn that parentheses are all little tyre cutouts bouncing around.

julienfr112• 3 years ago

The bibemdum himself should be clojure's mascot !

simula67• 3 years ago

There is nothing specific to tyre manufacturing in this article. The original title was more informative: "Bringing Clojure programming to Enterprise"

dgb232• 3 years ago

A first element of decision lied in the fact that our product used a great number of data structures and business management rules which aim to evolve very frequently and be adapted to new business contexts over time.

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.

rawoke0836004• 3 years ago

Never heard a lang-feature describe as "calming" but now that I think about it, you are very much right :D

simongray2• 3 years ago

Several Clojure/Datomic design decisions are directly inspired by RDF.

mpweiher2• 3 years ago

But one of the unsung heroes of Clojure is the namespaced keyword:

Sounds intriguing, can you say more?

dgb232• 3 years ago

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`

abc_lisper• 3 years ago

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

rawoke0836004• 3 years ago

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 :)

dmichulke• 3 years ago

Eventually you want non-developers to develop business rules, so you come up with pseude-code like

  when X then do Y

You can write them in Clojure like in the above example:

  [:rule [:when X] [:then Y]]

which is kind of self-explanatory. X and Y can be any valid predefined expressions, e.g.

  [:rule [:when [:< amount 100]] [:then [:send-email-to-boss]]]

If you had such a rule, you'd just parse that line as edn, substitute all symbols (check for injection attacks) and execute it.

However, effectively clojure itself is most often the smallest representation:

  (when (< amount 100) (send-email-to-boss))

It's just not that readable because it's missing the "then", but it would be valid clojure right away.

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

vincnetas• 3 years ago

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 :)

silcoon• 3 years ago

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!

Wonnk13• 3 years ago

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.

tragomaskhalos• 3 years ago

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.

Bringing Clojure programming to Enterprise (2021)

Related Stories