JVM is not so hard
Basically the answer to the fact that Clojure is a JVM. Like, this crap so hard.
It appeared on the ZA Tech channel in the Slack group a few weeks ago. During some Clojure speeches, the speakers made such a remark again and again.
On this occasion, I spoke at Slack . Now I will write for wider reading and discussion.
')
I also thought that the JVM was heavy. This was in the early 2000s, in comparison with PHP. There were other heavyweights, like .NET and ColdFusion. There were lighter alternatives like Perl and Python, but then I was on Windows, so ActivePerl and ActivePython were also a bit heavy.
I first overcome my “fear” of the JVM when I deployed a small JRuby production application on Heroku. This little monster had to perform only one task per day. He generated a number of PDFs, then uploaded them to iSign (currently not functioning) for storage and distribution. ISign itself was a classic Rails application hosted on three AMIs. This little dinosaur in the stock JVM (with the exception of
I still thought he was a bit heavy at work, but I fell in love with this ugly duckling.
I more or less followed the developments in the development of JRuby and success stories and had a wonderful time at Rubyfuza 2015 with Charles Nutter . This inspired me so much that I began to open pull requests in Ruby projects that simply run their tests on JRuby. On that one and finished, to my shame.
In November 2016, I tried to write a Rails application from scratch. For the first time in several months, I programmed in Ruby on my own machine. The
I had a presentation on WebSockets on Jozi.rb.
At the beginning of the speech, I wanted to play around with the React on Rails repository, just for the general feeling of sharing React and Rails. I have been using re-frame for a couple of months now and I was sure that I could pull it out with bare React.
The train got off the rails, and very spectacular.
To clone and run a single template application, you needed to update XCode, update the command line tools for Xcode (more than 6 GB in total), install a new version of Ruby and Bundler, and then link the installation in a template application ... Everything is simple, right? Like most Rails applications, this template application somewhere in the dependency graph had a dependency on libv8, and this alone adds more than 1 GB in size.
The whole exercise took several hours.
After playing with such an impressive demonstration, I realized that the work turns into a coin toss. Therefore, I decided to make a better frontend on Ember, because I know it, but I did not have enough time.
Again the same thing, you need to update nvm, install an acceptable version of node, install ember-cli, generate an application and install dependencies via npm and bower.
I played a little and admitted my defeat, and instead shared my experience with colleagues. It was humiliating, truly humiliating. I felt like a stranger in a world of which I had been so long.
Let's return to the statement that the JVM is heavy .
Here are some questions that help us overcome our emotional barriers about the JVM.
So let's take care of them and see what happens in reality.
This “gravity” of the JVM is pure FUD, starting with an allegedly large amount of initial installation. You compare about 200 MB of JDK downloads with about 15 MB of Node or Ruby downloads. But this is only the beginning. For both Node and Ruby, the system needs a C compiler, only one - hundreds of megabytes. Worse, you'll probably need a compiler in production!
A bunch of puffing load for both Node and Ruby is hiding from you in such small, sequential steps. If you stop and calculate the volume, not to mention the time spent, then 200 MB will be a much more optimal option.
I don’t even want to start compiling instructions for assembling your own web kit, just to not rewrite it as soon as a new tool is released.
JVM is fast, it’s probably one of the fastest media ever. Over time, it just gets faster and easier. Thousands of the smartest engineers are working to improve it, and have contributed even more over the past 21 years.
There are real execution threads, multi-core support, it can be hellishly configured or just left as is. The only useful thing you probably should know is setting the memory limits for the JVM, and then it will show wonders when dealing with the limitations of this environment.
Unfolding on Heroku?
Here is the key idea that Charles and other guys from the JRuby community continue to promote. Without any gestures, your applications will surely run faster and faster with each release of the JVM (regardless of the progress of JRuby).
I was interested, and I looked in the folder
The Ruby installation is fresh again and meets the basic requirements for running this blog and Middleman (I'm working on a fix there). Yes, it takes almost 700 MB of space to run this static blog and participate in the development of the tools on which it works.
Node has only ember, docpad and bower installed, and it is more than 200 MB.
You can probably predict what I'm going to talk about ...
When building, you make a single JAR file. It has everything to run your application on any platform. Just place the JAR where needed and provide the JVM to deal with it.
There is no such requirement that the application should work on a massive application server; you can very easily associate it with a productive HTTP server directly in the JAR file. Do guys from Node do that, and from Ruby too, but somehow JAR files can't stay on their own? I thought so too ...
I, for example, have been relieved of the need to run
I have at least five JVM processes running on my 2012 MacBook Pro with 8 GB of memory. Work constantly and every day. I never tried to run five Rails applications at the same time.
Why five? Two for Datomic (data collection and console), one for our backend APIs and one for the front end I work with. Sometimes there are also automatic tests in the background. Sure, macOS memory compression probably helps here because a significant part of these JVM processes should have the same bytes loaded into memory.
If you had told me about it 10 months ago, I would have just laughed. Who in their right mind will launch 5 or more JVM processes? I could give my hand to cut off, which I will never do.
Oh, and what about the class paths and all the other crazy things? They won't touch you at all thanks to the excellent Clojure toolkit. This is the same reason you use npm or bundler and do not suffer from the inclusion of paths. You could do this, but then you probably have another problem that you do not notice.
If I had to continuously stop and start JVM instances, I’d just go crazy. That bothered me about JRuby in the old days. Fortunately, with Clojure and a great REPL, you have to restart a JVM instance only in the rare case where I really screwed up somewhere. This is pretty good fool protection. Figwheel works without problems for days.
Be careful when evaluating the JVM as an object. Evaluate Java as a language in every sense, but do not mix it with a virtual machine.
I also used to think like you. I thought of the JVM as a hippo. Fortunately, now I was able to get rid of these restrictions and got the result of the work of thousands of giants supporting it.
In no case do not consider this post as a sign of "the end of Node" or "end of Ruby". Think of a fresh perspective. If you cannot switch to JVM, at least think about how to reduce bloatiness in your own world.
Thank you for your time. Learn Clojure and try Simple Made Easy .
It appeared on the ZA Tech channel in the Slack group a few weeks ago. During some Clojure speeches, the speakers made such a remark again and again.
On this occasion, I spoke at Slack . Now I will write for wider reading and discussion.
')
Foreword
I also thought that the JVM was heavy. This was in the early 2000s, in comparison with PHP. There were other heavyweights, like .NET and ColdFusion. There were lighter alternatives like Perl and Python, but then I was on Windows, so ActivePerl and ActivePython were also a bit heavy.
I first overcome my “fear” of the JVM when I deployed a small JRuby production application on Heroku. This little monster had to perform only one task per day. He generated a number of PDFs, then uploaded them to iSign (currently not functioning) for storage and distribution. ISign itself was a classic Rails application hosted on three AMIs. This little dinosaur in the stock JVM (with the exception of
-server -Xmx=512M ) produced PDFs so quickly that it literally killed the three-quanter cluster with each launch.I still thought he was a bit heavy at work, but I fell in love with this ugly duckling.
I more or less followed the developments in the development of JRuby and success stories and had a wonderful time at Rubyfuza 2015 with Charles Nutter . This inspired me so much that I began to open pull requests in Ruby projects that simply run their tests on JRuby. On that one and finished, to my shame.
And by 2016
In November 2016, I tried to write a Rails application from scratch. For the first time in several months, I programmed in Ruby on my own machine. The
brew upgrade crashed into rbenv and therefore threw out all installed Ruby versions, but I didn’t even notice.I had a presentation on WebSockets on Jozi.rb.
At the beginning of the speech, I wanted to play around with the React on Rails repository, just for the general feeling of sharing React and Rails. I have been using re-frame for a couple of months now and I was sure that I could pull it out with bare React.
The train got off the rails, and very spectacular.
To clone and run a single template application, you needed to update XCode, update the command line tools for Xcode (more than 6 GB in total), install a new version of Ruby and Bundler, and then link the installation in a template application ... Everything is simple, right? Like most Rails applications, this template application somewhere in the dependency graph had a dependency on libv8, and this alone adds more than 1 GB in size.
The whole exercise took several hours.
After playing with such an impressive demonstration, I realized that the work turns into a coin toss. Therefore, I decided to make a better frontend on Ember, because I know it, but I did not have enough time.
Again the same thing, you need to update nvm, install an acceptable version of node, install ember-cli, generate an application and install dependencies via npm and bower.
I played a little and admitted my defeat, and instead shared my experience with colleagues. It was humiliating, truly humiliating. I felt like a stranger in a world of which I had been so long.
Let's return to the statement that the JVM is heavy .
How are we weighing?
- JDK size when downloading too big?
- Does he use a lot of resources in his work?
- Do libraries take up a lot of disk space?
- Is deployment too heavy?
- Does she slow you down to the day?
Here are some questions that help us overcome our emotional barriers about the JVM.
So let's take care of them and see what happens in reality.
Is the original volume really that big?
This “gravity” of the JVM is pure FUD, starting with an allegedly large amount of initial installation. You compare about 200 MB of JDK downloads with about 15 MB of Node or Ruby downloads. But this is only the beginning. For both Node and Ruby, the system needs a C compiler, only one - hundreds of megabytes. Worse, you'll probably need a compiler in production!
A bunch of puffing load for both Node and Ruby is hiding from you in such small, sequential steps. If you stop and calculate the volume, not to mention the time spent, then 200 MB will be a much more optimal option.
I don’t even want to start compiling instructions for assembling your own web kit, just to not rewrite it as soon as a new tool is released.
Is JVM so hard at work?
JVM is fast, it’s probably one of the fastest media ever. Over time, it just gets faster and easier. Thousands of the smartest engineers are working to improve it, and have contributed even more over the past 21 years.
There are real execution threads, multi-core support, it can be hellishly configured or just left as is. The only useful thing you probably should know is setting the memory limits for the JVM, and then it will show wonders when dealing with the limitations of this environment.
Unfolding on Heroku?
java -server -Xmx512m beast.jar . If this is not enough, then you probably have the money to pay someone for the advice ... Oh, well, or just look at StackOverflow.Here is the key idea that Charles and other guys from the JRuby community continue to promote. Without any gestures, your applications will surely run faster and faster with each release of the JVM (regardless of the progress of JRuby).
Disk usage is so big?
I was interested, and I looked in the folder
~/.m2 , where for 9 months of development with Clojure 1010 MB of dependencies accumulated. Even a gigabyte yet.$ du -sh /usr/local/opt/rbenv/versions/2.3.3 ~/.nvm/versions/node/v6.9.1 ~/.m2
690M /usr/local/opt/rbenv/versions/2.3.3
232M /Users/kenneth/.nvm/versions/node/v6.9.1
1010M /Users/kenneth/.m2The Ruby installation is fresh again and meets the basic requirements for running this blog and Middleman (I'm working on a fix there). Yes, it takes almost 700 MB of space to run this static blog and participate in the development of the tools on which it works.
Node has only ember, docpad and bower installed, and it is more than 200 MB.
Is the deployment so heavy?
You can probably predict what I'm going to talk about ...
When building, you make a single JAR file. It has everything to run your application on any platform. Just place the JAR where needed and provide the JVM to deal with it.
There is no such requirement that the application should work on a massive application server; you can very easily associate it with a productive HTTP server directly in the JAR file. Do guys from Node do that, and from Ruby too, but somehow JAR files can't stay on their own? I thought so too ...
I, for example, have been relieved of the need to run
apt-get install build-essentials in production.Day to day with JVM
I have at least five JVM processes running on my 2012 MacBook Pro with 8 GB of memory. Work constantly and every day. I never tried to run five Rails applications at the same time.
Why five? Two for Datomic (data collection and console), one for our backend APIs and one for the front end I work with. Sometimes there are also automatic tests in the background. Sure, macOS memory compression probably helps here because a significant part of these JVM processes should have the same bytes loaded into memory.
If you had told me about it 10 months ago, I would have just laughed. Who in their right mind will launch 5 or more JVM processes? I could give my hand to cut off, which I will never do.
Oh, and what about the class paths and all the other crazy things? They won't touch you at all thanks to the excellent Clojure toolkit. This is the same reason you use npm or bundler and do not suffer from the inclusion of paths. You could do this, but then you probably have another problem that you do not notice.
Joy REPL
If I had to continuously stop and start JVM instances, I’d just go crazy. That bothered me about JRuby in the old days. Fortunately, with Clojure and a great REPL, you have to restart a JVM instance only in the rare case where I really screwed up somewhere. This is pretty good fool protection. Figwheel works without problems for days.
Conclusion
Be careful when evaluating the JVM as an object. Evaluate Java as a language in every sense, but do not mix it with a virtual machine.
I also used to think like you. I thought of the JVM as a hippo. Fortunately, now I was able to get rid of these restrictions and got the result of the work of thousands of giants supporting it.
In no case do not consider this post as a sign of "the end of Node" or "end of Ruby". Think of a fresh perspective. If you cannot switch to JVM, at least think about how to reduce bloatiness in your own world.
Thank you for your time. Learn Clojure and try Simple Made Easy .
Source: https://habr.com/ru/post/324572/
All Articles