Ah clojure. It's all fun and games until five years down the line, you've had 100% dev churn, and you have a 100kloc codebase that nobody understands, full of functions that don't give the slightest hint of the shape of the data they're processing (it's all lists!) yet down the bottom of the callstack there's some function that'll explode if the map doesn't have whatever magical key it expects.
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
As the saying goes, a bad workman always blames his tools. You can make a mess in any language, and Clojure is no exception.
There are plenty of ways to mitigate the problems the author describes. A few of these things would be having coding standards to ensure that code is written in a way everyone is comfortable with. This also covers things like adding schemas and documentation for maintainability. Doing pairing and code reviews so that multiple developers are familiar with different parts of the codebase. Having good tests so that you can have confidence that the code does what's intended when you make changes.
I'm also not sure what makes Clojure esoteric. It's a clean and well designed language that embodies good principles. It's a niche language, but far from being esoteric. I've been using Clojure for over a decade now, and I've seen the opposite of developer churn. Most people are pretty happy to stay at a company using Clojure. The fact that there is high churn is suggestive of a toxic environment that drives people away.
Finally, here's [1] a talk from a founder of a Clojure startup that grew into a large successful company. Clojure didn't get in the way of that.
I don't understand this reputation either. There are very large systems built on other Lisps, and they didn't collapse. What makes Clojure different?
For example, Emacs has a massive amount of Elisp. Elisp is much more primitive than Clojure, and traditionally libraries don't use e.g. data schemas [1] as runtime contracts for data.
Obviously, once a system built on top of a dynamic language grows beyond certain threshold, you need to be very disciplined as there are no static types to ensure some degree of correctness.
With that said, it would be interesting to have a language from the ML family as a viable contender. Perhaps a modernized version of Standard ML. Or perhaps OCaml, if it gains some traction with multicore and algebraic effects.
F# is nice, but it's a bit of a watered down version of SML due to the lack of functors. Scala is too complex and far from ML in some regards. Haskell is good, but lacks critical developer mass and some libraries / laziness overcomplicate certain usecases.
I offered a counter example to the comment author too (Clojure has been wonderful for us), but I do wonder if there is one area where OO languages excel above functional: the shape of the code hints at the shape of the data.
In Lisp, function names describe actions. In OO, classes, inheritance, static properties, and getters and setters give at-a-glance hints as to the shape of the application's data model. In Clojure, we compensate, as you pointed out, with forms of documentation. I'll take that trade-off any day—I never want to go back to classes! But it's perhaps one reason for which Clojure has a reputation of being hard to read by other devs.
since around the early 80s it was common to write large Lisp software using class-oriented or even class-based OOP (a few used also prototype-based OOP). For example Flavors for the MIT Lisp Machine was class-based: multiple-inheritance, mixins, message sending with single dispatch, ... CLOS (the Common Lisp Object System) then changed OOP such that it better fits into Lisp: generic functions with multiple dispatch, classes, multiple-inheritance, meta object protocol, ...
One of the drawbacks of those systems is that the code gets assembled at runtime (though cached) and thus to read and understand code one might need support from class/function browsers.
You can make a mess in any language, yes. But some languages tend to produce more messes than others. If your tool is mis-used more than other tools, at some point, it's not the fault of the users.
> If your tool is mis-used more than other tools, at some point, it's not the fault of the users
And Clojure isn't misused more than anything else. In fact, I've got a feeling it's less so.
The difference is just that you can scapegoat it, and people will believe you.
You can't blame Java for the failure of your project, cause everybody knows Java has worked fine for so many other teams, but nobody knows Clojure, so you can blame it for all your failures and people gives you the benefit of the doubt.
When you have a bad code base, and it's Java, people blame the people who wrote the code. When you have a bad code base and it's Clojure, people blame Clojure. Go figure!
I’ve personally had to deal with far more and worse messes in Python, Java and Javascript than I ever did in Clojure. (Started using Clojure ~13 years ago, but have been in jobs that use the other languages I’ve mentioned in that time too, not always exclusively using Clojure, although there were periods where I was).
I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal dream language wishlist item is “Clojure but with static types”, however, while that’s something I dream of having, it hasn’t held me or the language back in any meaningful way. The thing that makes Clojure less mess-inducing in my opinion is largely the fact that it’s data is immutable by default. An immutable-Python would be something I’d be interested in trying.
> I have mentioned a few times in the past, on HN and Reddit and elsewhere, that my biggest personal dream language wishlist item is “Clojure but with static types”, however, while that’s something I dream of having, it hasn’t held me or the language back in any meaningful way.
Sadly, Rich Hickey has always been pretty opposed to typing in Clojure. Enforcing values to be not null is basically table stakes for typed systems, and yet he doesn’t seem to think it’s valuable or feasible,
Yeah. By dream of I mean “if I had a on of free time, it’s something I’d love to make because I want it” while knowing it will never happen. I know that Clojure itself will never support it, outside of external projects like Typed Clojure
YMMV, but "messes" are for me things that manifest in projects spanning both multiple contributors and non-trivial periods of time. And in that framing, in my experience, the most effective individual proxy for "is this project a mess" is whether or not it's implemented in a dynamically typed language. Python, Javascript, Clojure, Ruby, my experience is that they all break down at scale, far more than equivalent projects in statically typed languages.
I’ve seen what I would consider messes in C++ and Java too, so it’s not exclusive to dynamically typed languages, but I’ve certainly seen enough in Python and Javascript to understand what you’re saying. It’s also a reason why I dream of a Clojure-like language with first class static typing, but, alas…
If Clojure was a bad tool then people wouldn't be using it in the first place. There is a big barrier to getting started with Clojure because it's semantically different from mainstream languages. The mere fact that people use it and there are successful companies built on it demonstrates that the language does provide value.
Your argument is based on a fallacy. The whole reason PHP became popular was that it was easy to get started with. The barrier for using PHP or JavaScript is very low. The opposite is true for a language like Clojure.
This is my experience exactly. I love the language and ecosystem in a lot of ways. I also believe that REPL-driven-development is a ridiculously productive way to work.
But I absolutely hate maintaining an old Clojure codebase (unless it's tiny).
The REPL helps a lot with discovering what the proper way is to call any random function you have in your code, but this is still really super annoying. I really hate to get into a dynamic-versus-static-typing debate, but I've long since come to the conclusion that -- all other things being equal (hah!) -- if I have to dig into a large and old project, I'd much rather have types by my side than not. Code will not ever be adequately documented or commented (and even if it _seems_ to be at first glance, you will always have nagging doubts about how up to date that info really is). This is where type definitions help to figure out the shape of the data that any piece of code is working with. People talk about adding spec/schema definitions but that doesn't solve all the problems with not having type definitions unless you add these spec/schema definitions _everywhere_ ... and let's face it, you just aren't going to do that in any Clojure project. So, best case scenario is you still have a large collection of functions in your project that are calling each other, etc that you are left having to deduce yourself what this random map or list actually contains.
As a Clojure admirer who has learned it enough to get things done (and subsequently forgotten it) twice, I recently had the positive REPL experience that people talk about. Or at least I think I did. I was able to write a web scraping tool almost entirely in the REPL.
However, I find myself running Ruby/Rails (console) in debug mode in RubyMine (Jetbrains IDE). The REPL-like experience seems quite close to that of Clojure, with the added benefit of being able to easily enable and disable breakpoints and see my local data (and snapshots of all previous local data up the call stack).
And honestly, the Clojure thing that always stops me from actually getting a full anything built is the lack of frameworks and approaches which have critical mass. It's always the same answer, "We like to choose our own libraries." That's lovely once you know what you're doing, but the ramp-up time is just SO much slower than with other languages.
Considering the time to working proof of concept is critical quite often, few beginners have time to figure out all the libraries and tooling and integrations to build something in Clojure.
I think despite still wishing I had a Clojure backend with Clojurescript/React frontend, I'll step from my Rails PoC to a Phoenix/Elixir product and be successful and happy (and have a lot of people doing something similar, with similar tools and libraries).
Yeah the (what I personally call it) "choose your own adventure" style approach to Clojure projects, where you don't use a framework like Rails, but just string together your own project from separate libraries, is really both a "pro" AND a "con".
It's great when you know what you're doing, and indeed, I have my own personal Leiningen templates to set up a Clojure project the way I like it and to save myself some time. Bigger project templates, like Luminus, I often find personally aggravating because I often feel like it just barfs a whole bunch of unnecessary and semi-complicated (in my opinion anyway) code in a new project even with the most minimal options chosen. But that's the power of the ecosystem ... you can create your own project templates to meet your own needs.
But a new developer getting their feet wet in this ecosystem? Yeah, it is hard. And even if they use an existing project template like Luminus to bootstrap their project ... well, the project template only helps generate the initial project. Ongoing maintenance for updating dependency versions and keeping a working integration of the libraries it initially set up for you (with respect to newer versions and any API/config changes, etc) ... well, those responsibilities are all on you! Kit (another newer successor to Luminus) _may_ provide some better alternatives here, but it'll still be limited with exactly how much it can help here. But I think it's still much too early to say one way or the other with Kit, so who knows.
(Also thanks for sharing your Ruby/Rails perspective on REPLs. A colleague of mine made some similar comments to me when we were discussing REPLs a while back, and I've not spent any time with Ruby so couldn't comment. It's interesting to hear! Most other REPLs I've used outside Clojure were not too useful as anything other than quick toys for trying short snippets outside of the context of a full project.)
Don't know about Ruby but agree that languages(think Java/C#/Javascript/C++) with really good debuggers don't have anything to envy from the Clojure REPL. But to be fair, companies have invested who knows how many millions to get that level of tooling while in Clojure and the nature of lisps you get it for free and low effort.
i'm starting to feel that REPL driven development can be bad for maintenance, when you have a REPL, you can write ridiculously compact and abstract code that is hard to understand just by reading it.
That's an interesting point I'd not thought of. I guess I'm more looking at it through the lens of "interacting with and modifying a running system" which kinda gives you a debugger (ish), compiler and execution environment all rolled into one. It's kind of nice to work in this kind of "scratch pad"-like environment while you figure something out versus the more traditional edit-compile-run cycle. But I have definitely seen what you describe as well, so I think that aspect is worth considering too, for sure.
It's almost by definition in some sense ... if it was obvious how to write the code you wouldn't need the REPL so by definition if it is uesful it must be producing non-obvious code.
That is a slightly shallow take though because its not really symmetrical like that. You can use a REPL as a way to arrive at the most easily understood rendition of something. But that is very prone to subjective bias as lots of things seem obvious in retrospect that are not at the start.
To the extent that the answer you eventually arrived at is a result of learning a mental model of the data and functions surround it, it will leave a significant residual gap for the next person who comes a long to bridge.
When using the REPL you can quickly experiment until it does what you want, but you need the discipline to distill something maintainable from it afterwards.
I agree. More generally, REPL-driven development rewards "guess-and-check" programming, and discourages "think-then-act" programming. This isn't a formula for success over time.
Oh man, this is not my experience. We may be different because we are a small company, and Clojure is our main language. But, we have a Clojure codebase of 90K lines, and is 10 years old. It has its problems, and while your points about an opaque data model resonate, for us, tests, specs, and assertions provide enough hints to help newcomers. And... where I disagree the most: the quality and professionalism of the developers who work on it are unparalleled. New, senior-level developers, quickly catch on to the system. I am grateful to Clojure __because__ it attracts this caliber of developer.
I'd say 100% developer churn is the real problem here, no inherited 100kloc codebase is going to be a walk in the park if the original devs are not around.
However, I do think that it harder to keep a large code base understandable when using a dynamic language v.s. a statically typed language.
Having problems with understanding the shape of expected data is certainly a problem experienced in larger Clojure code bases, I guess this is just a disadvantage of using Clojure.
Documentation, tests, spec/schema and good naming conventions can mitigate this disadvantage to some extent.
OK but that's a 500k LOC codebase in javascript/python that nobody understands, maybe the project doesn't even get there
everybody hates their language when they have 100k LOC of tech debt from 8 years ago
You're right that Clojure's sequence soup problem is painful at that scale (really any scale) but have you ever debugged Java? It's barely even possible, the project needs to drive $10M+/yr revenue to just not collapse once it reaches 500k+ LOC Java, 500k XML, 300k SQL ...
> have you ever debugged Java? It's barely even possible
hard disagree ... Java is a dream to debug. I've hacked into complex applications countless times by remote attaching the debugger and setting breakpoints to step through what they are doing. You don't even need source code in many cases. I'd pick Java ahead of any other language on that front.
I should have added that I've had similar experiences with (old school, untyped) python codebases - absent the esoteric programmers, which is not a small difference - although with python you tend to hit performance issues if your call stacks get too deep. Ironically the JVM performance lets you dig yourself into a gnarlier pit before you have to face up to it.
Nope. I have taken over large Java applications with zero documentation and managed to get up to speed maintaining it fairly quickly. The static typing is a huge help.
Java is one of the very few languages out there that is manageable and debuggable at the large scales you're talking about. The tooling around it is second to none, and because it is statically typed with a decent type system, you can refactor quite safely in general.
And let's be frank, XML, other than for Maven (where it can make sense), is not really a thing in modern Java.
The issues that C faces in terms of memory correctness do not occur in Java. You can use tools like `perf` on a Java program, and I don't see why you couldn't use valgrind for natively compiled Java programs.
For debugging and observability, tell me if C (or any other platform) has anything resembling JFR for the JVM.
- dev churn is just a fact of life in this industry
- I'd love to know which language stops you from having 100k LOC codebase that nobody understands! Certainly not C#, typescript, Java...
- "esoteric developers" - that's a bit glass half empty! In my experience people who have taken the time to learn functional programming or any non top-10 language are usually pretty smart and motivated.
Agree that dev chrurn is a fact of life. But smart and motivated doesn’t imply not painting onself in a corner, it requires a different kind discipline which could be achieved with any language more or less. However, I find that the most frequent reason for churn is company culture of overwork and chaotic environment and in a place where ‘devs rule’ churn goes down drastically.
What worries me the most about clojure and languages like it, is that seems to be for people who want to be clever with how they write programs, when that is the opposite of what I want from people I work with.
Yeah. Personally, I really love writing Clojure. But I’ve never run it in production because I have the same reservations. I’d be the overly clever dev in this scenario.
Knowing how to design and structure maintainable code is a must for any successful code base to remain manageable over many years.
Clojure, in the hands of someone that knows this, works wonders. It gives your team 10x productivity, safer more correct code, that's simple to extend and grow over time, keeping your velocity high and your tech dept low.
But if you don't know how to leverage it's strengths, what best practices to follow, you can end up in a mess like that.
And this is true of all languages honestly. I've seen this for C++, Java, JavaScript, C#, Scala, all kind of code bases that suffered this same fate, with 100% team attrition, and all kind of other issues.
I say this from first hand experience, 6 years on a team that transitioned to Clojure, in that time the team rotated fully twice, during the pandemic it had 100% attrition, even I left (working on another team), but all the new developers, even though they have zero Clojure experience, had no issue understand the code base and start making improvements and building new features, velocity saw no impact whatsoever. You get the usual some of them would rather it be something their more familiar with, others are loving it, some don't care either way. But no complaints about the code base itself, no talks of spaghetti code, or challenges to debug anything, or understand what's going on.
Basically don't expect Clojure to save you from yourself, it's an asset when you know what you're doing, not a safeguard when you don't.
Wow, I've finally found my tribe. All of this rings true for me. I kept hearing about how Clojure is this life-altering programming language that would make me forget all others and want to write parentheses for the rest of my life. But after working at a startup using Clojure for a couple of years, I've come to a couple conclusions about it: a) it is indeed a really nice, consistent language that's really nice to read and write, and b) the choice of programming language is a rounding error when determining whether a project or company is successful.
> esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code)
And to the article's title, "building a startup on Clojure," you're better off building a startup on a customer base.
> And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).
If I was choosing a language to base the tech stack for a startup on these days I'd be very reluctant to pick anything that didn't have a local user group. Slightly more esoteric languages that enable you to write better code faster are brilliant, but if you're successful enough to grow quickly, or you can raise funding, you'll need to hire devs relatively early on. If you've chosen a stack that's too esoteric then this will be a huge blocker to making any real progress.
When I did my last startup we switched from a Python API to Node for this reason. Python is a great language but there are no devs available where I live. I can't even imagine considering Clojure unless I was in a major tech hub.
The move to remote work is probably going to be a massive benefit to building in less mainstream languages.
Counterpoint: building in esoteric languages can serve as a filtering mechanism in and of itself. Given how broad the swaths of JavaScript and Java developers are, they can be much more hit-or-miss.
Counterpoint counterpoint: Esoteric languages attract PL nerds, who are much more interested in using every new/different "expressive" feature of the language than in getting business done using clear code understandable by anyone on almost any level.
True. But if you have a good well-enforced, sane style guide, then expressive powerful languages can be a good thing. If you hire devs who care more about playing with the language than delivering value then you're hiring the wrong people. You can't ditch these languages because some people are sometimes attracted to them for the wrong reasons.
I actually did start a company using Clojure. All these points are true. Yes, it helped filter candidates in the early days, and also helped attract people to jobs that might otherwise not be that interesting or competitive. It's difficult for pre-funded companies to compete with the FANG companies.
However, there were negatives. At the time the Clojure library landscape was less mature. Clojure developers would also tend to abandon projects to create "the next best version" which made migrating and keeping up with the libraries of the day difficult. Most of the libraries were very rough around the edges too. On the other hand we could use any Java library which was a boon.
As the team grew, it became harder and harder to hire people in larger numbers. Especially in a single timezone. Also it became apparent that many of the people who were very happy in the early days, were increasingly less happy as we added standardization and protocol to our dev process. As some commenters pointed out many of the people attracted to Clojure liked playing with the latest and greatest, and things were "boring" when they couldn't work with whatever the latest fast changing trend in the community was. Trying to teach people Clojure also an issue. For some it was challenging, and for others, they were not really interested in using it.
It was a good learning experience, but I don't think I'd do it again. There is something to be said for using "boring" technology for the majority of your tech stack.
I must note switching from novelty to boring phase is a crisis which every growing project will come through once it starts to expand its workforce. I saw it in teams with very average tech stack many times.
Esoteric languages by-nature have smaller populations of devs. They demand higher salaries for their specialist work. This can hurt you as you scale - salaries continue to increase (secularly), and the pool of possible engineers begins to shrink within your locale.
If you hire developers based on the languages they know / think of languages and stacks as part of the long-term identity of a developer, then you should not use esoteric ones. This is well known! On the other hand significant parts of the industry don’t do the former, so they are free to do the latter.
As an example, nobody knows Go when we hire them to write it.
Hopefully WFH helps there. In my niche Scala it does. We can hire more broadly. We also hire ppl with an aptitude for Scala and keep our style simple. That helps.
Having been at a Clojure startup I can second this, despite our non existent brand we found great candidates. And teaching a smart junior developer Clojure wasn't harder than teaching people Ruby or Java. As soon as the initial lisp shock is over learning is much faster due to the simplicity (it's just data).
Good point! In my experience, you don't need to hire "Clojure developers". Look for good candidates that have worked with functional programming languages and you'll be fine. They'll get up to speed in a matter of weeks. Any flexible and educated developer can use Clojure, it's not magic.
In other words, it's not about hiring a "Clojure developer", it's about hiring a good developer.
> building in esoteric languages can serve as a filtering mechanism in and of itself.
Yes, definitely in growth periods you get the best developers migrating to it. I'd say Rust is like this now. The problem is a few years time they'll move on to the next big thing leaving you stuck. I'd think Clojure is in this spot right now.
It absolutely does, because there’s a self-selection in being interested in an esoteric langage (assuming it’s not a corporate oddball or legacy langage) which raises the average above the background of targeting “employable” langages: people going through this process show more interest in the field.
Though that doesn’t mean they’ll be more productive, and then adds hiring challenges. So the break-even is not simple.
One of pg’s early essays was on exactly that subject (“the python paradox).
As a Scala dev, I had a similar belief as you: Scala using companies seemed to have higher calibre programmers. Until my current job at a major Telecom.
The code is all Scala, but written by a bunch of ex-Java devs. I have made attempts at education, and the code is improving, but the fundamental structure of the services are bad, and there is still a lot of bad code. I am not saying this as a FP purist, some of the code would be bad by the standards of Java programming.
Bad programmers then hire other bad programmers. Because it is hard to find experienced Scala developers, they have brought in people with java experience, or big data Python programmers who claim to have some experience using Scala with Spark. I am now involved in the hiring process, and it is slow and dismal. To be fair, the kind of contractors this company hires are mediocre, regardless of language.
The features of Scala create novel ways for confused programmers to screw up, and we aren't even doing anything esoteric, like pure FP. I suspect there are some similar traps in Clojure.
When it was released, there were two camps to adopt it: people that wanted an FP, and people that wanted a better Java. Since Java went through a long period of stagnation, most of the Scala code out there is written by Java developers that just wanted a better Java.
Kotlin has stepped in and replaced Scala for "better Java" role. But this history has left a pile of crap code written by people who didn't want to use Scala.
Clojure doesn't have this problem because you couldn't ever use it as just a better version of Java.
However I wouldn't mind coding in Scala. I like OO, I like FP, I'm comfortable with expression based programming and immutability. Based on that alone - and playing with Scala in my spare time - I feel like someone with my background may be more suited than someone with a commercial Java "mutate every variable" background.
Had this exact experience trying to hire at startups for Scala/Spark. There’s only so many Scala devs to go around. It also doesn’t help that “good” Scala is highly subjective, with different levels of Scala from better Java to functional paradise.
I’ve been happily coding (and hiring) in Python for the last four years or so. Still doing Rust and some Scala at home where deadlines don’t exist and hiring is a non-issue.
I haven't gotten to that stage yet. But I think it's difficult to hire good devs for all stacks, be it Python, Ruby, JS. Clojure community is super friendly and full of very talented developers and I'd love to pay someone to write Clojure :).
2 years ago I was hired into a Clojure based start-up with no experience in Clojure. It is easy to learn, and I love it now. One of my duties is hiring, and we don't look for developers with Clojure experience. Instead we look for developers with good skills in any language, and trust they'll be able to figure out Clojure. In a way, it has actually widened our hiring pool since we can't be shackled to the XXX years of experience in YYY approach.
We're paused right now since we're prepping for a funding round. However, have you checked out the Clojurians slack? They have a #jobs channel which is pretty good.
Also a point for node: in the time people have argued about how node sucks (some valid points, all easily mitigated) and how X is better, they could have already shipped a bunch of nice features.
Focusing only on web stuff.. If you have a good grasp of design patterns and you can build out your system in a modular way, I think node is a great starting point.
I love starting with node because typescript is awesome, the performance is nice, the community support is tremendous, the scaling is easy, and finally it’s easy to move off it. If some part of the system starts becoming a bottleneck, just swap that piece out for something more suitable. One thing I like about this time right now is that most things are built just fine to be used in creating something new and useful products.
Have we learned nothing from covid? You don't need to limit your talent pool to your own backyard. Especially since you're not in a major tech hub, by your own admission.
Learning a language like Python is easy enough, but the hard bit is actually unlearning the language you came from. If you give a JS dev a couple of weeks to learn Python they'll probably succeed, but their code will be 'python syntax written with a JS thought process'. The code will work but it won't be good code. Sometimes that's fine, but as the foundations of a startup?
Getting to the point where you're writing good Python and taking advantage of what the language provides, knowing the ecosystem, and building things that other Python devs won't look at and think "Wtf?" takes much longer than weeks.
Syntax is probably within an hour. Spurious colon in a few places, whitespace deemed more important than lambda. Brief confusion over the scoping rules.
Then the library ecosystem is probably good for a lifetime.
For me, the killer feature of Clojure is "REPL driven development". The ability to get rapid feedback as you build things up is incredible. I'll make a comment form and evaluate expressions within it to try things out as I go. By the time I've written any reasonably complex function, all of the pieces have been tested on various examples. Once I'm done, the comment form leaves a helpful record of my thought process.
If you're wondering what's so great about the Clojure repl (and other lisp repls) in particular, the thing is that you never have to actually type something into it. You can run evaluations from the code file itself. The structure of lisps makes it clear exactly which code you want to evaluate. To do this, I use the excellent CIDER package for emacs. I understand Calva for VS Code and Cursive for IntellJ offer similar functionality.
I kind of agree with you. I used to work with Common Lisp in a Desktop App (Nyxt browser). I had some fun playing with Racket. And I love Emacs. So, I am already into the Lisp idea. But, I was kind of disappointed with Clojure which is new in my life and has been used in my current job. Maybe you have a backend bias in your testimony?
I have been working with ClojureScript (re-frame and reagent) on front-end stuff and, unfortunately, the REPL does not seem to help me that much on my workflow. I miss the REPL driven development, by the way... The real "interactive programming" seems to happen on Chrome Dev Tools + Browser's reactions to Chrome Dev Tools tweaks on the UI + (lastly) changes on the source code via the editor (Emacs in my case).
Namespaces as prefix of invocations on the REPL are not that trustworthy on ClojureScript, apparently. It could also be that I am a noob and I missed something, so... How do you feel about ClojureScript?
Don't know about your exact environment but I've structured my code so most of it is in .cljc files which can be evaluated in browser and on server. This allows me to evaluate/test/run things easily in the emacs repl.
For view code I think hot reloading has been a great thing with Clojure/Script too. Everything is reloaded properly and the state remains.
I have basically the same experience doing cljs dev that I do with clj dev, when it comes to being REPL-driven.
I know that the setup for cljs is a bit more involved and things will break sometimes (putting a browser in the loop will do that). I have dev tools open ... but I use it less and less, between hot-reloading and a data browser (portal or reveal) hooked up to the clojurescript repl I only use dev-tools stuff occasionally (the network tab is still very important of course).
It does sound like you are missing something, I'd try out one of the shadow-cljs example projects or walkthroughs to see what an example setup includes as features to see what you might be missing.
I don't want to overstate my experience--I've used neither professionally. But I think it's true that the repl is better with Clojure than with Clojurescript. Cider with shadow-cljs is very nice but not quite as well-supported as vanilla. Plus, the very fact that you're producing code to be rendered by a browser pushes the work you do on the pure data level, where the repl really shines, towards the background.
If you haven't used a lisp or lisp clone, it's hard to describe fully. Still, the fact that you can trivially replace and reload modules in running code or being able to fix a bug in a function and resubmit the input to the function from the stack trace is amazing ergonomically.
In the same way that most languages have lambdas, it's very different from being able to trivially compose functions into new functions. (This one I can't even describe well, but if you try and write SICP exercises in a lisp vs. python, the difference is obvious.
Do you have any examples of this? Like a video on youtube or similar?
I have used Clojure before very lightly but I didn't really use the REPL in this way. I rather used it the same way I use it for javascript, python or any other language.
Our experience building a business with Clojure has been amazing. It has helped us to attract extremely strong engineers, and churn has not been a concern in the slightest. We've taught people (from code beginners to experienced engineers) Clojure, and all of them are able to start adding value in a very short space of time. We're six years in and there are no signs of increased maintenance difficulty due to the language. We follow the Polylith Architecture (https://polylith.gitbook.io/polylith/), which has given us yet another boost in
developer happiness, speed of delivery, and ease of maintenance. There are many extremely large Clojure code bases out there (Ladder life, Lemonade, Simply life, Wallmart, Nubank, Atlassian) not suffering from the maintainability issues that some people here have described.
After six years, I would absolutely (without hesitation) start another business with Clojure as the core.
I have not built a business with Clojure and I wouldn't recommend it. For the reason that I'm hoping one day to build one and beat the averages. Stay away from Clojure, or else... :)
No, I don't, but I probably should write one. I write about my experiences in various posts/comments from time to time, but that is lost after several minutes, as The Internet moves on to the next shiny thing :-)
My company (as in "I work there," not "I own it") is I think unique in that it started as an Elixir/TypeScript shop, things went seriously downhill, they brought in a new engineering team (I'm on it), we switched to Clojure, and we're doing fine.
If I were to start a new company I'd absolutely run it on clojure. Even without frontend/backend code reuse, REPL-driven dev---paredit is the killer app for me. It just makes editing text files, which is what we're doing if we admit it, so much easier.
This might actually be the first thing I've seen pop up organically about Elixir that isn't red hot glowing praise. Can you elaborate on what was going wrong and if it was anything specific to Elixir/Typescript?
From what I can gather the old CTO did some things that were...less than ethical.
As far as the code goes, they wrote a custom DB that is O(nm) when counting tables---that is, it must count every record in the DB to count how many tables there are.
(Incidentally, I had forgotten this the other day and tried to do a "quick" table count...oops!)
I don't know Elixir or TS well enough to say if we have Ex/ts problems---from what I can tell:
- Elixir seems alright, I'd love to learn what the BEAM magic I keep hearing about is
- however, syntactically I find it pretty garbage, or at least uninspired. (Note that I am a spoiled Clojure guy and have this reaction to Python, Ruby, etc. I acknowledge people can get productive work done in them.)
- TS I have ha-ha-kinda-seriously trauma about from a previous job. I'm not a good person to ask here b/c I'm pretty firmly pro-dynamic in the Type wars. I will say that it is pretty freaking great to be able to have an emacs buffer open w/a repl to the cljs frontend we have for other apps, and that I really miss it whenever I have to go through the ts code.
> Any sufficiently complicated TypeScript or Java program contains an ad hoc,
> informally-specified, bug-ridden, slow implementation of half of Clojure.
Once you grokk the approach and workflow Clojure takes in solving problems, the distance between having an idea and writing a rock solid implementation of that idea is the shortest I've experienced in my ~20 years of programming.
If you want to write succinct, transparent code whilst minimizing the future potential of introducing bugs, Clojure is as good as it gets.
If you did a Spring tutorial, I can see that this might be the takeaway. For me, I was thrown at a large project with a couple of large Spring codebases, I concluded that it's about structuring your code around an object graph with independent, testable, loosely coupled components.
I use both Spring and Java professionally. For a pretty long time now. I was being somewhat sarcastic.
I mostly use Spring because it's pretty widespread and I figure - why fight the current. But I still think the benefit is minor for most projects. And the existence of Spring Boot makes me chuckle a bit.
I get you. I think it encourages a certain application structure that is at least recognizable across projects. There's a pretty big benefit to that, even if at the detail level it's just a way to avoid new.
Maybe theoretically true (I'm not sure about the extent of the completeness), but definitely not practically true when it comes to annotation-driven-development frameworks such as Spring.
Ah. While objects have their uses, I think the Clojurist might prefer, well, closures. That's not to say one is better than the other, just that the Clojurist probably won't miss the style of the Spring framework.
Besides being fun for sure because you can use whatever you want for your own stuff I don't see what's special about clojure here. They are using react (behind a wrapper), IME, clourescript is not worth the hassle. On the server they are using ring/compojure which is similar to js/express, python/flask that can get the job done equally well in this case. The story would be more interesting if they were using something like datomic instead of postgres since datomic is were clojure could differentiate itself.
Keep in mind that they have to juggle between almost four different languages, Java, Javascript, Clojure and Clojurescript, almost because there are differences between Clojure and Clojurescript. Instead of for example just using one language: JS.
ClojureScript is one of the main reasons why Clojure makes sense in my business. I can use the same language and share the same business logic code between the server and the browser app. That's huge!
Also, I avoid a load of problems related to communication and serialization, because the native serialization format is EDN, e.g. Clojure data structures. There is no need to adapt your data structures to the limitations of, say, JSON.
EDN also contains support for date and UUID literals, the former of which is a huge pain when using JSON and needing to communicate which standard you're using and remember to encode/decode on each side of the wire.
Plus you can even write your own reader literals to enhance your data format. Aero does this well/horribly depending on your taste but it's a cool mechanism for declarative formats.
Yep, two types in fact, line comments with ; and a discard sequence - you can tag code that is read (so it must be correct), but then discarded. We have edn files that are well documented with comments.
or something else? And how can I distinguish between values which just happen to look like maps but are actually not maps? And what if the service I'm talking to does it differently? What if I'm comparing or sorting two JSON values, don't I have to modify the equality/hashcode/ordering logic now to interpret
[
["key", "value"],
["otherKey", "otherValue"]
]
and
[
["otherKey", "otherValue"],
["key", "value"]
]
as being equal and implement a new hashcode/ordering which treats them as equal?
Quite a lot easier when this is just native to the format.
Arguably the JVM is a better backend platform, due to better performance, observability, scalability, parallelism (it is not even a competition, and then we haven’t even talked about Loom), plus the least objective point of mine, more stable, battle tested libraries.
That's like saying that C++ is a better backend platform than the JVM due to better performance. For 95% of business web apps out there it doesn't matter, I mean, multiple business with evaluations in the billions of dollars have been created with runtimes 50x slower than nodejs.
Nodejs competes with Java in single threaded performance, I'll say normal JS code is faster than normal Java code. For web services that are IO bound, nodejs still competes with Java unless you go with all the batshit crazy complex reactive stuff in the Java world, supposedly is going to get better with the new green threads implementation.
You may have missed the other 10 reasons I listed besides performance.
Also, no JS code will be faster than Java. While both have insanely good JIT compilers that can output some truly, often surprisingly great machine code, java is all-around faster, if for no other reason, due to its killer GCs.
>That's like saying that C++ is a better backend platform
C++ isn't even a platform, period. It provides no runtime or anything else other than the language. If you build on top of the JVM ecosystem, similar to NET you get a cross platform, extremely performant ecosystem with millions if not billions invested into it basically for free.
And of course you can build a billion dollar company on a crappy tech stack, but if you had built it on a good one you'd still be a billion dollar company and be even better off. What a strange argument, you ought to make the best technical choice you can, it's a core part of anything you built. And getting a 10x performance on the JVM vs say Python, or smooth, non error prone concurrency in Clojure is a significant benefit.
In particular in business applications were you usually deal with data transformations, the single-threaded, mutable state type of design of some languages is awful. Clojure in particular was exactly made for this practical use case.
JavaScript is one of the few languages that works well both in the browser and on the server side. I don't think this is the time or the place to explain why I didn't write my software in JavaScript — let's just say that I don't think I could handle the incidental complexity in my team of size 1.
As for JSON, others have replied, but my point was perhaps not very well made. It's not just the limitations of JSON itself. By using the same language on both sides, I can avoid adapting to the limitations of any transit format. In other words, I can (pretty much) pass native data structures through and get them out on the other side. In my case, that means not just maps and vectors, but also sets, keywords, or UUIDs. Can this be done with JSON? Sure! But then I'd have an entirely new bug area to deal with (encoding/decoding, forgetting to coerce, etc).
I don’t use Clojure but based on a quick search, EDN is extensible so you can serialize things like datetimes and UUIDs with type information rather than as plain strings
I worked at a startup that was built on Clojure. It had trouble finding developers for reasonable salaries at the early mid stage. They decided to switch the stack to python at that point. Just an anecdote!
I think this is the key here. Clojure developers are expensive (see the Stack Overflow charts for how being a Clojure dev essentially guarantees a great salary) — but that's not because of them being Clojure developers, but rather because of them being more experienced, knowledgeable, and flexible than your "average" developer.
If you start a business and use Clojure, you should expect to hire more expensive developers. You will, however, need fewer of them, so this might all balance out in the end, especially as we all know that teams don't scale infinitely.
They are expensive purely because they are a smaller pool. I doubt they are automatically more capable. I did work with many and now write clonjre myself. Doesn't make me, or them automatically better devs imo!
They aren't automatically more capable, it's just a well known and frequently noticed fact that Clojure tends to attract more senior developers, and the community is very senior dev heavy compared to other language communities.
So of course that is interesting, probably says some important things, and moves the average salaries up as well. Everything points to "Clojure tends to attract some subset of better devs" rather than it making them better.
There are clearly also effects from the small pool of available candidates, the high output of experienced Clojure devs, etc but generally being in a smaller ecosystem doesn't drive prices up.
Building a company in Python feels like a bet against yourself ie the company/codebase will never get big enough that using Python (lack of static typing etc) will ever be a problem
The problem is that coverage of typing in third party libraries is not that high yet, so it’s not really possible to enforce typing in a thorough manner.
I’m aware. Before Python I wrote primarily in Scala and I do Rust on the side. Good luck hiring at scale for those without either offering a really interesting product to work on or lots of $$$. Even then, still easier to hire for Python.
The only code base that wound up being unmaintainable in that particular startup was the Clojure code base. I guess my point is no matter which language you are using, they all suffer from aging as they grow in size and addition of maintainers over time. The python code base was all incorporating mypy into the build / deploy pipelines and it worked quite well in my opinion. I am a huge fan of the recent additions to python and the work done there for static typing like mypy, pydantic, etc.
I'd take that bet any day. At the rate the language is improving, there'll probably be a good Python static optimizing compiler before its lack is a problem.
I started writing Python at work again after not using it for many years and was surprised at how useful type definitions are in modern Python. The notation is slightly awkward but it works well enough to provide a lot of the maintenance benefits of static types.
If you use Python and you aren't aware of its tradeoffs, yes it is going to bite you.
Dynamic typing and the lack of a formal compilation step are great for productivity, but they come at a cost. You need a proper CI pipeline to run linters (granted, you need that in statically typed languages too) and, most importantly, you need to write tests. Sure, you need to write tests for any language, but not having them for languages like Python is going to bite you that much harder.
I've seen pretty large Python codebases that worked just fine. And smaller Java codebases that were unmaintainable.
With GitHub Actions building a solid CI pipeline has never been easier. I built one with linting, tests, coverage and packaging to ghcr in an hour this weekend for Go. Python would have been very similar.
I don't know how any non-FAANG companies in the bay area hire non-junior developers. I have 4 kids and the difference in mortgage payments alone for relocating there is well into 5 figures per year.
Always great to see more start ups being built on Clojure! For folks interested, this is a great talk on the same subject: https://youtu.be/L9KcoRZcdbc
Full disclojure: I work for the company in the talk, though I'm not one of the presenters.
One thing to note about coding in Clojure — if you never learned Java, you hit a wall at a certain point. I only know scripting languages and I had fun writing little scripts in clojure, but at a certain point the lack of java knowledge and it's class system / standard libraries held me back from doing more serious things.
It was interesting to me the author seems to use 'old-school' Clojure, for lack of a better phrase, with lein as the build tool, etc., rather than more recent tools/stacks; I don't use Clojure myself, is my impression off?
Something being "more recent" doesn't necessarily make it better :-)
I use leiningen, too. I tried other approaches, but had trouble getting them to do everything that I need (for example, AOT compilation of the entire code that goes into the final .jar), and I couldn't really see any massive advantages.
deps is more flexible, but I you just want to run a repl, build and deploy code then lein still works fine.
I usually default to leiningen: I can't be arsed to spend time configuring deps to do what lein does out of the box. (For example: building an uberjar)
I was lost when I moved to deps from lein, but just forking and cloning https://github.com/practicalli/clojure-deps-edn as $HOME/.clojure solved the problem - this base deps.edn contained all the aliases I needed - creating a new project, searching and adding dependencies, hooking up data inspectors like portal or reveal, testing, code coverage, benchmarking, building uberjar etc. Moving to deps also introduced me to polylith [1], which has been very useful for building large multi-component projects
Question for Clojure's pros: as a designer I started programming javascript for a long time, now I can do my own APIs on Node easily, would it be hard to do APIs in Clojure? Can you recommend me a video course for learn it?
I learned by reading through a book, then working through problems on https://4clojure.oxal.org/. If you've got JS experience it won't take too much effort to pick up. Don't get too carried away with forming the perfect tail recursive pure functional monad or whatever. Get into just doing what you're trying to do quickly, then after you're competent, read other people's code to correct your style.
Well, i have to add having developing in a Clojure shop that starting to develop a new feature with Clojure is easier than Kotlin, you don't have to care almost about of the shape of the data. But later, this is a pain, you need a lot of discipline to document because you would look back at this code a who knows what data are you receiving.
In addition i have to say, that a lot of libraries are falling into clj-commons because the original developers no longer works on the project, other like compojure, that is mentioned in the blog post last stable release is from 2016 and version 2 is in alpha since then.
I am curious why are you using c3p0 on 2022 when hikaricp is being maintained, and last release of c3p0 is from 2019. Also no support for R2DBC.
My impression is that in the last 2 years, the ecosystem has shrink, less talks, less new libraries, new libraries that are no longer maintained.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library. No conversion from Java 8 CompletableFuture to clojure async primitives in 2022. And i think they not going to support it in the near future.
What i am saying is that Java is in the future, and Clojure is in the past. They just cannot catch with new Java features and i doubt they are going to support it ever. You can still run it on modern jvm because they update the bytecode but that is all.
Others problems arise is that Clojure lag a bit with compatibility with new Java features, still i think Clojure cannot pass Clojure functions as parameter to Java functions. It results in awkwardly having to reify Java function interface to pass function when using a Java library
Ouch, Java 8 was released in 2014. To be fair, Clojure was never a community project though.
What does everybody think here of C#? I've just made foray into it and I like it a lot compared to Python, Java etc. It almost feels like Kotlin, but with certain even cooler properties.
- Tons of developers know it
- Tons of Java developers can be made to know it with ease
- A good default IDE experience within VS and VSCode, and a JetBrains product if you prefer it.
- A good LSP implementation with OmniSharp if you don't want to use an IDE.
- ASP.NET, a good default Web framework.
- NuGet as a package manager with tens of thousands of packages.
- Better than java reflection and runtime generics.
- Cross-platform CLI tooling since .NET Core, now it's just .NET.
- Ability to deploy self-contained applications.
- Mono version of C# is used for making games.
- A continuously evolving cohesive language with minimal competitors (like Groovy, Kotlin, Scala, Clojure, etc... on the JVM)
- F# if you want a stricter functional language that interoperates with C# seamlessly.
- PowerShell as a way of interactively running any .NET assembly, regardless of how it was compiled.
And many more... C# is one language you can build a career on and also use for hobbying and have fun.
The haters will complain that MSBuild (the default build system) and Visual Studio suck. If you've tried them in the past, you're probably right. Try them again in 2022 and see if your opinion doesn't change.
Thank you. I tried a JetBrains product and Visual Studio but VS was both faster (on my Mini Mac ARM M1) and the visual aesthetics were better--not to mention the overall IDE experience was very comfy, it felt like VS was strictly made for C#.
I do want to branch into F# and FP but i didnt want to miss on the C# train so i tried it and it blew my mind how well the language has been designed (i mean at C# 10, .NET 6). They even made the Java-esque boilerplate thingies become automated so the code reads and feels almost like a better version of Javascript.
I am a new programmer (with only Intermediate Python and tid bits of CS under my belt) but i think choosing C# for a language made sense because of all the things you mentioned, and it also helps that it is aesthetically very beautiful, and worlds apart from C and C++ in many respects.
I'm glad you liked VS for Mac. I personally do not like it, it's a reskin of the Xamarin IDE that Microsoft acquired. Visual Studio on windows is IMO the real Visual Studio experience for C# and you should try it if you get a chance. There's tons of extensions for the IDE (including a Vim one!) and if you're bought into the MS ecosystem it has widgets for EVERYTHING:
re-iterating what onion2k said, hard pass on building a company around an esoteric language. enjoy attempting to hire people to work on this. best case you get an eager programmer wanting to learn the language. worst case you get zero experienced hires unless you’re a massive success.
The real worst case scenario is facing a competitor that's much faster than you on implementing new features and testing hypothesis. Using an esoteric language might be one of the leverages that this competitor has against your tight mainstream stack.
i’ve worked with people like you in the past. they all write books for their language now. none of them correct. it’s almost never the language that holds you back. it’s the organization and it’s priorities. an easy example is instagram and their use of python. they crushed with a language that clojure folx look down on.
In 2022 thinking that your esoteric language is going to help you implement new features faster than with a mainstream language is just plain language zealotry.
On the basis that esoteric languages come with fewer libraries and new features largely involve gluing libraries together to make things like other things that already exist?
That "best case" seems dishonest at best. How is the best case not "Best case you get awesome programmers with lots of experience and knowledge about what Clojure is all about, being able to ship software better than anyone else" or similar?
Clojure has pitfalls for sure, but no need to be dishonest in order to flag them.
I would also argue that the productivity delta between something like Clojure vs Python or Javascript or Kotlin is not as high as it was between Common Lisp vs C++/Java 10-15 years ago. So the payoff for a risky bet is not as high.
That said I would love to work in a lisp full time. There's just something appealingly elegant about it.
We have a number of libraries that are easy to use together for the backend, no fancy web framework (build your auth page yourself), no fancy client-side lispy libraries. We might have a Fighweel-like tool, but no one is interested (Trident-mode for Emacs).
There's one framework that looks promising to build fully dynamic apps in pure CL with one code base (websockets inside). It provides a GUI-like experience to build all kind of apps (a website, a chat, the snake game…): https://github.com/rabbibotton/clog/
I am using Hunchentoot, a routing library on top (easy-routes), the Mito ORM, and for the client side I am conservative: HTML templates with Djula, interactivity with HTMX, Vue if required, JS.
The great thing is that I can build a standalone binary of my web app, including the static assets, the webserver, the lisp compiler and debugger… for ±28MB unzipped and instantaneous startup times.
Not an expert, but I would expect hunchentoot https://edicl.github.io/hunchentoot/ for the backend and a Common Lisp "dsl" generating javascript for the frontend.
I am a hobbyist lisp developer and have written webapps in CL.
I use cl-who[1] for generating html and parenscript for javascript. I use clack on the backend, but hunchentoot is probably more popular. Both backends have plenty of routing libraries available (hunchentoot comes with a decent one baked in, clack does not).
postmodern is a Postgres specific sql backend that is great. There are database-agnostic SQL libraries as well (clsql and cl-dbi I believe are the two big ones) but I haven't tried them.
1: People whose opinions I trust have told me that spinneret is a better choice. It did not exist when I learned cl-who. cl-who is "good enough" for me that I haven't switched.
Here's a nice interview of a company using CL for their document processing stack: https://lisp-journey.gitlab.io/blog/lisp-interview-kina/ (edit: not a pure CL web stack: Ruby to CL logic via websockets to a lispy client side)
some recruiters tried to recruit me a while back. too bad they wanted an experienced clojurist for their client. i mean, it's good and all but it's too hard to find some corps which use clojure around here where i live.
so, yeah. while i'm excited with lisp, i don't think i have the gut to start my own shop with clojure as the main language.
If you're really lucky, someone will have thrown in a bunch of 'specs' that make a bunch of assertions about the data, put them on the API entry points, and then scattered some slightly different specs with slightly more restrictive assertions on various 'internal APIs', resulting in random explosions in production!
And the joy of working with an esoteric language is that it attracts esoteric developers, who often get frustrated by the requirements of being a software engineer in a large company (i.e. everything that's not writing code), which leads to the aforementioned 100% dev churn (after a lot of shouting).