Earlier quoted context omitted.
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 :). Yes, remote work for sure is an edge when hiring! Also reminds me of the essay "The Python Paradox" by Paul Graham ( http://www.paulgraham.com/pypar.html )
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 o…
Building a Startup on Clojure
111–120 of 215 posts
Re: Building a Startup on Clojure
#112It 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?
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)
Re: Building a Startup on Clojure
#113Ah 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…
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.
Re: Building a Startup on Clojure
#114Greenspun's tenth rule, adopted for 2022: > 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 program…
> Any sufficiently complicated Clojure program contains an ad hoc, > informally-specified, bug-ridden, slow implementation of half of Spring.
Re: Building a Startup on Clojure
#115Ah 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…
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-l...
Re: Building a Startup on Clojure
#116Ah 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…
Wow. Pretty insightful :)
Re: Building a Startup on Clojure
#117Greenspun's tenth rule, adopted for 2022: > 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 program…
Re: Building a Startup on Clojure
#118Greenspun's tenth rule, adopted for 2022: > 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 program…
Cute, but i'll counter with this one: > Any sufficiently complicated Clojure program contains an ad hoc, > informally-specified, bug-ridden, slow implementation of half of Spring.
Jokes aside, can't Clojure simply call whatever you want from the JVM?
Re: Building a Startup on Clojure
#119Earlier 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…
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 Cl…
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.)
Re: Building a Startup on Clojure
#120Ah 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…
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...