Spec is very useful, but please implement it without macros. Metosin did a great job to make it more usable, but we still struggle because specs could only exist in Namespaces. We want to use spec as EDN with pure functions. (+ recursive specs would be awesome)
This is why guest languages tend to fade away, as the platform evolves and the platform system languages adopt the features that made those guest languages appear in first place.
That is true for guest languages designed to overcome specific issues in a given language (think CoffeeScript vs. JavaScript in 2012 and then in 2019). But I don't think it really applies to Java vs. Clojure, which both pretty much force a specific (different) programming paradigms and have completely different design.
I'm looking at the docs -- is there a guide for targeting new host langs? As a starting point, what is the minimum "core" language that needs to be defined in the host lang so that the rest of the system can be bootstrapped by Clojure libs? (Clojure.core doesn't seem to be the answer -- there seem to be plenty of non-core/prim functions defined there.
Also, are Clojure libs (either automatically or via attribute on the package) flagged as "pure" (Clojure-only) vs. needing imports from a specific host lang?
Not sure I follow -- there are certainly many primitives that must be defined by the host to bootstrap that are not special forms -- starting with list, cons/conj...
I doubt there’s a guide anywhere: it’s far from a trivial undertaking. If you want to look at the Java code that builds all the primitives, see the Clojure/Lang folder:
Part of what makes it Clojure instead of just a Java-based lisp are the persistent data structures that allow for efficient immutability, and the seq interface for working with collections smoothly. There’s a big (scary, to my eyes) set of classes that underlies all of the convenience. Thankfully it’s very stable so I don’t have to think about it.
Unless they follow up and keep up with the host platform. This is the biggest pain point with Clojure for me, the java interop has some limitations that we could not come by.
Kotlin already has an impedance mismatch with the JVM, because like all guest languages they have come up with their own ideas, which don't follow how the platform ended up implementing them.
Examples are sequences vs streams, lambdas vs SAM types, default interface methods, co-routines vs fibers, inline classes vs records, reflection.
Only first class support on JetBrains products, while many Java shops are still Eclipse, NetBeans and Oracle Studio users.
Additionally, since they want to stretch outside the JVM, there are semantic restrictions if the code is also supposed to be compiled by Kotlin/Native.
Kotlin has indeed a future on Android, given that Google is unwilling to move their support beyond the Android Java flavour (aka Google's own J++) and with #KotlinFirst, Android has become the KVM.
So, on Android I do agree that Kotlin has a bright future, however in what concerns the JVM I forsee an adoption cycle like every other JVM guest language.
Thanks!
The entire project essentially lives in a series of horizontally scaling node.js processes doing all kinds of things. The worlds are divided into chunks which helps significantly with culling network traffic and distributing the load.
For the database I moved from MongoDB to Postgres. When I started doing Hordes I had very little DB experience and thought that using MongoDB might be a good idea since I am using node. Turns out that Postgres is much better at helping with transactional logic for an MMORPG. Inventory management for example can be constructed almost entirely with constraints, ensuring that the data always makes sense (no two items occupying one slot, that kind of thing).
The alpha used vanillajs for the entire front end, but with the beta I started using Svelte and Rollup, which I would highly recommend for almost anything.
Yup, Svelte is hot and Postgres is always a good decision! Thank you for the details, really interesting project!
Once I built a CSS based browser MMO myself as a challenge. I used Clojurescript and React on the front end and Clojure with a simple in memory key-value storage. My solution was basically a turn based architecture, but many turns happened in a sec, so it was semi-realtime.
CSS means I didnt use webgl, just pseudo 3D with divs and transforms. Field of view was small, but playable. :D
Clojure's startup time is very slow compared to other languages, but we balance it with fully reloadable systems both on the backend or frontend.
Otherwise the speed is almost identical to the speed of native Java and native Javascript.
Except when you experience the power of lazy structures, then Clojure is faster than native code.
