Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

321–330 of 373 posts

Re: The JVM is not that heavy

#321

Post by flamtap »

kdevrou wrote: post #302
frant-hartm wrote: post #282

Earlier quoted context omitted.

I could more or less agree with most of it apart from > arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code) https://www.jetbrains.com/resharper/documentation/comparison... Refactoring, Coding assistance, Navigation & search sections being most important.

I couldn't agree more. I constantly see this claim made about Visual Studio. I find it to be in the way most of the time. It does sound like most of the features that I want are in Resharper; I'll have to try it out.

You will never, ever look back.

Re: The JVM is not that heavy

#322

Post by kdazzle »

frant-hartm wrote: post #282
nikcub wrote: post #261

Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR. It has gotten almost everything right: * a small and fast CLR (JVM) * a class library that defaults to almost nothing but primitive classes * proper and standardized version, platform and package management (NuGet) * open source and MIT license[0] * a patent promise[1] * arguably the best dev IDE available (Visual Studio) and one of…

I could more or less agree with most of it apart from > arguably the best dev IDE available (Visual Studio) and one of the best up-and-coming dev text editors (VS Code) https://www.jetbrains.com/resharper/documentation/comparison... Refactoring, Coding assistance, Navigation & search sections being most important.

Yeah, if I had a dollar for every time I had to restart Visual Studio in order to get something to work...especially test debugging. But IntelliJ always works perfectly. Must say that I can't wait for Jetbrains' Rider to come out.

Re: The JVM is not that heavy

#323

Post by shard972 »

hota_mazi wrote: post #214
brianwawok wrote: post #96

Earlier quoted context omitted.

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

> This is the easy trap to fall into though. Indeed. It's a typical honeymoon phase with very little regards to 1-2-5 years in the future. The cost of having picked to Go will be fully apparent then.

I really want to see a comparison of a language like go to something much more in the functional sphere when it comes to maintainability of a large codebase.

I really feel like that one of the big issues we as programmers want to get a better handle on but there isn't a lot to go off that isn't based off opinions (which can be hard to validate).

Re: The JVM is not that heavy

#324

Post by snuxoll »

lmm wrote: post #151
snuxoll wrote: post #63

Earlier quoted context omitted.

1 file is the stupidest argument I've ever heard for saying one language is better than another. Look, here's the 1 file it takes to install a python app I wrote: mycoolapp-0.1.0-1.el7.rpm - how neat is that?! Sure, pretty much anything is "heavy" compared to go or rust, but those are systems programming languages by design, not something I'd write some huge web application in personally.

> Look, here's the 1 file it takes to install a python app I wrote: mycoolapp-0.1.0-1.el7.rpm - how neat is that?! Is that one cross-platform file? Is it even portable across different linux distributions? Across different servers running the same distribution but perhaps with different libraries installed? Will another python developer understand how the build process for it is set up and be able to add new dependen…

> Is that one cross-platform file?

No, and neither is a Go or Rust binary, next question.

> Is it even portable across different linux distributions?

Nothing preventing me from taking an extra 10 minutes to modify the spec to support SUSE, Fedora support usually comes for free if you support el7.

You like Debian derivatives? Let me toss a debian/ directory in there, that'll only take a couple minutes too.

Added benefit, I'm not just throwing files at a server like some hacky Windows developer doing an xcopy deploy to IIS. I can check what version of my application is deployed, and update it along with the rest of the system if I so desire (setting up a yum or apt repository isn't hard).

> Across different servers running the same distribution but perhaps with different libraries installed?

Different libraries? Do you mean different VERSIONS of libraries? Native libraries have figured this shit out for ages with soname's. Python too, different versions of an egg can be installed side by side, you need to pin a specific version just use pkg_resources.require() in your main script.

> Will another python developer understand how the build process for it is set up and be able to add new dependencies?

I had a Jr. Developer with no experience with Linux or Python pick up building the package and making basic edits to the .spec file 10 minutes. RPM/DEB packaging isn't magic, you describe your package with metadata, write some shell commands to build/install your package in a buildroot, and then list the files from said buildroot to include in the package. You could make your first package from scratch in under an hour if you read the Fedora or Debian wiki guides on packaging.

Re: The JVM is not that heavy

#325

Post by snuxoll »

bjoernw wrote: post #172
snuxoll wrote: post #147

Earlier quoted context omitted.

I mean, even the "enterprisey" stuff like Spring Boot is more than fast enough. I have a little REST service I just deployed to production today, 5 seconds to start up on my laptop's SSD (unfortunately it took about 50 seconds in production because our SAN is dog-slow for some reason).

How is Spring Boot "enterprisey"? It makes modern java programming simpler and more accessible by hiding some of the unnecessary complexity. It enables things like https://jhipster.github.io/ which to me is the Rails equivalent in the java world.

Spring Boot hides needing to deploy to an application server along with the extra configuration that entails, it doesn't hide Spring from you.

There's still a ton of "enterprise-grade" shit in Spring, you just aren't forced to use it if you don't want - but it's always there, lurking behind the scenes.

Re: The JVM is not that heavy

#326

Post by jshen »

hrjet wrote: post #319
jshen wrote: post #318

Earlier quoted context omitted.

128mb is a lot compared to go which will often run around 10mb. Was your jvm back then 32mb or 64mb? If it was 32 your memory requirement will be higher on 64.

128MB was the total RAM in the VPS including OS + nginx + JVM + Postgresql. The heap allocated to the JVM process was about 64MB, but bear in mind that this was an actual application. So, it's hard to do a detailed comparison between JVM and Go without standardising on the application. All that I am claiming is that JVM is in the same ball park.

It's not in the same ballpark. I'll throw some code up when I get a chance.

Edit: do you have a twitter or Reddit account? I'll ping you when I have code examples if you want.

Re: The JVM is not that heavy

#327

Post by geocar »

ipsi wrote: post #278
geocar wrote: post #270

Earlier quoted context omitted.

No, I'm really quite serious. KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster. That's the real cost of memory in 2017. So what did we gain for paying it? [1]: https://news.ycombin…

You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make. You're comparing KDB running on 4x Intel Xeon Phi 7210 CPUs, totaling 256 physical CPUs. Compared to the best result for Java/Spark, which was running on 11x m3.xlarge instances on AWS. That's only 44 CPUs, plus it's running on AWS, not 100% dedicated hardware, so it's tough to tell what sort of an im…

> You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make.

Then argue with the point you think I could be making instead of the point that you think I'm making[1]

[1]: http://philosophy.lander.edu/oriental/charity.html

> you would have to compare KDB and Java/Spark both running on the Xeon Phis, and/or running both on 11x m3.xlarge AWS instances - and even then, if Java/Spark does poorly on the Xeon Phi test...

If Spark can solve the business problem in less real-time in another way, I think that would be worth talking about, but it's my understanding that a bunch of mid/large machines connected to shared storage is the typical Spark deployment, and the hardware costs are similar to the Phi solution.

So my larger question still stands: What is the value in this approach, if it's not faster or cheaper?

Re: The JVM is not that heavy

#328

Post by lmm »

snuxoll wrote: post #324
lmm wrote: post #151

Earlier quoted context omitted.

> Look, here's the 1 file it takes to install a python app I wrote: mycoolapp-0.1.0-1.el7.rpm - how neat is that?! Is that one cross-platform file? Is it even portable across different linux distributions? Across different servers running the same distribution but perhaps with different libraries installed? Will another python developer understand how the build process for it is set up and be able to add new dependen…

> Is that one cross-platform file? No, and neither is a Go or Rust binary, next question. > Is it even portable across different linux distributions? Nothing preventing me from taking an extra 10 minutes to modify the spec to support SUSE, Fedora support usually comes for free if you support el7. You like Debian derivatives? Let me toss a debian/ directory in there, that'll only take a couple minutes too. Added benef…

> No, and neither is a Go or Rust binary

Sure, I'm comparing with the JVM per the article.

> Nothing preventing me from taking an extra 10 minutes

Indeed, but 10 minutes here, 10 minutes there, it all adds up.

> Different libraries? Do you mean different VERSIONS of libraries?

No, I mean some native libraries not installed. Does your package declare what packages it depends on? How do you handle different distributions using different package names for the same libraries.

> RPM/DEB packaging isn't magic, you describe your package with metadata, write some shell commands to build/install your package in a buildroot, and then list the files from said buildroot to include in the package. You could make your first package from scratch in under an hour if you read the Fedora or Debian wiki guides on packaging.

Sure, none of it's hard. But if there's no clear standard everyone ends up doing it slightly differently, and then every project you pick up you have to understand how they've set things up.

Re: The JVM is not that heavy

#329

Post by srpeck »

ipsi wrote: post #278
geocar wrote: post #270

Earlier quoted context omitted.

No, I'm really quite serious. KDB[1] is about 1000x faster than Spark[2], and is only about 600kb (and most of that is shared library dynamic linker stuff that makes interfacing with the rest of the OS easier). A big part of why it's fast is because it's small -- once you're inside cache memory everything gets faster. That's the real cost of memory in 2017. So what did we gain for paying it? [1]: https://news.ycombin…

You're comparing completely, utterly different results here, and it's really hurting any point you're trying to make. You're comparing KDB running on 4x Intel Xeon Phi 7210 CPUs, totaling 256 physical CPUs. Compared to the best result for Java/Spark, which was running on 11x m3.xlarge instances on AWS. That's only 44 CPUs, plus it's running on AWS, not 100% dedicated hardware, so it's tough to tell what sort of an im…

Have a look at the benchmarks here: http://kparc.com/q4/readme.txt

Also: https://hn.algolia.com/?query=http:%2F%2Fkparc.com%2Fq4%2Fre...

Re: The JVM is not that heavy

#330

Post by fetbaffe »

jpgvm wrote: post #301
fetbaffe wrote: post #231

Earlier quoted context omitted.

I could use the exact same arguments but for PHP.

Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP. PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be re…

Readability is not problem in PHP either. Follow PSR-1, PSR-2 and PSR-4 and use a command like tool like codesniffer in your build step to guarantee code standard on each commit (or use Upsource)

And in PHP7.x you have even more type hinting than before and with an IDE like PHPStorm refactoring is a breeze.

And with the release of PHP7, PHP is future proof. The community will continue improve it with the major features, they have shown it. Interest in the language have increased. More RFCs is contributed to the language than before. https://wiki.php.net/rfc

Multiple teams on a large code base is not really a problem in modern PHP. I do it every day. We follow modern design patterns, code reviews, code coverage over 80% of the system (old as new code). New code is probably over 95% coverage. Deploys regularly multiple times every week.

Almost all (>95%) of my problems stem from design decisions made in the past, not the language itself.

I'm not saying that you should not use Go (or Java). Both are fine languages. Use the right tool for the job. If you don't do a realtime stock trading system or some embedded system, but some web stack, I can't really see that the majority of the problems stem from language choice (whatever you choose). It is in the team, the culture, the understanding of the domain. There should be your focus.

Personally, the most two important things I look for in a language/platform is tooling and community.

Post reply on HN