3 ms·

There's a huge advantage to having language level support for null safety. Annotations are just metadata, and managing semantics of that metadata is pushed to

by cle 9y ago

There's a huge advantage to having language level support for null safety. Annotations are just metadata, and managing semantics of that metadata is pushed to the programmer: to configure a static analyzer to act on them, to figure out the differences between different backends, make sure it's enabled in the build, write/install IDE plugins, etc. Language level support for this stuff means programmers don't have to worry about any of that. Pragmatics of course necessitate that we sometimes need to tack these static analyzers on after the fact. But over time, the amount of tack ons and bandaids and unnecessary backwards-compatibility-necessitated complexity becomes so high that you're better off using a better language, if you and your team can handle it. For many people, this has already happened with Java. I kind of wish Java the language would just die already and stop adding just enough features to keep people from moving on to the next generation of languages. Science progresses one death at a time.

lazaroclapp 9y ago
> Annotations are just metadata, and managing semantics of that metadata is pushed to the programmer: to configure a static analyzer to act on them, to figure out the differences between different backends, make sure it's enabled in the build, write/install IDE plugins, etc. Sure, but keep in mind switching to a new language also entails a huge investment in tooling. There is definitely a higher cost in switching your build infrastructure, tools and IDE plugins to support a new language (nevermind porting an existing codebase) than the few configuration lines it takes to add an annotation processor. At a certain scale, the tools you need might not have even been built for Kotlin, while they have existed for years for Java. > For many people, this has already happened with Java. Yes. And, for many others, it hasn't. Look, I am not arguing that we should all be writing Java until the heat-death of the universe. Whether it is Kotlin or not, I am sure better ways to do things will pop up. But there are good reasons to start even many kinds of new projects in Java today: maturity/efficiency of the compiler, tooling support (including static analyzers, since nullability type systems are not the only feature you'd ever want to bolt onto a language), etc. Over time those reasons will be less, but even then, existing Java codebases will remain, and it will still be worth making them safer. Is not like C, C++ or even Fortran codebases are not around anymore.

by cle 9y ago

lazaroclapp 9y ago

> Annotations are just metadata, and managing semantics of that metadata is pushed to the programmer: to configure a static analyzer to act on them, to figure out the differences between different backends, make sure it's enabled in the build, write/install IDE plugins, etc. Sure, but keep in mind switching to a new language also entails a huge investment in tooling. There is definitely a higher cost in switching your build infrastructure, tools and IDE plugins to support a new language (nevermind porting an existing codebase) than the few configuration lines it takes to add an annotation processor. At a certain scale, the tools you need might not have even been built for Kotlin, while they have existed for years for Java. > For many people, this has already happened with Java. Yes. And, for many others, it hasn't. Look, I am not arguing that we should all be writing Java until the heat-death of the universe. Whether it is Kotlin or not, I am sure better ways to do things will pop up. But there are good reasons to start even many kinds of new projects in Java today: maturity/efficiency of the compiler, tooling support (including static analyzers, since nullability type systems are not the only feature you'd ever want to bolt onto a language), etc. Over time those reasons will be less, but even then, existing Java codebases will remain, and it will still be worth making them safer. Is not like C, C++ or even Fortran codebases are not around anymore.