Hacker News Reader

Comment by chartpath | Hacker News Reader

Would anyone recommend Clojure if you run an engineering org and get to make decisions about languages?

I've been running node shops for the last several years, and love Clojure since having hosted a couple meetups a while back.

That and being most influenced by lispy/ai culture from SICP, CTM, PAIP, AIMA books. Node is getting tiresome due to not being able to trust the ecosystem quality (which takes away some of the common justification of huge ecosystem).

Not worried about hiring since not open to fresh grads from universities or bootcamps without lots of training anyway (which can include a new lang). Are there crappy/charlatan Clojure devs out there or is it more of an elite/experienced culture?

With stuff like Fulcro, could we replace our basic REST APIs and business logic without having to re-invent too much?

View on HN

In my experience -- I was a professional Clojure developer for 6 years (until 2018), and hung out in the #clojure IRC channel on freenode a lot between 2011 and 2014 -- the Clojure community tends to be very experienced. Clojure is not many people's first language, but tends to be a language you find your way to after dissatisfaction with other languages, or exposure to other lisps.

I'm sure you can find crappy or charlatan Clojure devs, but I was generally impressed with the Clojure devs I met in #clojure or at the cons. Overall I found the community to have high levels of both knowledge/experience and patience in explaining things thoroughly and precisely to people who were asking questions.

You said 'was a professional Clojure developer'.

Are you not doing Clojure development anymore? If so, why?

Yes. I was at Puppet (nee Puppet Labs) for four years, one of the larger Clojure shops to my knowledge (not that I've been keeping close tabs on who's picked it up recently).

I switched jobs and language choice was not my #1 criterion. A very interesting opportunity that aligned well with my values (and paid better to boot), but was in a completely different tech stack (Python DS ecosystem, with some Scala). I love the language, think it's wonderfully concise yet expressive way to think about code, runs on a great platform for the web, and is a great fit for when team size exceeds codebase size (though not so much the other way around). All my fun software projects are still in Clojure or Clojurescript; I just wrote some today to scrape doggy listings.

Thanks for clarifying.

Do you have a blog or is there another way to contact you? I'm interested in what you wrote in your profile.

Send me an email at dlp@aperiodic.org

Ladder (ladderlife.com) is written entirely Clojure(Script). We feel it was worth it - having a single language that can stretch from frontend to ETL code is pretty powerful. The fact that parallelism in Clojure is real (and not 16 separate processes) is pretty great too. Some of the downsides are: the slow startup time and fat(ish) JavaScript payloads because of the extra runtime libraries. The community can also be a bit unwelcoming of new ideas sometimes.

If you’re thinking of migrating - especially if it’s just a rest API - just start with Ring (& maybe bidi for routing). It’s not really a framework - you can pick and choose what else fits into your stack well after that. Clojure libraries tend to be very stateless and end up composing surprisingly well. I think Fulcro is a bit more useful if you’re building a frontend from scratch with React.

In terms of hiring - it’s very similar to a niche language. You get less folks that are specialists in Clojure like people are specialists in Node or Ruby. It’s also an easy to teach the language so you can bring most people up to speed in a month or so. Our hiring process favors generalists - and Clojure fits in well for that role. I don’t think specialists would have a good time with Clojure though - it’s not the kind of language that is easy to use as a means to an end.

I work with Clojure about 50% of the time at my current job, and I can tell you that I've never felt blocked by it for anything. The libraries in Clojure are pretty ok, and when in doubt, I can virtually guarantee that a well-tested Java library exists for nearly anything you are working on.

In regards to dev-quality, I find that people that are interested in Clojure are typically good engineers, not due to the qualities of the language, but due more to its relatively niche-ness, attracting more enthusiasts.

I don't know anything about your stack, or Fulcro, but I've had no issue using Compojure for doing REST stuff.

EDIT: Just an FYI, I should point out that I work at a really big megacorporation, not a small startup or anything.

This thread might be of interest https://twitter.com/domparry/status/1110762025754521600

    We're a very young business, iterating fast through
    features, being very careful about writing maintainable
    code. We have full stack Node apps and full stack Clojure
    apps. This is a short thread on the difference technology
    (or would it be language?) choices have made for us.

I would recommend Clojure, but not necessarily for every organization. If you have experienced, mature and well-educated developers (which means expensive developers), it's a fantastic tool. But many organizations treat developers as interchangeable cogs with mediocre skills and mediocre pay, and Clojure would not work well for them.

I also think it's very easy to tell a crappy/charlatan Clojure dev from a good one just by looking at a small sample of his code.

The main issue with using Clojure is that you are expected to build everything out yourself. A lot of dependencies tend to stop being maintained after a while. Auth systems etc. are half-baked with 10 different implementations on GitHub. The newer shinier ones lack in features while the more featureful ones are from 3 years ago and have not seen a single update since. Now lisp people like to say "but...but.. backwards compatibility!" Sure that works for a lot of things but it goes out of the window when you need to prototype something quickly and your intern using Django/Rails has already built a MVP while you are still trying to sort out your dependencies story. Now you can always pull in Java libs, but then you will spend the rest of the week writing a wrapper for a very tiny subset of features that only you would use and the next person that comes along will have to do the same thing for the subset of features that they use.

Using Clojure (other Lisps have it way worse than Clojure so they are not even worth mentioning in an enterprise context) is a bit like using an extremely new cutting edge language like Rust or Nim where there's no high quality libraries for anything except the lowest common denominator but without the massive community and support. Yes Node has its issues. But at the end of the day, you still need to get things shipped. Elegant code that would look at home in SICP is useless when money is on the line and you can't ship. Clojure et al. is very much NOT a "Move Fast and Ship" type of language. If it's for a game jam where no one's using Unity and everyone's doing OpenGL or one of those dinky little Lua game dev suites, sure go for it. If it's your company, use Go and get things into production first.

Don't get me wrong, I love Clojure. There are a lot of smart people doing interesting things with it. It's probably the most advanced of all Lisps in terms of beginner-friendly tooling alone (shoutout to the Nightcode and Parinfer authors!) and it's Java interop is tremendously powerful in the right domain. Just that the ecosystem feels at times like Android 1.5 with its terrible fragmentation problems. The main corporate sponsor behind the language gives off apathetic vibes to community needs and the lack of featureful, maintained libraries is covered up under the guise of "Big frameworks bad! Elite programmers build their own!"

That's precisely the problem that Luminus [1] solves. It provides a batteries included template that follows best practices as well as documentation on how you would accomplish many common tasks. Making an app is quite straight forward, and all you need is Leiningen [2] and a JDK. For example, you could do:

    lein new luminus myapp +postgres +auth +swagger

This will create an app using Postgres as the database with a Swagger UI set up out of the box.

During development mode you'd run the app with:

    lein run

Any changes you make in the source will be automatically reflected when you reload the page. You can also connect the editor to the REPL that gets started on port 7000 by default.

You can package this app for production with:

    lein uberjar

and you can run the resulting jar as:

    java -jar -Dconf=config.edn myapp.jar

You really don't have to hand roll your app and go hunting for libraries unless that's something you want to do.

[1] http://www.luminusweb.net/

[2] https://leiningen.org/

The sweet spot for clojure is data oriented/data processing backend services (data engineering), where you can leverage stuff like kafka, spark, etc. You are going to get frustrated if you use it for common CRUD websites where the node.js/ruby/python ecosystem actually has quality libraries for all the common parts. In most cases I wouldn't trade node.js for clojure when writing front-end servers.

> A lot of dependencies tend to stop being maintained after a while. [...] The newer shinier ones lack in features while the more featureful ones are from 3 years ago and have not seen a single update since.

A lot of libraries are not updated because they do not need any updates. This is surprising to people coming from other languages, but is fairly common in the Clojure world. I use many libraries which haven't been touched in 3-5 years and it is fine: they don't need updates.

> Auth systems etc. are half-baked with 10 different implementations on GitHub

Here I would agree — authentication is a problematic area. I use buddy, which I had to integrate into my ring+sente app manually with quite a bit of pain. Friend has the wrong abstractions, IMHO, and does not get the job done.

Don't write a wrapper when using a Java lib. Just use it directly. Now the next person coming in just has to use it, no need to understand the wrapper and extend it. Interop is a first class feature specifically for that reason.

For the rest, I can only say that I don't understand the sentiment. It's true what you say about lots of Clojure libs, they were one off projects from someone and work has stopped on them. But I am able to move fast and ship with Clojure. For me, I can actually move faster with it. That's one of my main reasons for liking it so much.

There's a Java lib for everything complex. And there's a quality Clojure lib for everything common. I've never not found what I needed. And in general, I don't need as many things because the core libs are so full featured.

I'm not trying to deny your experience. It just makes me curious how my experience can be so different and almost opposite. That's why I've concluded that it's just not for everyone. It seems you are either a FPer or you aren't. And you are either a Lisper or you aren't. And with Clojure, you have to be both a Lisper and a FPer.

It has less to do with FP or Lisp and more to do a lack of emphasis for rapid development and a significant impedance mismatch with the rest of the ecosystem. JVM interoperability works when the API is clean. It doesn't when obscure OOP features are used three layers deep and have to be mapped into Clojure which is more functional in nature.

Reply on news.ycombinator.com