| Optimal in what sense? In the java shops I've worked at it's usually viewed as a pretty optimal situation to have everything in one language. This makes code reuse, packaging, deployment, etc much simpler. In terms of speed, memory usage, runtime characteristics... sure there are better options. But if java is good enough, or can be made good enough by writing the code correctly, why add another toolchain? |
| |
| ▲ | andriy_koval an hour ago | parent [-] | | > But if java is good enough, or can be made good enough by writing the code correctly, "writing code correctly" here means stripping 95% of lang capabilities, and writing in some other language which looks like C without structs (because they will be heap allocated with cross thread synchronization and GC overhead) and standard lib. Its good enough for some tiny algo, but not good enough for anything serious. | | |
| ▲ | jcgrillo an hour ago | parent [-] | | It's good enough for the folks who choose to do it that way. Many of them do things that are quite "serious"... Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java. It's not low effort, you have to be careful, get intimate with the garbage collector, and spend a lot of time profiling. It's a totally reasonable choice to make if your team has that expertise, you're already a java shop, etc. I no longer make the choice to use java for new code. I prefer rust. But neither choice is correct or incorrect. | | |
| ▲ | andriy_koval 43 minutes ago | parent [-] | | > Databases, kafka, the lmax disruptor, and reams of performance critical proprietary code have been and continue to be written in java. those have low bar of performance, also they mostly became popular because of investments from Java hype, and rust didn't exist or had weak ecosystem at that time. |
|
|
|
