My view is that Clojure has enough critical mass now that it's not going anywhere. There is a large community that's very active and enthusiastic about the language. There are many companies building their businesses around Clojure, and it's only going to continue to get better.
I don't think Clojure is ever going to become a mainstream language like JavaScript or Python, but that's very different from saying that it's dying.
I don't mean it's unsuited to them. My company has a developer with one year of Javascript programming experience productively working in Clojure. But, I think often about how hostile FP's vocabulary is to non-experts. (Personally, the baggage I brought from OO made FP incomprehensible for quite some time). Clojure documentation, and most tutorials aimed at it, for example, take for granted newcomers' comprehension. If we could measure the average number of languages a programmer brings to the table when he learns Clojure, I'd be willing to bet it's more than two.
Ruby and Python on the other hand are languages where beginners thrive! Not only are many of the language concepts self-evident, the communities are often driven by recently graduated beginners spawning beginner-level documentation, beginner-level sympatico, etc.
My biggest beef is actually with all the lisp true believers who wax on about their moment of clarity when all the pieces fit together and they realized that the universe is written in lisp. So far for me, it's just code.
I think the best we're ever going to see is mainstream languages like Kotlin, Swift, Ruby and Python which mix functional features with OOP. In fact Scala really falls into this category so it seems OOP is here to stay.
I wouldn't measure Clojure's success with those kind of numbers. The number of applications running Clojure code would come close to a real metric.
The whole point of Java and Python is to provide VPs with massive departments to bloat their egos with head counts. Clojure or Lisp don't aim for such goals.
And third, abstractions have costs. There is no wide-spread popular LISP, and people should really ask themselves why. We have lots of code generation, and depend on it more and more. But it’s “simple” (or “primitive”). It’s usually one step. You can read the input, and you can read the output.
I’m starting to get a sense that macros are like currying. Elegant, beautiful, powerful. But net negative if your concern is to get lots of people to create software together.
ADT DSLs + free monads or similar abstractions give you everything you need, in a more principled way.
Even as a whole it's slowing down heavily now, even Android is switching to Kotlin. The language is already not that trendy but Oracle's aggressive lawsuits is making it even worse.
Embedded software is a vast market, and it‘s mostly C with a rising share of C++.
Is it really? IoT still isn't taking off much and the more powerful the machines are getting (so every year), the less people are going to use C for that only tiny segment people are still using it for.
Where I've used C on a microcontroller 10 years ago, you would likely use a cheap Android board nowadays.
Look around your home. Right now. How many things have software in them?
How many things don‘t you see in your home? Everything in your home that doesn‘t include software has been manufactured and packaged.
My employer makes components for industrial automation. Have you ever thought about it? Nobody does, unless he has direct contact.
Building automation? Special machinery (huge presses or packaging machines). Whatever.
And re: your Android board: come back when your bricolage conforms to all kinds of requirements. Extended temperature range. Vibration. Electromagnetic compatibility (it‘s easy to accidentally broadcast in the naval emergency band). Etc. etc.
Not much as much as you think, apart from the routers, computers and phone, the only other thing I can think of is the dishwasher because it's half-recent. And I suspect the new ones just include a cheap Android board.
> And re: your Android board: come back when your bricolage conforms to all kinds of requirements. Extended temperature range. Vibration. Electromagnetic compatibility (it‘s easy to accidentally broadcast in the naval emergency band). Etc. etc.
I've worked on a company which manufactured their own card, that is much harder to do by yourself than buying a board which has been produced at millions of units where they solved all those issues directly. You can't compete with that easily. We had at least 5 iterations to solve the magnetic and heat issues, all of that comes for free in a mass-produced board.
I suspect you’re thinking at the wrong level. Your washing machine definitely does have software even if it’s not “recent”. When you press the buttons or turn the dials and it does stuff, even if it doesn’t have pretty graphics on the display, that’s software.
If you have a microwave, that has software, if you have a car that has a ton of software. Your car keys and your credit cards probably have software.
A developer board simply doesn‘t care about most of that, and if it does, to a much lower degree.
But we‘re done here, you‘re clearly not discussing in good faith. Stay in your web bubble if you want to.
Thanks for your well detailed argumentation, that was convincing.
Because your anecdotal evidence is more accurate than what this list (which describes its methodology) is showing you?
C jobs are very rare, and it's certainly not 14% of the programming jobs. Putting Java and C on the exact same level is a good sign something is wrong with what they are doing.
Most software developers don‘t hang out in internet forums, commit to GitHub or write blog posts about JavaScript frameworks. They just do their day job and go home to their family.
Outside of the web, mobile, desktop apps and even gaming (mostly C++) you mean? C is used mainly in low level computing and embed nowadays.
I've seen a fair number of metrics that show it's losing market share on a proportional basis, but holding steady on an absolute basis. Have you seen anything to contradict this?
E.g. the number of commits on Github vs percent of total commits on Github.
In JS in particular, activity is often used as a proxy for the "maintainedness" of a library. I think this is because JS is (currently) a moving target.
Clojure is one of those languages where, occasionally, problems get solved and don't require any significant further development.
Whenever Graal is mentioned, a host of reservations towards Oracle usually appears though.
I don't know how Graal will handle those two issues, it'll be interesting to watch.
Single data point, but nevertheless.
Cold Execution Times:
Java Function -> 660 ms
Native Java Function -> 460 ms
Go Function -> 470 ms
Java Function -> 30 ms
Native Java Function -> 30 ms
Go Function -> 30 ms
Java Function -> 17.8 MiB
Native Java Function -> 0.9 MiB
Go Function -> 1.2 MiB
Java Function -> 266 MB
Native Java Function -> 13.6 MB
Go Function -> 15.1 MBStill not a match for Hotspot and around me everyone still asks for .NET and Java projects.
And those data structures with indirect calls are never going to go away.
Now about all the other Clojure features...immutable, persistent collections by default, built-in async library, spec, standardized way of handling state and concurrency, and many more...