7 ms·

Was it a bad design decision to not include nullable types in Go? I can't count how often I've seen this: Go: panic: runtime error: invalid memory address or

• pjmlp 3y ago
  And enumerations, generics, less boilerplate way of error checking,.... It definitely wasn't due to lack of previous tested technologies with field experience since the 1970's.
  • valenterry 3y ago
    Then you don't have to create a new language. Golang was explicitly designed for not very experienced people to learn it and become productive quickly, even in big groups/teams with high attrition; that is: Google. And I think they reached their goal. If Golang starts to add more and more features, it will lose this advantage and become just "yet another language". But worse: because of how was Golang designed, it will then end up worse than, say, Java. In other words, it will lose its advantages without really gaining much. The problem is that this is probably inevitable, because the people that start as inexperienced developers with Golang will grow and become unsatisfied with the language features. Some more, some less, but that will be the general trend. And I think they are already vocal enough to push the things you listed. Instead, I think it would be better for everyone if those people would instead switch programming languages and leave Go as is. Otherwise the cycle will repeat with the next Golang...
    • baranul 3y ago
      Think that is a misconception, that Go was just designed for inexperienced people. Rather it was designed to be easier to use than C++, from which the motivation to have something different came. That a language is easier to use, doesn't mean it can't add features. The features are relative to how it helps the language be more useful and solve issues that users are having, so keeps it easier to use. Languages are always going to have pressure to adapt.
      • zelphirkalt 3y ago
        True, but it still took them 12y to add generics.
      • valenterry 3y ago
        I didn't say that it was designed only for inexperienced people. But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. And the more features a language has and that a codebase uses, the longer it takes for someone to learn it and be productive (unless they can transfer knowledge from similar concepts of other languages of course).
        • iainmerrick 3y ago
          But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. Do you have a citation for that? As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones.
          • valenterry 3y ago
            > Do you have a citation for that? I do indeed have a citation for that by Rob Pike - and no matter how downvoted I am, it stays a fact: > The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. (https://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/ https://bravenewgeek.com/go-is-unapologetically-flawed-heres...) and also: > Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. (https://go.dev/talks/2012/splash.article https://go.dev/talks/2012/splash.article) > As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones. No, it's not a second order effect. Or rather: both what you say (a language "as clean and straightforward as C") as well as a language for devs early in their career (i.e. inexperienced) are both second order effects from the underlying reason that the language is targeted at developers at google.
  • Hendrikto 3y ago
    Your opinion seems a bit outdated. Go has had generics for almost 2 years now.
    • randomdata 3y ago
      And enumerations from the start.
      • pjmlp 3y ago
        No it doesn't, it has a hack using constants and iota.
        • randomdata 3y ago
          Which is what an enumeration is. Perhaps you're thinking of sum types? They are often confused as enums.
          • pjmlp 3y ago
            Not at all. Go read Algol 60, Pascal, Modula-2, C manuals to understand what enumerations are all about. Not a comic dance between iota and manually written constants.
            • randomdata 3y ago
              It's always bizarre when someone on a discussion forum defers to the writings of someone else. If that someone else wanted to have a discussion, they could do so themselves. But since I'm in a silly mood, I'll play along with your silliness: From the GNU C manual: "An enumeration type represents a limited set of integer values, each with a name." Which is exactly what Go provides. Which isn't surprising as it is identical to C in that regard.
              • pjmlp 3y ago
                No my dear, this hack type Operation int const ( Escalated Operation = iota Archived Deleted Completed ) has nothing to do with typedef enum {Escalated, Archived, Deleted, Completed} Operation; Only someone that can't get type systems would ever assert they are the same. Literally "Go enums suck", https://news.ycombinator.com/item?id=39564737 https://news.ycombinator.com/item?id=39564737
• 65a 3y ago
  Pointers are "nullable types", but if you're seeing that a lot, it generally indicates an architectural problem.
  • segfaltnh 3y ago
    Agree with this. While I too wish that Go had better ways of handling this, there are patterns and guidelines to follow that should prevent this in practice. - Use factory functions for struct initialization where members are pointers. - Use errcheck and friends to ensure errors are not ignored. - Never dereference the left hand return value if the right hand is an error.
    • itake 3y ago
      +1. I only run into this issue when I don't follow the proper patterns our of laziness.
    • neonsunset 3y ago
      I believe the problem is if this happens to be an issue in a dependency, which you can have little recourse to. Let’s wait another decade or so and maybe the Go authors will catch on lessons learned by C# (and similar languages) long ago by introducing nullable reference types and all kinds of static analysis to help you not shoot yourself in the foot.
      • groestl 3y ago
        > - Use errcheck and friends to ensure errors are not ignored. - Never dereference the left hand return value if the right hand is an error. This itself is a very concise argument for exceptions. Automatically checks errors are not ignored, and don't allow access to the left hand return value.
        • ncruces 3y ago
          Bubbling up errors is not handing them. Making bubbling up even easier because people find this too verbose is the original mistake: if err != nil { return err } I find it verbose too. But if the alternative is to design something that allows you to ignore it 99%, and then put a huge syntactic penalty into doing anything other than bubbling up, then people will just bubble up 99.95% of the time, and complain about the other 0.05. I'm all for ensuring errors are not silently ignored. That's Go's mistake. Exceptions are not the answer.
• welder 3y ago
  Yes, it's a design flaw. It means the dev can make a mistake, forget to check for nil, BAM CRASH! I even wrote a blog post about this very thing: https://wakatime.com/blog/48-go-desperately-needs-nil-safe-types https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t... Nullable types allow devs to write safe functions (functions that don't allow nullable types as input) and spread that safety through the whole codebase. That safety isn't even an option without having nullable types. Nullable types also mean the compiler knows and warns devs if they forgot to check for nil. There's really no reason why Go sholdn't have nullable types.
  • kaashif 3y ago
    > There's really no reason why Go sholdn't have nullable types. Don't you mean non-nullable types? Go does have nullable types, everything is nullable. The blog post you linked calls them "non-nil types".
    • wrs 3y ago
      “Nullable types” is a phenomenon that occurs when non-nullable types are introduced to a language that started with null and already has libraries that rely on it. When you change the default to be non-nullable, you have to introduce the explicit concept of nullability for backwards compatibility, thus “nullable types”. Like, if you already had type X that could be null, and you change the language so X can’t be null, now you need the type Nullable<X> (often written something like X?) to let it be null again. C# and Swift are examples of this evolutionary process.
      • welder 3y ago
        Yea, non-nullable types. Thanks.
• hypeatei 3y ago
  C# took the nullable types route and it isn't the greatest experience since everything can be null regardless of the annotations. Null as a language concept is the issue since it's inherently flawed.
  • nicce 3y ago
    I would say that Rust does it pretty well with Option<>. You can define the logic when the Null should or can happen and you can avoid writing a lot of Error matching boilerplate, while still have a condition when something fails.
    • hypeatei 3y ago
      Yeah, Rust makes the handling of "None" values explicit, even if you want to ignore it with `unwrap()`
• deleted 3y ago
  [deleted]
• deergomoo 3y ago
  As someone quite new to Go, who has found a lot to like, I find the lack of a built in way to model optionality (besides pointers, which rather muddy the intent) absolutely baffling. I want to use values over pointers for as much as I possibly can; the sort of stuff I work on is not so performance sensitive that it would be a problem. But zero-values are totally insufficient for modelling optional values, especially for numeric data. Now it has generics I could implement my own Optional[T] type, but backup from the compiler forcing me to check a value exists before doing anything with it is what really makes optional types shine in languages that have it.
  • Mawr 3y ago
    You can just do it yourself as you mention and the compiler does force you to check: https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e1f84 https://gist.github.com/MawrBF2/0a60da26f66b82ee87b98b03336e...
    • deergomoo 3y ago
      That's cool, thanks for the link! Hadn't considered that multiple return values could cover this case