> Is it a responsible decision [snip] to bet on Clojure as the BE language of choice in 2023? Yes. Whether it makes sense for you is up to you 🙂 I know that right now is a great time to hire Clojure devs. It's also worth sharing that I know a bunch of companies which called in outsiders (from a consultancy like Juxt or Gaiwan or Cognitect itself, or individuals like me) to smooth out the early process of getting a team like you describe up and running. It works well.

Yea I get that but I don’t think my first decision as the only techie in the room with the founders is to hire someone else to advise me on how to tech 🙂

If I decide to do something, I need to be the person doing it, at least initially

Ah okay I interpreted CTO as primarily a hiring role, sorry. If it's more a technical cofounder/first dev situation then it depends even more on your feelings about building with tech that's new to you.

A few years ago it was difficult to hire clojure engineers. It's probably great now with the layoffs (I was laid off and am looking). However, I spoke with the CTO of Circle CI and he mentioned having trouble finding security engineers for Clojure/Java. So there could potentially be long term issues of finding hires for niche/specialized positions, but that was years ago.

I once joined a startup and they had golang. My first question to the CTO was "why golang"? The CTO never answered me but I kept thinking about it. They were a blockchain thing and this was "the normal practice". But golang has a lot of quirks and interesting syntax (like that if err !=nil line that takes 2% of all of your code (I calculated this on bitcoin source)). We failed to build the project in time even though we had three frontenders and two backenders (I was one of those and I also did the blockchain stuff). Then at some point the frontend guys were laid off and I left with CTO alone as the other founder decided to part ways too. And then the CTO asks me: Do you want to rewrite everything in OCaml? I said no. And now I used biff framework to develop my own app in about a month or more. So.... yeah... people didn't help, golang's "ecosystem" didn't help... "easy golang hiring" didn't help either. We had enough hands but we were focusing on the wrong stuff... why even bother with GraphQL... Are we going to have 50 apps that integrate with us? wtf... With my current experience I have to say that golang is a terrible language to write a DSL. And Clojure is a good language to do it. It doesn't mean that every problem can be reduced to an AST or a DSL but I did https://termsoverload.com/ by myself and I used some of the Clojure's recursive processing techniques. BUT I knew Clojure. And I knew XTDB. And I knew what MVP I want. And I knew I don't want a huge thing. And I had experience in startups.

> Is it a responsible decision for someone like myself to bet on Clojure as the BE language of choice in 2023? I think so. In my experience Clojure in the JVM is mature and rock-solid. The initial steps may be hard, you may hit some bumps, but this is a very helpful community and you can always count on someone to help you. In the long run, if your problem is well adjusted to Clojure, you definitely will reap many benefits.

@U028ART884X I appreciate your experience, thank you. I am not a fan of Golang. My usual philosophy for a first engineer/CTO is to pick something they’re an expert in. Hence my hesitation in picking Clojure, since even though it’s a great tool for the job, it’s also breaking my previously-held opinion about responsible technology choices 🙂 sounds like your CTO picked Go because it’s “standard practice” rather than because they were experts in it.

I'm not saying you shouldn't use golang. You can. But please have a reason for it. For yourself, not for me.

Yea totally

The hiring scenario seems pretty favorable nowadays see e.g. #C050UG324GM As for the choice itself, you'll only get biased answers here :) but the templates, libraries, tooling, etc make it exceptionally simple+easy to have a high-quality backend. One can easily get help over #C03S1KBA2 or specific channels (often directly from the library authors). We're an enthusiastic bunch that tends to be happy to help each other, so you'd rarely get stuck in a given problem.

Clojure on the backend isn't hard. There's a ton of knowledge on the jvm ecosystem, great libraries, monitoring and visibility tools And a decent pool to hire from if you know where to look domestically 🙃

The only real 'but' IMO comes with scaling a team. You don't want an in-house Lisp Curse. One can avoid it with explicit care e.g. make a design / set of guidelines, commit to those in cycles of 6 months and basically forbid any bikeshedding in between.

@U45T93RA6 can you expand on that? I know I don’t want a course. For example, Mercury runs a Haskell shop but I know that new devs take a 3-month haskell tutorial and aren’t expected to be productive for 6 months, which is not something I want to emulate. for design/guidelines choices, that’s where my inexperience is a liability - I don’t know what the bad practices are yet. What are some good resources for best practices? the only one I know rn is “don’t write too many macros”

(Just in case, I referred to https://news.ycombinator.com/item?id=14480157 famous article) I'd say Clojure is much quicker to pick up - especially nowadays when most mainstream languages have kept up with functional programming. Say that you start today, solo. I'd decide a stack, some basic linting, etc and focus on the startup's core problem for 6 months. Then, you can iterate on what went wrong. Maybe someone joined. Now, agree on what the new code should look like for the next 6 months, write it down and commit to that. This way you don't have random weekly discussions on whether to use Spec/Malli/nothing, this or that testing approach, etc. Clojure is very, very diverse in the possible choices, and that excess of choice can translate to problems in a team setting. (Of course there are many ways to avoid that problem - I laid out how I would solve it)

Also I googled bikeshedding and today I learned a new meeting-ending phrase (“let’s stop bikeshedding and move on”)

Imagine the worst case scenario and picture yourself taking responsibility for it - can you/the company survive it? Do you personally feel that it’s worth it? Do you have the energy/words to explain your rationale for choosing Clojure, probably repeatedly?

Prod readiness is a step beyond code complete, can you be confident that your Clojure app is ready for prod?

Hypothetically speaking

Great suggestion, Daniel. The worse case scenario for us would be that the software is insecure. Either it gets hacked, or leaks sensitive information. I don’t really know my way around JVM security and I recall at least one major JVM issue recently that I would have probably not been on top of.

Another worst case to consider is a hypothetical outage that causes a major loss of revenue or customer trust - do you have the tool/process knowledge to save the day?

In this particular business, security is a much bigger concern. It’s not a web-scale platform

And doesn’t need to have great availability

What sort of security concerns? What's your threat model? There's easy stuff like making sure you don't hard code credentials or use vulnerable libraries. What other things are particular to the JVM and not your general architecture?

A CI job that runs nvd-clojure or antq would keep the basics of the supply chain covered One Clojure-specific pitfall is that web frameworks templates may not make unmistakable whether you are using all possible best practices. They do default to a secure middleware stack, but it's easier to change than in e.g. Rails.

And the human factor is always the weakest link - so you found developers checked in hard coded credentials You raised all the relevant flags Did they fix it?

You can easily get rid of security in JVM. Just expose your C++ functions in some way. There should probably be an article how to do it online. But banks are happily using JVM in production and not trying to build in PHP. But facebook built their app on PHP... so I'm not sure what kind of security threats you're talking about. I think this discussion is not productive if you think that JVM is insecure "if you don't do something to it to secure it" I think this was a good comment: > What's your threat model? If you'll decide to run binary-level user blobs then it won't matter if you'll run JVM or PHP. Human stupidity trumps everything. So you are the one who decides what is secure.

Incidental to the conversation, I would recommend Release It second edition by Michael Nygard

I don’t think I said that the JVM was insecure, I just said that the worse case scenario is a security breach, in response to a thought exercise asking what the worse case scenario would be. I also said that I don’t know the JVM vey well, in particular w.r.t., security, and that there was at least one well-publicized JVM security incident recently (something with logging I think) that given my limited experience with the JVM I wouldn’t have been on top of. that doesn’t mean it’s less secure than anything else. I know it’s used in production, but banks are not a great example, because they can hire large security teams, and here it’s just me.

Worst case scenario is RCE because of insecure logging framework

@U07QKGF9P has talked before about security at startups; I believe that they have a company founded around the security needs of few-engineer companies

Latacora is the name

Sweet, thanks!

Howdy yes that’s me, and good memory: https://latacora.com

Wow thank you iOS slack for botching that URL somehow

Anyway we do lots of off the cuff security advice and this seems up that alley

I don’t think the JVM makes this particularly much worse than other platforms, but I do absolutely think that it is a reasonable position to take that the Java logging ecosystem mess causes security vulnerabilities

My position is less “JVM seems worse for security” and more “I have little experience in JVM security”

which arose in response to the question of “can you handle the worse case scenario in an unfamiliar tech stack”

For example, we’ve had clients including ones that I would characterize as being exceptionally technologically capable, who accidentally logged sensitive information where the root cause was spooky action at a distance (mystery logback config from some random jar re-enabling trace level logging at the wrong scope) that only could have happened because some really questionable design and requires pretty sophisticated controls to prevent

But I’d say that’s on average less bad than what we’ve seen in ruby for example, where are you swap the order of two pieces of rails middleware that should have nothing to do with each other around and all of a sudden CSRF protection goes poof

which arose in response to the question of “can you handle the worse case scenario in an unfamiliar tech stack”A more likely worst-case scenario is "what do you do when stuff goes down" - i.e. do you know how to observe+fix it The JVM shines here in terms of monitoring and profiling. Fixing issues can range from 'easily googleable' to 'requires expertise'. The nice part is that 9 of 10 times if you write down your problem over #clojure you'll get expert advice the same day (I've asked some pretty obscure pathological cases over the years and sure enough, folks helped me get it solved).

@U45T93RA6 Yea that’s fair, but it’s a bad case scenario, not the worse case scenario. And it’s something I have a bit more experience with. It’s also a bit less JVM-specific.

For what it’s worth almost everything we do is JVM clojure with a few counter examples in babashka and I’m sure a little bit of clojurescript somewhere

We hire people without that experience and train them up in it all the time

In my experience, the biggest mistake that you can make is telling Junior people that some of the modeling that they’re doing is generally considered to be very sophisticated, even if it is just because you’ll scare them and they’ll self select out

This will probably be unpopular on the Clojure slack, but I’m gonna disagree with everyone else in this thread Frame challenge: are you ready to build “the app”? Do you have product market fit? Has the company already received commitments from investors? If you’ve answered “no” to any of those questions, then you’re not building an application you’re building prototypes, whether you know it or not. If you try building “the app” then you’ll soon find that the company changes course, or the vision changes, or they need to pivot, and the problem you’re solving changes drastically enough that you’re stuck trying to jam a square peg into a round hole. Instead, your goal is to optimize for learning, and you want these prototypes to be a) delivered as fast as possible and b) easy to throw away. In such a situation, I would personally choose whichever tool I felt I could deliver with the most quickly. On the other hand, since the code is likely to be thrown away, that’s a great time to experiment with tech like clojure if you can get the project setup overhead/language learning done outside of working hours. So in your shoes I might start with tools I’m already comfortable with while simultaneously upskilling on Clojure in my spare time if that’s interesting to you. All the other questions about “what language is good for the problem” and “what can we hire for” can be answered once you know enough about your problem that you’re ready to grow beyond prototypes and build “the app” (or at least what you think it is in that moment).

That doesn’t sound controversial to me at all

I’d do it in Clojure, but I am already proficient with it

In my honest opinion, you weren't going to get an answer besides "yes", going and asking it in clojurians

Yea I thought so as well but I got a nice introduction to a security expert out of it 🙂

Clojure on the back-end is far less complex than ClojureScript for the front-end. Clojure projects typically don't need much if any direct Java interop on the main. The JVM will optimise Clojure very wel and there are tools and lots of articles discussing how to alleviate performance issues should they arise. The only optimization needed on the Clojure teams I've worked with was a little bit of core.async and using a message bus (event stream) effectively Unless you hire some really hacky developers, you shouldn't have any significant issues with the language or environment (backed is far more stable than front-end in general) Finding Clojure engineers seems to be relatively easy at the moment, especially given how many posts are in available for jobs channel

I’ve done what you are proposing to do (CTO in a startup with little clojure experience choosing to use clojure) and it was the best decision I made. My background was Java but I had been in a corporate role for a number of years so was generally rusty. The main reason it has worked so well can be distilled to one word: productivity. Because of the simplicity of the language, the availability of well designed libraries to accomplish most tasks, and the power of REPL-driven development, our startup has managed to build its product with a core team of two developers (one of us developing a flutter app and me doing everything else, including all devops work) - while also finding time to be involved in bus dev and operations stuff that come with being in a startup. Over the course of the past 18 months I’ve found my velocity steadily increase - even as the platform itself has grown in complexity. I haven’t experienced that before, with other languages, development slowed down as the platform got more complex. Of course some of that may be down to just having more experience in general, but my gut tells me clojure is a big part of it. Clojure encourages simple design, and the fundamental concept of not ‘complecting’ things from the start leads to significant cumulative gains over time. As others have said, startups are hard, most fail, and those that don’t fail more often than not have resource squeezes due to money issues at some point or other. If you build your product in a language and in a style that allows your team to do a lot with a little, your chances of success automatically go up - your low cash burn rate can become a superpower. Of course, you may find that your business takes off like a rocket, and you may find that the fact that clojure has a smaller community than java or javascript or whatever becomes a bigger problem for you. However this is a champagne problem and in my experience is very rare - and I would not make strategic decisions with such immediate success as an assumption. My advice: Let the last hour be the hardest, and go with clojure.

As long as you can get CORS middleware working in your Ring app, everything else will be plain sailing

Clojure is a safe choice for a startup. You can get a lot more done with less people. The flexibility affords you unlimited number of pivots. My startup pivoted so many times, and my initial code base written in 2014 continues to this day.

I also think that starting together with one or two experienced people would be a great way to build a team. By not being conventional, you have so many more options.