What do you mean by "falling apart"?
Clojure is the most stable and robust language I've ever used, and I've been using it in production for 15 years now.
215 karma · joined September 13, 2011
Clojure is the most stable and robust language I've ever used, and I've been using it in production for 15 years now.
Clojure 1.10: datafy/nav + tap> which has spawned a whole new set of tooling for exploring data.
Clojure 1.11: portable math (clojure.math, which also works on ClojureScript).
Clojure 1.12: huge improvements in Java interop.
And, yes, the new CLI and deps.edn, and tools.build to support "builds as programs".
If you post a JS position, you will get 1,000 or more applicants, so it is a huge amount of work behind the scenes to filter this down to try to find the vaguely worthwhile candidates to interview.
If you post, for example, a Clojure position, you will get 10s or maybe even a 100 candidates tops. And they tend to be uniformly more qualified because niche tech tends to self-select folks who want to explore outside the mainstream.
Of course, a lot of businesses want to use mainstream tech because "the hiring pool is much larger", but the flip side is "the hiring process is a lot more work", because of the volume. So, we get a crappy hiring process because they can't scale up a good hiring process :(
I have a map of topics and questions, and I get the candidate chatting about their past projects, their approach, and what they liked/disliked about past projects and various technology they've used.
It takes a maximum of one hour and usually close to about thirty minutes to make a yes/no decision on a candidate (sometimes it only takes ten minutes to make a no decision, and then it's a matter of trying to politely end the interview).
I've interviewed hundreds of candidates this way over the years, and everyone I've hired has been capable of doing the job. Not once have I ever had to let someone go for lack of technical ability.
Part of the problem is that we don't train people how to conduct interviews, and another part is "this is how I was interviewed, so this is how I'm going to interview other candidates" -- pure inertia.
As an industry, we really need to do better.
As for the OP, _if_ I had been administering a vague take-home project that had a 1-week delivery deadline, and a candidate peppered me with Qs and then presented a full proposal for the project for approval, prior to working on it... I would have rejected them. But I'm pretty certain I would have decided to reject them in my regular 30-60 "chat" interview, and I would not have moved on to the take-home project and wasted their time like that. So, again, I fault the interviewer(s) for not being able to filter candidates efficiently.
Where I work, we were previously a ColdFusion shop when I joined, and after a false start with Scala, I introduced Clojure and it stuck: we cross-trained the CF devs and slowly rewrote the platform from the bottom up in Clojure.
We had struggled with automated deployments, and the size of servers, when we were a CF shop but after the switch to Clojure we had a fully-automated deployment pipeline, with rolling cluster updates, and much smaller servers than we needed before, running more processes than before.
I was not commenting on the appropriateness of introducing a scripting language for devops work. I was responding to your incorrect assumption that writing scripts in Clojure would require a JVM.
If a company uses Clojure or ClojureScript already, Babashka is a fairly natural way to support devops for that company.
I loved working at Macromedia while it was between 1,000 and 2,000 employees (a lot of expansion by acquisition) but did not enjoy working at Adobe when they acquired us -- Adobe had a very corporate mindset, Macromedia almost felt like a whole bunch of startups. I had a blast working for Verizon (no idea how big they were back in the mid-90s but the IT department alone covered an entire floor of a warehouse-sized building), but then I went to work for a much smaller actuarial firm and, while the _project_ was fun, the corporate culture was not.
You have to figure out what is important to you ("fun", "interesting" are reasonable goals for work) and what sort of compensation you're willing to take in order to have fun. Are you willing to put up with more corporate BS for a ton of money? Would you rather have more fun and less rules but less money and far more risk (startups can be fun and interesting but also long hours and most of them fail -- I've been at three that imploded but I can't take that risk now I have a family and a home to keep up).
Is the tech stack important to you? Important enough that you'll really limit your choice of jobs? Important enough that you'd rather be out of work for months than work with tech you dislike?
I've been in IT for... over 40 years now. I've done everything from assembler and COBOL to Scala and Clojure, in companies as small as four people up to many thousands of people. Most of what contributed to my enjoyment at various jobs was the team interactions, closely followed by the problems being solved -- not the size of the company (nor the tech stack: the assembler job was at a large insurance company but the project was fascinating, and the team were awesome; and Macromedia was mostly C++ and Java and some ColdFusion -- but great people and interesting projects). For the last decade, I've mostly done Clojure and I love that and joke that I wouldn't work in another stack... but if push came to shove, I probably would if the team and the problem space seemed fun and interesting.
This year's funding by Clojurists Together allowed me to spend a lot of time completely rewriting large sections of the site to bring it up-to-date with modern Clojure tooling and libraries -- but I know there's still room for improvement.
A LOT has happened with the language and the tooling since then!
Clojure 1.9 gave us Spec "for describing, validating, and testing the structure of data and functions." and a whole bunch of new core functions (mostly new predicates).
Clojure 1.10 overhauled error reporting and gave us tap> (for debugging) and datafy/nav for lazy "navigation" through object graphs, which kicked off a series of new visual tools for exploring data structures: REBL (now Morse), Reveal, Portal, etc.
There's new Clojure CLI tooling now (tools.deps and the deps.edn file) and a library supporting programmatic builds (tools.build and the build.clj file). The 2023 State of Clojure survey shows the new CLI tooling surpassed Leiningen in popularity!
VS Code now has an amazingly capable Clojure extension called Calva, and you can script VS Code and Calva directly in ClojureScript via the Joyride extension.
The latter is made possible by sci -- Small Clojure Interpreter -- from @borkdude. He also created Babashka which provides a near-zero startup time solution for writing shell scripts in Clojure/Script, and clj-kondo which is a powerful, high-performance linter, which in turn powers clojure-lsp bringing static analysis for Clojure to several editors.
Datomic has grown up a lot in the last seven years and is now completely free to use (but not open source). We also have an open source bitemporal database in XTDB from the JUXT folks.
Clojure 1.12 is currently in alpha, and provides built-in support for adding new dependencies to your running REPL (without restarts).
It's a great time to be a Clojurian!
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
The source of clojure.org is at https://github.com/clojure/clojure-site/ and it gets a pretty constant stream of updates these days (it even accepts PRs!). It's a huge improvement over what it used to be -- so it depends on what/when you're comparing it to.
If you have specific criticisms or suggestions, I expect they'd be welcomed.
and https://news.ycombinator.com/item?id=36486486
https://news.ycombinator.com/item?id=36505733
That's how I came across Clojure back in 2010 and I've ended up using it in production ever since 2011 and I consider it my primary language these days.
Given how nearly all mainstream languages have adopted features from functional programming languages, I definitely think there's value in improving those skills, and working with a range of languages that are functional-first, including immutable data structures, lazy evaluation, and so on. Mastering these concepts will make you a better programmer overall, regardless of what language is your day-to-day "home" because you will think about problem solving in a more diverse way.
When I got started with Clojure (back in 2010), Leiningen was the only game in town. At work we switched to Boot in 2015 because Leiningen just wasn't "programmable" enough for us, but after a few years we started to run into limitations with Boot (both the file system abstraction and the "pod" isolation caused problems), so we were very happy to switch to the Clojure CLI in 2018 with deps.edn -- and then add build.clj (and the tools.build library) when that appeared a couple of years ago.
We manage a monorepo with over 140 subprojects building almost two dozen artifacts, and 136K lines of Clojure, using the official Clojure CLI and tools.build.