6 ms·

> But so are other stacks. Not really. Few if any platforms compete with the JVM on performance and observability (monitoring/management) and ecosystem. It's t

by pron 8y ago

> But so are other stacks. Not really. Few if any platforms compete with the JVM on performance and observability (monitoring/management) and ecosystem. It's technologically head and shoulders above pretty much all other runtimes (e.g. BEAM has excellent observability, but loses big time on performance and ecosystem). Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory.

rhizome31 8y ago
> Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory. I'm curious about this. How do you do it in practice? Doesn't it just crash with OutOfMemory errors when it runs out of memory?
- bad_user 8y ago
  The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system, which is why it is being configured with a maximum heap size. Also compacting garbage collectors need more memory available for de-fragmenting the heap. I've been running a simple JVM web app on my own personal server with an allocated 128 MB of RAM and a lot of that is actually unused. You can do a lot with a heap of just 64 MB. People aren't aware, but when running your average PHP app you need more than that with just a couple of requests done at the same time, whereas my JVM server can easily handle 1000 requests per second. Similarly Ruby or Python apps can be big resource hogs, especially when you end up setting up multiple parallel processes. I was also surprised to find that compilation to "native" isn't necessarily efficient in terms of used memory. I've built a similar app in Haskell and the used memory ended up being higher and more unpredictable. If something like Go fares better, it's not because it is compiled to native. All in all the JVM is actually quite efficient in terms of used memory, for a garbage collected language ;-)
  - brazzy 8y ago
    > The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system This is untrue. The default configuration is just to do it very reluctantly, but this can be changed.
  - liveoneggs 8y ago
    I like how you think 64MB is small
    - thomascgalvin 8y ago
      I mean I have 64 gigs of ram on my personal desktop. RAM is cheap, and there are a lot of problems that can be solved by throwing more RAM at it.
    - cutler 8y ago
      Considering Hetzner (hetzner.com) offer VPSs with 2Gb RAM for 2.99 Euros per month I think it's fair to say we've left the 90s behind as far as RAM is concerned.
  - cutler 8y ago
    I'm intrigued. Was your "simple JVM web app" written in Java? What kind of JVM optimisations were used and do these also apply to Clojure?
- pron 8y ago
  You get an OOM if your working set is larger than the heap. Otherwise, the GC just works harder, reducing your performance. Generally, the JVM uses as much memory as you let it.
gameswithgo 8y ago
.NET has come up on par, or slightly better than, the JVM in recent years in terms of performance. Ecosystem may not be as big but its pretty well fleshed out.
- dhruvmittal 8y ago
  At my last job, I was a C#/F# dev. Recently changed jobs and learned that even in 2018, .NET is a dirty word at many companies.
  - adambard 8y ago
    .NET-the-technology is pretty good, but for many developers, .NET is synonymous with expensive licensing and tooling (and you pretty much have to use Windows, ick). The JVM and .NET are presently about the same capability-wise, but Java is (or at least, is perceived as) much easier and cheaper to freely experiment with. Unless you need to use C# for some deep Windows integration, this makes Java the obvious choice for anyone without sunk costs in the .NET ecosystem.
    - h_r 8y ago
      You are aware of .net core right? We're deploying services using linux docker containers. And I'm having a blast writing my macos utilities in f#
  - crimsonalucard 8y ago
    You wrote 2018. It's 2019. Get with the times.
- pron 8y ago
  .NET is the only runtime that comes close. Unfortunately, some early design decisions (reified generics) make language interop on the CLR much more cumbersome than on the JVM. Clojure in particular makes heavy use of the fact that a Clojure map/list/set is a Java map/list/set. This is awkward on the CLR (where you must specialize the collection).
- 8y ago

by pron 8y ago

rhizome31 8y ago

> Also, if you're OK with the JVM running at BEAM speeds, you can give it far less memory. I'm curious about this. How do you do it in practice? Doesn't it just crash with OutOfMemory errors when it runs out of memory?

bad_user 8y ago
The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system, which is why it is being configured with a maximum heap size. Also compacting garbage collectors need more memory available for de-fragmenting the heap. I've been running a simple JVM web app on my own personal server with an allocated 128 MB of RAM and a lot of that is actually unused. You can do a lot with a heap of just 64 MB. People aren't aware, but when running your average PHP app you need more than that with just a couple of requests done at the same time, whereas my JVM server can easily handle 1000 requests per second. Similarly Ruby or Python apps can be big resource hogs, especially when you end up setting up multiple parallel processes. I was also surprised to find that compilation to "native" isn't necessarily efficient in terms of used memory. I've built a similar app in Haskell and the used memory ended up being higher and more unpredictable. If something like Go fares better, it's not because it is compiled to native. All in all the JVM is actually quite efficient in terms of used memory, for a garbage collected language ;-)
- brazzy 8y ago
  > The JVM doesn't use more memory than other virtual machines, the problem is that it doesn't release memory back to the operating system This is untrue. The default configuration is just to do it very reluctantly, but this can be changed.
- liveoneggs 8y ago
  I like how you think 64MB is small
  - thomascgalvin 8y ago
    I mean I have 64 gigs of ram on my personal desktop. RAM is cheap, and there are a lot of problems that can be solved by throwing more RAM at it.
  - cutler 8y ago
    Considering Hetzner (hetzner.com) offer VPSs with 2Gb RAM for 2.99 Euros per month I think it's fair to say we've left the 90s behind as far as RAM is concerned.
- cutler 8y ago
  I'm intrigued. Was your "simple JVM web app" written in Java? What kind of JVM optimisations were used and do these also apply to Clojure?
pron 8y ago
You get an OOM if your working set is larger than the heap. Otherwise, the GC just works harder, reducing your performance. Generally, the JVM uses as much memory as you let it.

gameswithgo 8y ago

.NET has come up on par, or slightly better than, the JVM in recent years in terms of performance. Ecosystem may not be as big but its pretty well fleshed out.

dhruvmittal 8y ago
At my last job, I was a C#/F# dev. Recently changed jobs and learned that even in 2018, .NET is a dirty word at many companies.
- adambard 8y ago
  .NET-the-technology is pretty good, but for many developers, .NET is synonymous with expensive licensing and tooling (and you pretty much have to use Windows, ick). The JVM and .NET are presently about the same capability-wise, but Java is (or at least, is perceived as) much easier and cheaper to freely experiment with. Unless you need to use C# for some deep Windows integration, this makes Java the obvious choice for anyone without sunk costs in the .NET ecosystem.
  - h_r 8y ago
    You are aware of .net core right? We're deploying services using linux docker containers. And I'm having a blast writing my macos utilities in f#
- crimsonalucard 8y ago
  You wrote 2018. It's 2019. Get with the times.
pron 8y ago
.NET is the only runtime that comes close. Unfortunately, some early design decisions (reified generics) make language interop on the CLR much more cumbersome than on the JVM. Clojure in particular makes heavy use of the fact that a Clojure map/list/set is a Java map/list/set. This is awkward on the CLR (where you must specialize the collection).
8y ago