Yes, as best as can reasonably be managed while interoperating seamlessly with Java. null still exists but the community strongly discourages using it (and there's a compiler plugin that will make it a warning or an error). Standard library methods don't expect or return null (e.g. Map#get returns Option), and the ecosystem follows the same convention. Option is very widely used and supported in for/yield syntax; better still it's a normal type in the language that can be abstracted over by the usual mechanisms (e.g. scalaz defines a Monad typeclass for it, so generic methods like traverse will work for Option). When wrapping a Java library you have to use your own judgement to know whether a method can return null (it's either that or force you to check every java method call, which some languages do but makes interop awkward); best practice is to wrap any calls to a possibly-null method in Option(...) immediately so that the null never "escapes" into Scala-land.

Of late the scala-native ecosystem has grown to the point where you can largely avoid using Java libraries at all. I can't remember the last time I saw a null or a NullPointerException at my Scala job.

Kind of. It's a sort of "bad karma" approach: There's no compiler support per se, but it's generally frowned upon to use "null" in native Scala code. Usually Scala APIs will use Option[T] to signify that something is optional and just assume that you don't pass a Some(null) -- I can't recall off-hand whether the latter will actually throw an NPE.

(Personally, I don't think that it's nearly sufficient, but as Paul Phillips would say "INTEROPERABILITY with Java!". Us Scala users suffer greatly for that nebulous goal.)