Kind of shocked that building database libraries for python (homebrew install gcc? pip install foo) was "hard" for them.
I find the Python ORM options (sqlalchemy/Django/etc) lot better evolved than what is available for clojure and couldn't image that being a roadblock. Korma is basically a query builder and lacks a lot of things I was used to, and I had to engineer a declarative layer for defining models in the ways I wanted.
Pain in setting up developer machines could be simplified with an ansible playbook pretty easily.
OTOH, one of the worst things I hate is trying to figure out how to automatically get around Sun's paywalls and fiddle with Java classpaths :)
I do feel some level of want to avoid vagrant in the development workflow, in which cases I'm usually fond of just logging into a real VM. I do think it's potentially good for tests.
IDK, I always want to solve the idea of "fragile deploys" with immutable systems in prod. Uberjar was cool, I'll give it that -- but the startup time of clojure was often not worth the wait.
My biggest complaints with clojure is documentation quality,
inconsistency in return types (or just willingness to return nil in error scenarios), and tracebacks that are very difficult to sort through.
Clojure also presents some problems with the idiomatic nature of trying to roll up everything into one statement, whereas adding debug and debugging require unrolling it, than packing statements up again to be socially acceptable idiomatic clojure.
Testing in clojure also strikes me as painful, as it tends to punish you with "let" causing an indentation every time you need to assign a variable, something that is useful in tests that want to check results a lot along the way.
My gut feeling is clojure was good for a little light scripting on top of a big Java codebase (kind of like you might use Lua in a game engine) but would not be something I'd pick for a primary language. Primarily using Java libs would also solve some of the ecosystem problems.
It's not hat "homebrew install gcc? pip install foo" is hard for us, it's that we didn't want to support 1000s of people trying to set it up on their machines.
Every possible source of error we eliminated meant we'd need to spend less time on twitter debugging installation problems. It's useful to remember that our target install base isn't python developers who might want to hack away on a python project, but rather analysts, end users, DBAs and all kinds of people who've never heard of homebrew and who might not even be comfortable with using a terminal in Mac OS X let alone compiling things.
So why can't you release an installer? You are not compiling .NET. If many desktop applications are either written in Python, Java, or C++, so what prevents you from releasing an installer? Heck, even Go programmers have to think about compile cross-platform.
For what it's worth, Korma isn't an ORM such as what you would use in Python. It's a relatively thin wrapper around SQL queries. I don't know whether they found that to be plus or not, but it would put it in a slightly different category than the Python ORM options.
I'm also betting that the startup time of the JVM wasn't terribly important in their scenario.
The fact that it wasn't an ORM was a huge win. We effectively had to build a dynamic ORM that modeled our end user's data warehouses which is a very different problem than a normal web app's database access patterns.
sqlalchemy is my favorite library for pretty much any language. It's fantastic and a huge part of the python draw for me. The only downside is it doesn't play well with new async python tools, but python is totally fine at not being async
I find the Python ORM options (sqlalchemy/Django/etc) lot better evolved than what is available for clojure and couldn't image that being a roadblock. Korma is basically a query builder and lacks a lot of things I was used to, and I had to engineer a declarative layer for defining models in the ways I wanted.
Pain in setting up developer machines could be simplified with an ansible playbook pretty easily.
OTOH, one of the worst things I hate is trying to figure out how to automatically get around Sun's paywalls and fiddle with Java classpaths :)
I do feel some level of want to avoid vagrant in the development workflow, in which cases I'm usually fond of just logging into a real VM. I do think it's potentially good for tests.
IDK, I always want to solve the idea of "fragile deploys" with immutable systems in prod. Uberjar was cool, I'll give it that -- but the startup time of clojure was often not worth the wait.
My biggest complaints with clojure is documentation quality, inconsistency in return types (or just willingness to return nil in error scenarios), and tracebacks that are very difficult to sort through.
Clojure also presents some problems with the idiomatic nature of trying to roll up everything into one statement, whereas adding debug and debugging require unrolling it, than packing statements up again to be socially acceptable idiomatic clojure.
Testing in clojure also strikes me as painful, as it tends to punish you with "let" causing an indentation every time you need to assign a variable, something that is useful in tests that want to check results a lot along the way.
My gut feeling is clojure was good for a little light scripting on top of a big Java codebase (kind of like you might use Lua in a game engine) but would not be something I'd pick for a primary language. Primarily using Java libs would also solve some of the ecosystem problems.