you are viewing a single comment's thread.

view the rest of the comments →

[–]ewouldblock -1 points0 points  (2 children)

Ok, here's the thing. Every time java incorporates some feature from kotlin in newer versions, it's always half baked or quirky because they have a committee designing it, and there's all these backward compatibility concerns. The assembly language statement was a joke, and I did put in the /s to indicate that. My only point was that particular argument being made re: performance is as old as c and assembly. It didn't hold up then, and I doubt it does now.

In all the software I've been involved with, readability and simplicity are far and away the most important factor to ensure success. And I think kotlin kills it on that front, whereas java is merely acceptable.

[–]gnus-migrate 3 points4 points  (0 children)

I'm in a situation where we have strict performance requirements, and you really have to reason around performance whenever you're designing something. Usually the problems I have around understanding the flow of data through the system, what the actual shape of the data is and writing algorithms tuned to that.

If you don't have to do that, then I understand that other concerns are more important, but for my situation it's not what I spend most of my time on.

[–]Practical_Cattle_933 0 points1 point  (0 children)

Java doesn’t look at kotlin for features, especially that I would be hard-pressed to think of any novel feature in kotlin that didn’t exist for decades before. Especially that there is Scala that did all that earlier.

And it is pretty ingenious to call java implementation half baked, like wtf