I've come to find Datomic less than great for prototyping in situations where my data model is evolving. Since your history of data is immutable you get to live with all of your mistakes forever, you can't really just write a migration that shifts from one data model to the next.
It was a service ticket system where we moved from a boolean status to a string for more states (noob modeling mistake I know). The problem came up a few months later when a dev pulled every attribute, saw the old field, and wrote new code against the old field, leading to some really confused tickets.
Looking at that blog post though, it seems that using #9: Annotate your Schema could have helped us avoid this situation. Thats an interesting feature of Datomic I was unaware of.
I suppose it’s all a trade off. The pain of jumping through hoops with the libraries mentioned above
With no libraries, modern JS makes being "diligent about immutability (as the article puts it)" straight forward, making the benefits of something like Clojure very small and not worth it for the majority of projects. Having immutability by default pales in comparison to the benefits of using mainstream languages with big ecosystems IMO.
It depends on the language. Elm does not allow you to call JS directly, but ReasonML and Fable (F#) both do. This means with a little effort you can use any JS library.
I think the advantage of these functional web languages is in small but high-skill teams where robust code can be written in a minimal number of lines (more expressive, type checked, etc) and everyone on the team is able to pick up new things quickly. The big caveat is that you need to have a solid understanding of JS before learning these languages on top. This makes the barrier too high for all but the best junior developers.
Another point is that Node is not particularly good at vertical scaling, so if you care about this and want a shared language between client and server, F# and OCaml (ReasonML) are much better bets.
I definitely agree about the benefits of a mainstream language/big ecosystem when it compares to something more niche (Although ClojureScript with shadow-cljs [0] has an excellent interop story with the JavaScript ecosystem).
I’m not sure I can agree with the premise that “developer diligence” is a reliable approach immutability (or any other development ideals). Maybe in a small team of like-minded devs diligence is enough, but in the large, with a multi-paradigm language that allows pretty much anything, you can be sure to see pretty much anything!
Clojurescript still has the annoying problem of having to convert between the two language data structures. So even with shadow-cljs(no idea how good it is) Cljs is no smooth sailing either. Immer seems to be the best compromise and more ergonomic approach to immutability in JS. Immutability is also needed much less in single-threaded environments where JS operates where async code is pretty much used for IO 99% of the time.
Agree that converting between JS and CLJS data structures is a pain.
The best approach to dealing with that is to isolate that interop at the edges of your program.
I’m currently, coincidentally, working on a wrapper for Express to do just that. The wrapper library is responsible for mapping between the Express req/res objects to simple ClojureScript maps. Combine that with a similar wrapper around something like fetch or axios and all my code can be pure ClojureScript.
I mean, that is the general practice in Clojure/Java land. Write wrappers around the native libraries to isolate the pain that comes from interop.
I’m a sucker for Clojure though, and willing to do the work.
In my opinion, the Emacs/Vim communities clearly missed a golden opportunity for a more larger adoption.
They just copy their init.el/vimrc to the server, Emacs/Vim users have been able to do this (coding on remote environments without all the kludges) since forever ;) and personally, I find it superior to vscoce's remote plugin since your editor and tools sit on the same machine.
For GUI editors, I agree that vscode's remote development extension is a killer feature and nothing can't match it today.
> They just copy their init.el/vimrc to the server, Emacs/Vim users have been able to do this (coding on remote environments without all the kludges) since forever ;) and personally, I find it superior to vscoce's remote plugin since your editor and tools sit on the same machine.
Unfortunately this doesn't work well if your connection has a high latency though, which I think is what VScode does really well.
did you ever try this? or is this just something which you think should be it's distinguishing feature?
Asking mainly because I think this is cool, but the whole setup (lots of random binaries in the server) is not so different to an AppImage of emacs+xpra (if you could do tha) and the times I tried, the thing was _very_ picky about connection losses/timeouts...
Yes, I did try this and although I don't particularly need remote editing, the fact that it took me less than 2 minutes to setup a remote editor with auto-complete and other IDE features was pretty amazing.
Yes, Clojure relies heavily on the JVM's GC being very good. It trashes it like there is no tomorrow and it would be a lot of work and extremely hard for an implementation of Clojure from scratch to match the performance of Clojure in the JVM because of how good the JVM's GC is.
Having said that, I have move 3 projects (10k-20k LoC) to JS from Clojure and don't plan creating new ones in Clojure, the JS projects ended up being faster, shorter and easier to understand. Idiomatic Clojure is very slow, as soon as you want to squeeze any little performance out it your code base will get ugly really fast. Learning Clojure is nice for the insights but I'll will pick nodejs first any day for new projects. Even if I need the JVM, my first choice probably will be Kotlin and then Clojure.
Of course there are many more downsides to using Clojure. No ecosystem, the cognitive overhead of doing interop with over-abstracted over-engineered Java libraries(because of no ecosystem ;)), the horrible startup times, the cultist community and the interop is really not that good, sometimes you have to write a Java wrapper over the Java lib to make it usable from Clojure. The benefits over JS are minimal but the overhead and downsides are too much. Worth learning it but not worth using it for real production projects.
Is there anything in particular that you had to give up to make the move (aside from thr jvm)? I am assuming that for node.js to be shorter and faster you avoided the bigger frameworks (next, typeorm etc) and had to stick pretty close to basic middleware ala express.
This is what bugs me about the Node.js cult - it's often compared with Rails, Django and Laravel which is just nonsense. Even Express isn't the same as plain Node. Plain Node.js is only comparable to something like Golang's net/http, Ruby's rack or raw imperative PHP with no classes. Once you add the kind of scaffolding included in Rails and Django Node.js slows down rapidly with significant memory bloat. Try Redwood - the latest Rails-in-Node and observe the memory footprint.
I’m intrigued by what kind of code you’re finding is shorter and faster in JS. I’ve had the opposite experience, even limiting Clojure to a single thread.
