Yeah, I'm in the same boat. I'm coming fresh to the team and I haven't written any Java in anger for 8 years, and there's Rx in here. I'm sure I could sit here and study it over and over until I get it, but why? My service is running at <10 QPS. I cannot believe the runtime value is worth the SWE onboarding time.
Promises are all over the place too. I understand why someone thought this was a good idea ("I'm doing the scalable thing!"), but in the end it appears completely unnecessary (e.g. doing a blocking get call in all uses).
The problem with Java isn't Java. The problem with Java is that it lets so many people hold it wrong, and the Java ecosystem encourages it.
Yeah the problem with Java and a language like Kotlin is it has so many language features. Meaning programmers can do lots of hard to understand things.
I've been coding in C recently and really enjoy the limitations. Usually there's only one way to do something.
Comments
Yeah, I'm in the same boat. I'm coming fresh to the team and I haven't written any Java in anger for 8 years, and there's Rx in here. I'm sure I could sit here and study it over and over until I get it, but why? My service is running at <10 QPS. I cannot believe the runtime value is worth the SWE onboarding time.
Promises are all over the place too. I understand why someone thought this was a good idea ("I'm doing the scalable thing!"), but in the end it appears completely unnecessary (e.g. doing a blocking get call in all uses).
The problem with Java isn't Java. The problem with Java is that it lets so many people hold it wrong, and the Java ecosystem encourages it.
Yeah the problem with Java and a language like Kotlin is it has so many language features. Meaning programmers can do lots of hard to understand things.
I've been coding in C recently and really enjoy the limitations. Usually there's only one way to do something.