4 ms·

> I understand that, but for starting new projects the equation can be different. I don't think for new projects the equation is any different. Why would I thr

by vips7L 3y ago

> I understand that, but for starting new projects the equation can be different. I don't think for new projects the equation is any different. Why would I throw away a language and ecosystem that I understand, that I'm productive in and with language designers that I trust to do the correct thing for the future? Why go learn another language and ecosystem when the things it brings to the table are of no value _to me_ ? I honestly do not struggle with null. If you actually read the code you call and test the code you write you won't have a problem.

The_Colonel 3y ago
> Why go learn another language and ecosystem when the things it brings to the table are of no value _to me_ ? The language is conceptually very similar and ecosystem is shared to a large degree. > I honestly do not struggle with null. If you actually read the code you call and test the code you write you won't have a problem. Looks like you work on small projects only. If you can just read the code you call, then you don't need much of a type system at all. In my case, the call I make often executes 10,000s of lines of code and figuring out if it can return null in some cases can take hours or days.
- kaba0 3y ago
  It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null. Ideally everything should be non-nullable, with optionally specified nullability.
  - The_Colonel 3y ago
    > It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null. Of course, in the type system. Just like we're "documenting" types themselves in the type system and not in JavaDocs.
- vips7L 3y ago
  > Looks like you work on small projects only. Don’t be dismissive. I could easily just say “looks like you’re just a bad dev if you can’t handle null.” I work on large code bases too. There’s nothing special about them.
  - The_Colonel 3y ago
    It's very hard to take you seriously if your argument is "just read the code you call to figure out if it returns null or not". That just isn't feasible in large code bases.

by vips7L 3y ago

The_Colonel 3y ago

> Why go learn another language and ecosystem when the things it brings to the table are of no value _to me_ ? The language is conceptually very similar and ecosystem is shared to a large degree. > I honestly do not struggle with null. If you actually read the code you call and test the code you write you won't have a problem. Looks like you work on small projects only. If you can just read the code you call, then you don't need much of a type system at all. In my case, the call I make often executes 10,000s of lines of code and figuring out if it can return null in some cases can take hours or days.

kaba0 3y ago
It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null. Ideally everything should be non-nullable, with optionally specified nullability.
- The_Colonel 3y ago
  > It sounds like badly documented code then. A function, especially if some kind of API boundary, should absolutely state whether it can or can’t return null. Of course, in the type system. Just like we're "documenting" types themselves in the type system and not in JavaDocs.
vips7L 3y ago
> Looks like you work on small projects only. Don’t be dismissive. I could easily just say “looks like you’re just a bad dev if you can’t handle null.” I work on large code bases too. There’s nothing special about them.
- The_Colonel 3y ago
  It's very hard to take you seriously if your argument is "just read the code you call to figure out if it returns null or not". That just isn't feasible in large code bases.