Earlier quoted context omitted.
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.
I disagree.
love the substance in your comment
Building a Startup on Clojure
91–100 of 215 posts
Re: Building a Startup on Clojure
#92My 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.
It's a data point.
Re: Building a Startup on Clojure
#93re-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.
Re: Building a Startup on Clojure
#94Ah 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…
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.
Re: Building a Startup on Clojure
#95For 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.…
I don't understand, doesn't most languages these days have a REPL?
[deleted]
Re: Building a Startup on Clojure
#96One 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.
Re: Building a Startup on Clojure
#97Ah 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…
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.
Re: Building a Startup on Clojure
#98Ah 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 collapse once it reaches 500k+ LOC Java, 500k XML, 300k SQL ...
Re: Building a Startup on Clojure
#99Ah 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 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.
Re: Building a Startup on Clojure
#100Ah 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…
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.