Since I've been interested in how the Functional paradigm might help us developers deal with concurrency, there are 2 items here that really strike me:
1.) Clojure fell back
2.) Elixir, though small, is still moving forward
I've been a fan of Clojure since 2009. It grew rapidly for a few years, from 2009 till at least 2014. It has stalled out. This makes me sad because I've loved working with it and I think it a great community, in most ways. But it is true that the community has been unable to answer some of the criticisms leveled against it. The reliance on Emacs has meant it is not easy for beginners. On the other side, the elite (the purists?) have wanted to see Clojure be more like Scheme, or more like Racket, or more like Haskell. Clojure has offered up many interesting ideas, but perhaps hasn't quite built a complete eco-system that makes it broadly appealing.
Elixir, though very small, still seems to be moving forward, and perhaps has a chance to answer some of the demands that people made of Clojure (more pure? easier syntax?). Maybe Elixir is the language that make the Functional style the dominant style in computer programming?
A few (rambling) thoughts, as a long-time Clojure dev who's recently been focusing on Elixir.
The thing I like most about Elixir is the low friction between it and it's host language, Erlang. Erlang is a functional language right from the start, and the BEAM is designed to run a functional language, which means you never hit the weird FP-OO barrier that comes up so commonly in Clojure.
I really think the impedence mismatch between Clojure and the underlying Java implementation is a big, painful problem which is going mostly unacknowledged by the inner-core of the Clojure community. And that makes sense, because they're all (or mostly) "Java Guys" who are already sold on the Java ecosystem and are fine with there being a layer of spindly OO horror in their projects. They don't mind the Java layer poking through in unpleasant ways.
When I bring this up in a congregation of Clojurists I just get "shrug, welp, Clojure is a hosted language", not even an acknowledgement that there may be a problem worth discussing.
For the rest of us, the FP enthusiasts who don't have an emotional or professional attachment to Java, this sucks, because you can't do much in Clojure without also touching Java. As I said at the start of this ramble, Elixir/Erlang don't suffer from this problem, it's FP all the way down. Erlang idioms fit in with Elixir, and vice versa. No friction, no bullshit.
One final point: I think the Elixir team visibly care about ergonomics and good design, much more than the Clojure team seem to. Look at `mix` and compare it to `leiningen`, honestly. Look at Plug and Phoenix and compare to something like Luminus in Clojure-land. The difference is night-and-day. Look at how fast the `iex` repl boots up, or how fast the stop-compile-start workflow is in a Phoenix app. Even look at the content of the languages respective homepages (http://elixir-lang.org and http://clojure.org)
> When I bring this up in a congregation of Clojurists I just get "shrug, welp, Clojure is a hosted language", not even an acknowledgement that there may be a problem worth discussing.
I'm not quite sure what you are expecting. It is a tradeoff they explicitly made.
I've yet to see another platform come close to rivalling the JVM ecosystem. It is a powerhouse.
I think it's a great tradeoff. From a team and organisational productivity point of view unless you are based on either the JVM, the CLR, or have fantastic c/c++ interop you are dead in the water.
According to these rankings JavaScript is the most popular language, and it's not based on the JVM/CLR, and it doesn't have great c/c++ interop. Other compile-to-JS languages like Typescript, Elm, and Idris are in the same boat.
Elixir made some solid gains this quarter, and it's based on the BEAM VM, so not JVM/CLR, and not great c/c++ interop. It has great concurrency support, and is widely regarded as being rock-solid.
Haskell fell one spot, but it's still in the top 20, and it's not based on the JVM/CLR, and doesn't have great c/c++ support. The library support is similar to the situation in Python 3, and I've written plenty of performance sensitive Haskell code that's within 2x the speed of c.
It's a big world out there, and there are so many great languages. The JVM/CLR definitely provide a nice head-start, but they're not the only way to build a good language.
Small correction : there is a good (not stellar but good) interop with C/Rust/c++ on the Beam.
NIFs work quite well even if htey have quirks and are limited. And with ports and Dirty Schedulers, you have other solutions for more complex and longer things.
I also dropped Clojure/ClojureScript, even though it was my favorite language between 2012 and 2014/2015.
The main reason for me is the progression of Java and JavaScript during these years, which make ClojureScript less useful. ES6 has completely transformed the JavaScript development. I finally enjoy to code in JavaScript - this wasn't the case before. On the contrary, coding in ClojureScript became painful. It's difficult to follow the recent trends, to integrate new libraries without hassle. Currently I work on a project that use DraftJS. I don't want to know how to integrate it in ClojureScript ! It's a waste of time, and again the "joy of Clojure" still exists but is now less superior to the "joy of Javascript".
On the Clojure/JVM side, Java 8 is far from perfect but the lambdas expressions have made the language a bit less boring. I think many developer feel less the urge to leave Java for an alternative language. And if they really want it, there is Scala, still the best strong statically typed language on the JVM, and so, for me, still the best language for backend development.
In short, Clojure/ClojureScript was for me the best language for rapid prototyping and for front development. I've never really considered it for "serious" backend applications based on a complex data models, because of its dynamic typing. However, JavaScript development became much more pleasant, making ClojureScript less attractive, less differentiating. I believe that today, you have to be a true Clojure fan to code in ClojureScript.
The Android team did a AMA on Reddit this week, they were pretty clear that regardless of people wishes only Java, C and C++ matter on Android.
Anything else it is up to the respective language communities to make it work.
Right now only Kotlin seems to be improving their Android support, but that is because JetBrains needs a killer application for it, which appears to be improving the world of those stuck in Java 6.
"Anwar: We don’t have any plans to officially support a new language in Android, so we’d encourage folks to continue to use Java:) That said, you should continue to use what works for you."
People have to get over the fact that regardless of what happens in the Oracle vs Sun, the Android team which has a quite a few Sun alumnis, doesn't want to use anything else.
Even the NDK is designed in a way that native C and C++ code is always exposed via Java native. The example code on the NDK start page is pretty clear how they see the NDK.
"The Android NDK is a toolset that lets you implement parts of your app using native-code languages such as C and C++. For certain types of apps, this can help you reuse code libraries written in those languages."
And another fun fact is that given the NDK constraints, having Linux as kernel doesn't matter that much, they could change to something else and only OEMs would notice.
I don't understand why Scala would drop the Java 6 backend. Surely Android is a big enough "market" to be worth maintaining it as a compilation target? Particularly now that Scala is expanding to be very clearly multi-backend (ScalaJS as first class, Scala Native starting up).
> Every time I think about using Scala and go through the list of configurations I need to do, I just give up.
It's pretty easy. You have to setup less things than with Gradle, because SBT deals with all the downloading, installing and managing of the two dozen SDKs Google wants you to use.
> I want a setup that embraces Gradle (even though we love to hate it), Android Studio GUI designers, plugins and annotations.
You can keep all you Gradle configuration. SBT-Android has a Gradle support mode so you can e. g. use the Gradle definitions for your IDE, but enjoy the fast turn-around and compile-times of compilation with SBT.
"The update includes the Android Studio 2.0 features: faster Emulator, experiment GPU Debugger, faster full builds, and code generation and testing for App Indexing. Note, Instant Run is not fully-merged yet."
If you want to drive adoption, it should work on Android Studio as well.
This is what I usually mean by using first party platform languages versus relying on third party support.
For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
And still I am not using it, because there are a few rough edges with all the Android workflows.
> For Kotlin, all I need is to install the plugin on Android Studio and am off to the races.
What is preventing you from doing that with Scala?
I see that you filed a ticket that the setup of IntelliJ != Android Studio, but is there anything that works in one, but not the other? (Except having to skip the "install android support" from the install guide?)
I guess no-one cares enough to support it? Definitely a shame though. (In the rare cases where I write Android apps I stick to Eclipse, stick to Maven, use Scala, and for me it all works - but presumably people have their reasons for preferring android studio/intellij).
Fair enough, but there are bugs/missing features in Scala 2.11 that I want fixed, and they're going to be fixed in Scala.js and Scala-Native so it would be a real shame if they weren't fixed in Scala-for-Android at the same time.
The usual ones, I'm sure. Poor syntax for type lamdbas. Unification across kinds (hopefully possibly going to be backported to 2.11). All the ways of expressing union types (or indeed basic enums) are a bit clunky. Irrefutable patterns in for/yield constructs compile to a silly withFilter call. PartialFunction/Function having the wrong subtyping relationship. mapValues being lazy when all the other functions on the same interface are strict. Stream implementing the collection interface.
More than anything specific though, I don't want to be stuck on an old version as the language moves forward.
Huh? None of that will be in 2.12 except unification, and that's already planned for backporting to 2.11 (and you can just use the compiler plugin until then).
> I don't want to be stuck on an old version as the language moves forward.
How are you going to be stuck? You might need to stay on 2.11 a bit longer until Google gets their shit together. Most likely this will be during 2.12. Sure, you might miss the first few minor releases of 2.12 ... but stuck?
Where are you getting this confidence that Google will "get their shit together" quickly, or ever? I can easily imagine Google not shipping Java 8 for as long as Oracle remains in business.
Hi, Scala team lead at Lightbend here (I left academia in 2012 to lead the team). We dropped Java 6 because we did not anticipate any business case for it, based on surveying our customers (we have continued to monitor the adoption of Java 8 amongst our customers, and everyone is upgrading, save for android).
We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
As announced in http://scala-lang.org/news/2.12-roadmap/, we will continue to support 2.11 for a bit longer than most releases, and we welcome community backports of 2.12 features that you'd like to see in 2.11.
> We did consider (and regret) potentially leaving android behind, but we were (perhaps naively) hoping that something like retrolambda would suffice, or that android would catch up. In any case, it doesn't make a lot of sense to have 2.12 still support Java 6, since most of its features require Java 8 (those that don't, we first implemented in 2.11.x).
Presumably 2.11 won't be supported going forward? Or as someone who would like my libraries to work on android and doesn't particularly care about them being callable from Java 8, should I just stay on 2.11 indefinitely?
Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter? We do everything we can to enable 2.11.x maintenance by the community (and contributions are trending up!), as well as doing some of our own -- time permitting. If you'd like to get commercial support, we do offer that to our customers.
> Yes, if you're tied to Java 6, you're also tied to Scala 2.11. Why is the former version peg ok but not the latter?
a) Java 6 is forward binary compatible with later versions
b) Google has a reasonable excuse in terms of the Oracle lawsuit. Don't get me wrong, I'm not happy about Android being stuck on Java 6, but there are extenuating circumstances.
c) Scala 2.11 has issues that affect me and I want to see fixed. Java 6 doesn't, at least not that I've noticed. (If JVM 8 were necessary to the implementation of a Scala feature I cared about I would understand that, but as far as I can see it's irrelevant to my use cases)
Yes, but from a "business" standpoint, Java 6 hasn't EOL'd. If your business needs to build Android applications, it doesn't matter that it's technically EOL'd.
I would guess there's probably quite a few VB6 applications out there in business-land, and it's been EOL'd since 2012 IIRC. Not that most people would want to deal with them, but they exist, just like Java 6 in Android.
In addition to being supported by the community, we (Lightbend) offer commercial support for Scala 2.11. If you're paying Oracle for Java 6 support beyond its EOL, perhaps you'd be willing to establish a commercial relationship with us as well? That said, the vast majority of our customers are eagerly upgrading to Java 8 (https://news.ycombinator.com/item?id=7346224, https://info.lightbend.com/COLL-2014-10-20-Java-8-II-Survey-...)
The code emitted by 2.12.0-M5 is slower in certain benchmarks, but I don't expect this to be the case for the final 2.12 release.
We're working on the performance issue, with help from the team at Oracle. The problem is likely the JIT having trouble optimizing the bytecode we emit in M5 (we know of other schemes that don't suffer this slowdown, but require more bytecode).
Actually, I'm hoping to avoid TypeScript. Its use in Angular 2 probably makes it inevitable, though.
At the moment, still using ES 5 (for an Angular 1 app), as we have to support IE 11 and started the project a while back before Angular 2 shipped.
I'm more interested in the functional-friendly features of ES 6 / 2016 (tail call elimination, gather/spread params & return values operations, etc) than I am in emulating Java with TypeScript. Also, I actually like JS, and would like to avoid a transpiler step.
To clarify, I wasn't trying to convince you to use TypeScript, just saying that it's taking a larger share of the compile-to-JavaScript crowd, along with ES2015, both competing with ClojureScript.
I would like to clear something up, though. TypeScript is not very much like Java, in my experience. To me, it feels like programming in JavaScript but with type annotations where you want them. If you think that TypeScript will make programming like Java, I'd encourage you to at least reevaluate that position.
I don't feel like clojure stalled out. You have to realize the redmonk rankings are using very weak heuristics to get these results. I'd rather choose languages and tools by how much they match the problem space rather than how popular they are at any particular point in time.
If you trim out all the worthless SO questions/anwsers you'll get radically different rankings on redmonk. JavaScript could very easily drop from its first place doing just that.
I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.
>I don't get why people chase popularity in programming languages. That's what you do in a pop culture, not in an engineering one.
That's wrong. Every civic engineer I know, for example, would prefer standard, and lacking that, popular nuts, bolts, construction parts, materials etc, over niche ones, unless there's some very pressing reason not to. They are cheaper and available in greater volumes, you can find skilled workers easier, their properties are more studied, etc.
That's even more important in programming, where ecosystem, availability of libraries, continued support on the language and compiler, availability of skilled programmers, existing codebase support, etc, matter even more than pure language level issues.
Popularity in a language is crucial, to the point that other attributes, like expressiveness, or even speed, can be inconsequential compared to that.
And while engineering can be a pop culture (e.g. Mongo or the latest fad), popularity is important for aspects that are totally counter to pop culture too: namely, pragmatism.
Programming is not about using what's "best", it's about using "what's best given business constraints" (which is something else altogether).
Besides, the hipster figure who listens to obscure music because it's "best" is also a pop culture phenomenon -- not to dissimilar to certain programming cults.
Having worked in both huge teams using popular languages/libraries/frameworks and small teams using what works best I'll choose the later any day.
We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
If you hire developers for what they know right now, of course you'll limit yourself to only the popular languages/frameworks. Its much more lucrative to hire developers for their potential to learn and grow; these people will make the best of any language/library/situation.
Of course, like you said, economics come into play but my point is that the popular choices often lead you to a path where you end up with a lot of mediocre developers, terrible architectures and endless conceptual debt. At the end of the day this is much, much more costly and doesn't even yield quality software.
> We're already allergic to frameworks where I work and we're slowly moving away from libraries as well given how low quality the average open-source library is. Once you realize you spend more time debugging open-source libraries than your own codebase, you stop caring about popularity.
See, the problem is, you still need to use frameworks and libraries, you just end up rolling your own, and now you are responsible for supporting and documenting all the different use cases your developers have. If I have an issue with, say, React.js, I can tap into the pool of the thousands of Stack Overflow questions and discussions, whereas I can't do that with a home-grown framework. Unless I'm doing something really low-level, I'll take the thing that has had thousands of man hours poured into it and an entire ecosystem built around it over the thing that you made because you're "allergic" to open source. You're going to be debugging someone else's code anyway, but the time spent doing that with open source frameworks is offset by the time saved because you don't have to build everything from scratch.
I never said I'm allergic to open-source, I said I'm allergic to frameworks and the vast majority of libraries out there. That leaves the few gems like React.js but they're libraries, not frameworks.
I won't have to write my own framework by not using one, while it may be easier to use one, its far simpler not to use any. You spend so much time trying to fit your use-cases into the framework's paradigm that its usually much faster to just write from scratch. Every single framework I've seen so far had huge scalability issues, they're easy to get started with but you end up crippling your agility as the codebase scales.
As for rolling our own libraries, we can make them specifically for the use-case at hand without anything extra. What's the point of using a few dozen libraries when you only use a fraction of each and now your bundle is megabytes in size? And that's not even counting all the extra code required to wire them all together. There's a reason why we say the web is bloated.
I tend to think the other way - the more popular the language, the more mature it's open source libraries. For instance, there are amazing open source java libraries out that's been battle tested in the wild.
Also, isn't the alternative of debugging open-source libraries writing the functionalities you need yourself? Working with faulty open source library is tedious, but that work can be seen as way to contributing your time to make open source library better for everyone.
As much as I like to contribute to open-source, the reality is I have budgets and deadlines to meet.
Most libraries out there will do a LOT of things I couldn't care less about, making them harder to integrate and debug and reason about, on top of bloating your executable.
I do agree there are a lot of amazing libraries out there and we do use a lot of them. But that's after analyzing them and figuring out they solve our problems and actually will save us time. For the vast majority of libraries we look at, its usually faster and better to roll our own.
"I don't get why people chase popularity in programming languages"
I am forced to do this simply because I consult at companies where the managers do exactly this. They will not let me use a language unless it is a top language. If I say "Clojure would be excellent for the project that you have in mind" they will reply "We can not use Clojure because it is not popular enough. We have to use a language where there is a large pool of developers that I can hire, and there is no risk that the language will disappear in 5 years."
I can understand in these environments they want to limit risks. And because the work is boring and the conditions are average to begin with, these companies are always on a massive roll of junior developers. It's especially bad if code isn't their main area of expertise.
I've seen companies of 300-500 employees struggle to keep even a single senior programmer over half a decade. They'd get far more talent by actually embracing an engineering culture. What I always see is that the juniors start getting experience, realize the place they work at is a huge pop culture and leave for an engineering one, thus lowering the talent pool of said company.
Basically they don't want smart engineers, they want replaceable code monkeys. They have yet to realize there's a few orders of magnitude worth of quality and productivity between the two.
I used to work in such an environment until I had enough of this cancer and decided to move to a small studio with less than 30 employees but with a very strong engineering culture.
Yes, that, and the quality of applicants tends to be higher for some of the less popular but more interesting languages. I worked at a company that had a large java codebase and was reluctant to try anything different for fear of not being able to find developers. But then we'd get these applicants with dozens XML/JAX-WS related keywords on their resumes but who couldn't write a simple for loop or understand what a database transaction meant.
I recall reading about someone (was it Spolsky? IDR) who looked for candidates with certain niche languages on their resumes, because it served as a quality signal. If they're interested in learning Clojure, for example, they may just be more generally curious and/or have a desire and interest in learning about different paradigms.
That said, at a practical level one has to balance competing demands. If you have someone on your team working on a project in X and they're the only X developer you have, you're at risk because if they leave, you may be screwed. Plus, they won't be getting quality feedback on their work because no one else can understand X.
I think its google who also asks for Python experience next to Java experience because it shows you went ahead and learned something on your own that wasn't spoonfed to you in school.
While others have pointed out the value of popularity, I think you make an interesting point about SO part of the ranking.
Consider the corners in the graph off the line. E.g. - SQL: "nobody" is making voluntary github projects with it, but it generates a lot of questions (the legacy code quadrant). Alternately, there are fewer things below the line, but those would be the things that people are using, and NOT being regularly confounded by WTF they do :-)
Because if you like a language and that language is popular, you're more likely to find a job using that language, which in turn will make you happier.
I will be blunt and state that neither of them matter.
Some people might hate Java and search for alternatives on the JVM, but 90% of the production code on the JVM, its commercial variants, and Android is plain Java.
Also ClojureScript is not 100% Clojure and most web shops across the world only care about JavaScript.
Likewise, the majority of developers targeting BEAM will be using Erlang.
If something I learned from my Turbo Pascal/Delphi, Oberon experience, is that programming languages that aren't considered a first class experience from the platform owners never manage to get a significant market share, long term.
I agree and add even 90% sounds like conservative estimate. One reason I think is Java is good enough and the incredibly loud communities of smaller JVM languages have not produced enough libraries, tooling etc to attain a 'just works' title which is needed for most common type of development done by salaried workers.
I am not sure why Clojure is "stagnating". I don't think it's about Emacs, we have Cursive now which is very powerful and runs on top of IntelliJ. Clojure also is picking up in webdev. A new book just came out from Sotnikov, Arachne was announced recently, Om is being worked on, couple of different screencast series are being made, etc. I am not a seasoned developer but I like Clojure and I am sticking with it because it makes sense to me. I think it's an awesome language and I wish more people would try it and develop in it.
I am yet to do any web development project where the customer allow us to use anything other than JavaScript, eventually TypeScript but only because it is a Microsoft language.
Elixir's doing very well for its age—before 1.0 it had four books, a conference, and a dedicated video series. With the rise of Phoenix there's quite a lot mire of resources for it.
Clojure (and ClojureScript via Reagent[1]) is what got me into functional programming in the first place. However, as a developer working in a .NET shop I found more opportunities (e.g. .NET interop) to do "functional programming" in F#, which has also been well support cross-platform for some time.
At the time, Leiningen was still in its infancy and I hit a lot of issues getting things running but when I finally did the language had a profound impact on me as a developer.
"the language had a profound impact on me as a developer."
I think Clojure will remain in the developer culture for that. Clojure will be recognized for its action in LISP resurrection and functional programming renaissance.
It's often said that "The Velvet Underground's first album only sold a few thousand copies, but everyone who bought one formed a band.". It's the same for Clojure: there will be never a lot of apps, but I'm pretty sure that all the developers who learned Clojure became better developers, developed good libraries in other languages, started a blog, etc.
I think ClojureScript could benefit my team as both a productivity and performance boost. But convincing a large team to switch to a lisp is pretty much never going to happen. I might as well try to get everyone to switch to dvorak keyboards while I'm at it.
Clojure worked for me until I started to do parallel programming. I tried to use core.async but immediately found that I'm using two distinct style of programming, and code reuse became a serious problem.
I didn't find any resources on how other Clojure programmers deal with this problem, but this eventually lead me to drop Clojure and Clojurescript, and use Elixir and Elm instead.
I don't think it matters much what these charts say as long as they do not measure merit and Clojure has a lot of it. You can use it irrespective of how an ill-advised majority of developers think Javascript/Node/Angular is good.
Please think about what you are saying when you write "You can use it irrespective of how an ill-advised majority of developers think Javascript/Node/Angular is good."
Most of the places I work will only allow the use of a language that is in the top 10. I am not allowed to introduce Clojure, because it is not popular enough. But if I told management "We should use Angular" that would be an easy sell. You sentence would be more accurate if you had simply written:
"You can use Javascript/Node/Angular irrespective of how good they are, but you can't use something that is great because a sometimes ill-advised majority of managers base their decisions on their estimate of future risks."
Regarding the reliance on Emacs, might not be the case anymore. When I was new to Clojure, I immediately used an IntelliJ plugin called Cursive. It was/is great, same experience as writing Java in IntelliJ. (https://cursive-ide.com/)
But the problem is you really do need a "paredit" for your editor when developing in Clojure. It's a double whammy for beginners, and a huge one at that. Pretty much every other language ever is perfectly editable in everyone's editor as it exists today.
Check out parinfer! It's a great new editing mode for lisps that doesn't require memorizing any special commands. It's built into Cursive as well as my own IDE (Nightcode).
You don't even need a full-blown "paredit", just the ability to jump back and forth between different kinds of opening and closing braces. I've been using vim for Clojure exclusively since I first started dabbling with it in 2011, I'll die before succumbing to emacs... A bigger issue though is that to really sell Clojure you need to sell the alternate mindset of developing it represents as a lisp. With emacs, you can assume slime, and immediately you're exposing people to developing their code iteratively instead of the traditional approach of edit file, save, run from scratch.^1 With every other editor you need to first give beginners^2 something to approximate slime^3, or else you're going to present developing in Clojure the same as you'd present developing in Java, which is to say you'll lose a lot of the punch.
^1 As an aside this is why I'll never be satisfied with plain Java/JavaScript no matter how many new static features they get so long as they remain fundamentally opposed to the build-up style of programming.
^2 By beginner I mean to Clojure; I don't think Clojure is a good language for programming beginners. It is suitable for people as a second or later language, but not their first. So basically I agree the need to explain the preferred editing environment is a hurdle -- if the person's first language was Scheme, maybe there wouldn't be a problem since you don't really-really need paredit or syntax highlighting or auto-indent or anything besides the ability to edit and save text.
^3 For me that's just a separate terminal in a screen session that a vim plugin talks with, though there are others (and probably better, I haven't tried them seriously) for vim.
As a beginner I found that learning a single keyboard shortcut - Ctrl+W - "expand the selection to the surrounding semantic unit" was a huge productivity boost (the opposite action is Shift+Ctrl+W).
Coupled with the setting "Settings→Editor→Smart Keys→Surround selection on typing quote or brace." it's amazing.
My point is you have to use a paren tool to keep lisps sane. That's not true of any other type of language. So when trying to introduce someone to clojure, they see not only a very strange language but a new tool requirement as well. It really creates barriers to entry.
And for those of us who prefer editors (vs IDEs), Proto REPL for Atom (https://github.com/jasongilman/proto-repl) is a great option to work with Clojure. I think it deserves more attention, as it can help a lot with Clojure adoption.
Full time Clojure dev here who has been transitioning to non-Clojure projects recently, for two main reaons:
1) I've decided that static typing is the world I want to program in, for a wide range of reasons.
2) The JVM (and JS) have their limits, and Clojure is just not as portable as I'd prefer.
Otherwise, I learned a lot from working with Clojure over many hundreds of programming hours, and it is an impressive feat of engineering, but it's limitations are insurmountable at this point.
A lot of what I learned in Clojure I can now use in C++ since the C++14 version of the languages supports a lot of functional programming techniques (though not thoroughly). C++ today is not the language it used to be, and the ability to write and use standard library higher-order functions with my own simple anonymous functions is really nice.
I guess the patronizing and uncooperative attitude towards the community plays its part. If you don't accept Rich Hickey and Relevance / Cognitect / whatever they call themselves nowadays as the ultimate source of wisdom, your opinion is worthless and you're "Doing It Wrong™".
But on the other hand, they're very much keeping the tradition of the of the Smug Lisp Weenie alive, albeit as a caricature rather than a rebirth.
Regarding FP: My daughter is a (non CS STEM) student at UC. She knows one language: "R". (I tried to get her to learn Python in high school, but it never took)
While R is certainly not a general purpose language (yet?), it is very much an FP type language, and gaining in popularity. I have only tinkered with it a little, but it looked pretty sound.
If that's the worst issue, I'm not seeing much of a problem. I guess I'm not particularly hyped about intro of "let" (block scope) into Javascript, vs "var" (function scope), either, but it bothered somebody enough to need "let".
Does R have an "IIFE" type construct, similar to JS or Golang?
1.) Clojure fell back
2.) Elixir, though small, is still moving forward
I've been a fan of Clojure since 2009. It grew rapidly for a few years, from 2009 till at least 2014. It has stalled out. This makes me sad because I've loved working with it and I think it a great community, in most ways. But it is true that the community has been unable to answer some of the criticisms leveled against it. The reliance on Emacs has meant it is not easy for beginners. On the other side, the elite (the purists?) have wanted to see Clojure be more like Scheme, or more like Racket, or more like Haskell. Clojure has offered up many interesting ideas, but perhaps hasn't quite built a complete eco-system that makes it broadly appealing.
Elixir, though very small, still seems to be moving forward, and perhaps has a chance to answer some of the demands that people made of Clojure (more pure? easier syntax?). Maybe Elixir is the language that make the Functional style the dominant style in computer programming?