Should the future of Clojure be ClojureScript?

Community Center Watercooler
61

This is a good point. That’s probably one area where ClojureScript server side could improve. Lumo was a good start here. Since self-hosted ClojureScript exists, it’s possible to have a ClojureScript that can compile itself, running on NodeJS and V8 server side. But I think since it’s more focused on browser targets, there’s some quality of life improvement that could be done. But with this, you could recreate the Clojure/JVM experience, by getting rid of ahead of time compilation, and having ClojureScript compile code as it’s loaded in memory, and support REPLs and Eval and Macroexpand, and all that.

I think that’s where someone motivated could maybe continue the work on Lumo, and that could evolve to be a pretty good server side story.

2 Likes
62

Without wanting to get too involved in this discussion, you’re comparing two totally different things here. You should probably compare Express to, say, Jetty, or whatever the cool Java kids are using these days.

63

The premise of the original post seems quite flawed as its only dealing with one issue, the technology platform, for which the majority of employed developers have little or no say.

Also basiing a strategy on popularity is also incredibly flawed (i.e. everyone allegedly’ hates using JIRA yet its still the most used commercial ticketing system by developers)

A more valuable question to ask would be:

“How can the Clojure community effectively reach out to the wider development community to continue the adoption of Clojure/Script/CLR”

With a follow-on question:

“How can the Clojure community provide confidence to companies and industry that Clojure is a viable technology choice (a part of which is about hiring Clojure developers)”

I understood the major appeal to Clojure/Script/CLR was the language itself, the fact that “Clojure” is a hosted language is a removal of a barrier to adoption and not the main reason to adopt.

The Clojure syntax, a powerful REPL, a focus on simple design, a focus on data design, and wealth of open source libraries seem far more relevant to adoption by developers regardless of their background.

With Clojure starting on the JVM then familiar tools and environment would help ease adoption, but there has to be an over-riding driver to changing language. A Java developer is not going to invest time in learning a new language (and functional programming paradigm) just because they can sneak in an uberjar file into their current Java stack. Having a simple way to deploy into an existing stack does remove an important barrier to adoption though.

Comparing languages by popularity is generally meaningless. Python went from relative obscurity to being hailed as the ‘number one’ language to learn as data science became a huge trend. There has been an explosion of languages over the last decade and so what becomes and remains ‘popular’ is very unclear.

Promoting technology based on popularity requires a serious amount of financial investment. When you have Microsoft, Facebook, Google and many other companies investing billions in languages, then popularity can come more readily (although not guaranteed, e.g. Dart).

4 Likes
64

This has to be a show and not tell thing. Most developers couldn’t care less about the theoretical underpinnings of languages. They care about what gets the job done easier. This leads to path of least resistance a lot of times, unfortunately.

Jira’s a good example. Yes, it’s quirky and annoying, but dealing with those quirks is better than having the ticket system replaced every couple of years because some new shiny thing came along. While most people hate using it, they don’t really care about ticket systems and use whatever the company decided to go with. Trying to get it changed isn’t a fight that’s worth fighting.

As far as getting Clojure adopted, start with non-prod tools, test environments, things like that. When people start to see what it can do, they’ll be more likely to get on board with it.

In general, though, languages become popular due to what problems they solve, not how well designed they are. Go’s a good example. The one thing I keep hearing about it is “it’s a horrible language, but a great tool.” Java was the first to have native performance without needing to compile to native, so it exploded. Javascript became the language of the web. Python found its niche with data science and testing. Clojure needs something like that for people to move to it en-mass. As long as it’s solving the same problems in a different way, it’ll remain niche. Which might actually be better because there won’t be pressure to add little features that aren’t generally useful.

1 Like
66

I’d say that this is more of an obsolete perception, dating back in Sun’s times, when every Java release took years (along with other perceptions such as “Java is slow”, which isn’t true for a long while now, but still ). Java - both language and VM - are evolving quite nicely these days, with very carefully considered additions/removals. Project Loom may even make threads trendy again :slight_smile:

67

Maybe instead of moving JS programmers into ClojureLand we could move Clojure into JS source files with an embedded syntax à la JSX. It would be the occasion for Clojure to shine for basic immutability and pipelining and prove itself as a superior alternative to Immutable.js and other libraries it has inspired.

If this ever gets as much traction, then programmers will naturally slip towards Clojure.

I also wished Clojure was more portable. Even things as high level as handling files are specific to the host which makes porting code real (but hopefully boring) work.
Ideally I’d like to have Clojure’s compiler implemented in Clojure so that any Clojurian can understand it, with the interface to the host minimized as much as possible. I’d like to have guides tutorials and examples on how to port Clojure to a new host and this should be made in such a way even a beginner programmer could do it.

Is this realistic (I haven’t ported Clojure to anything myself) ?

Edit: I’ve been programming IoT controllers lately (raspberry pi zero & onion omega 2), and both Clojure (on the pi) and ClojureScript (on the omega via node) are very slow. Chicken Scheme is blazingly fast. It’s faster through a local ssh connection to my mac than Clojure on the JVM on that same mac. It’s like switching from an old cathodic tube to a 120Hz 4K screen.

68

True, but my main point is that it’s increasingly becoming an enterprise language. Small companies and startups are avoiding it more and more. With things shifting to the cloud, micro services, and serverless solutions, Node, Python, Go, etc are more appealing. On top of that, Android switching to Kotlin doesn’t help its chances outside the enterprise.

Not really. Java’s a late arrival to that game. By the time Loom sees the light of day, it will be well behind Python, Node, Go, et al that have had those features in the wild for years.

It depends on your definition of realistic. I don’t know how tightly coupled the Clojure front end and back end are in the compiler. It relies on the host for garbage collection and whatnot, would require the immutable data structures to be ported, etc, so you’d have some work to do, but it should theoretically be possible to host it on top of C++, for example. Where the “possible” and “realistic” lines cross is the question.

69

It’s really hard to create a good abstraction for such things. So you often risk getting stuck in a “least common denominator” abstraction that no one likes in the name of portability, which people rarely actually make use of in practice. And the biggest downside actually relates to your next question. If you created more IO related APIs inside the core lang instead of having it be done through interop, it would now become much harder to port Clojure to a new host, because you’d need to figure out a way to implement all of the core IO behavior on your new host in a compatible way, which is no easy task, and has a high risk of bugs due to unaccounted for slight behavior differences of the host.

In my opinion, it’s better to keep all the stuff meant to be portable IO free, because that’s easy to provide a reliable implementation for on a new host. And keep IO as something that’s meant to be done through host specific interop. A library or framework can still be multi-host by having cljc files with host specific implementations of the IO parts of their code base.

I think the ClojureScript compiler is like that. And that’s the compiler that Clojerl used to implement Clojure over BeamVM. The talks about that work are the closest to a tutorial about it I know off.

Well, Chicken compiles down to C, and has a pretty simple GC. Also Scheme is a much smaller and simpler language than Clojure, which probably helps it have a compiler to C in the first place. The closest I’d know off here for Clojure would be to possibly look into GraalVM native compilation for aarch64 which should run. The annoying bit is Graal can’t cross compile, so you’d need to get say an AWS aarch64 EC2 instance, compile your app there with Graal native image, and then run it on your Raspberry Pi.

The other thing I can think of here is, if you can do the above and get Babashka running on a Raspberry Pi, then you can use that to run your Clojure. Add in a Babashka lib to manipulate GPIO, and you’d get something pretty good I think. Though might still be slower than Chicken Scheme since Babashka runs your code interpreted.

There were some attempts at that for a full fledge Clojure, but the closest I know off that is usable is Ferret, which compiles to C++ 11, but it’s only a subset of Clojure proper: https://ferret-lang.org/

70

very interesting post.

also this kind of reminded me of the following ( very interesting ) talk:

also:

agreed!

now, although it is impossible to predict which language is gonna become popular and which will not, i do feel like there are some factors at play, that are definitely gonna help with a language becoming popular. i think it is a bit like what you get with economics ( soft science? ) or something, where you will not be able to predict things perfectly, still that doesn’t mean that there is no value in paying attention to concepts such as “supply and demand”.

now to discuss these factors with any real seriousness is clearly outside the scope of this topic… so, what i wanna point out / focus on now is one factor in particular: ( not saying it is necessarily the most important factor, i just think it is an interesting one to consider… )

so… and coming back to python, here is ( probably - i have not followed this myself, tbh… ) a good intro course on programming:

my point being, that people do like to use what they know.
also to learn something new is a major investment.
therefore i think that something like the following definitely does matter:

https://timms.uni-tuebingen.de/tp/UT_20081127_002_info1_0001

( i could of course also link to the classic SICP course, but the quality of the course from tübingen i can personally vouch for… also… it doesn’t get nearly as much attention as it deserves… so… )

anyway, what i am saying is this: if you wanna make clj more popular ( afaik that is still an explicit non-goal, which i interpret as “if it happens, fine. we’re just not aiming for it. also, we are not actively trying to prevent that from happening, we just do not see it as a priority, at least for right now.” ) you should probably contact as many schools as possible in order to convince them to teach racket. ( yes (((racket))) because of HTDP + all that wonderful stuff… then, once people have fallen in love with lisp, chances are they’ll become interested in clj as well… )

okay, now you say, well… sounds plausible enough in theory, but since i don’t have those kinds of connections, there is really nothing i can do about that, right?

WRONG!!! you can always be proactive and create a blog about clj / cljs … or a screencast… or just give a “thumbs up” to the people who are writing about lisp… or whatever it is you would like to see take off!

alright, now that brings me full circle i guess, :smile: because obviously what i have in mind is this stuff:

now, tbh, i have only had a quick look from time to time at some of your videos ( what i have seen was always really really good! ) but i have been subscribed to your channel for quite some time now, so even if i can not make time to actually watch the video, i still get the mail from youtube ( every saturday? ) telling me that you are going online again and ( knowing how this is more work than it looks ) i always end up thinking… look at how people are still caring about lisp / emacs!!!.. - and that, to me at least, feels real good! :smile: so, thank you for that! and keep up the good work!

71

That’s not entirely accurate. Project loom aims to give you M:N threads, where at least Python and node can only do M:1. I don’t even think Node has threads - it’s callbacks or promises.

I think a lot of the bashing on the JVM is just based on perception and not real production experience. The only downside I see is the Clojure slow startup time due to having to compile a lot of stuff. Slow startup doesn’t mean slow performance though.

3 Likes
72

Well, it aims to allow millions of concurrent operations without spawning millions of threads. Node and Python both allow that today. Python’s 1:1, but everything gets serialized because of the GIL. It does allow you to run async event loops on multiple threads, so it can do some pretty elaborate stuff. Node doesn’t have threads, but doesn’t necessarily need them because everything is non-blocking. It’s only an issue with CPU intensive stuff that loops without releasing the CPU.

There is a lot of that. I also know people who now avoid anything JVM based because of their PTSD from previous jobs. There’s plenty of times when another tool is just a better fit, though. Using Java with AWS Lambda, for example, is an issue because of the JVM startup times. Throwing together a REST server is easier in a language that handles JSON better. Java still does well for larger projects, but it tends to be too heavy for smaller ones and the current trend is multiple small projects instead of one big one. Java and the JVM will have their place for a long time to come, but their piece of the pie will continue to shrink.

73

So does the JVM – with pretty much all the http servers out there that use NIO (Jetty, Netty etc) – and with 3rd-party libraries (Akka etc). There’s nothing magic with Python’s async event loop. Before the current flavour of asyncio, there was Twisted, and having written production systems based on it, I don’t want to go near an event loop any more. Nothing against Twisted, it’s a fabulous project written by fabulous people, just that debugging and monitoring and tuning code that’s written against an event loop is a PITA.

The JVM’s feature set is a superset of what Python and Node have. The ergonomics and community and libraries around them are different – for sure. But technically there’s no real challenge. It’d be more interesting to talk about Go, Ocaml, Erlang – there is some pretty stiff competition for some use cases.

1 Like
74

No challenge there, Java is (used to be? I haven’t used it for 15 years now) heavy and ceremonial. Javascript plays well with JSON, but arguably so does Clojure. These days when I’m thinking about production systems, I’m much more interested about the underlying runtime rather than the language on top, and JVM will continue to shine in that aspect.

1 Like
75

Start with ClojureScript vars not being reified at runtime, and follow the implications.

76

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.