10 ms·

A case study on strict null checks

166 points by rudi-c 6y ago

_greim_ 6y ago
A third of the entire value proposition of TypeScript is the `strictNullChecks` flag. I'm glad they turn it on by default in new projects.
hardwaregeek 6y ago
I'm a huge fan of strictNullChecks but it is remarkable how much language features contribute towards making non-nullable types ergonomic. For instance Rust has a lot of primitives on Option a lot nicer. One that I love is `Option::ok_or` (or `Option::ok_or_else` if you like). It takes an Option and converts it to an error. With the try macro (?) it makes Option a lot easier to use. Compare: function parseFile(file: File | null) { if (file === null) { throw new Error("File must exist"); } // TS now infers as File } to: fn parse_file(file: Option<File>) { let file = file.ok_or(Error::new("File must exist"))?; } Likewise if you want to apply a function to an Option if it is Some and pass along None otherwise, you can use `Option::map`: fn parse_file(file: Option<File>) { let parse_result = file.map(|f| parse(f)); } Indeed it's a little interesting how libraries have adopted paradigms beyond the language. React is extremely expression based, but that makes for a clunky combo with JS' primarily statement based control flow. You see this in React developers' reliance on ternary operators and short circuiting for control flow in JSX. Of course this just JavaScript being a classical imperative language. Not much to do about that.
- nicoburns 6y ago
  > Of course this just JavaScript being a classical imperative language. Not much to do about that. I think you could actually make JavaScript expression based very easily and completely backwards compatibly. Using a statement in expression position currently throws an error. So you would simply be widening the number of allowable programs.
  - svieira 6y ago
    There is actually a Stage 1 proposal that introduces an expression that does _exactly_ that (because it's not as easy as just making `const x = for(let i of foo) { yield i; };` parse.) https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
  - munificent 6y ago
    > very easily and completely backwards compatibly. Object literals, blocks, and ASI take that out of the realm of "very easily": var x = if (c) {} else { b: console.log("hi") } If `c` is true, does this give you `null` from executing an empty block, or an empty object? If `c` is `false`, do you get an object with key "b" and value whatever `log()` returns, or is that a block with a labeled statement?
    - MHordecki 6y ago
      This specific problem was already dealt with during the introduction of arrow functions[1]. It makes sense to keep the same parsing semantics. [1]: https://www.ecma-international.org/ecma-262/11.0/index.html#prod-ConciseBody https://www.ecma-international.org/ecma-262/11.0/index.html#...
- centimeter 6y ago
  Haskell does a nice job with this as well. There's a lot of machinery available for dealing with error handling, much of it through typeclasses. format :: Maybe Int -> String format = maybe "No Int Provided" show formatIfFormatterAvailable :: Maybe (Int -> String) -> Maybe Int -> Maybe String formatIfFormatterAvailable formatter int = formatter <*> int The latter will work with any error handling type, not just Maybe. formatIfAvailable :: (Int -> String) -> Maybe Int -> Maybe String formatIfAvailable formatter int = fmap formatter int And so on. Using a combination of functor, monad, and applicative typeclasses, you can get really ergonomic error handling. It can be a little confusing to see it at first, where during parsing you have expressions like data Entry = Entry Username Date Dollars parser :: Parser Entry parser = Entry <$> usernameParser <*> dateParser <*> dollarsParser What the above is doing is "first try to parse a username, then try to parse a date, then try to parse a dollar amount, and if they all parse then return an Entry object with all that data". This is a lot easier than writing out something like 3 nested if statements, checking if any of the parsers returned null each time, or trying to use GOTOs or whatever.
- rudi-c 6y ago
  > I'm a huge fan of strictNullChecks but it is remarkable how much language features contribute towards making non-nullable types ergonomic. For sure, that was our experience as well. Without TypeScript's control flow analysis, it would be much less ergonomic to use and would probably lead to a lot of non-null `!` assertions everywhere. When writing correct code, you never notice that control flow analysis is there at all. A desirable feature, though as a result of operating in the background, few know how much TypeScript innovates in this area over other mainstream languages.
  - scns 6y ago
    Kotlin has this, may not be part of mainstream languages, depending on the definition.
- ketzo 6y ago
  Is it crazy if I think that first example is the most readable of the three? In fairness, I've done a lot of work in TS and exactly none in Rust, so this is totally biased, but at the very least, it seems like all you're getting in the next examples is two fewer lines of code, in return for assuming that the reader is familiar with 1) `Option<x>` 2) `.ok\_or` 3) the syntax of the third block which I don't remotely get. Genuine question, how comparable are these things to understanding "File | null" in TS, which I would consider day 1 learning?
  - richardwhiuk 6y ago
    The former code is more equivalent to: let file = match file { Some(file) => file, None => panic!("file was null"); };
    - timidger 6y ago
      Which you'd never write in practice since `expect` exists
      - vikiomega9 6y ago
        Can you say more here, I don't have the context.
        steveklabnik 6y ago
        This code is identical to let file = file.expect("file was null"); That is, the "expect" method does exactly this.
        jeswin 6y ago
        I like Rust from what I've tried. But I'd have preferred something like this: let file = file.unwrapOrPanicWith("file was null"); option.expect(message) doesn't semantically make sense.
- TylerE 6y ago
  Isn't this code rather leaky? What if, for instance, the file DOES exist but the current user doesn't have read permission.
  - ketralnis 6y ago
    The example code isn't a treatise on proper file handling, it's a minimal example of Option
- fuzzy2 6y ago
  I agree! At the very least, the `map` operator/monad/whatever is very much required when you have to go beyond optional chaining (with the safe navigation operator). I very much miss it in TypeScript. It's never going to happen, sadly.
- andrepd 6y ago
  Tbf I find infix operators much more straightforward and readable. E.g.: let file = file |? raise Some_error or let parse_result = parse <$> file For the last two examples respectively. EDIT: For completeness, the operators are let (|?) opt y = match opt with | Some x -> x | None -> y let (<$>) f opt = match opt with | Some x -> Some (f x) | None -> None
  - hardwaregeek 6y ago
    Infix operators are certainly more readable if you're familiar with the operators. I imagine the possible ways of handling non-nullable types (and algebraic types as a whole) as a spectrum: * TS style explicit if branches: Easy for beginners, annoying to experts * Rust style methods on Option/Result/etc: Slightly confusing for beginners, somewhat elegant for experts * Haskell/OCaml style infix operators: Confusing for beginners, elegant and easy for experts Note that this is beginners to functional programming. Not necessarily beginners in programming as a whole. Plenty of smart people would get tripped up by a `<$>`
    - smichel17 6y ago
      In my opinion, the problem with <$> is actually a problem with Haskell, which is that there's too damn many "operators" -- it's hard to keep track of them all. This also makes them hard to search for. When I search for "kotlin question mark colon", the first page of results is flooded with results about the Elvis operator (also a very memorable name for future searches, if I forgot). Searching for "haskell dollar sign in angle brackets" unearths nothing. Something as common as option types (which is basically how nullable types are used in Kotlin) deserves special syntactic sugar, in my opinion. Granted many of Haskell's operators are also common, but I wish they'd been able to limit the variety a bit.
      - tome 6y ago
        This is how you're supposed to search for Haskell operators: https://www.stackage.org/lts-13.21/hoogle?q=%3C$%3E https://www.stackage.org/lts-13.21/hoogle?q=%3C$%3E
- kazinator 6y ago
  I don't think I would ever write code where a file argument to a parse-file would be null, even if that is possible. A null instead of a file could occur if there is some API to open a file which returns null. That should be throwing something instead of returning a value that might not be handled. If I did have some object which either holds an open file or else a nil to indicate there is no open file right now, I would carefully guard that this nil does not escape; i.e. that it's never passed into any functions that cannot work without a file, such as parse-file. All methods of that object which deal with that file have to have conditionals for the situations when it's missing. Once parse-file has received nil instead of a file, it's game over. It might as well not even bother checking. The only reason to check for a nil in parse-file is if we can provide a better diagnostic for the situation compared to letting a lower level file I/O routine produce the error. Checking for null at higher levels is a bad habit from C. In C, lower level API's and library functions often don't check for null pointers: they just dereference them or crash. A C version of parse_file has to check for a null stream, because getc(stream) will crash miserably.
  - PaulDavisThe1st 6y ago
    > Checking for null at higher levels is a bad habit from C. or its a way to allow the developer to decide how much they are willing to pay for checking, since the library doesn't do it itself. I appreciate the sentiment that the ability to not check has caused many problems; I also appreciate using APIs that don't cost me conditionals when I know that the passed in value cannot be null. Sometimes I get the sense that Rust tries to be a language that promises you can get the best of all worlds here, but everytime I did deeper, it seems that this is an illusion.
- erichocean 6y ago
  TypeScript has just as few characters/lines as your Rust example: if (file === null) throw new Error("File must exist"); vs.: let file = file.ok_or(Error::new("File must exist"))?; It's also easier to type (5 non-numeric characters vs. 8 in Rust), and IMO it's easier to read and requires less tribal knowledge. (Also could be just 4 non-numeric characters in TypeScript since the semi-colon is not required.)
- lmm 6y ago
  You don't really need language features, assuming your language has sum types, polymorphism and first class functions (and why bother using a language that's missing any of those). All you need is some functions, and you can write those yourself since they're just functions. https://fsharpforfunandprofit.com/posts/recipe-part2/ https://fsharpforfunandprofit.com/posts/recipe-part2/
  - saghm 6y ago
    > You don't really need language features, assuming your language has sum types, polymorphism and first class functions (and why bother using a language that's missing any of those). To be fair, this is basically saying "you don't need language features as long as you have these language features".
    - lmm 6y ago
      Sure, but those are general language features that you'd want to have for many other reasons anyway. You don't need any option/result-specific language features.
  - JackFr 6y ago
    > You don't really need language features, assuming your language has sum types, polymorphism and first class functions Aren’t those features?
    - lmm 6y ago
      My point is that Option::ok_or and Option::map aren't language features, they're just plain old functions written in the language; if they weren't there you could implement them yourself. You need some language features to implement them (e.g. you can't implement map without first-class functions), but those are general-purpose language features that you'd want to have anyway.
- smichel17 6y ago
  Kotlin: function parseFile(file: File?) { val file = file ?: throw Exception("File must exist") } (Not the only way to do it, but in general I really like the language's economics).
  - ByteJockey 6y ago
    I'm pretty sure a function declaration in Kotlin is fun, not function.
    - smichel17 6y ago
      Yes, you're right. I copy-pasted from the previous example on my phone and missed that change.
      - ByteJockey 6y ago
        Happens to everyone. You have a nice day.
- rzwitserloot 6y ago
  I'm not sure what these snippets are really supposed to show. This one: if (file == null) throw new Error("File must exist"); is literally one character less code than this one: let file = file.ok_or(Error::new("File must exist"))?; and seems to be easier to 'read', but that's of course in the eye of the beholder. More generally, accepting an optional file seems a bit bizarre; shouldn't the job of dealing with am missing file value be done by the caller?
  - moonchild 6y ago
    In typescript, the type of 'file' implicitly changes, which is more information to keep track of. In the rust example, a new variable is explicitly introduced—though, granted, it shadows the old by using the same name—and every variable has a static type for the entirety of its lifetime. Which being said, I don't have a preference for either of those styles.
  - ChrisSD 6y ago
    The character count isn't the important point. The point is that there's no way to use a `Option<File>` type as a `File` without first checking for null. And once you do get a `File` you know that from then on it can't be null. On the other hand, using a nullable `File` requires that you remember the null check. And that you remember it for every function that takes a `File`. Yes, that last part shouldn't be necessary with sufficient care but historically people do make mistakes that go unnoticed when refactoring or generally just editing code or reusing functions in large projects.
    - presentation 6y ago
      But it doesn't require "remembering" the null check since TypeScript will error when you try to access a member of a nullable value?
  - red75prime 6y ago
    > More generally, accepting an optional file seems a bit bizarre; Yes, but in languages where all types are nullable, you cannot opt out.
- moonchild 6y ago
  function ok_or<T>(x: T | null, msg: string): T { if (x === null) throw new Error(msg); return x; }
  - frenchy 6y ago
    This is actually more similar to what is going on above: function ok_or<T>(x: T | null, msg: string): T | Error { if (x === null) return new Error(msg); return x; } Thrown values (or exceptions if you like that term) are very much not type-safe in TypeScript.
    - moonchild 6y ago
      Does TS have syntax sugar for returning errors, as rust has? If not, I don't see what's interesting about your form.
      - frenchy 6y ago
        Sorry for the late reply. It does not. My point was mostly that the TypeScript analogs are either more of a pain or less type safe.
- SloopJon 6y ago
  I ported some null-heavy Java code to C++. The source frequently returns an object, or null in case of error; e.g., BigInteger bi = rational.asBigInteger(); if (bi != null) { ... } One of the classes is essentially a node in a graph, so in my first pass its objects were wrapped in a shared_ptr, which can be null. However, objects of the other two types are typically passed by value in C++, so I had to think about that. Exactly what std::optional was designed for, but do I want to require C++17, both in the implementation and the public interface? The syntax looks nice enough: if (auto bi = rational.asBigInteger()) { ... // bi is like a non-null pointer } Java has java.util.Optional, but the source predates Java 8. TypeScript's type guard approach is really clever. Once you've checked the value, you can use it like normal. No need for a wrapper class, or different syntax.
- jillesvangurp 6y ago
  Interesting. I kind of like how Kotlin provides syntactic sugar for this with ? and?: (and !! but you should avoid using that). I think Typescript integrated a similar feature last year. However, Kotlin goes one step further and adds smart casting and contracts to the mix that enable the compiler to take null checks into account when inferring the type of something: String and String? are two different types so calling e.g. .length on a String? is a compile error. However, if you do a if(!s.isNullOrBlank()), s becomes a String. That gets rid of a lot of ugly code. Works for type checks as well. With contracts, you can tweak this further. And with extension functions you can add functionality to nullable types as well or generic types. The standard library has a few of those included. For example let is an extension function defined as inline fun <T, R> T.let(block: (T) -> R): R So if you have a String? you can write val message = s?.let { "hello %s" } That works for any nullable type and basically one of the idioms in Kotlin that lets you avoid having to do null checks. Typescript has absorbed quite a few similar features in recent years but it is being held back by backwards compatibility with Javascript. The two languages are actually very similar, especially if you turn on the strict mode. But there's always this untyped mess behind the facade that typescript provides. Currently, I'm dabbling with kotlin-js and I'm actually liking that as an alternative.
- danvk 6y ago
  If you prefer the "or throw" approach to handling null values, you can write a little helper to get something like it in TypeScript: function assert<T>(v: T | null | undefined, message?: string): asserts v is T { if (v === null || v === undefined) { throw new Error(message); } } function parseFile(file: File | null) { assert(file, 'File must exist'); // TS now infers type of file as File } Check out the TypeScript 3.7 release notes for more on assertion functions: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions https://www.typescriptlang.org/docs/handbook/release-notes/t...
- Chyzwar 6y ago
  To some extent Promises provide a similar API. I am not sure if JS needs Option. In many cases try/catch and Promises on boundaries of your code is enough. In real life you would wrap async file operation in try/catch and then call parseFile once you know that you have data. The obvious benefit of try/catch is that it can catch unexpected errors (including logic/data errors). IMO JS/TS provide a nice compromise between Go checking errors everywhere and rust more complex abstractions.
dlbucci 6y ago
I was always a big fan of Optionals, but having learned Kotlin this year, I was pleasantly surprised at how much non-nullable types seem to remove the need for them. And non-nullable can be just as ergonomic as Optionals with the `?:` operator (or `??` in TypeScript). My only issue when working with `strictNullChecks` in TS is that `null` and `undefined` both exist (thanks JS...). I also wish TS adopted a `Type?` syntax like Kotlin that would signify `Type | null | undefined` and could be used anywhere, not just in function parameters and object types (like TS's current `key?: value` syntax).
- srcreigh 6y ago
  The tsdef library has a Nilable<T> type that means T | undefined | null. It's not so bad to type with a snippet like ?<tab> => Nilable<|>.
  - shhsshs 6y ago
    That snippet is a great idea, thanks!
- slewis 6y ago
  I recommend just treating undefined and null as equivalent (since you can't control which one or ones third-party libraries will use). Everywhere you need to check for them do `!= null` or `== null` which is an idiomatic way to check for either.
z3t4 6y ago
Why is null/undefined bad?
- monoideism 6y ago
  Because it’s very easy to write code that fails to check for null or undefined, which usually leads to errors since subsequent code often expects to find a non-null and non-undefined value. The beauty of a type checker here is that it can check to make sure you properly handle the nullable/undefinable type.
  - CraigJPerry 6y ago
    There’s another approach - where null takes on contextual meaning. List<Integer> f = null; f.add(1); This is clearly a NullPointerException in Java but in a language with Nil punning, f is automatically a list containing 1. (conj nil 1) ;;=> (1)
    - monoideism 6y ago
      Sure, I’m not asserting it’s the only way to handle nulls. That said, for me personally, nil punning is uncomfortably close to the kind of weak typing (like in traditional JS) that can be catastrophic in large code bases. However, I’ve never worked with a large code base in a Lisp - whereas I have with various statically-typed functional and non-functional languages - and I find static typing, particularly Option types, very valuable.
      - kazinator 6y ago
        I've only ever carved out solutions with stone knives and bearskins. I find stone knives very valuable.
        monoideism 6y ago
        Yes, noted caveman technology Haskell. In terms of dynamic languages, I’ve also worked with a great deal of Python and JavaScript, with significantly less success on large codebases (which could be due to selection bias, admittedly).
herrvogel- 6y ago
I was very curious about their “visualization tool”, but it seems to be just one simple script. Which is fine, because it probably did all they wanted. But I believe that there’s great potential for code visualization in many ways!
ddevault 6y ago
> This website stores data such as cookies to enable necessary site functionality, including analytics, targeting, and personalization. By remaining on this website you indicate your consent. This is illegal.
- alkonaut 6y ago
  Only in some areas. Where are you browsing from? Inside EU or outside? To me it says "This website stores information such as cookies to enable necessary web site functionality including analysis targeting and personalization. You can adjust your preferences at any time or accept the default preferences" Settings Marketing: OFF Personalization: OFF Analysis: ON (Literally, in Swedish) Denna webbplats lagrar data såsom cookies för att möjliggöra nödvändig webbplatsfunktionalitet, inklusive analys, inriktning och anpassning. Du kan ändra dina inställningar när som helst eller acceptera standardinställningarna. Integritetspolicy
  - ddevault 6y ago
    EU law applies to EU citizens abroad, so unless you have a means of detecting the nationality (not the location) of the user, this is still illegal. Plus, even for EU visitors who decline consent at the prompt that you received, they still include heaps of tracking crap.
    - incrudible 6y ago
      > EU law applies to EU citizens abroad... Not in this case. The GPDR refers to residents of the EU, not citizens.
phpnode 6y ago
in addition to counting dependents you can also run the graph through pagerank to find the most impactful files to convert first. This strategy is useful when converting codebases from JS to TS too because it's common to incorrectly type a file when it has a bunch of untyped dependencies, so getting the translation order right saves a lot of rework.
hannofcart 6y ago
Strict null checks have a dramatic positive improvement on code correctness. Just want to point out that Python typecheckers (like mypy) do quite some sophisticated strict null checks when you use the 'Optional' type annotation.
didibus 6y ago
> In terms of catching errors, we can say that null errors no longer show up in our error dashboard I really wish they tried to have better metrics into if all this actually lowered their defect rates or not. Something a bit more quantitative then them not seeing null errors in their dashboards anymore. At least give us some sense of the measure? How many null error did they see before and what about now? What about other kind of errors? Did they see an uptick elsewhere as a result? What about developer productivity, was that impacted? Etc. This would have been a great opportunity to gather some real data about it.
acemarke 6y ago
I'm very curious what they mean by "Figma uses Redux, so we have models, actions and reducers". "Models" is not a term that is normally associated with Redux. Note that we now recommend using the "ducks/slice file" pattern for organizing Redux logic for a given feature in a single file: https://redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks https://redux.js.org/style-guide/style-guide#structure-files... which you basically get for free anyway if you're using our official Redux Toolkit package and the `createSlice` API (which generates action creators based on your reducers): https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Obviously the Figma codebase has been around for a while so this isn't an immediate solution to their issue, but it definitely simplifies dealing with most Redux logic.
- rudi-c 6y ago
  Good question! Looks like I might have slipped an internal term in there inadvertently. It just refers to type definition/interface declaration files for objects that are stored in the Redux store, we just happen to stick most of them in a folder that’s been called “models” for a long time.
ganafagol 6y ago
This may be slightly off topic, but I'm wondering about this in C++. There is not_null<T *> and some people even argue for using std::reference_wrapper<T> to void null dereference. But isn't the root issue that the compiler allows dereferencing of a pointer that's not guaranteed not null? Wouldn't life be much easier if we'd tweak things so that dereferencing a pointer is not actually allowed unless it's a not_null wrapped one? What are peoples thoughts on this?

166 points by rudi-c 6y ago

A third of the entire value proposition of TypeScript is the `strictNullChecks` flag. I'm glad they turn it on by default in new projects.

hardwaregeek 6y ago

I'm a huge fan of strictNullChecks but it is remarkable how much language features contribute towards making non-nullable types ergonomic. For instance Rust has a lot of primitives on Option a lot nicer. One that I love is `Option::ok_or` (or `Option::ok_or_else` if you like). It takes an Option and converts it to an error. With the try macro (?) it makes Option a lot easier to use. Compare: function parseFile(file: File | null) { if (file === null) { throw new Error("File must exist"); } // TS now infers as File } to: fn parse_file(file: Option<File>) { let file = file.ok_or(Error::new("File must exist"))?; } Likewise if you want to apply a function to an Option if it is Some and pass along None otherwise, you can use `Option::map`: fn parse_file(file: Option<File>) { let parse_result = file.map(|f| parse(f)); } Indeed it's a little interesting how libraries have adopted paradigms beyond the language. React is extremely expression based, but that makes for a clunky combo with JS' primarily statement based control flow. You see this in React developers' reliance on ternary operators and short circuiting for control flow in JSX. Of course this just JavaScript being a classical imperative language. Not much to do about that.

nicoburns 6y ago
> Of course this just JavaScript being a classical imperative language. Not much to do about that. I think you could actually make JavaScript expression based very easily and completely backwards compatibly. Using a statement in expression position currently throws an error. So you would simply be widening the number of allowable programs.
- svieira 6y ago
  There is actually a Stage 1 proposal that introduces an expression that does _exactly_ that (because it's not as easy as just making `const x = for(let i of foo) { yield i; };` parse.) https://github.com/tc39/proposal-do-expressions https://github.com/tc39/proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
- munificent 6y ago
  > very easily and completely backwards compatibly. Object literals, blocks, and ASI take that out of the realm of "very easily": var x = if (c) {} else { b: console.log("hi") } If `c` is true, does this give you `null` from executing an empty block, or an empty object? If `c` is `false`, do you get an object with key "b" and value whatever `log()` returns, or is that a block with a labeled statement?
  - MHordecki 6y ago
    This specific problem was already dealt with during the introduction of arrow functions[1]. It makes sense to keep the same parsing semantics. [1]: https://www.ecma-international.org/ecma-262/11.0/index.html#prod-ConciseBody https://www.ecma-international.org/ecma-262/11.0/index.html#...
centimeter 6y ago
Haskell does a nice job with this as well. There's a lot of machinery available for dealing with error handling, much of it through typeclasses. format :: Maybe Int -> String format = maybe "No Int Provided" show formatIfFormatterAvailable :: Maybe (Int -> String) -> Maybe Int -> Maybe String formatIfFormatterAvailable formatter int = formatter <*> int The latter will work with any error handling type, not just Maybe. formatIfAvailable :: (Int -> String) -> Maybe Int -> Maybe String formatIfAvailable formatter int = fmap formatter int And so on. Using a combination of functor, monad, and applicative typeclasses, you can get really ergonomic error handling. It can be a little confusing to see it at first, where during parsing you have expressions like data Entry = Entry Username Date Dollars parser :: Parser Entry parser = Entry <$> usernameParser <*> dateParser <*> dollarsParser What the above is doing is "first try to parse a username, then try to parse a date, then try to parse a dollar amount, and if they all parse then return an Entry object with all that data". This is a lot easier than writing out something like 3 nested if statements, checking if any of the parsers returned null each time, or trying to use GOTOs or whatever.
rudi-c 6y ago
> I'm a huge fan of strictNullChecks but it is remarkable how much language features contribute towards making non-nullable types ergonomic. For sure, that was our experience as well. Without TypeScript's control flow analysis, it would be much less ergonomic to use and would probably lead to a lot of non-null `!` assertions everywhere. When writing correct code, you never notice that control flow analysis is there at all. A desirable feature, though as a result of operating in the background, few know how much TypeScript innovates in this area over other mainstream languages.
- scns 6y ago
  Kotlin has this, may not be part of mainstream languages, depending on the definition.
ketzo 6y ago
Is it crazy if I think that first example is the most readable of the three? In fairness, I've done a lot of work in TS and exactly none in Rust, so this is totally biased, but at the very least, it seems like all you're getting in the next examples is two fewer lines of code, in return for assuming that the reader is familiar with 1) `Option<x>` 2) `.ok\_or` 3) the syntax of the third block which I don't remotely get. Genuine question, how comparable are these things to understanding "File | null" in TS, which I would consider day 1 learning?
- richardwhiuk 6y ago
  The former code is more equivalent to: let file = match file { Some(file) => file, None => panic!("file was null"); };
  - timidger 6y ago
    Which you'd never write in practice since `expect` exists
    - vikiomega9 6y ago
      Can you say more here, I don't have the context.
      - steveklabnik 6y ago
        This code is identical to let file = file.expect("file was null"); That is, the "expect" method does exactly this.
        jeswin 6y ago
        I like Rust from what I've tried. But I'd have preferred something like this: let file = file.unwrapOrPanicWith("file was null"); option.expect(message) doesn't semantically make sense.
TylerE 6y ago
Isn't this code rather leaky? What if, for instance, the file DOES exist but the current user doesn't have read permission.
- ketralnis 6y ago
  The example code isn't a treatise on proper file handling, it's a minimal example of Option
fuzzy2 6y ago
I agree! At the very least, the `map` operator/monad/whatever is very much required when you have to go beyond optional chaining (with the safe navigation operator). I very much miss it in TypeScript. It's never going to happen, sadly.
andrepd 6y ago
Tbf I find infix operators much more straightforward and readable. E.g.: let file = file |? raise Some_error or let parse_result = parse <$> file For the last two examples respectively. EDIT: For completeness, the operators are let (|?) opt y = match opt with | Some x -> x | None -> y let (<$>) f opt = match opt with | Some x -> Some (f x) | None -> None
- hardwaregeek 6y ago
  Infix operators are certainly more readable if you're familiar with the operators. I imagine the possible ways of handling non-nullable types (and algebraic types as a whole) as a spectrum: * TS style explicit if branches: Easy for beginners, annoying to experts * Rust style methods on Option/Result/etc: Slightly confusing for beginners, somewhat elegant for experts * Haskell/OCaml style infix operators: Confusing for beginners, elegant and easy for experts Note that this is beginners to functional programming. Not necessarily beginners in programming as a whole. Plenty of smart people would get tripped up by a `<$>`
  - smichel17 6y ago
    In my opinion, the problem with <$> is actually a problem with Haskell, which is that there's too damn many "operators" -- it's hard to keep track of them all. This also makes them hard to search for. When I search for "kotlin question mark colon", the first page of results is flooded with results about the Elvis operator (also a very memorable name for future searches, if I forgot). Searching for "haskell dollar sign in angle brackets" unearths nothing. Something as common as option types (which is basically how nullable types are used in Kotlin) deserves special syntactic sugar, in my opinion. Granted many of Haskell's operators are also common, but I wish they'd been able to limit the variety a bit.
    - tome 6y ago
      This is how you're supposed to search for Haskell operators: https://www.stackage.org/lts-13.21/hoogle?q=%3C$%3E https://www.stackage.org/lts-13.21/hoogle?q=%3C$%3E
kazinator 6y ago
I don't think I would ever write code where a file argument to a parse-file would be null, even if that is possible. A null instead of a file could occur if there is some API to open a file which returns null. That should be throwing something instead of returning a value that might not be handled. If I did have some object which either holds an open file or else a nil to indicate there is no open file right now, I would carefully guard that this nil does not escape; i.e. that it's never passed into any functions that cannot work without a file, such as parse-file. All methods of that object which deal with that file have to have conditionals for the situations when it's missing. Once parse-file has received nil instead of a file, it's game over. It might as well not even bother checking. The only reason to check for a nil in parse-file is if we can provide a better diagnostic for the situation compared to letting a lower level file I/O routine produce the error. Checking for null at higher levels is a bad habit from C. In C, lower level API's and library functions often don't check for null pointers: they just dereference them or crash. A C version of parse_file has to check for a null stream, because getc(stream) will crash miserably.
- PaulDavisThe1st 6y ago
  > Checking for null at higher levels is a bad habit from C. or its a way to allow the developer to decide how much they are willing to pay for checking, since the library doesn't do it itself. I appreciate the sentiment that the ability to not check has caused many problems; I also appreciate using APIs that don't cost me conditionals when I know that the passed in value cannot be null. Sometimes I get the sense that Rust tries to be a language that promises you can get the best of all worlds here, but everytime I did deeper, it seems that this is an illusion.
erichocean 6y ago
TypeScript has just as few characters/lines as your Rust example: if (file === null) throw new Error("File must exist"); vs.: let file = file.ok_or(Error::new("File must exist"))?; It's also easier to type (5 non-numeric characters vs. 8 in Rust), and IMO it's easier to read and requires less tribal knowledge. (Also could be just 4 non-numeric characters in TypeScript since the semi-colon is not required.)
lmm 6y ago
You don't really need language features, assuming your language has sum types, polymorphism and first class functions (and why bother using a language that's missing any of those). All you need is some functions, and you can write those yourself since they're just functions. https://fsharpforfunandprofit.com/posts/recipe-part2/ https://fsharpforfunandprofit.com/posts/recipe-part2/
- saghm 6y ago
  > You don't really need language features, assuming your language has sum types, polymorphism and first class functions (and why bother using a language that's missing any of those). To be fair, this is basically saying "you don't need language features as long as you have these language features".
  - lmm 6y ago
    Sure, but those are general language features that you'd want to have for many other reasons anyway. You don't need any option/result-specific language features.
- JackFr 6y ago
  > You don't really need language features, assuming your language has sum types, polymorphism and first class functions Aren’t those features?
  - lmm 6y ago
    My point is that Option::ok_or and Option::map aren't language features, they're just plain old functions written in the language; if they weren't there you could implement them yourself. You need some language features to implement them (e.g. you can't implement map without first-class functions), but those are general-purpose language features that you'd want to have anyway.
smichel17 6y ago
Kotlin: function parseFile(file: File?) { val file = file ?: throw Exception("File must exist") } (Not the only way to do it, but in general I really like the language's economics).
- ByteJockey 6y ago
  I'm pretty sure a function declaration in Kotlin is fun, not function.
  - smichel17 6y ago
    Yes, you're right. I copy-pasted from the previous example on my phone and missed that change.
    - ByteJockey 6y ago
      Happens to everyone. You have a nice day.
rzwitserloot 6y ago
I'm not sure what these snippets are really supposed to show. This one: if (file == null) throw new Error("File must exist"); is literally one character less code than this one: let file = file.ok_or(Error::new("File must exist"))?; and seems to be easier to 'read', but that's of course in the eye of the beholder. More generally, accepting an optional file seems a bit bizarre; shouldn't the job of dealing with am missing file value be done by the caller?
- moonchild 6y ago
  In typescript, the type of 'file' implicitly changes, which is more information to keep track of. In the rust example, a new variable is explicitly introduced—though, granted, it shadows the old by using the same name—and every variable has a static type for the entirety of its lifetime. Which being said, I don't have a preference for either of those styles.
- ChrisSD 6y ago
  The character count isn't the important point. The point is that there's no way to use a `Option<File>` type as a `File` without first checking for null. And once you do get a `File` you know that from then on it can't be null. On the other hand, using a nullable `File` requires that you remember the null check. And that you remember it for every function that takes a `File`. Yes, that last part shouldn't be necessary with sufficient care but historically people do make mistakes that go unnoticed when refactoring or generally just editing code or reusing functions in large projects.
  - presentation 6y ago
    But it doesn't require "remembering" the null check since TypeScript will error when you try to access a member of a nullable value?
- red75prime 6y ago
  > More generally, accepting an optional file seems a bit bizarre; Yes, but in languages where all types are nullable, you cannot opt out.
moonchild 6y ago
function ok_or<T>(x: T | null, msg: string): T { if (x === null) throw new Error(msg); return x; }
- frenchy 6y ago
  This is actually more similar to what is going on above: function ok_or<T>(x: T | null, msg: string): T | Error { if (x === null) return new Error(msg); return x; } Thrown values (or exceptions if you like that term) are very much not type-safe in TypeScript.
  - moonchild 6y ago
    Does TS have syntax sugar for returning errors, as rust has? If not, I don't see what's interesting about your form.
    - frenchy 6y ago
      Sorry for the late reply. It does not. My point was mostly that the TypeScript analogs are either more of a pain or less type safe.
SloopJon 6y ago
I ported some null-heavy Java code to C++. The source frequently returns an object, or null in case of error; e.g., BigInteger bi = rational.asBigInteger(); if (bi != null) { ... } One of the classes is essentially a node in a graph, so in my first pass its objects were wrapped in a shared_ptr, which can be null. However, objects of the other two types are typically passed by value in C++, so I had to think about that. Exactly what std::optional was designed for, but do I want to require C++17, both in the implementation and the public interface? The syntax looks nice enough: if (auto bi = rational.asBigInteger()) { ... // bi is like a non-null pointer } Java has java.util.Optional, but the source predates Java 8. TypeScript's type guard approach is really clever. Once you've checked the value, you can use it like normal. No need for a wrapper class, or different syntax.
jillesvangurp 6y ago
Interesting. I kind of like how Kotlin provides syntactic sugar for this with ? and?: (and !! but you should avoid using that). I think Typescript integrated a similar feature last year. However, Kotlin goes one step further and adds smart casting and contracts to the mix that enable the compiler to take null checks into account when inferring the type of something: String and String? are two different types so calling e.g. .length on a String? is a compile error. However, if you do a if(!s.isNullOrBlank()), s becomes a String. That gets rid of a lot of ugly code. Works for type checks as well. With contracts, you can tweak this further. And with extension functions you can add functionality to nullable types as well or generic types. The standard library has a few of those included. For example let is an extension function defined as inline fun <T, R> T.let(block: (T) -> R): R So if you have a String? you can write val message = s?.let { "hello %s" } That works for any nullable type and basically one of the idioms in Kotlin that lets you avoid having to do null checks. Typescript has absorbed quite a few similar features in recent years but it is being held back by backwards compatibility with Javascript. The two languages are actually very similar, especially if you turn on the strict mode. But there's always this untyped mess behind the facade that typescript provides. Currently, I'm dabbling with kotlin-js and I'm actually liking that as an alternative.
danvk 6y ago
If you prefer the "or throw" approach to handling null values, you can write a little helper to get something like it in TypeScript: function assert<T>(v: T | null | undefined, message?: string): asserts v is T { if (v === null || v === undefined) { throw new Error(message); } } function parseFile(file: File | null) { assert(file, 'File must exist'); // TS now infers type of file as File } Check out the TypeScript 3.7 release notes for more on assertion functions: https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions https://www.typescriptlang.org/docs/handbook/release-notes/t...
Chyzwar 6y ago
To some extent Promises provide a similar API. I am not sure if JS needs Option. In many cases try/catch and Promises on boundaries of your code is enough. In real life you would wrap async file operation in try/catch and then call parseFile once you know that you have data. The obvious benefit of try/catch is that it can catch unexpected errors (including logic/data errors). IMO JS/TS provide a nice compromise between Go checking errors everywhere and rust more complex abstractions.

dlbucci 6y ago

I was always a big fan of Optionals, but having learned Kotlin this year, I was pleasantly surprised at how much non-nullable types seem to remove the need for them. And non-nullable can be just as ergonomic as Optionals with the `?:` operator (or `??` in TypeScript). My only issue when working with `strictNullChecks` in TS is that `null` and `undefined` both exist (thanks JS...). I also wish TS adopted a `Type?` syntax like Kotlin that would signify `Type | null | undefined` and could be used anywhere, not just in function parameters and object types (like TS's current `key?: value` syntax).

srcreigh 6y ago
The tsdef library has a Nilable<T> type that means T | undefined | null. It's not so bad to type with a snippet like ?<tab> => Nilable<|>.
- shhsshs 6y ago
  That snippet is a great idea, thanks!
slewis 6y ago
I recommend just treating undefined and null as equivalent (since you can't control which one or ones third-party libraries will use). Everywhere you need to check for them do `!= null` or `== null` which is an idiomatic way to check for either.

z3t4 6y ago

Why is null/undefined bad?

monoideism 6y ago
Because it’s very easy to write code that fails to check for null or undefined, which usually leads to errors since subsequent code often expects to find a non-null and non-undefined value. The beauty of a type checker here is that it can check to make sure you properly handle the nullable/undefinable type.
- CraigJPerry 6y ago
  There’s another approach - where null takes on contextual meaning. List<Integer> f = null; f.add(1); This is clearly a NullPointerException in Java but in a language with Nil punning, f is automatically a list containing 1. (conj nil 1) ;;=> (1)
  - monoideism 6y ago
    Sure, I’m not asserting it’s the only way to handle nulls. That said, for me personally, nil punning is uncomfortably close to the kind of weak typing (like in traditional JS) that can be catastrophic in large code bases. However, I’ve never worked with a large code base in a Lisp - whereas I have with various statically-typed functional and non-functional languages - and I find static typing, particularly Option types, very valuable.
    - kazinator 6y ago
      I've only ever carved out solutions with stone knives and bearskins. I find stone knives very valuable.
      - monoideism 6y ago
        Yes, noted caveman technology Haskell. In terms of dynamic languages, I’ve also worked with a great deal of Python and JavaScript, with significantly less success on large codebases (which could be due to selection bias, admittedly).

herrvogel- 6y ago

I was very curious about their “visualization tool”, but it seems to be just one simple script. Which is fine, because it probably did all they wanted. But I believe that there’s great potential for code visualization in many ways!

ddevault 6y ago

> This website stores data such as cookies to enable necessary site functionality, including analytics, targeting, and personalization. By remaining on this website you indicate your consent. This is illegal.

alkonaut 6y ago
Only in some areas. Where are you browsing from? Inside EU or outside? To me it says "This website stores information such as cookies to enable necessary web site functionality including analysis targeting and personalization. You can adjust your preferences at any time or accept the default preferences" Settings Marketing: OFF Personalization: OFF Analysis: ON (Literally, in Swedish) Denna webbplats lagrar data såsom cookies för att möjliggöra nödvändig webbplatsfunktionalitet, inklusive analys, inriktning och anpassning. Du kan ändra dina inställningar när som helst eller acceptera standardinställningarna. Integritetspolicy
- ddevault 6y ago
  EU law applies to EU citizens abroad, so unless you have a means of detecting the nationality (not the location) of the user, this is still illegal. Plus, even for EU visitors who decline consent at the prompt that you received, they still include heaps of tracking crap.
  - incrudible 6y ago
    > EU law applies to EU citizens abroad... Not in this case. The GPDR refers to residents of the EU, not citizens.

phpnode 6y ago

in addition to counting dependents you can also run the graph through pagerank to find the most impactful files to convert first. This strategy is useful when converting codebases from JS to TS too because it's common to incorrectly type a file when it has a bunch of untyped dependencies, so getting the translation order right saves a lot of rework.

hannofcart 6y ago

Strict null checks have a dramatic positive improvement on code correctness. Just want to point out that Python typecheckers (like mypy) do quite some sophisticated strict null checks when you use the 'Optional' type annotation.

didibus 6y ago

> In terms of catching errors, we can say that null errors no longer show up in our error dashboard I really wish they tried to have better metrics into if all this actually lowered their defect rates or not. Something a bit more quantitative then them not seeing null errors in their dashboards anymore. At least give us some sense of the measure? How many null error did they see before and what about now? What about other kind of errors? Did they see an uptick elsewhere as a result? What about developer productivity, was that impacted? Etc. This would have been a great opportunity to gather some real data about it.

acemarke 6y ago

I'm very curious what they mean by "Figma uses Redux, so we have models, actions and reducers". "Models" is not a term that is normally associated with Redux. Note that we now recommend using the "ducks/slice file" pattern for organizing Redux logic for a given feature in a single file: https://redux.js.org/style-guide/style-guide#structure-files-as-feature-folders-or-ducks https://redux.js.org/style-guide/style-guide#structure-files... which you basically get for free anyway if you're using our official Redux Toolkit package and the `createSlice` API (which generates action creators based on your reducers): https://redux.js.org/tutorials/fundamentals/part-8-modern-redux https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Obviously the Figma codebase has been around for a while so this isn't an immediate solution to their issue, but it definitely simplifies dealing with most Redux logic.

rudi-c 6y ago
Good question! Looks like I might have slipped an internal term in there inadvertently. It just refers to type definition/interface declaration files for objects that are stored in the Redux store, we just happen to stick most of them in a folder that’s been called “models” for a long time.

ganafagol 6y ago

This may be slightly off topic, but I'm wondering about this in C++. There is not_null<T *> and some people even argue for using std::reference_wrapper<T> to void null dereference. But isn't the root issue that the compiler allows dereferencing of a pointer that's not guaranteed not null? Wouldn't life be much easier if we'd tweak things so that dereferencing a pointer is not actually allowed unless it's a not_null wrapped one? What are peoples thoughts on this?