4 ms·

I'm an experienced Go user. I'm also a lover of Haskell and Hindley Milner type systems. and in practice these complaints are not that big of a deal. Generics m

• Silhouette 12y ago
  If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used. I suspect this is where many philosophical differences in these discussions originate. I appreciate the value of having quick and easy tools, but for production software where I care about quality, I don't want the language to get out of my way if I'm doing something silly, like treating data as if it's a different type to what it really is or assuming there is data to work with at all if a null value is a possibility. The web is plagued by security problems, so it seems odd to me that anyone would promote a new language for writing web-based software that retains obvious and entirely avoidable ways to introduce vulnerabilities.
  • pcwalton 12y ago
    I doubt that null pointers lead to security vulnerabilities. Panics, yes; worse performance, yes; vulnerabilities, unlikely. Null pointers are not dangling or wild pointers, which are the problematic ones.
    • Silhouette 12y ago
      I suppose that depends on how broadly you define a security vulnerability. Almost anything that can crash a process on a server -- either literally at OS level or figuratively by requiring something to reset itself before it can continue to do its job -- is probably a DoS attack waiting to happen. That might or might not be as dangerous as something like a remote root vulnerability, but I would argue that it is a serious security issue just the same. (I'm sure it also goes without saying that having code that can crash with a the equivalent of a null pointer dereference is still highly undesirable in a public-facing web server, even if it doesn't actually risk things like data leakage/loss.)
      • Silhouette 12y ago
        Interesting response... Do the multiple people downvoting not realise that even in Go a null dereference might trigger some sort of automatic reset in your server process (if the unexpected panic is only recovered by some high-level generic error handling logic) or even crash the program entirely (if you didn't have anything up the stack that recovered at all)? Or maybe not realise how these kinds of behaviours might allow denial of service attacks?
    • DonnaConners 12y ago
      You might want to google dereference null pointer code execution. Go regresses language design, because it allows constructs that have been proven to fail and are already fixed in other languages. This has nothing to do with shiny features of the newest language or whether language A or B is someone's favorite. This has to do with program correctness.
      • pcwalton 12y ago
        Those have to do with the undefined nature of null pointer dereference in C. In Go, accessing a null pointer is guaranteed to produce a panic on every architecture.
      • Scramblejams 12y ago
        You might want to google pcwalton, just sayin'.
    • lmm 12y ago
      What if e.g. a programmer calls some normalize function on data before hashing it? Then if the normalize function sometimes returns null and the programmer hasn't handled this case, an attacker could use this to generate collisions.
      • zaphar 12y ago
        That particular problem is not specific to null pointers. It's specific to normalizing functions.
• coldtea 12y ago
  >Go's single best feature and the one around which almost every decision in the languages is centered is an almost total lack of developer friction. If Go has a slogan that slogan is "Frictionless Development". It's easily the simplest, least annoying, and most "get out of your way" language I've ever used. Unless you want to do generics. Of extend the language to have custom operators, for things like scientific computing. Or tons of other things.