4 ms·

Well, there is an OpenJDK version that azul systems make called zulu, which is open source and free from oracle. The jvm is still a really good runtime. Java i

Well, there is an OpenJDK version that azul systems make called zulu, which is open source and free from oracle. The jvm is still a really good runtime. Java is a way more consistent language than javascript. Other languages running on top of the jvm are way more beautiful and sensible than javascript. The jvm can be leveraged many ways when it comes to performance and use cases, and I consider it way more stable than different javascript runtime implementations running in different browsers coded by different organizations. Out of curiosity, why do you think the JVM is such a thing of the past and so bloated and clunky? I'm curious about what reasons people have. From my own experience, I get that javascript is easy to start things in, but damn, it can get sucky once you have to maintain and refactor a bigger codebase. It just feels like javascript and node gets a lot of mindshare since it is what the web industry pushes down everyones throat sometimes :/

always_good 9y ago
Well, you're writing ClojureScript in TFA so I'm not sure what Java vs Javascript has to do with it. But if you're interested in one way Node is nice: single-threaded + unified way to write async code.
- FieryTransition 9y ago
  From my understanding, the article is about leveraging clojurescript serverside on nodejs. Then someone asks why just not write in clojure serverside on the jvm. I just took some example languages, maybe I shouldn't have as it polluted my point with my own biases. It also felt relevant to bring them up, since it is what people mostly end up writing in, on those respective platforms. But I'm mostly interested in the JVM vs. node discussion though and opinions. Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away. But it can also be a limiting factor that you cannot change if you need to, but then you maybe choose the wrong tech to begin with if your use case can include high cpu usage etc.
  - dahauns 9y ago
    >Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away. What often astounds me in these kinds of discussion: People just seem to assume that's not possible with the JVM. So, just for the record (not neccesarily directed to you :) ): You can totally do node.js style (event-driven, async, nonblocking, no-shared-state - "single-threaded", if you will) with the jvm, and it works great (e.g. vertx, netty, play and many others). And as you said: Contrary to node, with the JVM there's no danger of it being a limiting factor you're stuck with.
    - always_good 9y ago
      Nobody said it's not possible to do it on the JVM. It's also possible to do it in C. It's totally different. There is no unified solution. Just about every library is blocking the thread and you have to code around that. And the solutions don't interop. And they can be atrocious abstractions: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... I work with Netty professionally and I would not call that a pleasant experience. Async programming in Node has really good ergonomics that are hard to find elsewhere. For example, compare Promise.map(..., { concurrency: N }) to the Go solution.
      - dahauns 9y ago
        Huh? Just about every library is blocking? Maybe x years ago. Get with the times. And yeah, of course there's no single unified solution - the JVM landscape isn't restricted to a single programming model. That's actually its strength. Just because not every solution, every model works well together, doesn't mean that "the solutions don't interop" in general. (what are "the solutions"?) And your general statement about "ergonomics that are hard to find elsewhere", yeah, that would really need a bit more than a small promise example to back it up...
        dmohs 9y ago
        Yes, you can often find async Java libraries to fit your architecture, but those are usually less mature than the thread-based ones. With Node libraries, your architecture is set, so you are free to pick the library that best meets your needs. This is a substantial benefit, which I say as someone who loves and regularly uses the ClojureScript on Node model and selected it only after running into this exact problem with Clojure on the JVM.
grzm 9y ago
The parent may be assuming "Clojure on the JVM" as opposed to the JVM alone. Loading the Clojure runtime on the JVM can be slow.
krisdol 9y ago
JVM is slow as heck to start, but an awesome runtim. In an ideal world I'll never have to restart my application or my repl, but in the real world I do it all the time. It's much faster than node.js/V8 when executing heavy tasks. One reason I might be interested in running clojurescript on node.js is because most web technologies nowadays are written for node.js/javascript first and ported as an afterthought. GraphQL servers on Clojure/Java, for example, are like 3rd class citizens compared to node.js. Google provides nice wrappers to their APIs as long as you're not using clojure. I end up writing things in-house a lot more often than I would with node where I just npm install the package I want and I get something that is maintained by the official author.
- coltnz 9y ago
  ~ time java test Hello world java test 0.11s user 0.03s system 88% cpu 0.161 total MacBook Pro (Retina, 15-inch, Late 2013)
  - grzm 9y ago
    I think what's missing in your parent but assumed is, within the context of Clojure, startup is slower than ClojureScript. The Clojure runtime is relatively slow on startup.
    - jeremiep 9y ago
      Unless you restart your server 400 times a day, how does startup times matter, even remotely?
      - grzm 9y ago
        I think your question is better directed upthread: I'm attempting to clarify possible misunderstandings, not arguing for any particular position. But it's important to keep in mind that people have different needs and desires in different contexts. One off the top of my head is something like AWS Lambda. It's not necessarily the context where Macchiato would play a role, but a server context where one might indeed be starting up processes thousands of times a day.

always_good 9y ago

Well, you're writing ClojureScript in TFA so I'm not sure what Java vs Javascript has to do with it. But if you're interested in one way Node is nice: single-threaded + unified way to write async code.

FieryTransition 9y ago
From my understanding, the article is about leveraging clojurescript serverside on nodejs. Then someone asks why just not write in clojure serverside on the jvm. I just took some example languages, maybe I shouldn't have as it polluted my point with my own biases. It also felt relevant to bring them up, since it is what people mostly end up writing in, on those respective platforms. But I'm mostly interested in the JVM vs. node discussion though and opinions. Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away. But it can also be a limiting factor that you cannot change if you need to, but then you maybe choose the wrong tech to begin with if your use case can include high cpu usage etc.
- dahauns 9y ago
  >Yeah, the single threaded model + async can be nice and resolve problems with race conditions etc. making one headache go away. What often astounds me in these kinds of discussion: People just seem to assume that's not possible with the JVM. So, just for the record (not neccesarily directed to you :) ): You can totally do node.js style (event-driven, async, nonblocking, no-shared-state - "single-threaded", if you will) with the jvm, and it works great (e.g. vertx, netty, play and many others). And as you said: Contrary to node, with the JVM there's no danger of it being a limiting factor you're stuck with.
  - always_good 9y ago
    Nobody said it's not possible to do it on the JVM. It's also possible to do it in C. It's totally different. There is no unified solution. Just about every library is blocking the thread and you have to code around that. And the solutions don't interop. And they can be atrocious abstractions: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html https://docs.oracle.com/javase/8/docs/api/java/util/concurre... I work with Netty professionally and I would not call that a pleasant experience. Async programming in Node has really good ergonomics that are hard to find elsewhere. For example, compare Promise.map(..., { concurrency: N }) to the Go solution.
    - dahauns 9y ago
      Huh? Just about every library is blocking? Maybe x years ago. Get with the times. And yeah, of course there's no single unified solution - the JVM landscape isn't restricted to a single programming model. That's actually its strength. Just because not every solution, every model works well together, doesn't mean that "the solutions don't interop" in general. (what are "the solutions"?) And your general statement about "ergonomics that are hard to find elsewhere", yeah, that would really need a bit more than a small promise example to back it up...
      - dmohs 9y ago
        Yes, you can often find async Java libraries to fit your architecture, but those are usually less mature than the thread-based ones. With Node libraries, your architecture is set, so you are free to pick the library that best meets your needs. This is a substantial benefit, which I say as someone who loves and regularly uses the ClojureScript on Node model and selected it only after running into this exact problem with Clojure on the JVM.

grzm 9y ago

The parent may be assuming "Clojure on the JVM" as opposed to the JVM alone. Loading the Clojure runtime on the JVM can be slow.

krisdol 9y ago

JVM is slow as heck to start, but an awesome runtim. In an ideal world I'll never have to restart my application or my repl, but in the real world I do it all the time. It's much faster than node.js/V8 when executing heavy tasks. One reason I might be interested in running clojurescript on node.js is because most web technologies nowadays are written for node.js/javascript first and ported as an afterthought. GraphQL servers on Clojure/Java, for example, are like 3rd class citizens compared to node.js. Google provides nice wrappers to their APIs as long as you're not using clojure. I end up writing things in-house a lot more often than I would with node where I just npm install the package I want and I get something that is maintained by the official author.

coltnz 9y ago
~ time java test Hello world java test 0.11s user 0.03s system 88% cpu 0.161 total MacBook Pro (Retina, 15-inch, Late 2013)
- grzm 9y ago
  I think what's missing in your parent but assumed is, within the context of Clojure, startup is slower than ClojureScript. The Clojure runtime is relatively slow on startup.
  - jeremiep 9y ago
    Unless you restart your server 400 times a day, how does startup times matter, even remotely?
    - grzm 9y ago
      I think your question is better directed upthread: I'm attempting to clarify possible misunderstandings, not arguing for any particular position. But it's important to keep in mind that people have different needs and desires in different contexts. One off the top of my head is something like AWS Lambda. It's not necessarily the context where Macchiato would play a role, but a server context where one might indeed be starting up processes thousands of times a day.