Hacker News new | past | comments | ask | show | jobs | submit login

> If you're not picking the JVM in 2016 to build your core services and web applications then you're making a mistake that is going to cost you time and money either upfront in building things that already exist or later down the road when you start to need more performance and your RoR application isn't cutting it anymore.

Honestly, unless you are operating on thin margins due to your business structure ... this isn't really an issue.

Pretty much anyone with well padded margins that the primary cost is engineering time or product costs [e.g. Physical products to ship] this is a complete non-issue as long as the datastore/service architecture is designed for horizontal scaling.

I'm constantly amazed by the tribalism of developers and the delusion that language performance is in any way relevant.

The reality is you need to just stick with one language so you can keep your engineering talent, tooling, etc. consistent due to the economies of scale of avoiding duplication of effort [libraries, learning time, tooling, etc]. The gain is in terms of engineering costs, not hardware costs.

The language, honestly, just does not matter when we can have a 10 man IT team with ~$50k/year in hardware handling a $100mil/year in business with good margins. It just doesn't even register.




Good for you that you are in that kind of business. I've never worked on anything where we didn't need more performance in the end. And when you do need it you need it quick. Having an environment and tools (e.g. top class profilers) that make that possible is often the only way to get it done in time.


The OP's one-size fits all approach is simply wrong.

Simply because it is correct for a subset of organizations does not make it true for all organizations as the OP implied.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: