Clojurians Log v2

Reading a https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7242027/ for completely non-Clojure reasons, when suddenly: > For this, we suggest usage of edn, a serialisation format with parsers available in most mainstream programming languages and then: > A short example written in Clojure is given in Listing 1.1 at which point I was so surprised I nearly missed this footnote at the end: > It would be sensible to define different standard formats for different formalisms. These can be automatically enforced in a CI pipeline, e.g., by Clojure Spec, before pull requests are accepted.

hi, i'm a total newbie here, wanna ask about does node.js and clojure could serve the same purpose?

@adrianimanuel It depends on your use case. NodeJS is a JS environment and JS hasn't got threads, which the JVM has. Also the ecosystems are different: available libraries, etc.

If you are familiar with NodeJS and you want to use "Clojure" then choosing ClojureScript is a natural choice (possibly with #shadow-cljs for better NPM interop?)

no i never use node.js

But if you're more familiar with the JVM, then Clojure on the JVM is a better fit and possibly NodeJS isn't so interesting for you then

does nodejs more to front end?

NodeJs is a server technology to run Js on backends.

Somehow people loved Js so much that they also wanted to use it on the server / desktop. It's a miracle.

guess i need to learn the fundamental first, difference between javascript and jvm

A general recommendation: if you don't do front-end, just go with Clojure JVM and start learning from there

ahh okay, thanks so much for the advice

I'm getting the following error when making a POST request to a local server with http://java.net.http, but no such error with clj-http:

connection close, x-websocket-reject-reason Client must provide a value for Sec-WebSocket-Key.

Immediately after asking this I guess it's obvious that the error message itself is telling me what header I need.

Now I'm just curious why a sever would require that key when I don't believe it's using websockets, and why the apache http client clj-http uses does include the websocket headers by default

Sounds like a badly configured server

I doubt clj-http is including that header, but clj-http be speaking http 1.x and the java http client may be trying http2(a wild guess) which might explain getting different behavior

The java http client can be configured to prefer http1 or 2, you could try changing that to see what happens

That did it, it was the version, thanks!