14 ms·

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it shou

by tensor 7y ago

Startup time isn't what is holding the language back. In my opinion it's: 1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices. The last point has many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable. So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working. Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.

Goladus 7y ago
> Startup time isn't what is holding the language back. For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead). > For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.
amelius 7y ago
But creative people also need to do boring stuff from time to time. If they still choose Clojure, then apparently it suffices for these tasks.
slifin 7y ago
If all you want is a rails thing but with a Clojure twist I'd keep an eye on https://youtu.be/jkx9F-RIFiY https://youtu.be/jkx9F-RIFiY I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting the new one true way because most of us are refugees from other languages where it's already happened
- slifin 7y ago
  The normal one true way for most commercial companies right now is reframe, there's a nice ecosystem there and it's teachable
  - vga805 7y ago
    reframe is just the front end though isnt it? i think this is not the crud/rails alternative the op is talking about
    - smnplk 7y ago
      Checkout Fulcro http://book.fulcrologic.com/#_fulcro_from_10000_feet http://book.fulcrologic.com/#_fulcro_from_10000_feet
crispinb 7y ago
As someone just playing with Clojure for curiosity, I agree that it's hard to find a way through the thicket of available tooling & library options. On the other hand, to start with just picking something reasonably mainstream (in Clojure terms) is a perfectly good strategy. The choice will be poorly informed, but that's a given if you're a beginner in any case. And such a beginner isn't really in a place anyway to make this choice for a significant project (for any platform/language). Once an initial choice is made, it seems to me (so far) pretty easy with leinigen templates & plugins just to get started on something. Time from tool setup to coding hasn't been any longer for me than other things I've learned in recent years.
inferiorhuman 7y ago
What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell. Ultimately rust (and go to some extent) seemed to fit my use cases better. If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).
- crispinb 7y ago
  Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.
  - inferiorhuman 7y ago
    Why?
  - bad_user 7y ago
    A command-line tool is nothing more than a script that maybe parses some input from the program's arguments or from stdin and then does something useful. Naturally you want to have the libraries you're used to available and the best language for CLI tools is the one you already know. Building CLI tools in C/C++ is silly. If you like Rust/Go, sure, knock yourself out. But the obvious choices are the scripting languages with runtimes that are already distributed as part of the OS .On Linux most CLI tools are built in Python or Perl and Ruby or Node.js are decent choices too. JVM languages aren't an ideal choice due to the startup time, but given the size of the ecosystem you can find a library for pretty much anything you need and now we've got GraalVM to help with the startup time. So not a bad choice either.
hota_mazi 7y ago
I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never catch it now.
- peferron 7y ago
  Python and JS succeeded long before they had a static type system. Many people still use Python and JS today without type annotations. Elixir is not statically typed either and seems to be doing fine. I like static typing and agree that it will eventually "win", but I really don't see where you're coming from here. > I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system What makes you say that?
  - modarts 7y ago
    spec
    - peferron 7y ago
      Describing the Clojure dev team as "trying very hard to catch up to statically typed languages by retrofitting some type system" because they work on spec is pushing a narrative that I doubt they'd agree with, both regarding spec's goals and its rhythm of development.
      - engineeringwoke 7y ago
        I'm not thinking highly of any narrative that the Clojure dev team believes. It is the pièce de résistance of the new "new" functional programming cult, which is in fact very old school. Even just parroting some of the memes from this thread like "static types only prevent 2% of bugs" and "you can replace 12 developers with 3 amazing (italics) Clojure developers" and "a Clojure developer can replace any kind of developer!" means you don't have to make up absurd viewpoints to argue the contrary. These trends are old as time and completely nonsensical.
peferron 7y ago
Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.
- grimgrin 7y ago
  While you're here: https://clojuredocs.org/clojure.core/while https://clojuredocs.org/clojure.core/while
  - peferron 7y ago
    Ha, I did run into that one. Take my upvote! Clojure's while is very rarely used so hopefully my point still stands, especially when languages like Go have been wildly successful going in the exact opposite direction.
- escherize 7y ago
  Clojure has while loops, but I think I see where you're coming from: It is a significantly different approach to programming, and if an engineer is not willing to re-jigger their style Clojure is not going to be a good fit for them.
  - peferron 7y ago
    I meant that they won't even try.
    - m0skit0 7y ago
      Those who won't even try are not worth hiring.
- iLemming 7y ago
  Clojure for a Lisp dialect has already gained quite some adoption. I like Lisp, and of course, I would love to see Lisp being used everywhere and used more. But honestly, if someone asked me ten years ago if Clojure would ever become more popular than languages like OCaml, Haskell or Scala, I would've said: "very few people would probably know that such language has ever existed." I'm not trying to bash on other PLs, the popularity of any language is difficult to measure, and it is a very subjective topic. Still, today Clojure has lots of conferences, and the number is growing every year, several active podcasts, tons of (relevant and up to date) books, jobs (that no matter how many, never will be enough), meetups, etc. I'm seeing Clojure related posts on top of HN almost every week. And I'm watching people trying Clojure, coming with all sorts of different backgrounds. I have worked with people who came to Clojure from C++, Ruby, Python, C#, Haskell, Go, Scala, OCaml, JavaScript, CL; people with no programming experience at all. Of course, that all is incomparable with the craze that something like Typescript receives. And I used to feel anxious, worried that this would be the last ever job where I happily used Clojure. But after my third job where Clojure was the primary language, I stopped sweating about that. I think Clojure, at this point, has stabilized in the industry and slowly and steadily would continue to attract people. The only thing that can genuinely kill Clojure - is a better version of its fork.
billfruit 7y ago
And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur clojure does not give an interactive repl like other lisps.
- stingraycharles 7y ago
  > Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn. This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.
  - devin 7y ago
    That’s an exaggeration. You’re not entirely wrong, though. First, it is not called deps.edn, it is called tools.deps. Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not change the build tool. I have worked with them, and the attitude was always pragmatic > dogmatic. Where I will agree with you is that some folks in the community took an alpha release of tools.deps and treated it like it was the new lein or boot. It isn’t. It’s different, and as a Clojure programmer of 10+ years I use it in exactly 0 production projects. That said, it improves greatly upon “lein checkouts” by allowing one to refer to git SHAs as versions and do cross-project interactive development.
    - stingraycharles 7y ago
      Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.
lgrapenthin 7y ago
Instead of just measuring how many developers adopt Clojure and how difficult/easy that is, I'd also love a measure of how many developers Clojure "puts out of business". IME Clojure is quite aggressive on that front. In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired and fired 4. When I left they had 3. All 3 were not experienced in Clojure prior to the project (Java), but by 2018 each knew the entire codebase and was able to modify it and able to step in for each other. They spent less than half of their budget and all goals were met ahead of schedule. IME learning how to put Clojure and its ecosystem in good use takes more time and effort than other languages, but its effectiveness really compensates.
- bambataa 7y ago
  Were they fired because they weren’t good enough at Clojure? Perhaps all Clojure did was filter out less capable performers. The small team of skilled developers might have been just as fast in Java if they weren’t encumbered by the mediocre ones.
  - christophilus 7y ago
    That’s still an argument in favor of Clojure. People spend loads of time and money trying to figure out how to do such filters. If it comes for free by choosing Clojure, that’s pretty great.
    - The_Colonel 7y ago
      I doubt this filtering is in any way done by Clojure though. It's difficult to recognize top performers in interviews, but it's much easier to see that in day to day work. What is usually missing is the willingness to fire people for not being top performers.
  - lgrapenthin 7y ago
    I was mainly concerned with teaching Clojure in this project as everyone had little or no experience prior, so nobody was blocked by learners. Those who were fired all had one thing in common: They refused to adopt Clojure beyond its syntax in favor of patterns they learned to rely on in another language. This varied from porting Scala polymorphism to just banging out imperative while loops with atoms. I don't think they were incapable. They simply didn't want to learn it. Code reviews turned into arguments quickly, took endless time and lead nowhere. Their code was never touched by those who stayed and were able to work together. Later it was rewritten, because in spite of tons of unit tests (which passed), it was full of bugs. The code was considered "write-only". The rewrites averaged at 5-10% LOC.
roenxi 7y ago
The other interesting problem is that the experts are using tools and concepts that are a long way away from a beginner and that can make it harder for beginners to learn. In Clojure when a beginner wants to accomplish a task their biggest problem is that they are solving the wrong problem or being pushed to deal with problems they don't understand. Case in point the var/agent/ref system is fantastic and probably critical to how to think about Clojure projects - but the problems being solved by it are a long way away from the concerns of someone at the beginner-intermediate type level. They don't need to solve multithreading right now. They don't see their data model as an urgent priority. Compare that to Python where most of the core language is (1) call function, solve problem or (2) feature does something you could already do but with a little less typing. I prefer Clojure but it is easy to see that the lack of an opinionated onboarding process is going to hurt the language.
- dimitar 7y ago
  The advice the community usually gives is just use hashmaps. You can easily refactor when you need that more difficult functionality, because the language strongly disincentives mutable state, which is what usually causes issues.
doglooksgood 7y ago
If you tried Clojure a few years ago, the Tooling could be a problem. But now, the tools-deps(official Clojure cli) is awesome.
- wry_discontent 7y ago
  How do you find it compares to Leiningen? I'm using lein for all of my side projects (and shadow-cljs) and I like it. What does tools-deps offer me?
  - ashes-of-sol 7y ago
    Better dependency resolution is one highlight - Alex Miller presented on conj on this and some other pieces at the recent conj conference: https://youtu.be/7CM7Ef-dPWQ https://youtu.be/7CM7Ef-dPWQ
  - doglooksgood 7y ago
    Tools-deps is a lightweight alternative, when working with it, the configuration mainly care about three things. The source path, the dependencies and the aliases(all kinds of entry point and launcher command). I found this solution much more clear than in Leiningen. But tools-deps don't care about packaging, deploy, install, etc. Like its name, it's focusing on `deps`. I use tools-deps and shadow-cljs.
DannyB2 7y ago
Yes, this. Tooling. If you want to get started, Clojurists will insist you learn emacs. After all it's so great you must learn it. Now I have nothing against emacs. But I don't expect to have to invest significant effort to learn a specific editor in order to use a programming language. No other programming language has this requirement. I was surprised at how many Clojure users took this as an attack upon emacs. It took some careful explaining to make the point that I have better things to invest my time into, such as building more code in Clojure, rather than learning yet another tool, that does something for which I have other tools already. There were some great IDEs for Clojure. But they have all fallen into disrepair and being unmaintained.
- ashes-of-sol 7y ago
  I don't think this is accurate today - while Emacs is still dominant, there are other options with growing support, and a growing recognition that foisting Emacs upon newcomers is not ideal
- fulafel 7y ago
  You might have a biased sample of Clojurists, in my vicinity ~50% use Cursive. Not sure where you get the disrepair part, Cursive is alive and well and seems to be a sustainable business for the author, and Calva also seems to do be doing well. It's true that there have been various open source IDE efforts that are dead now (Counterclockwise for Eclipse went the way of Eclipse, Lighttable and Nightcode were probably a bit too experimental / radical)
  - DannyB2 7y ago
    I haven't used IntelliJ. So I haven't used Cursive. I did use Eclipse and Counterclockwise for quite a while and enjoyed it very much.
mark_l_watson 7y ago
Great language and ecosystem. I donated at the beginning and made my living writing Clojure code for a few years. However, I find myself way more productive using Common Lisp, perhaps because since I have used it since 1982. I think Clojure’s sweet spot is a small team working on a large enterprise project.

by tensor 7y ago

Goladus 7y ago

> Startup time isn't what is holding the language back. For what it's worth, I am a system administrator (or DevOps engineer or infrastructure architect or whatever the trendy name is now). I've written several non-trivial automation tools where I had the option to use pretty much any language I wanted. The startup time and overall awkwardness of deploying the JVM for scripting was the undeniable deal-breaker. (I used Python instead). > For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done. More likely they just need a solution with the least-necessary added complexity or observable downsides, and that rules out the bulky JVM with its slow start-up time and the fact that Java has been under the jurisdiction of Mordor since 2010.

amelius 7y ago

But creative people also need to do boring stuff from time to time. If they still choose Clojure, then apparently it suffices for these tasks.

slifin 7y ago

If all you want is a rails thing but with a Clojure twist I'd keep an eye on https://youtu.be/jkx9F-RIFiY https://youtu.be/jkx9F-RIFiY I agree there's a sometimes frustrating lack of branding and documentation for the one true way of doing things But I'd be careful what you wish for, Clojure is still fertile land, nothing has come along and crushed all alternatives yet and I think our community is right to think long and hard before promoting the new one true way because most of us are refugees from other languages where it's already happened

slifin 7y ago
The normal one true way for most commercial companies right now is reframe, there's a nice ecosystem there and it's teachable
- vga805 7y ago
  reframe is just the front end though isnt it? i think this is not the crud/rails alternative the op is talking about
  - smnplk 7y ago
    Checkout Fulcro http://book.fulcrologic.com/#_fulcro_from_10000_feet http://book.fulcrologic.com/#_fulcro_from_10000_feet

crispinb 7y ago

As someone just playing with Clojure for curiosity, I agree that it's hard to find a way through the thicket of available tooling & library options. On the other hand, to start with just picking something reasonably mainstream (in Clojure terms) is a perfectly good strategy. The choice will be poorly informed, but that's a given if you're a beginner in any case. And such a beginner isn't really in a place anyway to make this choice for a significant project (for any platform/language). Once an initial choice is made, it seems to me (so far) pretty easy with leinigen templates & plugins just to get started on something. Time from tool setup to coding hasn't been any longer for me than other things I've learned in recent years.

inferiorhuman 7y ago

What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback hell. Ultimately rust (and go to some extent) seemed to fit my use cases better. If I had to do a web app from scratch I would think long and hard about going Clojure if only because it leverages such a widely used VM. Points 1 & 2 weren't issues for me, but #3 was (and there are similar problems with Elixir).

crispinb 7y ago
Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.
- inferiorhuman 7y ago
  Why?
- bad_user 7y ago
  A command-line tool is nothing more than a script that maybe parses some input from the program's arguments or from stdin and then does something useful. Naturally you want to have the libraries you're used to available and the best language for CLI tools is the one you already know. Building CLI tools in C/C++ is silly. If you like Rust/Go, sure, knock yourself out. But the obvious choices are the scripting languages with runtimes that are already distributed as part of the OS .On Linux most CLI tools are built in Python or Perl and Ruby or Node.js are decent choices too. JVM languages aren't an ideal choice due to the startup time, but given the size of the ecosystem you can find a library for pretty much anything you need and now we've got GraalVM to help with the startup time. So not a bad choice either.

hota_mazi 7y ago

I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never catch it now.

peferron 7y ago
Python and JS succeeded long before they had a static type system. Many people still use Python and JS today without type annotations. Elixir is not statically typed either and seems to be doing fine. I like static typing and agree that it will eventually "win", but I really don't see where you're coming from here. > I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system What makes you say that?
- modarts 7y ago
  spec
  - peferron 7y ago
    Describing the Clojure dev team as "trying very hard to catch up to statically typed languages by retrofitting some type system" because they work on spec is pushing a narrative that I doubt they'd agree with, both regarding spec's goals and its rhythm of development.
    - engineeringwoke 7y ago
      I'm not thinking highly of any narrative that the Clojure dev team believes. It is the pièce de résistance of the new "new" functional programming cult, which is in fact very old school. Even just parroting some of the memes from this thread like "static types only prevent 2% of bugs" and "you can replace 12 developers with 3 amazing (italics) Clojure developers" and "a Clojure developer can replace any kind of developer!" means you don't have to make up absurd viewpoints to argue the contrary. These trends are old as time and completely nonsensical.

peferron 7y ago

Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.

grimgrin 7y ago
While you're here: https://clojuredocs.org/clojure.core/while https://clojuredocs.org/clojure.core/while
- peferron 7y ago
  Ha, I did run into that one. Take my upvote! Clojure's while is very rarely used so hopefully my point still stands, especially when languages like Go have been wildly successful going in the exact opposite direction.
escherize 7y ago
Clojure has while loops, but I think I see where you're coming from: It is a significantly different approach to programming, and if an engineer is not willing to re-jigger their style Clojure is not going to be a good fit for them.
- peferron 7y ago
  I meant that they won't even try.
  - m0skit0 7y ago
    Those who won't even try are not worth hiring.
iLemming 7y ago
Clojure for a Lisp dialect has already gained quite some adoption. I like Lisp, and of course, I would love to see Lisp being used everywhere and used more. But honestly, if someone asked me ten years ago if Clojure would ever become more popular than languages like OCaml, Haskell or Scala, I would've said: "very few people would probably know that such language has ever existed." I'm not trying to bash on other PLs, the popularity of any language is difficult to measure, and it is a very subjective topic. Still, today Clojure has lots of conferences, and the number is growing every year, several active podcasts, tons of (relevant and up to date) books, jobs (that no matter how many, never will be enough), meetups, etc. I'm seeing Clojure related posts on top of HN almost every week. And I'm watching people trying Clojure, coming with all sorts of different backgrounds. I have worked with people who came to Clojure from C++, Ruby, Python, C#, Haskell, Go, Scala, OCaml, JavaScript, CL; people with no programming experience at all. Of course, that all is incomparable with the craze that something like Typescript receives. And I used to feel anxious, worried that this would be the last ever job where I happily used Clojure. But after my third job where Clojure was the primary language, I stopped sweating about that. I think Clojure, at this point, has stabilized in the industry and slowly and steadily would continue to attract people. The only thing that can genuinely kill Clojure - is a better version of its fork.

billfruit 7y ago

And poor tooling support on MS Windows. Leiningen does not even have a proper installer on Windows, last time I checked. Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. There were also complexities in including local jars into projects, as it required setting up a local maven repository, which is tedious job. Also when exeptions occur clojure does not give an interactive repl like other lisps.

stingraycharles 7y ago
> Having leiningen not bundled into the clojure distribution, is in strong contrast to the "batteries included" approach of python. The problem is that Cognitect (the company behind Clojure) don’t use Leiningen themselves, and instead have released their own tool called deps.edn. This has only fragmented the community even further, making it even more difficult for newcomers, with questionable benefits.
- devin 7y ago
  That’s an exaggeration. You’re not entirely wrong, though. First, it is not called deps.edn, it is called tools.deps. Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not change the build tool. I have worked with them, and the attitude was always pragmatic > dogmatic. Where I will agree with you is that some folks in the community took an alpha release of tools.deps and treated it like it was the new lein or boot. It isn’t. It’s different, and as a Clojure programmer of 10+ years I use it in exactly 0 production projects. That said, it improves greatly upon “lein checkouts” by allowing one to refer to git SHAs as versions and do cross-project interactive development.
  - stingraycharles 7y ago
    Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.

lgrapenthin 7y ago

Instead of just measuring how many developers adopt Clojure and how difficult/easy that is, I'd also love a measure of how many developers Clojure "puts out of business". IME Clojure is quite aggressive on that front. In 2017 a customer wanted a set of services written in Clojure. Based on their Java experience they wanted to hire 10 devs. When I arrived they had 4, over the 1.5-year period I was there, they hired and fired 4. When I left they had 3. All 3 were not experienced in Clojure prior to the project (Java), but by 2018 each knew the entire codebase and was able to modify it and able to step in for each other. They spent less than half of their budget and all goals were met ahead of schedule. IME learning how to put Clojure and its ecosystem in good use takes more time and effort than other languages, but its effectiveness really compensates.

bambataa 7y ago
Were they fired because they weren’t good enough at Clojure? Perhaps all Clojure did was filter out less capable performers. The small team of skilled developers might have been just as fast in Java if they weren’t encumbered by the mediocre ones.
- christophilus 7y ago
  That’s still an argument in favor of Clojure. People spend loads of time and money trying to figure out how to do such filters. If it comes for free by choosing Clojure, that’s pretty great.
  - The_Colonel 7y ago
    I doubt this filtering is in any way done by Clojure though. It's difficult to recognize top performers in interviews, but it's much easier to see that in day to day work. What is usually missing is the willingness to fire people for not being top performers.
- lgrapenthin 7y ago
  I was mainly concerned with teaching Clojure in this project as everyone had little or no experience prior, so nobody was blocked by learners. Those who were fired all had one thing in common: They refused to adopt Clojure beyond its syntax in favor of patterns they learned to rely on in another language. This varied from porting Scala polymorphism to just banging out imperative while loops with atoms. I don't think they were incapable. They simply didn't want to learn it. Code reviews turned into arguments quickly, took endless time and lead nowhere. Their code was never touched by those who stayed and were able to work together. Later it was rewritten, because in spite of tons of unit tests (which passed), it was full of bugs. The code was considered "write-only". The rewrites averaged at 5-10% LOC.

roenxi 7y ago

The other interesting problem is that the experts are using tools and concepts that are a long way away from a beginner and that can make it harder for beginners to learn. In Clojure when a beginner wants to accomplish a task their biggest problem is that they are solving the wrong problem or being pushed to deal with problems they don't understand. Case in point the var/agent/ref system is fantastic and probably critical to how to think about Clojure projects - but the problems being solved by it are a long way away from the concerns of someone at the beginner-intermediate type level. They don't need to solve multithreading right now. They don't see their data model as an urgent priority. Compare that to Python where most of the core language is (1) call function, solve problem or (2) feature does something you could already do but with a little less typing. I prefer Clojure but it is easy to see that the lack of an opinionated onboarding process is going to hurt the language.

dimitar 7y ago
The advice the community usually gives is just use hashmaps. You can easily refactor when you need that more difficult functionality, because the language strongly disincentives mutable state, which is what usually causes issues.

doglooksgood 7y ago

If you tried Clojure a few years ago, the Tooling could be a problem. But now, the tools-deps(official Clojure cli) is awesome.

wry_discontent 7y ago
How do you find it compares to Leiningen? I'm using lein for all of my side projects (and shadow-cljs) and I like it. What does tools-deps offer me?
- ashes-of-sol 7y ago
  Better dependency resolution is one highlight - Alex Miller presented on conj on this and some other pieces at the recent conj conference: https://youtu.be/7CM7Ef-dPWQ https://youtu.be/7CM7Ef-dPWQ
- doglooksgood 7y ago
  Tools-deps is a lightweight alternative, when working with it, the configuration mainly care about three things. The source path, the dependencies and the aliases(all kinds of entry point and launcher command). I found this solution much more clear than in Leiningen. But tools-deps don't care about packaging, deploy, install, etc. Like its name, it's focusing on `deps`. I use tools-deps and shadow-cljs.

DannyB2 7y ago

Yes, this. Tooling. If you want to get started, Clojurists will insist you learn emacs. After all it's so great you must learn it. Now I have nothing against emacs. But I don't expect to have to invest significant effort to learn a specific editor in order to use a programming language. No other programming language has this requirement. I was surprised at how many Clojure users took this as an attack upon emacs. It took some careful explaining to make the point that I have better things to invest my time into, such as building more code in Clojure, rather than learning yet another tool, that does something for which I have other tools already. There were some great IDEs for Clojure. But they have all fallen into disrepair and being unmaintained.

ashes-of-sol 7y ago
I don't think this is accurate today - while Emacs is still dominant, there are other options with growing support, and a growing recognition that foisting Emacs upon newcomers is not ideal
fulafel 7y ago
You might have a biased sample of Clojurists, in my vicinity ~50% use Cursive. Not sure where you get the disrepair part, Cursive is alive and well and seems to be a sustainable business for the author, and Calva also seems to do be doing well. It's true that there have been various open source IDE efforts that are dead now (Counterclockwise for Eclipse went the way of Eclipse, Lighttable and Nightcode were probably a bit too experimental / radical)
- DannyB2 7y ago
  I haven't used IntelliJ. So I haven't used Cursive. I did use Eclipse and Counterclockwise for quite a while and enjoyed it very much.

mark_l_watson 7y ago

Great language and ecosystem. I donated at the beginning and made my living writing Clojure code for a few years. However, I find myself way more productive using Common Lisp, perhaps because since I have used it since 1982. I think Clojure’s sweet spot is a small team working on a large enterprise project.