5 ms·

This submission isn't titled correctly despite it being the title of the article. The author has an issue with the JVM, not Clojure, and then chooses a dialect

by casion 5y ago

This submission isn't titled correctly despite it being the title of the article. The author has an issue with the JVM, not Clojure, and then chooses a dialect of Clojure (I assume because they like Clojure and it is for them). It would be nice though to understand what the author believes the issues with the JVM are since they they aren't expounded upon in the article.

swlkr 5y ago
I should have gone into more detail for sure. The problems with the JVM are more cultural or political and not necessarily technical, although at the time clojure on the jvm did require quite a bit of memory and the cold startup times weren’t great for a simple, “watch this file in development and restart the server” workflow.
- capableweb 5y ago
  > “watch this file in development and restart the server” workflow Fortunately, no one in the Clojure ecosystem works like that, thanks to the REPL :) You fire up the server, send code straight from the editor to the server and evaluate everything on the fly, no restarts needed.
  - swlkr 5y ago
    Yes the repl was one of clojure’s strong points, definitely, but I would argue that a fast restart + logging + irb gets you most of the way there
    - casion 5y ago
      Why shoot for "most of the way there" when one of the core features of the language is "all the way there"?
      - swlkr 5y ago
        The downsides of clojure on the jvm which I had kind of forgotten about until today like long stack traces and using a lot of memory kind of outweigh the upside of the repl
    - capableweb 5y ago
      Hmm, not sure about that. Consider the following (very simplified) example: (defonce current-count (atom 0)) (defn handle-request [req] (swap! current-count inc) (str "Hello " (-> req :params :name) @current-count)) (run-server handle-request :port 8080) If you do the whole "restart server" process every time you change `handle-request`, you lose the state of `current-count`, but if you instead just change the function and "send" the new one to a already running server, the state of `current-count` is still the same, even when the new function definition is being used. Now imagine it with more complex state, or with things that require multiple states to do something. Reloading the server each time would mean you have to manipulate the state into the right "shape" each time before you can test your change, while if you can retain your state even after changing the code, you'd avoid that. This is why I'm still stuck in Clojure and unable to go back to writing code in other languages. The productivity gain is simply too high to throw away by not using Clojure (or other languages that are driven by the same ideas).
      - Jtsummers 5y ago
        If your long term state depends upon ephemeral, non-persisted, data then you're hosed if you ever have to restart anyways. If anything brings that server down, you lose current-count as well, whether it's to change out the definition of handle-request or a power outage. So current-count must not be a useful (long term) value worth persisting or the above program is broken from the start. In the former case (it's useless) the stop-the-world-and-restart approach doesn't hurt anything, in the latter you would need to fix the program anyways.
        capableweb 5y ago
        Yeah, I mean, obviously atoms are not used for long term state storage, I'm not suggesting your replace your database with a atom. But it's useful for a lot of things that are not needed for long-term storage. And even more importantly, it demonstrates the example of how you can use the stateful repl to avoid restarting the full server on every change and still keep state around.
      - swlkr 5y ago

by casion 5y ago

swlkr 5y ago

I should have gone into more detail for sure. The problems with the JVM are more cultural or political and not necessarily technical, although at the time clojure on the jvm did require quite a bit of memory and the cold startup times weren’t great for a simple, “watch this file in development and restart the server” workflow.

capableweb 5y ago
> “watch this file in development and restart the server” workflow Fortunately, no one in the Clojure ecosystem works like that, thanks to the REPL :) You fire up the server, send code straight from the editor to the server and evaluate everything on the fly, no restarts needed.
- swlkr 5y ago
  Yes the repl was one of clojure’s strong points, definitely, but I would argue that a fast restart + logging + irb gets you most of the way there
  - casion 5y ago
    Why shoot for "most of the way there" when one of the core features of the language is "all the way there"?
    - swlkr 5y ago
      The downsides of clojure on the jvm which I had kind of forgotten about until today like long stack traces and using a lot of memory kind of outweigh the upside of the repl
  - capableweb 5y ago
    Hmm, not sure about that. Consider the following (very simplified) example: (defonce current-count (atom 0)) (defn handle-request [req] (swap! current-count inc) (str "Hello " (-> req :params :name) @current-count)) (run-server handle-request :port 8080) If you do the whole "restart server" process every time you change `handle-request`, you lose the state of `current-count`, but if you instead just change the function and "send" the new one to a already running server, the state of `current-count` is still the same, even when the new function definition is being used. Now imagine it with more complex state, or with things that require multiple states to do something. Reloading the server each time would mean you have to manipulate the state into the right "shape" each time before you can test your change, while if you can retain your state even after changing the code, you'd avoid that. This is why I'm still stuck in Clojure and unable to go back to writing code in other languages. The productivity gain is simply too high to throw away by not using Clojure (or other languages that are driven by the same ideas).
    - Jtsummers 5y ago
      If your long term state depends upon ephemeral, non-persisted, data then you're hosed if you ever have to restart anyways. If anything brings that server down, you lose current-count as well, whether it's to change out the definition of handle-request or a power outage. So current-count must not be a useful (long term) value worth persisting or the above program is broken from the start. In the former case (it's useless) the stop-the-world-and-restart approach doesn't hurt anything, in the latter you would need to fix the program anyways.
      - capableweb 5y ago
        Yeah, I mean, obviously atoms are not used for long term state storage, I'm not suggesting your replace your database with a atom. But it's useful for a lot of things that are not needed for long-term storage. And even more importantly, it demonstrates the example of how you can use the stateful repl to avoid restarting the full server on every change and still keep state around.
    - swlkr 5y ago