4 ms·
Choice of language does matter. For instance if you commit in 2022 to java/scala - you subscribe to heavy 20yo over-engineering legacy, whether you want it or
by aristofun 4y ago
Choice of language does matter.
For instance if you commit in 2022 to java/scala - you subscribe to heavy 20yo over-engineering legacy, whether you want it or not. No matter how fancy and eloquent your frameworks are, or how smart is your founding team — sooner or later this will catch your project.
The benefits may still outweigh the drawbacks for your particular case (though i never seen such cases except some external infra constraints like dependency on critical jvm service etc.) - but it is an important factor to consider that so many overlook.
- poulsbohemian 4y ago>you subscribe to heavy 20yo over-engineering legacy Maybe the key word here is "over-engineering" but given the age of Python, Ruby, Javascript (IE: other languages in popular use, all of which are of a similar age) I'm curious how you see Java as being different in this regard. Seems like you've done some thinking on this point so I'm genuinely curious to hear your perspective.
- aristofun 4y agoRuby Python and js has their own downsides and benefits, I just took java as an example to illustrate the point — language is not just a syntax, vm and standard lib, it’s always bundled with some traditions, mentality, patterns that one should take into consideration.
- birdymcbird 4y ago> “if you commit in 2022 to java/scala - you subscribe to heavy 20yo over-engineering legacy, whether you want it or not” Fully committed to Java on services side and Scala for data transforms and Spark jobs. The Java services have 500k-1MM TPS. For a dev onboarding, setting up personal dev environment on Mac or their VM and creating personal cloud stack takes less than 10 min. some of the services are up to 4-5 years old. couple spun up end of q3 this year. I think those are getting more like 100k TPS. Devs are pretty happy, we have decent roadmap for next year, and operational support is totally reasonable. Zero pages all month (knock on wood). We have high test coverage, including unit and integ tests, canaries, and full ci/cd. A couple code paths use AWS X-ray but with very low sample rate to avoid blowing up costs. All the services are Java. The Scala I think is even simpler and more straightforward. Spark and a few other things orchestrated using Airflow. The Airflow scripts are in Python though. Let me know more about your prediction for our over engineering. People are happy (close 1:1 feedback from people I mentor, their managers, and managers manager), and we’re making money [knock on wood]. Why is this not good enough and how can it be better? Btw we have dedicated software engineers in test. Their tooling is also using Java in quite a few places, and their partnership with core dev teams is very strong. Haven’t gotten negative feedback from them or their leadership either.
- aristofun 4y agoI can just congratulate you on a great job done. You may as well have said that Amazon is living on JVM mostly and look how rich and happy they are as company. It would be a much stronger argument :) Sometimes things happen not thanks to, but inspite of.
- birdymcbird 4y agoI’m assuming this is sarcasm. I am not working at Amazon. If anything, you can view my post history and see my disfavor of big tech. If you have something more substantial to say, please do it, but a sarcastic/snark remark isn’t jt
- aristofun 4y agoIt is not sarcastic (tiny bit of sarcasm is pointed towards Amazon if any, because they are actually using JVM a lot). I'm just saying that your arguments doesn't refute my point, nor supports it. Your success with java doesn't mean that java world is not full of legacy and suffering for many other teams.
- birdymcbird 4y ago> “because they are actually using JVM a lot” It has nothing to do with my company, and so interesting your rebuttal to my comment was snark and about an entirely different company. Here’s your original comment. > “if you commit in 2022 to java/scala - you subscribe to heavy 20yo over-engineering legacy, whether you want it or not” And now you said: > “Your success with java doesn't mean that java world is not full of legacy and suffering for many other teams.” You painted a broad brush stroke, and I shared personal evidence of a successful business running on JVM. Now you’re painting another brush, indirectly saying this case is exception or somehow doesn’t matter. If you have something meaningful to say, or any particular experience on what my organization should watch out for (some blind spot), call it out. It feels like you’re not here to teach or inform, this is more about you being right. Everyone can have an opinion. They’re worthless unless you have something actually constructive to add.