Clojure on the back end and ClojureScript on the front end.
Some reasons:
1. It's a proper full-stack solution. You can share code between client and server if you need to.
2. There is some amazing front end technology (Om, figwheel etc.) that can change the way you think about front end development.
3. It is hard to match Clojure for productivity / interactive development. You can code almost everything at the REPL without restarting (no restarts or edit/compile cycle time needed)
4. You can use all the Java libraries very easily (although idiomatic Clojure wrappers exist for almost everything you are likely to need)
5. The usual Clojure reasons: functional programming, concurrency, immutability, Lisp macro etc.
Note: you don't need to commit to Emacs to get the productivity benefits of Clojure.
Eclipse with the Counterclockwise plugin (and I believe IntelliJ with Cursive too) also give you comprehensive REPL, s-expr manipulation and paredit features.
Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.
goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.
Silverline Mobile (http://silverline.mobi/) uses Clojure in production - managing data from sensors installed in the homes of senior citizens in Singapore.
IMHO Clojure's omission of reader macros is sensible: it prevents proliferation of custom syntax, which makes it harder for a human to read code and reason about reader behaviour. The Clojure reader also already has its own literal syntax for vectors and maps [] and {} (which eliminates the most common use cases for reader macros).
If you believe that standards are helpful, then surely one standard reader behaviour is a good thing?
Regular macros are a different issue: they allow creation of custom control structures that aren't possible with normal functions. That's a powerful and useful feature, as many Lisps have proved over the years.
So Clojure rejects the former (unnecessary syntax sugar, potential for confusion, dubious value of reader proliferation) and accepts the latter (additional semantic power, proven utility). I personally think that's a good trade-off. YMMV of course.
Of course, there's nothing stopping you from implementing a custom reader in Clojure if you really want reader macros. So far, nobody (to my knowledge) seems to have cared enough to do this.
NOTE: I'm not bashing Common Lisp: just pointing out that language design has real trade-offs. For me, Clojure gets the majority of these design decisions right. For others, maybe reader macros are an essential feature and Clojure therefore doesn't work. No problem, use whatever works for you.
FWIW, I've been in the Clojure community for a few years and see almost zero FUD about Common Lisp. The atmosphere in the Clojure community is much more about pragmatism than zealotry.
Mostly, I see a healthy respect for other Lisps and a recognition that learning from traditions is a good way to build good things for the future.
There's a pretty good argument that taking away features is what makes programming paradigms effective. You create restrictions (invariants, if you like) that enable the paradigm. Consider:
- Structured programming takes away GOTO
- OOP takes away manual function pointer tables
- FP takes away unrestricted mutation
- Logic programming takes away explicit specification of execution order
- etc.
None of this is about "forcing" you to do anything. It just appears that humans aren't very good at coding with unrestricted power over their machines, and it helps to simplify paradigms in a way that enables them to be effective at reading and writing higher level code.
If this wasn't the case we'd all still be programming in assembly.
One of the reasons that Clojure has so many libraries is that most things didn't have to be implemented from scratch.
Building Clojure on the JVM was a genius move by Rich Hickey - it meant that an advanced runtime platform (the JVM) and a huge ready-to-use library ecosystem was already there from day 1.
Backwards compatibility with Common Lisp was never a goal. The JVM ecosystem is bigger by far (and IMHO more valuable as a target).
I don't think you can credibly describe Java/JVM as a small ecosystem.... there's nothing else remotely close in terms of the combination of runtime platform capabilities and the number of available open source libraries.
I'm actually trying to prototype a language that gets you the best of both:
* Clojure style dynamic development
* A Lisp (with proper macros, homoiconicity etc.)
* Runs on JVM
* Can use Clojure libraries unmodified
* Static type system (similar to Typed Clojure, but as part of the compiler and driving real optimisations, not just as a separate static analysis tool)
Also I would guess that people who like Clojure's philosophy are much more likely to build simple / loosely coupled / composable services than a big monolithic project.
Agree with everything you say, but it is worth noting that the insights you get from static analysis on desugared forms (which can be very large and complex!) is much harder to interpret than static analysis on the original forms.
So to make static analysis tools useful on macros, they really need some way to map back to the original source forms. Not all tools do this (either at all, or well) - and to the extent that they don't it is an big impediment for static analysis.
Also the killer challenge: macro expansion in Clojure can depend on a mutable environment at the time of macro expansion. This makes it impossible to do reliable static analysis, unless you are able to recreate the runtime environment at the time of macro expansion in your static analysis tool, which is hard/impossible in general.
This is part of the motivation for my little Kiss language experiment: with immutable environments you can keep the power of macros, but avoid the mutable environment problem. Ideally, macro expansion would be governed only by things that are provably compile-time constants (not sure how feasible this is while maintaining the dynamic flexibility of Clojure that we all love... but it's an attractive idea at least).
The problem is the design paradigm where you enforce an arbitrary fixed hierarchy on real-world data.
This doesn't work for several reasons:
* In the real world there are multiple overlapping hierarchies, which have different uses. Human 'isa' SentientBeing as well, which may be a much better heirarchy for modelling communications with aliens and robots. Most OOP languages either don't handle this at all, or handle it badly.
* Your hierarchy will almost certainly have to change (you'll be wrong, or new requirements will come along). Frequent major code breakage / refactoring is the likely result. If you also need to persist data across versions, you're in big trouble.
Property / prototype based methods are in general much more flexible for real world data.
It concerns me when people confuse the idea of gender equality and rights (which I think most reasonable people agree is a good thing) with the idea that men and women's lives have to be the same in all aspects.
I think it is much more harmful to impose a dogmatic belief that forces everyone to lead identical, mono-cultured lives and denies individual choice.
What if I want to go to a single-sex school? Who are you to deny me that choice?
Erlang has a very nice concurrency approach, particularly if you are into distributed and fault tolerant systems.
But it's ridiculous to say that "only Erlang can do concurrency". Many other languages do concurrency very well in slightly different ways (Clojure, Scala and Go, for example).
Biggest wins for us are:
- ClojureScript / figwheel as an awesome front end development combination.
- The combination of functional programming with immutable data structures
- Lisp "magical powers" (macros, interactive REPL etc.)
- Ability to exploit the Java library ecosystem whenever you need it
Biggest downside = Lack of types.