Live data from Hacker News

Building a Startup on Clojure

wobaka.com

101–110 of 215 posts

Re: Building a Startup on Clojure

#101
post #89

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…

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 coll…

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.

Re: Building a Startup on Clojure

#102
post #99

Earlier quoted context omitted.

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…

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.

Re: Building a Startup on Clojure

#103

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

Java has `jshell`.

Re: Building a Startup on Clojure

#104
post #89

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…

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 coll…

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.

Re: Building a Startup on Clojure

#105

Earlier quoted context omitted.

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

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…

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.

Re: Building a Startup on Clojure

#106
post #99
post #89

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…

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…

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

Re: Building a Startup on Clojure

#107
post #99

Earlier quoted context omitted.

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…

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.

With great power comes great responsibility.

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.

Re: Building a Startup on Clojure

#108
post #89

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…

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 coll…

Disagree about Java, I've worked on several large Spring applications and making small changes was not a problem at all.

Re: Building a Startup on Clojure

#109
post #89

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…

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.

Re: Building a Startup on Clojure

#110
post #99

Earlier quoted context omitted.

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…

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.

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.

Post reply on HN