Hacker News new | past | comments | ask | show | jobs | submit login

I'd say it is more like a basic requirement than a killer feature at this point.



While I love null safety, It's hardly a given. For Dart in particular, it sounds like there was a serious discussion about the choice, and it could have gone the other way.

(edit: removed incorrect statement about Python's type safety)


> For Dart in particular, it sounds like there was a serious discussion about the choice

Yes, we debated it for years.

Literally the day we launched, a user filed an issue requesting support for null safety: https://github.com/dart-lang/sdk/issues/22

For most of Dart's history, that was the #1 upvoted issue on the issue tracker.

Back in 2011 before I worked directly the language, I proposed null safety:

http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...

I'm immensely glad we finally did it, even though the migration has been a ton of work.


> languages like Python that don't provide any static type safety

https://docs.python.org/3/library/typing.html

https://github.com/python/mypy

> let alone null safety

https://docs.python.org/3/library/typing.html#typing.Optiona...


FWIW my (1 year old) experience with mypy was very poor. Stuff breaking between releases, wrong resolution, bugs. It kinda felt like a 3rd party fun project, not an official high quality solution.

The fact that the source can contain completely wrong declarations and Python will happily run it anyway felt really bad. It's kinda like JavaDoc rather than a classic type system.


Languages like Java, Go and C were all designed before it became obvious that `Option<>` or `?` were obviously the right thing to do.

You can live with it, but most language eventually add some way to deal with it. Java has @NonNull. Javascript and Python both have static type annotations that are non-nullable. Even C++ has some attempt at it (std::option<>).

The only one I know of that hasn't bothered trying is Go.


C yes, Standard ML was already a thing when Java and Go came to be, and even plenty of other ML derived languages.


Go absolutely wasn't. It has been obvious since ML and Haskell.


But only to ML and Haskell programmers. Not it is obvious to basically everyone. (Excluding people who just haven't discovered static typing at all yet.)


The designers of Go should have known this. It was designed 20-30 years after ML/Haskell.


But the absence of nulls is the feature, not the presence of Option.


Zero-values and pointers-as-options is not even half as good as Option<T>. At best, it was easy to implement, and convenient to use, until you actually had to run the program.


I feel the same. My problem is that my teammates (future and past) will continue using null deliberately. Makes it a bit hard to eliminate.


Go doesn't have null-safety, so it seems more like a nice-to-have based on Go's success.


I dunno, we had a terrible experience with Go nils at my current job:

- It's super-easy to create a situation where some some obscure code fragment can cause a panic and crash the whole app due to nil pointer access, especially in multithreaded scenarios

- We had to start using linters to track possible nil errors early on

- Eventually we just moved to Kotlin, where this is not an issue

- And don't get me started on nil interfaces, good luck properly checking nilability and tracking these kind of issues


An other fun one is that methods may or may not receive nils depending whether they’re defined with a value or a pointer receiver.


I mean all of those things are downsides to having unsafe nullability. However, my point was that those things obviously aren't deal breakers for many, many people as Go is still extremely popular.


Please don't make new accounts to reply to a single comment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: