Clojurians Log v2

Seems to be up-to-date to me. From what I've seen Cursive with the non-commercial/student license would be the most appropriate for your students. Those that already use vim, VS Code, emacs would in any case be able to figure stuff out themselves mostly, but Cursive would be a better default for everyone else especially if they had other courses using conventional IDEs.

The http://Clojure.org Editor page is although I have some updates I'd like to add to that page, especially for neovim. If students are using a particular editor already, then that is usually the best editor to use for Clojure. Learning Clojure with an unfamiliar editor adds much more cognitive load (more than people usually appreciate) I also created a editor support page with all editors: https://practical.li/clojure/clojure-editors/

I've said "start with Calva" to people I've introduced to Clojure, and have not regretted it.

at this point in the students curriculum they are being introduced to lots of different programming language. I am not claiming that is good or bad, I just have to deal with students as they arrive in my class.

BTW I'm pretty happy (not 100%) with my clojure intro course. I'm teaching in parallel a Scala intro course, and the homework problems are almost the same. So students taking both courses will solve the same problems in Clojure and also Scala. Some problems are easier in one, some in the other, also this depends on the student's individual tastes.

What is the appropriate channel to recommend improvements/updates to http://clojure.org btw? Talking about Java interop in another thread reminded me that the learn clojure guide was outdated in the sections on Java Interop (about methods not being able to be passed as arguments etc.) back when I was reading it, and it still is outdated. (nvm, found https://github.com/clojure/clojure-site)

I'd say there's a very high probability that they have used VS Code so for anyone teaching, learning the basics of calva might be a good idea. That's Calva, to be clear

If you want to give students an idea of what is used by professional Clojure developers, there's the state of clojure survey (https://clojure.org/news/2024/12/02/state-of-clojure-2024) which asks this question

Those are very interesting statistics. Thanks ed.

@matti.uusitalo117 I should mention one of my hesitations is that I use emacs (have used emacs since the mid 1980s, so 40+ years). I always intend to learn Calva or Cursive, but I just never get around to it. I'm not a typical user.

I've taught this course once before (last year), and no student ever brought up questions about the development environment. I provide them with a makefile which runs their tests via the lein command line.

I can relate. Calva is a fine environment but it is hard to leave the comforts of emacs

Mine is not an ideal point of view, because even though I'm comfortable with it, students rarely are. On the other hand I use IntelliJ for Scala, and Pycharm for Python. When I first started with Scala, I tried to use emacs, but the environment was so hostile to beginners, that I bit the bullet and learned IntelliJ. But for complicated edits, I occasionally open up emacs to edit the scala code. E.g., search and replace copyright comments over scala files in several unrelated projects. Not sure how I would do that in IntelliJ

Some documentation for how to build a runnable uberjar like that https://clojure.org/guides/tools_build#_compiled_uberjar_application_build

nginx could be set up to terminate https and then the apps would see plain http traffic. depending on your threat model that might be fine, or you might actually need to encrypt traffic between the load balancer and applications as well

Just in case - note that neither building an uberjar nor using something like nginx is required.

I liked the explanation (there is a video and a blog post) that helped me understand how to build a JAR with my deps.edn projects: https://kozieiev.com/blog/packaging-clojure-into-jar-uberjar-with-tools-build/ Regarding SSL, I used https://caddyserver.com with a pretty simple configuration, and it handled all the TLS/SSL stuff for me.

Based on your parameters I suggest configuring nginx to reverse proxy to your app. It doesn’t need to be a jar unless for some reason you can’t install clojure on the deployment machine. You could bring it up and down with a simple systemd unit. Assuming a small-scale deployment with everything on one machine, bind jetty to 127.0.0.1 with the :host option and you’re done—nothing about your clojure app proper need be site-specific.

My Parameters based on my naive assumption this is how this should work with a VPS. Thx for the links i will take a look into the building jar video and documentation. @p-himik What options would i have if not using nginx or something like that?

Any reasonable web server can be configured to do whatever nginx does, at least for the typical cases. Of course, it's a trade-off. But if deploying specifically to VPS is not a hard requirement, you can also use some platform that configures SSL and whatnot for you.

@thomasfuston337 If you use deps-new to create a new app project, it creates the appropriate deps.edn and build.clj flies to create an "uber jar" -- so that also be useful for you, as guidance. https://github.com/seancorfield/deps-new if you don't already have it installed.

there is no strict need to build a jar, but there are multiple advantages to the entire app deploy being contained in a single artifact. for example you can browse the jar as if it were a file system in any good programming editor, and verify precisely what code is in each namespace, including libraries.

> the entire app deploy being contained in a single artifact Personally, I prefer containers for that. Then a deploy becomes not just the app, but also Clojure, JDK, any system components.

even if you use a container, an uberjar has advantages over running the app out of a repo

So far, I haven't encountered those. :) But I have encountered, first- and second-hand, issues with uberjars - way more than I've personally seen with containers.

For now i just want to learn how to deploy - with limited know how. What do you mean by containers? Docker?

if you're on some simple vps then the simplest way to test if your stuff works is to copy the uberjar on your vps then run it with java -jar my_app.jar and see if it connects

> So far, I haven't encountered those. :) specific example: due to AOT, a pre-compiled version of foo used by library-a was overriding the version of foo used by library-b, in a code path that was not straightforward to cover in integration testing in an IDE or code editor, using navigate to source would always show the expected and working version of foo. by opening the uberjar, it was easy to see that the compiled mismatched version was erroneously present in the artifact

in my experience most uberjar related frustrations are actually AOT frustrations, and not making an uberjar does not mean they won't hit you. in fact my preference is to make an uberjar with AOT turned off.

IIRC in the above case, foo was a part of clojure.core that had changed incompatibly (library author was using an alpha clojure.core when compiling)

> due to AOT Ah, this is the crux. I also eschew AOT completely because it's way too many potential issues for a second or two of startup time. I prefer to have the code running in production in a way that's very similar to how it runs during development, of course with pure dev-only stuff removed. I think there's only one exception due to practicality - CLJS code gets compiled in advance. I just remembered a very specific case of where creating an uberjar actually doesn't work - when some specific library demands to be a module. Like JavaFX: > The JavaFX classes must be loaded from a set of named javafx.* modules on the module path. Loading the JavaFX classes from the classpath is not supported. > library author was using an alpha clojure.core when compiling I'm also fully against distributing compiled Clojure libraries.

IIRC (but the recollection is getting better as we discuss these issues) it was a pragmatic problem, where an avro serdes API used then-new clojure.spec and required AOT. yeah, the few cases I haven't been able to excise AOT from the app entirely have been repeated pain points. like avro itself, something that I put in the bucket labeled "only use if forced to, and use as few of the features as possible"

though, to be fair, the more experience I have in tech generally, the more it seems like everything belongs in that bucket haha

"a second or two of startup time" -- without AOT, some of apps take a full minute to start up; with AOT it's dramatically less. So it's worth it for us. But we only ever use AOT (+ direct-linking) for building deployable uberjars.

in retrospect we would have saved a lot of time by porting all our code that interacted with avro to Java or Scala - the assumptions about compilation and type checking were an impedance mismatch with Clojure

but that's a big digression from the topic

I'd heard others say the same about avro... 🙂