5 ms·

> But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C

> But in Golang the language semantics require the runtime to panic on nil dereference, so that won't result in something like RCE as it technically could in C or C++ (but isn't likely to). While you thoughtfully address the concerns Mr. Yager presents regarding the potential result of using a null pointer in Go, IMHO the more relevant fact is that Mr. Hoare identified in his own words a mistake he made _fifty years ago_ (1965) by introducing "null." The fact that Mr. Gerrand stated in the submitted article: “What should a modern programming language look like” Begs the questions: Why is this mistake oft addressed in _other_ languages repeated in Go? What are the benefits of _intentionally_ introducing this boundary condition into the language? Put bluntly, there is no benefit to dragging 0x0 forward in "a modern programming language." The lack of an answer to a function/method call is trivially encoded with some form of an option[1] type. 1 - https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type

zimbatm 11y ago
nil dereference is only really critical if it can result in security issues like in C and C++. After that there are a lot of class of errors that are possible even in stronger types systems like in Haskell, nil dereference is only one of them. The question ultimately is what is the shortest path to developing a functioning and correct program ? Compilers can be very smart and help you catch a lot of errors but they can also introduce friction if they become too slow. Everyone has different opinions about the "best" because we have different ways of getting to the end-result. Programming is a discovery process and some people prefer to think a lot upfront, some like to experiment and probably a different mix of both for every one of us. All this to say that nil in Go is not an absolute mistake. It's just a trade-off like everything else. Since I took Haskell as an example, it's also much much slower to compile.
- jerf 11y ago
  NULL's ability to create security errors in C/C++ is a relatively recent practical concern. (The theory that permits them goes back a long ways, but only recently have the optimizing compilers gone so crazy with unspecified behaviors.) Our concerns with NULL being a bad idea go back farther than that.
- catnaroek 11y ago
  In my experience, unless you enable all the crazy type system extensions (which isn't a terribly good idea IMO), GHC doesn't really spend that much time typechecking programs. Most of the time is spent on optimizations, which are (0) possible thanks to purity [hooray!], (1) necessary to overcome the limitations of laziness [dangit!]. In any case, Haskell supports exploratory programming just fine. It's true that Haskell's definition of "exploring" (refine your design until you can convice GHCi and QuickCheck that it makes sense) is somewhat idiosyncratic from a Lisper or Smalltalker's point of view (refine your design until you can convince yourself that it makes sense), but that doesn't make it any less legitimate. It's still experimenting, except now you have a tool to validate the degree to which the experiment has been a success. It's experimental science, not experimental art. --- On the specific topic of nils, I think it's fair to say they're an absolute mistake in a statically typed language first released as late as in 2007. Standard ML and OCaml, both much older languages, have parametric polymorphism, algebraic data types, freedom from nils, and fast compilers: Poly/ML and OCaml's bytecode compiler, respectively. In addition, both Standad ML and OCaml have unrestricted imperative facilities, so freedom from nils is perfectly possible in an imperative language. --- Regarding the classes of errors that are still possible in type systems like Haskell's, I have found only one that really matters, and where the usual workarounds (e.g., phantom types) don't help. Haskell, being a mathematically-inspired language, favors programming in terms of "timeless" entities whose existence is unaffected by the number of times you use them. While appropriate for manipulating pure data (numbers, strings, lists, trees, etc.), it's awkward for manipulating ephemeral computational resources, such as file descriptors or open sessions. A language that fares better in this regard is Rust. Rust has parametric polymorphism, algebraic data types, freedom from nils (are we seeing a common theme?) and type classes, but gives up on interactive programming in exchange for precise control over data structure representation and resource management. Rust's type system design understands very well the ephemeral nature of objects: When a non-`Copy` object is passed around elsewhere, it's truly gone from the current lexical context. --- Now, I don't want to give the impression that I think verification is the be all and end all of computer programming. There's plenty of room for languages that let you develop "fast and loose" solutions, as opposed to follow some principled philosophy. (Ruby comes to mind.) However, Go's very own marketing suggests that this isn't what they're trying to achieve. They do want a language that enforces a programming discipline. They just happen to have designed a language whose discipline doesn't provide enough benefits to justify the freedom restriction.
not_with_retard 11y ago
It's not a mistake, stop calling an orange purple.
_ak 11y ago
Who is Mr. Yager and why should I believe in his to appeal to authority?
- AdieuToLogic 11y ago
  He is a person who wrote a lucid description of what many, myself included, see as fundamental issues with Go. Yet he does so without anthropomorphizing it. Reading the first paragraph reveals: "I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good." Since Mr. Gerrand decided to take cheap shots at other languages, I felt it best to present the community with genuine criticisms of the Go language which were _not_ expressed in that style.
  - enneff 11y ago
    > Since Mr. Gerrand decided to take cheap shots at other languages I don't think I was taking any kind of "cheap shot." It is literally the origin story of Go. Google has a few unreasonably large C++ projects and the incredible build infrastructure to make that possible. It was in part Rob's dissatisfaction with this state of affairs that triggered the first discussions of Go.
incepted 11y ago
> What are the benefits of _intentionally_ introducing this boundary condition into the language? Don't ascribe to malice what can adequately be explained by stupidity. I think the Go authors are simply unaware of the ways we can mitigate null in programming languages.

zimbatm 11y ago

nil dereference is only really critical if it can result in security issues like in C and C++. After that there are a lot of class of errors that are possible even in stronger types systems like in Haskell, nil dereference is only one of them. The question ultimately is what is the shortest path to developing a functioning and correct program ? Compilers can be very smart and help you catch a lot of errors but they can also introduce friction if they become too slow. Everyone has different opinions about the "best" because we have different ways of getting to the end-result. Programming is a discovery process and some people prefer to think a lot upfront, some like to experiment and probably a different mix of both for every one of us. All this to say that nil in Go is not an absolute mistake. It's just a trade-off like everything else. Since I took Haskell as an example, it's also much much slower to compile.

jerf 11y ago
NULL's ability to create security errors in C/C++ is a relatively recent practical concern. (The theory that permits them goes back a long ways, but only recently have the optimizing compilers gone so crazy with unspecified behaviors.) Our concerns with NULL being a bad idea go back farther than that.
catnaroek 11y ago
In my experience, unless you enable all the crazy type system extensions (which isn't a terribly good idea IMO), GHC doesn't really spend that much time typechecking programs. Most of the time is spent on optimizations, which are (0) possible thanks to purity [hooray!], (1) necessary to overcome the limitations of laziness [dangit!]. In any case, Haskell supports exploratory programming just fine. It's true that Haskell's definition of "exploring" (refine your design until you can convice GHCi and QuickCheck that it makes sense) is somewhat idiosyncratic from a Lisper or Smalltalker's point of view (refine your design until you can convince yourself that it makes sense), but that doesn't make it any less legitimate. It's still experimenting, except now you have a tool to validate the degree to which the experiment has been a success. It's experimental science, not experimental art. --- On the specific topic of nils, I think it's fair to say they're an absolute mistake in a statically typed language first released as late as in 2007. Standard ML and OCaml, both much older languages, have parametric polymorphism, algebraic data types, freedom from nils, and fast compilers: Poly/ML and OCaml's bytecode compiler, respectively. In addition, both Standad ML and OCaml have unrestricted imperative facilities, so freedom from nils is perfectly possible in an imperative language. --- Regarding the classes of errors that are still possible in type systems like Haskell's, I have found only one that really matters, and where the usual workarounds (e.g., phantom types) don't help. Haskell, being a mathematically-inspired language, favors programming in terms of "timeless" entities whose existence is unaffected by the number of times you use them. While appropriate for manipulating pure data (numbers, strings, lists, trees, etc.), it's awkward for manipulating ephemeral computational resources, such as file descriptors or open sessions. A language that fares better in this regard is Rust. Rust has parametric polymorphism, algebraic data types, freedom from nils (are we seeing a common theme?) and type classes, but gives up on interactive programming in exchange for precise control over data structure representation and resource management. Rust's type system design understands very well the ephemeral nature of objects: When a non-`Copy` object is passed around elsewhere, it's truly gone from the current lexical context. --- Now, I don't want to give the impression that I think verification is the be all and end all of computer programming. There's plenty of room for languages that let you develop "fast and loose" solutions, as opposed to follow some principled philosophy. (Ruby comes to mind.) However, Go's very own marketing suggests that this isn't what they're trying to achieve. They do want a language that enforces a programming discipline. They just happen to have designed a language whose discipline doesn't provide enough benefits to justify the freedom restriction.

not_with_retard 11y ago

It's not a mistake, stop calling an orange purple.

_ak 11y ago

Who is Mr. Yager and why should I believe in his to appeal to authority?

AdieuToLogic 11y ago
He is a person who wrote a lucid description of what many, myself included, see as fundamental issues with Go. Yet he does so without anthropomorphizing it. Reading the first paragraph reveals: "I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It's not bad; it's just not good." Since Mr. Gerrand decided to take cheap shots at other languages, I felt it best to present the community with genuine criticisms of the Go language which were _not_ expressed in that style.
- enneff 11y ago
  > Since Mr. Gerrand decided to take cheap shots at other languages I don't think I was taking any kind of "cheap shot." It is literally the origin story of Go. Google has a few unreasonably large C++ projects and the incredible build infrastructure to make that possible. It was in part Rob's dissatisfaction with this state of affairs that triggered the first discussions of Go.

incepted 11y ago

> What are the benefits of _intentionally_ introducing this boundary condition into the language? Don't ascribe to malice what can adequately be explained by stupidity. I think the Go authors are simply unaware of the ways we can mitigate null in programming languages.