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!
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
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.
Including Spring itself? Jokes aside, can't Clojure simply call whatever you want from the JVM?
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.
> 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.
clojure inherits the exact same debug tooling you describe
except the debugging experience in clojure is much more difficult - try step debugging through a macro.
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 mak…
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?
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!
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
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.
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.
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.
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…
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 a…
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.
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.
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.
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…
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 a…
> As the saying goes, a bad workman always blames his tools.
And many times purveyors of a bad tool blame the workman.
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…
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.