3 ms·

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out wel

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release. > Null Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null. > - Type inference Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying. > - Tooling I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.

the_af 10y ago
> If you want things to be nullable, you will have to opt-in explicitly with T|Null I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?
- airless_bar 10y ago
  Thanks for the downvote. Let's close this discussion.
  - the_af 10y ago
    I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
    - airless_bar 10y ago
      Alright. Sorry. Regarding your question about nulls and Java: I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability". As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first. The approach of supplying external nullability meta data has largely been a failure, because a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim. The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.
bshanks 10y ago
I'm interested in exploring what makes a build tool good. Which design choices does SBT choose that makes it amazing?

the_af 10y ago

> If you want things to be nullable, you will have to opt-in explicitly with T|Null I can see how the opt-in null references might help prevent you from writing Scala code that uses null, but how does it help when interacting with Java code?

airless_bar 10y ago
Thanks for the downvote. Let's close this discussion.
- the_af 10y ago
  I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.
  - airless_bar 10y ago
    Alright. Sorry. Regarding your question about nulls and Java: I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability". As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first. The approach of supplying external nullability meta data has largely been a failure, because a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim. The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.

bshanks 10y ago

I'm interested in exploring what makes a build tool good. Which design choices does SBT choose that makes it amazing?