7 ms·

As a heavy user of Clojure (my SaaS is written in Clojure/ClojureScript) for 10 years or so, I would fully agree with what Kyle wrote. In addition, things that

by jwr 3y ago

As a heavy user of Clojure (my SaaS is written in Clojure/ClojureScript) for 10 years or so, I would fully agree with what Kyle wrote. In addition, things that I found very valuable: * 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.

drikerf 3y ago
Similar story. I'm also running my SaaS on Clojure and maintenance has been a dream compared to other languages. Things rarely break and are easy to upgrade. Developer experience is fantastic too with HMR, REPL and cljc files. It's fun to write Clojure code :)
- weikju 3y ago
  HMR?
  - G4BB3R 3y ago
    "Hot Module Replacement (HMR) is a feature in some programming languages and frameworks that allows developers to update modules or parts of the application in real-time while the application is running, without requiring a full page refresh. This is particularly useful during development as it speeds up the development process and helps maintain the application state."
    - weikju 3y ago
      Hmm I’d rather hear more from the GP (assuming it’s the same concept) and specific tools being used than a generic GPT sounding reply. Thanks though at least I learned an acronym (no snark).
      - eddtries 3y ago
        Fwiw it's a quote from https://webpack.js.org/concepts/hot-module-replacement/ https://webpack.js.org/concepts/hot-module-replacement/, what else would you like to know about HMR?
        PaulHoule 3y ago
        It's actually the answer ChatGPT should give, with the citation to back up the quote.
        weikju 3y ago
        if only.... lol
      - monsieurbanana 3y ago
        I can't blame you for thinking it was a GPT reply these days. Anyway I'm also not GGP but he's right, it is Hot Module Replacement. 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 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?
- packetlost 3y ago
  What do you use for an editor/IDE? I'd love to write more Clojure, but the tooling story is a bit confusing
  - Volundr 3y ago
    In my case, Emacs+clojure-mode+cider. I'm not sure I recommend learning Emacs at the same time as Clojure though. I usually recommend new users look to Cursive(for IntelliJ) or Calva (vscode) depending on what they are most comfortable with.
    - packetlost 3y ago
      I'm a vim user and there's no way in hell I'm switching to emacs, even with EVIL mode. I'll check out Calva
      - Volundr 3y ago
        Hopefully someone will chime in with their recommended setup for vim. I think there is pretty mature tooling available, but I'm not immediately familiar with it, so my advice there would be no better than Google. Calva is a solid choice if you don't mind switching editors.
      - fiddlerwoaroof 3y ago
        I forget what the current recommendation for vim is, but back when I still wrote a lot of Clojure, people used vim-fireplace. I think there is a newer one for NeoVim, though
        fiddlerwoaroof 3y ago
        I too resisted emacs for years while writing Common Lisp in vim, but eventually I ported my vim config line by line to the emacs lisp implementation of the vi standard
        epiccoleman 3y ago
        Almost ten years ago, I gave a lightning talk about Overtone (Clojure mappings for SuperCollider). I used "vim-fireplace" to connect to cider-nrepl and had a pretty good experience being able to quickly eval sexps in Vim. 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.
DeathArrow 3y ago
Does Clojure have a decent web framework?
- deleted 3y ago
  [deleted]
- gleenn 3y ago
  Luminus has been around a long time and Kit is newer. Most Clojurists believe in libraries over frameworks though so that's why you don't hear about web frameworks much. I've messed with Luminus a few times and it is really easy to pull out parts and swap in almost any bit of it. They document a lot well and make it really easy to pick different parts out of the gate like different DBs, JavaScript libs, and a lot more. The maintainer roams HN frequently as well :)
  - gengstrand 3y ago
    Whatever happened to ring or donkey?
    - gleenn 3y ago
      Luminus uses Ring.
  - aphyr 3y ago
    Aphyr.com is built with Luminus. :-)
- jwr 3y ago
  I am not sure what a web framework is, to be honest. The choices for many parts of a web application are really domain-specific and I'm not sure a single "framework" would work for everyone. 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 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.
alberth 3y ago
What % of the overall benefits would you attribute to the JVM vs. Clojure (the language)?
- jwr 3y ago
  I barely even care about the JVM. I'm happy because it is an impressive feat of engineering, representing tens of years of huge investment into development, compiling my code to levels of performance that poorer VMs cannot reach. But JVM is just one of the environments where my code runs (the other is the JavaScript VM in browsers).
- iLemming 3y ago
  Clojure is not only on JVM. There's Clojurescript. There's ClojureDart. There's ClojureCLR. There a bunch of experimental things like ClojureRS (Rust) and Clojerl (for Erlang). You can "talk to" Python and R from Clojure. You can use Fennel if you need to deal with Lua (It's not Clojure, but it's very Clojure-like lang). The benefits are there, for any platform you choose.
pif 3y ago
Out of topic, sorry! > 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?
- aphyr 3y ago
  There's a happy medium, I think, and I also imagine that depends on scope of change and the kind of applications involved. Speaking personally, I'm OK rewriting code, say, every decade. In the Ruby world, things moved so fast that my code would rot every six months. Now that I've been maintaining the same software for 20 years I'm really starting to care about that. ;-)
  - pif 3y ago
    > I'm OK rewriting code, say, every decade If it is your code, or your company's code, why not? But think about dependencies!
    - aphyr 3y ago
      I maintain dependencies for a lot of people--nowhere near operating systems or stdlibs, but my OSS gets fairly broad use--and I try very hard not to change their APIs too much! It's a real concern.
- deleted 3y ago
  [deleted]
- rhaen 3y ago
  I'll also note a lot of objections to the way C++ does backwards compatibility is their adherence to an ABI which they refuse to break, but also refuse to say they'll never break. 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.

by jwr 3y ago

drikerf 3y ago

Similar story. I'm also running my SaaS on Clojure and maintenance has been a dream compared to other languages. Things rarely break and are easy to upgrade. Developer experience is fantastic too with HMR, REPL and cljc files. It's fun to write Clojure code :)

weikju 3y ago
HMR?
- G4BB3R 3y ago
  "Hot Module Replacement (HMR) is a feature in some programming languages and frameworks that allows developers to update modules or parts of the application in real-time while the application is running, without requiring a full page refresh. This is particularly useful during development as it speeds up the development process and helps maintain the application state."
  - weikju 3y ago
    Hmm I’d rather hear more from the GP (assuming it’s the same concept) and specific tools being used than a generic GPT sounding reply. Thanks though at least I learned an acronym (no snark).
    - eddtries 3y ago
      Fwiw it's a quote from https://webpack.js.org/concepts/hot-module-replacement/ https://webpack.js.org/concepts/hot-module-replacement/, what else would you like to know about HMR?
      - PaulHoule 3y ago
        It's actually the answer ChatGPT should give, with the citation to back up the quote.
        weikju 3y ago
        if only.... lol
    - monsieurbanana 3y ago
      I can't blame you for thinking it was a GPT reply these days. Anyway I'm also not GGP but he's right, it is Hot Module Replacement. 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 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?
packetlost 3y ago
What do you use for an editor/IDE? I'd love to write more Clojure, but the tooling story is a bit confusing
- Volundr 3y ago
  In my case, Emacs+clojure-mode+cider. I'm not sure I recommend learning Emacs at the same time as Clojure though. I usually recommend new users look to Cursive(for IntelliJ) or Calva (vscode) depending on what they are most comfortable with.
  - packetlost 3y ago
    I'm a vim user and there's no way in hell I'm switching to emacs, even with EVIL mode. I'll check out Calva
    - Volundr 3y ago
      Hopefully someone will chime in with their recommended setup for vim. I think there is pretty mature tooling available, but I'm not immediately familiar with it, so my advice there would be no better than Google. Calva is a solid choice if you don't mind switching editors.
    - fiddlerwoaroof 3y ago
      I forget what the current recommendation for vim is, but back when I still wrote a lot of Clojure, people used vim-fireplace. I think there is a newer one for NeoVim, though
      - fiddlerwoaroof 3y ago
        I too resisted emacs for years while writing Common Lisp in vim, but eventually I ported my vim config line by line to the emacs lisp implementation of the vi standard
      - epiccoleman 3y ago
        Almost ten years ago, I gave a lightning talk about Overtone (Clojure mappings for SuperCollider). I used "vim-fireplace" to connect to cider-nrepl and had a pretty good experience being able to quickly eval sexps in Vim. 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.

DeathArrow 3y ago

Does Clojure have a decent web framework?

deleted 3y ago
[deleted]
gleenn 3y ago
Luminus has been around a long time and Kit is newer. Most Clojurists believe in libraries over frameworks though so that's why you don't hear about web frameworks much. I've messed with Luminus a few times and it is really easy to pull out parts and swap in almost any bit of it. They document a lot well and make it really easy to pick different parts out of the gate like different DBs, JavaScript libs, and a lot more. The maintainer roams HN frequently as well :)
- gengstrand 3y ago
  Whatever happened to ring or donkey?
  - gleenn 3y ago
    Luminus uses Ring.
- aphyr 3y ago
  Aphyr.com is built with Luminus. :-)
jwr 3y ago
I am not sure what a web framework is, to be honest. The choices for many parts of a web application are really domain-specific and I'm not sure a single "framework" would work for everyone. 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 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.

alberth 3y ago

What % of the overall benefits would you attribute to the JVM vs. Clojure (the language)?

jwr 3y ago
I barely even care about the JVM. I'm happy because it is an impressive feat of engineering, representing tens of years of huge investment into development, compiling my code to levels of performance that poorer VMs cannot reach. But JVM is just one of the environments where my code runs (the other is the JavaScript VM in browsers).
iLemming 3y ago
Clojure is not only on JVM. There's Clojurescript. There's ClojureDart. There's ClojureCLR. There a bunch of experimental things like ClojureRS (Rust) and Clojerl (for Erlang). You can "talk to" Python and R from Clojure. You can use Fennel if you need to deal with Lua (It's not Clojure, but it's very Clojure-like lang). The benefits are there, for any platform you choose.

pif 3y ago

Out of topic, sorry! > 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?

aphyr 3y ago
There's a happy medium, I think, and I also imagine that depends on scope of change and the kind of applications involved. Speaking personally, I'm OK rewriting code, say, every decade. In the Ruby world, things moved so fast that my code would rot every six months. Now that I've been maintaining the same software for 20 years I'm really starting to care about that. ;-)
- pif 3y ago
  > I'm OK rewriting code, say, every decade If it is your code, or your company's code, why not? But think about dependencies!
  - aphyr 3y ago
    I maintain dependencies for a lot of people--nowhere near operating systems or stdlibs, but my OSS gets fairly broad use--and I try very hard not to change their APIs too much! It's a real concern.
deleted 3y ago
[deleted]
rhaen 3y ago
I'll also note a lot of objections to the way C++ does backwards compatibility is their adherence to an ABI which they refuse to break, but also refuse to say they'll never break. 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.