This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (1)
- # babashka (5)
- # beginners (46)
- # calva (8)
- # cider (12)
- # clj-kondo (2)
- # cljfx (3)
- # clojure (23)
- # clojure-europe (7)
- # clojure-israel (2)
- # clojure-nl (11)
- # clojure-norway (8)
- # clojure-uk (1)
- # clojurescript (27)
- # conjure (2)
- # cursive (50)
- # data-oriented-programming (1)
- # data-science (1)
- # datahike (1)
- # datascript (12)
- # emacs (3)
- # events (1)
- # fulcro (13)
- # lambdaisland (7)
- # leiningen (4)
- # lsp (102)
- # meander (2)
- # off-topic (19)
- # parinfer (3)
- # reveal (8)
- # rewrite-clj (13)
- # shadow-cljs (3)
- # specter (13)
- # tools-deps (6)
- # vim (12)
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?)
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
Somehow people loved Js so much that they also wanted to use it on the server / desktop. It's a miracle.
A general recommendation: if you don't do front-end, just go with Clojure JVM and start learning from there
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:
Anyone know what setting might be causing this?
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
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