eh?

    scala> val safe = Option(null)
    safe: Option[Null] = None

  // The type of 'unsafe' is Option[String]
  var unsafe = Option("some string")
  unsafe = null
  unsafe map println

  Exception in thread "main" scala.MatchError: null

--

edit: you could object to my use of var (and you should). Ok, let's re-write it to be a val:

  def unsafeFunction(x: Option[String]): Option[String] = {
    x orElse null
  }

  ...

  val unsafe = unsafeFunction(None)
  unsafe map println 

Yes, in Scala val should be king (unfortunately, it's not -- if you've taken the two Coursera courses by Odersky you'll see some use of var in the exercises, refuting your claim). But it's true val is more common, and the use of var was accidental to my point anyway (mutation wasn't the issue), hence my clarification and second example. Yes, it's pretty obvious where I introduced the mistake, I said as much. In the real world, the mistake might be harder to spot, which is why the type system shouldn't allow it.

If I understand your position correctly, it seems to boil down to "programmers will code correctly, therefore this static check (that Option must not be null) isn't needed". Which is pretty much what dynamic typing proponents have been saying all along. A pretty untenable position if you want to stay on the side of Scala...

I'd much prefer if Option were more like Haskell's Mabye, but then again, I side with static typing. I understand why, given Scala's requirements, this wasn't possible. It's just disappointing.

val is indeed king, var is used sparingly, look under the hood of any prominent Scala library and you'll see val-ue of immutability put into practice. Locally scoped vars can be useful, but beyond that dangers waits (not unlike Haskell's unsafePerformIO).

In terms of disappointment, I could say similar things about Haskell: I'm deeply disappointed with the eternal compile times, meaningless stack traces (no line number, heh, nice), non-existent tooling (read: null IDE), etc.

Scala lives on the JVM and has seemless interop with Java; concessions have been made, the type system will never rival that of Haskell, but then again, outside of Haskell no other mainstream language's type system rivals that of Scala.

I agree there are pain points with Haskell as well, no language is perfect. But slow compilation... surely you're kidding when you don't see this as a problem with Scala? The compiler is SLOW. And as for IDEs, which one do you recommend? I heard good things about IntelliJ, but please don't recommend Scala IDE because to say it's inadequate would be a huge understatement. I've cursed too many times with its phantom compilation errors.

When calling a Java method assume a null return and wrap it up in an Option just as you'd do with Haskell when interfacing with the "outside" world.

As for Scala compilation speed, Haskell's not gonna win that battle, ghc is to scalac as scalac is to javac, which is to say, the last is first and the first is last in terms of compilation speed. Also, IIRC only Yesod provides incremental builds, no? With SBT incremental builds most code changes incur a < 1 second recompilation hit.

As for the IDE story, the secret to a performant Scala IDE is to turn off automatic builds in Eclipse and let SBT run the show. With the SBT eclipse plugin there's a setting that allows SBT compilation target and Eclipse target to be shared so you never have to clean/build in Eclipse -- this is a huge win, the difference between standard dog slow Eclipse performance, and snappy, oh this is real nice if only the haters knew, joy ;-)

  scala> val x = Some(null)
  x: Some[Null] = Some(null)

Even so, to continue with your example:

    scala> x foreach println
    null

    x.get
    res2: Null = null

Try harder ;-)

Although (having just re-read it), the original post's complaint was actually that:

> the compiler (afaik) doesn't prevent you from setting an Optional field to null

ie

  scala> val option: Option[Any] = null
  option: Option[Any] = null

With the introduction of null, this is no longer possible. I've just shown an example of getting an NPE while mapping over an Option[String]. Now we're back in Java-land, where I must explicitly check for nulls, read the source code of every method or trust some comment that tells me that it will never return null. (Ok, not exactly like Java-land: a Scala programmer who returns a null for a function with type Option is very inexperienced or is doing something naughty. But why does the language even allow it?)

Aside from telling me I'm wrong, can you explain why?

Those are just my guesses of the design rationale, working from the fact that Scala does support nulls. But perhaps Scala could have come up with a better solution that still allows null use when necessary. If you think of some syntax and elegant semantics for allowing you to forget about null for most code, I’d be interested to see your proposal.

  unsafe {
    ...
  }

I have never ever seen this happening.

The complaint feels a lot like "well, someone could use reflection and change the cached values of Integer, why don't you check that every time something returns an Integer?" to me.

null is the sad fact of running on the JVM, but pretending that it doesn't exist works 99.9999% of the time in Scala.

The fact is that type system should NOT allow an Option val to be null. That's what type systems are there for. If a Scala programmer coming from a Java background wants to use null in Scala programs, the compiler will happily allow it. This is awful practice in Scala, of course, but it's allowed without warning. I've seen this happen with amateur Scala devs (and I'm ready to admit I'm an amateur with Scala too, I don't want to sound condescending).

Your remark that "null is the sad fact of running on the JVM" was what I was saying all along. Am I allowed to express disappointment that Scala's type system is compromised because of this fact?

What I'm saying is that you are barking up the wrong tree. You need to go to Oracle and complain there if you are unhappy about nulls.

It is commonly understood that if an API returns Option[A] then the client can assume it will not return null. Personally I have never experienced a real error from this.