7 ms·

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 f

by ldite 4y ago

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

CyberDildonics 4y ago
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.
- christophilus 4y ago
  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.
- freilanzer 4y ago
  As opposed to the paradigms of beautiful design that are Java codebases.
  - CyberDildonics 4y ago
    What does a bad java program have to do with a language who's advantage and use case is to be clever on an expression level?
dustingetz 4y ago
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 ...
- ldite 4y ago
  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.
- seer-zig 4y ago
  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.
  - Kamq 4y ago
    > The tooling around it is second to none I feel like you've never looked at C's tooling. Admittedly, some of it is stuff you just don't need in Java, but things like Valgrind are crazy impressive.
    - seer-zig 4y ago
      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.
gered 4y ago
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.
- strikelaserclaw 4y ago
  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.
  - gered 4y ago
    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.
  - synthc 4y ago
kbuchanan 4y ago
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.
synthc 4y ago
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. I found some the advice in this blog post useful: https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-line-clojure-codebase https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-l...
tasubotadas 4y ago
> 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). Wow. Pretty insightful :)
Mikeb85 4y ago
Of course everything you're complaining about means that the company has been successful enough to get to that point... Startups that act too much like big companies just don't ever get product out the door and fail before you can bitch about technical debt...
yogthos 4y ago
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. [1] https://www.youtube.com/watch?v=u-4FiFpkPlQ https://www.youtube.com/watch?v=u-4FiFpkPlQ
- preseinger 4y ago
  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.
  - dkersten 4y ago
    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.
newlisp 4y ago
The same could be said about Ruby/Python/JS except for them not being esoteric. And they are wildly successful, even for new projects today.
ilkhan4 4y ago
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.
LAC-Tech 4y ago
Not a clojure fan, but: - 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.
- tartoran 4y ago
  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.
dehrmann 4y ago
> 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.
ngc248 4y ago
>>> full of functions that don't give the slightest hint of the shape of the data they're processing This is a big problem with Dynamic languages. If you are new to the codebase, you have no idea of what the shape of the data is, what to expect etc.
didibus 4y ago
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.

by ldite 4y ago

CyberDildonics 4y ago

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.

christophilus 4y ago
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.
freilanzer 4y ago
As opposed to the paradigms of beautiful design that are Java codebases.
- CyberDildonics 4y ago
  What does a bad java program have to do with a language who's advantage and use case is to be clever on an expression level?

dustingetz 4y ago

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

ldite 4y ago
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.
seer-zig 4y ago
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.
- Kamq 4y ago
  > The tooling around it is second to none I feel like you've never looked at C's tooling. Admittedly, some of it is stuff you just don't need in Java, but things like Valgrind are crazy impressive.
  - seer-zig 4y ago
    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.

gered 4y ago

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.

strikelaserclaw 4y ago
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.
- gered 4y ago
  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.
- synthc 4y ago

kbuchanan 4y ago

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.

synthc 4y ago

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. I found some the advice in this blog post useful: https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-line-clojure-codebase https://tech.redplanetlabs.com/2021/06/03/tour-of-our-250k-l...

tasubotadas 4y ago

> 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). Wow. Pretty insightful :)

Mikeb85 4y ago

Of course everything you're complaining about means that the company has been successful enough to get to that point... Startups that act too much like big companies just don't ever get product out the door and fail before you can bitch about technical debt...

yogthos 4y ago

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. [1] https://www.youtube.com/watch?v=u-4FiFpkPlQ https://www.youtube.com/watch?v=u-4FiFpkPlQ

preseinger 4y ago
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.
- dkersten 4y ago
  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.

newlisp 4y ago

The same could be said about Ruby/Python/JS except for them not being esoteric. And they are wildly successful, even for new projects today.

ilkhan4 4y ago

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.

LAC-Tech 4y ago

Not a clojure fan, but: - 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.

tartoran 4y ago
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.

dehrmann 4y ago

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

ngc248 4y ago

>>> full of functions that don't give the slightest hint of the shape of the data they're processing This is a big problem with Dynamic languages. If you are new to the codebase, you have no idea of what the shape of the data is, what to expect etc.

didibus 4y ago

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.