4 ms·

const/immutability at the variable declaration introduces a whole lot of annoyances, see const in c/c++. If you want immutability do it at the type. For a lang

by jesstaa 14y ago

const/immutability at the variable declaration introduces a whole lot of annoyances, see const in c/c++. If you want immutability do it at the type. For a language that uses multiple return values to indicate error nilable pointers are a requirement. With no constructors a non-nillable pointers would become a strange rarely used feature. 'defer' is currently very useful in loops, open a bunch of files in a loop and schedule them all to be closed at the end of the function. If defer was block scoped this would be impossible. The error handling with sum/option types is an idea that usually comes from people that haven't used Go or at least haven't thought about how it would work at all. It doesn't work. Languages that use sum/option types for errors are universally functional languages that don't mutate function parameters. The io.Reader interface is a good example of this problem. Read(p []byte) (n int, err error) You could make an option type of 'n' and 'err' but since the caller owns 'p' you can't prevent them from using it without checking for the error. It's non-trivial to transfer features between languages, they all interact with each other and have dependencies on each other.

deleted 14y ago
[deleted]
Peaker 14y ago
Output parameters are indeed a safety problem not solved by sum types. However, sum types would still give extra safety in most cases. Also, it is possible to differentiate a type of allocation and a type of a usable buffer, such that "io.Reader" could take an allocation as an argument and return a sum type of an error and a usable buffer. The allocation should be an opaque type not usable as a buffer unless io.Reader converts it to such.
- jesstaa 14y ago
  There are all kinds of additional complexity you could add to the type system to get additional safety. Unique pointers and linear typing are a few options, this is the route that Rust is going. But with complex type systems comes a lot of pain and work arounds to get around the types when you need to. Is the benefit of the additional safety worth the complexity?
  - Peaker 14y ago
    For some features (your examples of linear types are good ones) the cost-benefit analysis is not clear. For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features.
    - burntsushi 14y ago
      > For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features. In a vacuum, sure. But sum types don't interact in obvious ways with Go interfaces. And FYI, I enjoy both Haskell and Go. Each have their own strengths (and weaknesses). Haskell's expressiveness and safety are a pure joy to work with. But the simplicity in the language design of Go make working with the language very productive. (I very rarely find myself in a situation in Go in which I have to think about "how do I express this idea using Go". Unlike Python and Haskell, which are huge languages.) The cost-benefit analysis of a language feature MUST be performed in the context of a language and its stated goals.
genwin 14y ago
> 'defer' is currently very useful in loops, open a bunch of files in a loop and schedule them all to be closed at the end of the function. If defer was block scoped this would be impossible. Why couldn't it work at both the function and block level? I too would like to use defer at a block level. I find myself creating functions just to gain usage of defer, or not using it when I'd like to.
- drivebyacct2 14y ago
  I can think of lots of times I use defer in a block where it would be very problematic to have it execute at the end of block rather than end of function. I'm assuming there would be new syntax. That alone I think would be a strong mark against it.
  - genwin 14y ago
    You're right, it would have to be a new syntax.

by jesstaa 14y ago

deleted 14y ago

[deleted]

Peaker 14y ago

Output parameters are indeed a safety problem not solved by sum types. However, sum types would still give extra safety in most cases. Also, it is possible to differentiate a type of allocation and a type of a usable buffer, such that "io.Reader" could take an allocation as an argument and return a sum type of an error and a usable buffer. The allocation should be an opaque type not usable as a buffer unless io.Reader converts it to such.

jesstaa 14y ago
There are all kinds of additional complexity you could add to the type system to get additional safety. Unique pointers and linear typing are a few options, this is the route that Rust is going. But with complex type systems comes a lot of pain and work arounds to get around the types when you need to. Is the benefit of the additional safety worth the complexity?
- Peaker 14y ago
  For some features (your examples of linear types are good ones) the cost-benefit analysis is not clear. For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features.
  - burntsushi 14y ago
    > For other features (explicit nullability, sum types, etc) the cost-benefit is very clearly in favor of having those features, at least according to all PL researchers and most users who have experience with languages that have these features. In a vacuum, sure. But sum types don't interact in obvious ways with Go interfaces. And FYI, I enjoy both Haskell and Go. Each have their own strengths (and weaknesses). Haskell's expressiveness and safety are a pure joy to work with. But the simplicity in the language design of Go make working with the language very productive. (I very rarely find myself in a situation in Go in which I have to think about "how do I express this idea using Go". Unlike Python and Haskell, which are huge languages.) The cost-benefit analysis of a language feature MUST be performed in the context of a language and its stated goals.

genwin 14y ago

> 'defer' is currently very useful in loops, open a bunch of files in a loop and schedule them all to be closed at the end of the function. If defer was block scoped this would be impossible. Why couldn't it work at both the function and block level? I too would like to use defer at a block level. I find myself creating functions just to gain usage of defer, or not using it when I'd like to.

drivebyacct2 14y ago
I can think of lots of times I use defer in a block where it would be very problematic to have it execute at the end of block rather than end of function. I'm assuming there would be new syntax. That alone I think would be a strong mark against it.
- genwin 14y ago
  You're right, it would have to be a new syntax.