seancorfield

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.

Clojure 1.9: Spec.

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

Think of Civitas as a "static site generator" that uses the GH pages for the project as the public hosting for all the content -- a centralized, Clojure-specific blog if you like.

Absolutely this, yes!

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

A lot of companies seem to want to hire folks who "think like me". IMO, that's a mistake: you need diversity of thought to provide new insights into problems. If you all think the same way, and one of you gets stuck, then it's likely you'll all get stuck. This seems to be a common problem in startups, IME, and perhaps an indicator of why 9 out of 10 startups fail.

I'm surprised this seemed to be voted down. I've been a hiring manager for over 30 years, and I never do "technical tests" -- no take-home, no live coding, none of it.

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.

I guess it depends what the tech stack was before?

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.

My bad... the sixth time (the fifth time was under a different title).

The fifth time this has been posted in just over a week... it must be a REALLY good article! :)

Jeez, these FreshCodeIT guys are really spamming us lately...

There have been several comments from the core team folks that a vthread variant of core.async is being considered. It would be a different library and may be somewhat API-compatible -- but that's all up in the air right now.

Babashka is a self-contained executable that can run with no dependencies.

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.

There's babashka for scripting without the JVM, which I think quite a few Clojurians use for devops-style work.

What exactly is the question here?

I sympathize to a degree. I've worked in startups, and I've worked in Large Corps, but size alone isn't necessarily correlated with "fun" and startups aren't always good environments, nor do fun startups always turn into a corporate enterprise. I _generally_ prefer the smaller companies but you can find fun and interesting work in larger companies too.

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.