[d_t_w]

We build a product in Clojure that runs on the JVM and in the browser (https://kpow.io).

Clojure/Clojurescript gives us a language/toolset that works in both the front and back ends. In some cases we have we have code in a single source file (.cljc) that works in both the browser and on the JVM with no modification.

The feature that cross-environment functionality implements in a single source file is complex in some cases (e.g. a grammar / parser / interpreter for a subset of JQ).

Both the front and back end use the same core functions and same datastructures to implement the product. Data is moved between front/back via Transit (and encoding format for Clojure datastructures).

In my experience the reduction in complexity through the stack is staggering. Once you've learned Clojure that is..

[pjmlp]

My experience with guest languages for the last 30 years is exactly the opposite, not only one needs to master the platform, there is also the need to add on top extra tooling, libraries and the occasional dark magic debugging knowledge for the guest language to decipher how the compiler chose to represent the guest language to the platform infrastructure.

Hence why I only play with them to learn about new concepts, but always go back to what gets delived in the box for production code.

[d_t_w]

Clojure is as much a 'Guest Language' on the JVM as Scala or Kotlin.

[pjmlp]

Indeed, my point applies to all of them, to anything !JavaScript on the browser, to anything !C#/F#/VB/C++/CLI on .NET, to anything !Objective-C/Swift/C++ on iOS,...

Basically whatever gets added on top of what is available when platform XYZ SDK (or equivalent), gets installed on a fresh new computer.