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

341–350 of 373 posts

Re: The JVM is not that heavy

#341

Post by tobz »

geocar wrote: post #327
ipsi wrote: post #278

Earlier quoted context omitted.

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…

If "this approach" is using Java/Spark, instead of something that is a smaller binary, then there are some easy answers to your questions:

- people don't want to write C (or K, or whatever yields a small binary)

- the cost of switching languages is not worth the speed-up

- it's already fast enough

I don't think you're wrong, overall, that, specifically, kdb can be much faster than an equivalently sized Spark cluster, but simply being faster does not invalidate other approaches, which is what you seem to be arguing for.

Re: The JVM is not that heavy

#342

Post by kodablah »

geodel wrote: post #337
kodablah wrote: post #125

Earlier quoted context omitted.

As another commenter mentioned, I think this is much more the programmer and less the language. Sure, the language may recommend certain approaches which carry across teams differently, but it still often comes down to the app, not the language. I implemented a rudimentary Java AOT targetting Go and the trimmed-down stdlib grew so big Go took hours compiling it (granted some of that is how I approached OOP and what n…

> I implemented a rudimentary Java AOT targetting Go and the trimmed-down stdlib grew so big Go took hours compiling it Have you reported to Go devs? Sounds interested use case.

Yes[0] though I think the issue title is a bit off. They did bring it down from over 7 hours to 30 minutes ish in a recent release, but it's still is too long, too much CPU, and too much mem. They are very reactive of course which is something I can never say about OpenJDK.

0 - https://github.com/golang/go/issues/18602

Re: The JVM is not that heavy

#343

Post by bjoernw »

kazagistar wrote: post #227
bjoernw wrote: post #172

Earlier quoted context omitted.

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.

> hiding complexity This makes me shiver in terror.

Our job as programmers is to hide complexity and expose it when needed. Nothing to shiver about.

Re: The JVM is not that heavy

#344

Post by bjoernw »

cutler wrote: post #203
bjoernw wrote: post #172

Earlier quoted context omitted.

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.

JHipster equivalent to Rails? You have to be joking, surely. I just setup a JHipster site and when I opened it up in IntelliJ it was the same labyrinthine mess I've come to expect from Java frameworks, ie. knee-deep in endless subdirectories and everything abstracted away to the point of incomprehension. Contrast that with the simplicity of Ruby and Rails. Java by its very nature makes it impossible to build simple,…

I didn't say equivalent in general. I said equivalent in the Java world where we are more used to having to deal with bloat. Just free yourself from your preconceptions and run ./gradlew . Everything will start up fine, no mess, I promise.

Re: The JVM is not that heavy

#345

Post by astrostl »

martingxx wrote: post #46

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to ru…

> memory usage was slashed

A lot of this has to do with another unmentioned, terrifically annoying property of the JVM: pre-launch min/max heap allocation. Standard operating procedure is to go with the default, and overbump it if your needs exceed it. I can't possibly imagine how many petabytes of memory are unnecessarily assigned to JVMs throughout the world as I type, apps consuming 79MB with a 256MB/512MB heap size.

Re: The JVM is not that heavy

#346

Post by untoreh »

geodel wrote: post #297
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 feel that if Android were being developed today, they'd almost certainly take .NET Core as the runtime. If it were to develop today as against raising against time(Apple) then Google would have written their own runtime and everything.

isn't dart with flutter pretty much that?

Re: The JVM is not that heavy

#347

Post by btschaegg »

kdazzle wrote: post #322
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.

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.

Yeah, same here. I can't count the amount of times I heard statements like that one (also about Eclipse) and was puzzled. I'm starting to think that people saying this just haven't had the curiosity to really explore the alternatives. That said, even though VS causes me to cringe pretty constantly when I use it, you have to give props to MS for the language integration tools they put together for .NET. Some of the tricks they managed to come up with (like moving the instruction pointer in a method while debugging) is pretty impressive. Unfortunately, every time I get amazed by something like this, either some blatantly stupid behavior of VS destroys the magic again, or it outright crashes. Sigh.

Re: The JVM is not that heavy

#348

Post by filomeno »

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…

> Microsoft seem to have learned a lot from Java in designing their new .NET Core CLR

Of course they did. It's not a secret they designed it as a Java clone when the justice ruled they couldn't embrace the original one.

However, they missed something: cross-platformness. So essentially you get a windows only Java platform. That's why not everybody finds it impressive nor are looking forward to commit to using it everywhere (they wouldn't be able, though)

Re: The JVM is not that heavy

#349

Post by gozur88 »

cperciva wrote: post #70
gozur88 wrote: post #58

Earlier quoted context omitted.

A megabyte of disk space is now worth about $0.0000290, according to this site: http://www.jcmit.com/diskprice.htm The numbers we're talking about here just aren't a practical consideration any more.

The disk space is cheap, sure. But the CPU time spent by the dynamic linker resolving thousands upon thousands of symbols? That's actually rather painful.

You must be very busy if two hundred milliseconds is painful.

Re: The JVM is not that heavy

#350

Post by pythonaut_16 »

tonyedgecombe wrote: post #315
janwillemb wrote: post #222

Earlier quoted context omitted.

"Don't rewrite an application from scratch. There is absolutely no reason to believe that you are going to do a better job than you did the first time." -- Joel on Software, Things You Should Never Do, Part I [1] [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

I do like that article but have ignored it several times for good reasons.

I think a better interpretation of the title/article is "Don't assume that rewriting from scratch will fix all of your problems"
Post reply on HN