News for hackers. Stuff that matters.
Re:Performance in Big Data Land: Every CPU cycle matters by corysama on Wednesday October 28, 2015 @08:16PM (#10468389)
Because a couple decades ago Java convinced Enterprise Land that they can't hire millions of C++ jockeys and expect them to work effectively in huge projects that plan to evolve into the next decades' (aka: the present's) legacy mudball. Instead, they decided it would be easier to hire millions of Java jockeys and have them build enormous kiln-fired mudballs using the same architectural strategy as the Egyptian pyramids. They convinced academia to raise an entire generation of Java jockeys, hired them all right out of school, and set them immediately to piling up enormous mud bricks forever.

So, now they have a few million Java jockeys churning away and a few million person-decades of work put into their mud piles. When starting any new project, there isn't much question about how to build it: More Mud!

Re:Performance in Big Data Land: Every CPU cycle matters by nascentmind on Thursday October 29, 2015 @08:40AM (#10470519)
This is the problem here.

As an embedded developer where every cycle counts I have come up with the same question as the poster above why bother with such languages. If a switch processes packets at line rate with the use of ASIC's why not have some similar development in the world of big data.

Re:Performance in Big Data Land: Every CPU cycle matters by schmidtc on Wednesday October 28, 2015 @08:43PM (#10468494)
Thank you