Developer experience is fantastic too with HMR, REPL and cljc files. It's fun to write Clojure code :)
You don't really need specific tools for HMR in clojure, it's kind of baked in the language thanks to:
- immutability (not impossible but hard to do HMR without it)
- REPL workflow
When developing on clojure, there's a long-lived clojure process and you continually send expressions to be evaluated there.
Let's say you start a server, you make a change to one of the functions that handle a route, just after making the change you will evaluate that function (from your editor) and the update will be "live" in the running server.
It's honestly hard to describe and it doesn't help that we call that "repl-based workflow" when in fact we are not using the REPL directly, but rather through plugins available for various editors. People might think it's the same as using nodejs or python repl, when it's nothing like that. If you're interested, you could check "Parens of the Death" or look for "Clojure CALVA" (VSCode's clojure plugin) videos on youtube.
https://www.parens-of-the-dead.com/s2e1.html
Edit: It is also not limited to development. Nothing prevents you from hooking into the clojure process in your prod server from your editor, editing a function and evaluating it.
You just monkey-patched a live server to fix a time-critical bug with roughly the same workflow as editing your code locally. Or brought production down, 50/50, but what's life without some risks eh?
> immutability
Make a case for immutability being so critical to HMR. How does an immutable data allow for swapping of code.
But objects don’t give themselves very easily to hot reloading, there are a bunch of edge cases that are not well-defined in a semi-swapped state (e.g. this new field always gets a value in the constructor, but was no just added. Should you rerun the constructor, or have it be in an inconsistent state?)
Immutable/FP concepts are a much better fit, especially if the building blocks are as small as they are in case of Clojure.
Also, it is worth noting that everything is immutable, not just data. Functions/protocols/records/etc are also immutable.
Functions/classes being immutable makes it much, much easier to reason about the dependencies of that function/class. E.g. check out this Python code:
import someotherpackage
import threading
import random
class MyLogger:
def __init__(self, name, path):
self.path = path
self.name = name
def log(self, message):
with open(self.path, 'w') as fd:
fd.write(message)
my_logger = MyLogger("init-logger", "init.log")
someotherpackage.logger = my_logger
someotherpackage.logger.error = print
print = someotherpackage.logger.error
my_logger.thingy = "thingy"
def change_logger():
def actually_do_change():
time.sleep(random.randint(1, 100000))
new_logger = MyLogger("main-logger", "main.log")
someotherpackage.logger = new_logger
someotherpackage.logger.error = my_logger.error
time.sleep(random.randint(1, 10000))
threading.Thread(target=actually_do_change).start()
time.sleep(random.randint(1, 10))
threading.Thread(target=change_logger).start()
Trying to hot-swap this would be awful. The big issues related to mutations are that a) there's no indication in someotherpackage that it's behavior depends on this package, and b) because mutations are allowed, the order that things are reloaded in matters, and c) some mutations are time-bounded.
If I change MyLogger and the VM/interpreter wants to hot-swap MyLogger, it has to recognize that it can't just re-load the instances of MyLogger with the same state. It has to re-load those instances, then re-mutate them, then re-mutate someotherpackage, and finally re-mutate the print function. It might also need to do the stuff that's delayed by that thread. Maybe. Depends on a couple of random integers that probably got GCed a while ago.
If you want to add an extreme layer of annoying, consider that this package could be a late import and only happens if a plugin is enabled, so the earlier code might rely on `print` actually being `print` or on someotherpackage.logger behavior that changes over time.
None of that applies in an immutable world. Nothing can mutate the someotherpackage package nor the `print` function, ergo nothing can depend on an earlier or different version of them. Dependencies are easy to track because the only way to introduce them is to import/directly reference them, or have them passed as parameters.
I don't know that it even needs any dependency tracking, though (provided they're using a pointer to a pointer, or maybe something smarter than that I can't think of). Immutability means that a) everything can be passed as pointers safely, b) those pointers can't be modified by the code, and c) there is never a reason to have more than one copy of a pointer to the bytecode for a function.
Each function gets a pointer to its bytecode, let's call that p1. Every reference to that function is a pointer to p1, which we'll call p2.
When you want to hot-swap code the language pauses the VM/interpreter, recompiles any function with a diff (easy with an AST), puts the new functions in memory somewhere new, changes p1 to point to the new bytecode, then marks the old bytecode for GC.
If you tried something that simple in Python for the code I wrote above, it would explode. It's an infinitely harder problem.
> Using Java I can have n distinct versions of a class each implementing the same interface in the same process as long it is the interface reference that is passed around.
It's been a while since I worked with those app containers, but from my recollection it shares virtually nothing with hot reloading. E.g. is state preserved between those? If I'm caching stuff in RAM, and I change that class out, does it keep the cache? HMR does, as I recall.
My understanding is that app containers basically just run N versions of your app/class and allow you to choose which one you route execution to.
App containers are more similar to blue-green deployments with a load balancer. Each instance is totally separate, and the load balancer lets you choose which one you route to. App containers just do that process inside the JVM.
That's not bad, but it's also not as good as being able to repeatedly tweak a function without ever clearing caches or re-connect to downstreams or etc.
It is almost both. Clojure creates n distinct versions of the function (which are in fact objects and subject to garbage collection). The symbol of the function is rebound (technically this language is wrong) to point to the most recent one. Then, usually, the Java garbage collector deletes the old object.
So it is possible (likely under some code styles) that old versions of a function can hang around in a REPL environment if they ended up embedded in a data structure. However, if you make the call by resolving the function's symbol then that will reliably call the most recently def-ed version.
For example:
(defn poor-style [] 1)
(def object {:fn poor-style :call (fn [] (poor-style))})
(defn poor-style [] 2)
(prn ((:fn object))) ; => 1, calls the old embedded function
(prn ((:call object))) ; => 2, calls a function that resolves the symbol, finds the new version.
(prn (poor-style)) ;=> 2, just call the new function
I don't remember what your describing being a feature of SLIME, but it's been 10+ years so I may just not remember.
That does seem like an interesting, although in practice I rarely have to evaluate something that would take more than a a couple of seconds, so manually wrapping it in a future seems acceptable.
On a semi-related note, sometimes I mistakenly evaluate something that will take a long time, or there's a bug and I'm stuck in an infinite loop. CIDER has a command to interrupt the on-going evaluation but I'm my experience it only works about half the time. In those cases having it wrapped in a future would certainly be helpful.
I'm sure this is wildly outdated by now - I'd be shocked if there wasn't something halfway decent in the NeoVim ecosystem.
I will say, though, that during a brief flirtation with Spacemacs, I absolutely loved the Clojure integration - emacs just feels like it's more "at home" with lisps. Some of the most satisfying programming experiences I've had, honestly.
Calva is a solid choice if you don't mind switching editors.
Both of these rely on some of the most popular and simple libraries for web dev.
Most seem to simply use said libraries directly, mix and match what is needed.
If you’re an experienced web developer but new to Clojure, then you’re going to spend a good weekend or so to set up a proper environment, combine the necessary libs and so on, if you have some guidance. The Clojure community is quite welcoming and helpful in that regard.
There’s an initial learning curve, because it’s a functional Lisp though. That comes with some necessary re-wiring, but also with some unique powers.
The cool thing about writing Clojure is that feeling: „Really that’s it?“ when you realize how simple it is. It’s also simply fun to use, because of how interactive it is.
However, if you just want to get started and have a minimal thing working without much fuss I recommend this one:
https://clojure-doc.org/articles/tutorials/basic_web_develop...
I haven't directly used it but I reviewed it once and it seems to be one of the most straight forward and carefully written web development tutorials for Clojure. It uses a very minimal set of libraries and it really goes from A to Z. Perfect if you want to just get yourself familiar and have something working.
Thank you for sharing it!
This year's funding by Clojurists Together allowed me to spend a lot of time completely rewriting large sections of the site to bring it up-to-date with modern Clojure tooling and libraries -- but I know there's still room for improvement.
I love the idea of a community investing in this type of outreach (beginner oriented) and I'll be happy to contribute when I can.
You compose your stack of smaller libs and build your own framework so to speak. The right questions in this context are; what http server to use, what routing lib is decent, what is a good lib for my database, what is a good lib for generating html from the server. etc.
If you wanna start using clojure as a web server. Start with 'ring', and you can recieve http requests. You quickly realize you're missing stuff to do what you need and will go searching for libs. You'll find great libs out there for anything you ordinarily need for a web-server setup.
As far as web-related components go, my app uses Rum (as an interface to React), ring, http-kit, pushy (for history manipulation), sente (for websockets), buddy (for authentication tools).
If you are looking for a batteries-included "I want to have some sort of webapp right away" thing, I think https://kit-clj.github.io would fit the bill, but the general feeling in the Clojure community is that unlike Python with Django or Ruby with Rails, the choice of app components is not predetermined by the language.
I guess you weren't lying because that is not what a web framework is.
If it works for just me, that's a web framework. The fact that there are so many web frameworks shows that none work for everyone.
1. Routing
2. ORM
3. Auth handling
4. Request middleware
5. Templating (if your application requires it)
6. User input validation
Many other components that are escaping me right now
- background job system
- email sending
- translation/localisation
- a decent configuration system suitable for differentiating dev/test/staging/prod/etc, and handling both secret and non-secret values in a sane way
Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself.
What I like about (say) Rails secret handling is that the secrets file is an encrypted file in the repo itself. This makes it so that you can easily check out and run different versions of the repo from different times and not have to worry about that one time you renamed an envvar or something. Secrets get version controlled together with the app. The autogenerated .gitignore even includes patterns for the key files so you have to go out of your way to check them into the repo. The downside is that merging encrypted files can be a right pain in the arse, for example when two devs added different secrets in different branches.
This sounds horrible. Why does specifically your CI/CD need to know those things?
This also sounds like your CI/CD system is "too smart" and your build process is "dumb pipes", what I believe to be a unsupportable, unmaintainable anti-pattern - if people can't build/test things on their own machine, things are likely not repeatable/reproducible at all and you're one CI/CD issue away from losing your project.
> Something I dislike about spring boot is how spring-y everything has to be.
I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
You set it up so that production secrets are kept in that store and are only accessible by a 1 or 2 high level people. Developers don't have access to production secrets, only dev or staging, which live on their own machines and are lower security risk
> if people can't build/test things on their own machine
I don't see why they wouldn't be able to build/test on their own machine. You just have a different secrets store and keys than the CI/CD does
> I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
Yes I hate this. I want to be able to decide how properties are loaded, not rely on some ethereal state managed behind the scenes and not be able to see if it's loading properly. If I want to use their terrible resources/config file, I'll specify that in middleware/startup
I don't use templating, at least not for web pages.
User input validation — that's something I've spent the better part of several years working on, but in a larger context of a toolkit for dealing with forms, tables, data presentation, filtering and sorting. I daresay the solution I have now (which uses ideas dating back to Smalltalk) is way more extensive and flexible than what every "framework" out there has.
And that's why I use good frameworks.
[:div
[:p "I am a component!"]
[:p.someclass
"I have " [:strong "bold"]
[:span {:style {:color "red"}} " and red "] "text."]]
My main problem with Clojure was the dynamic nature of it. I have not used it in very long time now (probably 7 years at this point) - but despite the amazing aspects of it I would not trade in TypeScript annotations.
A question for clojurists here - what is the level of static type checking adoption in CLJ world ? When I was using it last time there were some things like schema validators, but nothing like TypeScript. It looks like there's static typing annotations support now but are the types widely used by popular projects/provided for big libraries ?
I do use spec, and I've used other checking solutions before. I also use :pre/:post conditions a lot, as well as plenty of assertions. But in a large and complex application the errors I'm likely to run into are not as simple as a mismatched type. My most valuable checks and specs constrain multiple data fields.
Thinking about stuff I run into, I would say that the majority of errors are due to optionality — where a key is optional in some contexts, but mandatory in others.
I feel that due to its functional nature or perhaps this is just the community bias, Clojurists tend to prefer mixing lower level libraries to build their web application instead of relying on a specific big web framework like RoR for example. Luminus would be one RoR-like system.
But today, I think people would probably choose reitit for the writing the API and use a clojurescript framework for the frontend or perhaps still use reitit to generate HTML pages using hiccup.
> Backwards compatibility is hugely important
Why is this always considered a Good Thing (TM), apart when applied to C and C++?
Why is it OK when languages and systems are bent backwards in order to avoid breaking stuff that works, but the two languages that together support a huge part of the running software are expected to up and break ties with their glorious past and present?
But I still loved, it. And it changed every year, and I was even part of the proponent of the changes.
But after a while, you realise that your old project stop working. That if you want to use a new library, you also need to update many dependencies. But each one has breaking changes, so you start updating your code.
Mainly, if you wrote some code, and forget about it, it will no longer work or will be very hard to use with newer libraries. After a while this became very tedious.
In Clojure, the code I wrote 10 years ago is still working perfectly today. The application still launches.
If a bug is discovered and I need to fix it, for example, by upgrading or adding a new lib, I am not afraid to loose hours finding an fixing my existing code that suddenly become deprecated.
So yes, stability is VERY important for me now.
And last but not least, Rich Hickey talked about it in this talk and make a lot of very great points:
Many of the problem that can't be fixed for backward compatibility reasons are because they'd break the ABI, not new code. I think that's very different from other language's policy, which, from the ones I'm more familiar with, is about building old and new code together, rather than linking old and new code together.
It makes for a much more restrictive, but also ambiguous and not guaranteed, set of requirements on any change.
If it is your code, or your company's code, why not? But think about dependencies!
* most of my domain code is in cljc files, so these get compiled both server-side and client-side and I get a huge boost from that
* transducers and transducer pipelines are an under-appreciated feature, I get huge mileage out of them, because of performance, composability and reusability
* stability and longevity: Clojure was created by a very experienced system designer and programmer (Rich Hickey) and it shows. Backwards compatibility is hugely important, and I can focus on my application rather than rely on tools that are a moving target. It's not an accident that an average "Clojure programmer" (I dislike these kinds of tags, but let's run with it here) has 12+ years of experience and earns a salary in the top quartile at least.