6 ms·

The fact that it sets null to uninitialized variables is mindblowing for lang created within the past 5 years. We all have learned that there "null" is there ju

• skrebbel 6y ago
  Pure FP isn't the only acceptable programming paradigm, please stop pretending that it is. (For context: a language without null pretty much implies an Option type, which is mostly useless (or no better than null itself) without static typing. Once you're that far you're probably gonna want to get monads to make them workable and congratulations you're reinventing Haskell)
  • baq 6y ago
    Rust is quite far from pure FP.
  • alipang 6y ago
    Found the guy who completely missed Kotlin, TypeScript and Scala.
    • skrebbel 6y ago
      All three of which have null? TypeScript even has two kinds of null. Scala even has monads as well! :-)
      • neurotrace 6y ago
        TypeScript requires you to verify if the value is null-ish or not (assuming you're using the new default "strict mode"). I don't believe Gravity does
  • enricozb 6y ago
    Since when does static typing imply monads...
    • choeger 6y ago
      Actually, it does. If you want a sound and complete static type system for a practical language, you end up with monads (or something very close to it, like streams or effects) or you cannot type your side effects (and then your type system is either incomplete or your language impractical).
      • skrebbel 6y ago
        You don't need a sound type system for the language to be practical though. Eg C#, Kotlin, TypeScript.
      • tomcam 6y ago
        Argh this sounds interesting but I’m not smart enough to make the connections. Could you dumb the explanation down a bit?
        • lostcolony 6y ago
          It's just saying that your type system is incomplete if it doesn't capture side effects. That is, if the function can do something that is not expressed as part of its return type, its return type is insufficiently expressive. As an example, imagine an "updateDB" call that returns void. Totally could exist, and be useful, but all it does is a side effect; as a function you haven't expressed its functionality via its type. From a 'pure' perspective, it would be fair for the compiler to remove that call entirely, since you do nothing with the result (since there is no result). Instead you need a monad or something to express that side effect. Obviously, many languages don't choose to express side effects within their type systems. It's not that means the language isn't useful, just that its type system isn't complete; you have things happening without a type attached to them (and in that way it's dynamically typed).
          • 6y ago
  • Risord 6y ago
    First: Yes null VS option type is all about static knowledge so it's pretty irrelevant topic in context of dynamic language. In my mind in such languages null propagation operator is basicly all you need. But cmoon it's not about FP. Checkout C# value types nullable<T> for example. C# 8 brings same principles to reference types (however being non-safe since you cannot break compatibility). Only good reasons to have (Java like) null is to either because you already did it and you cannot take away or you are in ecosystem where it's fundamentally in. And to be precise it's not about null per se. Null can be just fine but it shouldn't be valid value for every type. You can solve it either by boxing (traditional option type) or some Type Scripty flat: Car | null ideology. In some sense all languages with Java like null have some option types buuut they are missing regular non-nullable types.
  • willtim 6y ago
    The absence of nullable references is completely orthogonal to pure FP and static typing.
• throwaway894345 6y ago
  The language is dynamically typed in the first place, I don't think 'null' is dramatically increasing risk here.
• barrkel 6y ago
  This is a dynamically typed language, it has nothing in its static type system to distinguish between definitely-assigned values and optionally-assigned values. That is, there's no way to tell the compiler that a variable or function parameter or return value is a T vs a Maybe<T> or Either<T,U>. At best it could perform definite assignment analysis on variable declarations, but it can't go very far. In particular, it would do nothing for function return values. As a result, the best it could give you is runtime errors when you e.g. access the value of a dynamic Maybe without checking for presence first. Without static analysis, this isn't hugely useful.
  • fulafel 6y ago
    Uninitialized variable access trapping at run time seems useful since it's likely an error. Some statically typed languages do comparable things too if their static TS is not very powerful, see eg trapping representations or IA64's NaT in C.
• discreteevent 6y ago
  null in a language with stacktraces is not the end of the world. Null is a value and compared to other erroneous values it's much easier to find and fix. Often it is not erroneous, it's extra information that you can use to make a decision. I really don't get it because in many years of programming, in practice, null pointers are one of the least of my worries.
• _bxg1 6y ago
  What a narrow-minded view. The problem is not that null exists, it's that many statically-typed languages don't let you distinguish nullable from non-nullable variables. In the ones that do, null is functionally equivalent to Maybe/Option. And in languages that lack static types altogether, it's a moot point.