Also a lack of documentation was always a problem, especially around clojure script.
I also don't like smug community. When you say about the lack of documentation and get told that's a good thing, clojure is meant to be hard to learn, it's not for everyone and maybe you just aren't smart enough...
Hmmm. That attitude might put people off.
But things have changed. Clojure and Clojurescript community is among the most helpful and Stackoverflow questions are promptly answered. If you take the time , like I did, you will find that Clojurescript has awesome tooling. Go though the tutorial on Figwheel.main (https://figwheel.org/docs/ ) and then check out re-frame TodoMVC here https://github.com/day8/re-frame/tree/master/examples/todomv... or this simpler reframe tutorial from here https://opengisgal.wordpress.com/2018/05/19/re-frame-clojure... . And this here is the Reagent cookbook https://github.com/reagent-project/reagent-cookbook . Good Luck!
I was in the Clojure usenet from very early on and do not recall this happening. That's not to say that it never happened but it was certainly not a common response to questions. Instead, I remember early adopters like Chris Houser, Chas Emerick, Phil Hagelberg, and many others taking a lot of time to help people who had questions with the language.
Clojure is not meant to be hard to learn and you are definitely smart enough. There are many, many learning resources for Clojure in every form and it has one of the most helpful communities I'm aware of on Clojurians slack, etc.
Where did you experience this? That is unacceptable in most of the Clojure communities I know, and the only big one I don't know personally is the subreddit.
(I am not suggesting the subreddit is toxic.)
I mean, Java is pretty much the biggest ecosystem there is and it's trivial to use Java libs from Clojure, so I'm not sure this is a fair comparison.
The Go ecosystem seems pretty weak outside of the standard library. I'm not an expert, but I was trying to fix something the other week and was shocked by how few packages there were to solve my problem. The main one (which is a dep of things like k8s) is currently unmaintained.
As Rich has said, Clojure is small and intends to remain so. Clojure has everything you need right now. It doesn't need gobs of new features to be sufficient. Most Clojurists are hard pressed to come up with things they really need in the language itself, so the rate of change in the core language has slowed. (And the rate of change in the tooling and libraries around Clojure gets more attention now.)
> they are disinterested in promoting the language and ecosystem beyond selling their database software
... is incorrect. We have every desire to promote Clojure as a language (regardless of Datomic). Could more be done, sure that's always the case. Please help promote Clojure by doing great stuff and telling people about it!
I also believe that tools.deps is a step in the wrong direction, fragmenting an already small community and forcing all tools to support yet another dependency/build system.
Leiningen is super powerful, and it was never made clear what kind of conflicting requirements / philosophy led to the birth of tools.deps etc. In absence of an official answer, the presumed answer is Not Invented Here Syndrome.
Wouldn't you consider this and official answer?: https://github.com/clojure/tools.deps.alpha#rationale
Look at create-react-app. Two commands and a ton of editor integration across intellij, vscode, vim, etc gives you incredible access to a rich ecosystem and plugs together really nicely with sensible defaults.
Clojure has some answers in this space but everything feels bolted on and not nearly as polished. A big part of the problem is the size of the community, there just isn't enough hands to build out the infrastructure that other langs enjoy.
I still love Clojure and will continue to use it but in order to do so I have to understand that some simpler things will just be more work.
Tooling is definitely important, so I don't want to downplay friction here, just curious about what other ecosystems do better.
An exercise for you to try that might illustrate it. Setup create-react-app and get hello world up and running. Now do the same with Clojurescript. That should include a way to hot reload and edit because that is often the next steps.
Notice the friction that CLJS still has and the aimlessness of starting from a build script as is suggested on the Clojure site vs getting a functional build in two commands.
I don't want to come across as ungrateful for the hard work that David and Alex and the whole team put in, they are the only reason have dev tools that feel comfortable to me and I can't thank them enough for that, but I just want to point out that friction and difficulty and to try and get people who do understand to put themselves in the shoes of developers who don't and to acknowledge that we as a community can aspire to more.
1) the most popular Clojure programming environment
2) solidly documented
3) built on top of Emacs, which is in itself very well documented (Just the reference manual of the vanilla Emacs is 500 nicely written, if dry, pages)
4) very featureful.
I guess the biggest problem is that most people are not familiar with Emacs, and not willing to read any documentation and guides.
These kinds of issues a part of the tooling gap and are real reasons people give up on Clojure and I do find the dismissive attitude of most when I have suggested this in the past off putting.
Addressing Emacs specifically, while it would be probably worth the investment it is not an answer most people want to hear and when we suggest that Clojure is this great thing it is important to show people on some of their terms because learning a new editor on top of Clojure more then we should be asking IMHO and for all the talk of Clojure being pragmatic this feels directly opposed to that ethos.
Let me emphasize, I don't want to say anyone is doing anything wrong or that Emacs isn't the right way forward but it had to be acknowledged that there are real problems that path that need improvement when it comes to onboarding new developers and with daily use.
A few times Cider had major changes, but even then it was quickly resolved, and was relevant only to people that were using daily snapshots. I guess if someone is a beginner, they'd use a stable version, and these are rather stable.
Big files could be problematic in Emacs. OTOH, Clojure files are never big.
As for Emacs requiring a bit of learning at first. Well, yes. It has lots of features that beginners have probably never encountered in other tools. These features are awesome. They also help a lot. So, someone expects to unlock a great featureset, but refuses to spend even a few afternoons learning about that featureset. I understand that people would rather get something out of nothing, but it's not Emacs's fault.
Per the big files, its not so much Clojure but output at the REPL. Especially as a noob accidentally grabbing way to much data for a buffer is really easy, Emacs hangs, REPL and process dies and has to be rebooted and you have to bring up everything again. This is non-trivial friction when learning and should really be handled gracefully by the editor.
As for everything else regarding Emacs and learning all these points stand and are valid but still don't address the problem of someone wanting to learn Clojure and instead having to learn Emacs + Clojure + Cider. For someone just starting on the path most won't have more than 3 files of CLJ and may not even interact with Lein or Deps. Refactoring IS important but not to them. I just don't think the trade off is worth it for someone just toying around with CLJ in their free time. It may not be the best metric but "time to hello world" and "time to blog" matter to people coming in because it shows that the promise that they are sold is something that they can reach and achieve.
That said, you're right: you should just be able to use vim, and historically CIDER has been the dominant (most polished) environment. At Clojurists Together Foundation, we're trying to fix that though: a lot of our funding has gone towards IDE development including for vim. Some of it towards CIDER also benefits vim because they share internals.