10 ms·

The language I wish Go was

59 points by dochtman 16y ago

sid0 16y ago
You know what I wish Go had? Compiler-enforced immutable state. It is inexcusable that a language designed for concurrent programming in 2010 doesn't support immutability [1]. [1] http://groups.google.com/group/golang-nuts/browse_thread/thread/0678c6dcdefb21ca http://groups.google.com/group/golang-nuts/browse_thread/thr...
- sausagefeet 16y ago
  Someone on the reddit thread argued that because it is CSP you do not need this. The idea being when you send your object down the channel you lose ownership of it. I don't know enough about the Go implementation to know if this is true or not.
  - nickik 16y ago
    Normaly thats right but you can pass pointers on a channel you share mutible state. Listen to the go talk at Emergin Languages Camp. Rich Hickey asks about that in the end.
    - sausagefeet 16y ago
      Is there any point where you would want to pass a pointer but NOT because you want mutable state, simply because it's more efficient or something?
      - jpr 16y ago
        Well, pointers have fixed size, random structures may be arbitrarily big and involve a crapload of copying.
- jashkenas 16y ago
  Rob Pike answers this question directly in the last couple minutes of his Go talk at the Emerging Languages Camp, earlier this summer. I think it's pretty illuminating as to the rationale behind why Go does it the way it does. http://confreaks.net/videos/115-elcamp2010-go http://confreaks.net/videos/115-elcamp2010-go Check out the video, but here's a rough transcription of part of it: "This is a systems language, which means you should have the choice to do efficient things, if you know what you're doing. You shouldn't be told "you can't do that because you might get it wrong." Let me explain. The model for sharing and locking all that stuff is like having a big piece of paper and we all gather the paper and we make notes on it about who owns what, when -- and we scribble and erase and rewrite and work on it. This model is: you don't have one piece of paper, you have lots of pieces of paper. And you write a message on a piece of paper, and you give him that piece, and he goes away, and you don't have it anymore. He'll bring it back to you if it's relevant to you; he won't if it's not. And because the individual pieces are broken up, there's no concern or worry about who owns what at any one time -- it's whoever's got ahold of it at the moment. And once you understand that, it just doesn't come up as an issue, that for efficiency reasons, I want to pass a pointer on a channel, because once I've passed it I forget it. The only person who has it is the person whose business it is to deal with it now. If you're worried about it and you really care: don't pass a pointer, pass a value. Make it a channel of struct, rather than a channel of pointer to struct. It will be a copy, and there's no way you can share it. But that's your decision, not the language's."
  - nickik 16y ago
    I think CSP is often good but in a system language you need to share stat and with passign pointer you can only share state unsave. So you copy or you share unsave.
  - sid0 16y ago
    > This is a systems language, which means you should have the choice to do efficient things, if you know what you're doing. You shouldn't be told "you can't do that because you might get it wrong. I don't have the time to watch the video right now, so maybe I'm reading this out of context, but how does compiler-enforced immutability change this? I'm not asking for everything to be immutable (not even in Haskell is that true) -- I'm just asking for the ability to mark an object as immutable and have the compiler make sure that it isn't modified. I'd prefer that non-local objects be immutable by default, but I'm willing to live with mutable by default. Really, immutable state gives you the efficiency of pointers coupled with the nice semantics of copy-by-value. It's the best of both worlds -- not having it is denying the programmer "the choice to do efficient things".
- munificent 16y ago
  I agree completely. I had a note to discuss that (and globals, eww!) but I cut it because honestly that post was too long already.
seles 16y ago
"Once you have constructors and you can statically ensure that every variable has a chance at initialization, you can start to escape one of the most unfortunate language misfeatures in wide use today: null" Question, can anyone think of a case where the lack of pointers being able to point to null will make it more difficult to implement something? That is will you lose expressivity if this becomes impossible?
- mcobrien 16y ago
  So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values. A better improvement would be to handle null references better - Rails' whiny_nil support is great for example.
  - masklinn 16y ago
    > So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values. These nulls are a different issue than the initialization-originated nulls (that is in fact an other issue with null: they can mean both "I have nothing to put there" and "I forgot to put something there"). > A better improvement would be to handle null references better No. > Rails' whiny_nil support is great for example. whiny_nil exists because you can't do much more in a dynamically typed language, apart from making nil a message sink. Go is not a dynamically typed language, and statically typed language communities have found much better ways to handle most cases where you would use null references decades ago.
- masklinn 16y ago
  The only case is when you want to express data is missing (not that a variable is unitialized, but that there's nothing there, think ternary boolean) and that is very neatly taken care of by option types (ML's `option`, Haskell's `Maybe`) which you can easily replicate via union types (create a type Nothing with a single value `nothing` and replace what was formerly a nullable type `T` by the union type `Nothing | T`; depending on whether you want these to be easy to use or not, you may or may not want to add the ability to lift computations into the option type)
Symmetry 16y ago
Totally agree about Unions, and I think that one of the reasons that nil is there might be because there aren't any yet. I'm not sure I agree about overloading, though. Maybe something like Haskell's infix notation (1 `add` 2) would be good enough.
shin_lao 16y ago
Sorry to nitpick, but one should say "The language I wish Go were"
- sid0 16y ago
  Please read http://itre.cis.upenn.edu/~myl/languagelog/archives/005515.html http://itre.cis.upenn.edu/~myl/languagelog/archives/005515.h....
  - samg_ 16y ago
    The fact that the subjunctive mood really only matters for one verb to me is an equally compelling argument that a) it's not a big deal that people forget and b) people should just remember it.
  - jmulho 16y ago
    The link says: 'As a result, appeals to "preserving distinctions" that are "important for communication" and to "avoiding ambiguity" are baseless and indefensible in this case.' "no matter which form you use, people will understand what you are trying to say." That is simply not true. Case in point: when I saw the title "The language I wish go was" I expected to find an article about google cancelling the go language.
    - sid0 16y ago
      > Case in point: when I saw the title "The language I wish go was" I expected to find an article about google cancelling the go language. I'm not a native English speaker, but I do think my English is pretty good. Care to explain why the plain past form made you expect that? In any case, an article titled "Go language cancelled" would have shown up much before anything else. That's what's generally meant by "context".
    - Abscissa 16y ago
      That would have been written "The langauge I wish Go had been"
- deleted 16y ago
stcredzero 16y ago
tl, dr; This post ended up way longer than I expected. Super science summary: I wish Go had tuples, unions, constructors, no Nil, exceptions, generics, some syntax sugar, and ponies that shoot Cheez Whiz out of their noses. There's always D, if you want more whiz bangs. It's been oft quoted, that good library design involves leaving someone wanting more. I think one form of good language design involves this too. Go is supposed to be minimalist. I think it's a good sign if people keep wishing it were just a little less minimalist.
- masklinn 16y ago
  If you read the post instead of just the funny tldr, you realize that many of the demands would make Go simpler and/or more orthogonal and/or smaller.
  - enneff 16y ago
    Can you flesh that claim out a bit more? I read the post and it was almost all extra stuff that would make the language spec longer, not shorter.
    - grogers 16y ago
      One example was that tuples elegantly handle multiple return values anyways, so you don't need to bother with them if you have tuples (and tuples are good in their own right). Another is that generics already exist in the language - map works even for user defined types. But since you can't make your own generics, map is all you get. With generics map is just a standard library feature rather than a core language feature, and you could write your own containers too if you wanted. These might not make the language spec strictly shorter, but definitely more orthogonal.
      - deleted 16y ago
        [deleted]
  - uriel 16y ago
    If you have actually used Go, you would realize that many of his demands display seriously lack of familiarity with the language. For example, he completely missed defer.
papaf 16y ago
I mostly program in Clojure now and I have only used Go a little bit. However, I really like Go. I have a lot of respect for the people who developed Go. I'm sure in their many years of designing operating systems and languages that the features described in these obvious criticisms were considered. That is not to say the language shouldn't be criticised but, in this case, a little research would have made the article a more interesting read. To take two examples. Constructors are easy to write in GO: http://sites.google.com/site/gopatterns/object-oriented/constructors http://sites.google.com/site/gopatterns/object-oriented/cons... An exception-like mechanism has been proposed: http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4/8bc45b58a32aed25 http://groups.google.com/group/golang-nuts/browse_thread/thr...
- uriel 16y ago
  > An exception-like mechanism has been proposed: Proposed and implemented almost six months ago. But that doesn't stop people from writing criticisms of the language and asking for their pet features after a cursory watching of Rob's original (and very superficial) talk. sigh
  - vilya 16y ago
    Exception-like is not the same as proper exceptions. From what I've read about it (there's the caveat: I haven't used it yet), the error handling model in Go sounds pretty badly broken.
    - papaf 16y ago
      the error handling model in Go sounds pretty badly broken Broken in what way and what have you read? I'm genuinely interested. I don't want to end up doing language advocacy for a language I hardly use, but you seem to be confusing error handling with exception handling - something the design of the exception-like mechanism was designed to prevent. As I understand it, in this approach, errors are things you expect to happen (but are errors) and exceptions are things you never anticipated.
gmaster1440 16y ago
Give ooc-lang.org a try ;)
nickik 16y ago
In general I think he is right but he has to start use D not Go.
SeanDav 16y ago
He mentions BitC. Any comments about this language as I have never heard about it before?
- Avshalom 16y ago
  I don't have a lot to say about it personally but it came up fairly often on LtU http://lambda-the-ultimate.org/search/node/bitc http://lambda-the-ultimate.org/search/node/bitc
jimbokun 16y ago
"Now when you need to read from a file, you just do: ReadFile(filename, func(file) { fmt.println(file.Read()) }); Now you’re safely guaranteed to close the file when the operation is done. This works because Go has lexical closures, a really nice feature. But the syntax for this is ungainly. Ruby addresses this with block arguments. Translated to Go, they could look something like: ReadFile(filename) do(file) { fmt.println(file.Read()) } " He does realize, that all he did was replace "func" with "do", and moved some parentheses around, right? Are there other examples where the difference is more dramatic than this?
- barrkel 16y ago
  Of course he does. And yes, this small syntactic difference does have effects in the real world; rename 'func' to 'delegate', and with the addition of a semicolon (at the end of the println() call) this is valid C# code today - but almost noone writes their resource protection using this idiom because it's ugly.
  - masklinn 16y ago
    > this is valid C# code today - but almost noone writes their resource protection using this idiom because it's ugly. Incorrect (and you don't need delegate, C# has lambdas now). It's because C# doesn't use that for its stdlib and instead has a (redundant) special form and defined protocols.
    - barrkel 16y ago
      It is correct to say that replacing the func with delegate and adding the semicolon makes it valid C# syntax. The correctness of that statement is completely independent of C# lambdas, which are neither a complete subset nor a complete superset of C# anonymous delegates. And it is ugly. It's ugly because the argument list visually expands across more than one line, including whole statements. The "redundant" forms of "using" and "lock" are both more limited than the closure-passing approach, but their limitations haven't been pressing enough to overcome much of tthe ugliness of the closure-as-parameter approach for this specific case of passing a statement block.
vinutheraj 16y ago
The discussion over at golang-nuts, the official mailing list - http://groups.google.com/group/golang-nuts/browse_thread/thread/4ac917c9cf43e529 http://groups.google.com/group/golang-nuts/browse_thread/thr...

59 points by dochtman 16y ago

sid0 16y ago

You know what I wish Go had? Compiler-enforced immutable state. It is inexcusable that a language designed for concurrent programming in 2010 doesn't support immutability [1]. [1] http://groups.google.com/group/golang-nuts/browse_thread/thread/0678c6dcdefb21ca http://groups.google.com/group/golang-nuts/browse_thread/thr...

sausagefeet 16y ago
Someone on the reddit thread argued that because it is CSP you do not need this. The idea being when you send your object down the channel you lose ownership of it. I don't know enough about the Go implementation to know if this is true or not.
- nickik 16y ago
  Normaly thats right but you can pass pointers on a channel you share mutible state. Listen to the go talk at Emergin Languages Camp. Rich Hickey asks about that in the end.
  - sausagefeet 16y ago
    Is there any point where you would want to pass a pointer but NOT because you want mutable state, simply because it's more efficient or something?
    - jpr 16y ago
      Well, pointers have fixed size, random structures may be arbitrarily big and involve a crapload of copying.
jashkenas 16y ago
Rob Pike answers this question directly in the last couple minutes of his Go talk at the Emerging Languages Camp, earlier this summer. I think it's pretty illuminating as to the rationale behind why Go does it the way it does. http://confreaks.net/videos/115-elcamp2010-go http://confreaks.net/videos/115-elcamp2010-go Check out the video, but here's a rough transcription of part of it: "This is a systems language, which means you should have the choice to do efficient things, if you know what you're doing. You shouldn't be told "you can't do that because you might get it wrong." Let me explain. The model for sharing and locking all that stuff is like having a big piece of paper and we all gather the paper and we make notes on it about who owns what, when -- and we scribble and erase and rewrite and work on it. This model is: you don't have one piece of paper, you have lots of pieces of paper. And you write a message on a piece of paper, and you give him that piece, and he goes away, and you don't have it anymore. He'll bring it back to you if it's relevant to you; he won't if it's not. And because the individual pieces are broken up, there's no concern or worry about who owns what at any one time -- it's whoever's got ahold of it at the moment. And once you understand that, it just doesn't come up as an issue, that for efficiency reasons, I want to pass a pointer on a channel, because once I've passed it I forget it. The only person who has it is the person whose business it is to deal with it now. If you're worried about it and you really care: don't pass a pointer, pass a value. Make it a channel of struct, rather than a channel of pointer to struct. It will be a copy, and there's no way you can share it. But that's your decision, not the language's."
- nickik 16y ago
  I think CSP is often good but in a system language you need to share stat and with passign pointer you can only share state unsave. So you copy or you share unsave.
- sid0 16y ago
  > This is a systems language, which means you should have the choice to do efficient things, if you know what you're doing. You shouldn't be told "you can't do that because you might get it wrong. I don't have the time to watch the video right now, so maybe I'm reading this out of context, but how does compiler-enforced immutability change this? I'm not asking for everything to be immutable (not even in Haskell is that true) -- I'm just asking for the ability to mark an object as immutable and have the compiler make sure that it isn't modified. I'd prefer that non-local objects be immutable by default, but I'm willing to live with mutable by default. Really, immutable state gives you the efficiency of pointers coupled with the nice semantics of copy-by-value. It's the best of both worlds -- not having it is denying the programmer "the choice to do efficient things".
munificent 16y ago
I agree completely. I had a note to discuss that (and globals, eww!) but I cut it because honestly that post was too long already.

seles 16y ago

"Once you have constructors and you can statically ensure that every variable has a chance at initialization, you can start to escape one of the most unfortunate language misfeatures in wide use today: null" Question, can anyone think of a case where the lack of pointers being able to point to null will make it more difficult to implement something? That is will you lose expressivity if this becomes impossible?

mcobrien 16y ago
So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values. A better improvement would be to handle null references better - Rails' whiny_nil support is great for example.
- masklinn 16y ago
  > So many I wouldn't know where to start. Databases have had not-null constraints for years, but an accurate model often means having null values. These nulls are a different issue than the initialization-originated nulls (that is in fact an other issue with null: they can mean both "I have nothing to put there" and "I forgot to put something there"). > A better improvement would be to handle null references better No. > Rails' whiny_nil support is great for example. whiny_nil exists because you can't do much more in a dynamically typed language, apart from making nil a message sink. Go is not a dynamically typed language, and statically typed language communities have found much better ways to handle most cases where you would use null references decades ago.
masklinn 16y ago
The only case is when you want to express data is missing (not that a variable is unitialized, but that there's nothing there, think ternary boolean) and that is very neatly taken care of by option types (ML's `option`, Haskell's `Maybe`) which you can easily replicate via union types (create a type Nothing with a single value `nothing` and replace what was formerly a nullable type `T` by the union type `Nothing | T`; depending on whether you want these to be easy to use or not, you may or may not want to add the ability to lift computations into the option type)

Symmetry 16y ago

Totally agree about Unions, and I think that one of the reasons that nil is there might be because there aren't any yet. I'm not sure I agree about overloading, though. Maybe something like Haskell's infix notation (1 `add` 2) would be good enough.

shin_lao 16y ago

Sorry to nitpick, but one should say "The language I wish Go were"

sid0 16y ago
Please read http://itre.cis.upenn.edu/~myl/languagelog/archives/005515.html http://itre.cis.upenn.edu/~myl/languagelog/archives/005515.h....
- samg_ 16y ago
  The fact that the subjunctive mood really only matters for one verb to me is an equally compelling argument that a) it's not a big deal that people forget and b) people should just remember it.
- jmulho 16y ago
  The link says: 'As a result, appeals to "preserving distinctions" that are "important for communication" and to "avoiding ambiguity" are baseless and indefensible in this case.' "no matter which form you use, people will understand what you are trying to say." That is simply not true. Case in point: when I saw the title "The language I wish go was" I expected to find an article about google cancelling the go language.
  - sid0 16y ago
    > Case in point: when I saw the title "The language I wish go was" I expected to find an article about google cancelling the go language. I'm not a native English speaker, but I do think my English is pretty good. Care to explain why the plain past form made you expect that? In any case, an article titled "Go language cancelled" would have shown up much before anything else. That's what's generally meant by "context".
  - Abscissa 16y ago
    That would have been written "The langauge I wish Go had been"
deleted 16y ago

stcredzero 16y ago

tl, dr; This post ended up way longer than I expected. Super science summary: I wish Go had tuples, unions, constructors, no Nil, exceptions, generics, some syntax sugar, and ponies that shoot Cheez Whiz out of their noses. There's always D, if you want more whiz bangs. It's been oft quoted, that good library design involves leaving someone wanting more. I think one form of good language design involves this too. Go is supposed to be minimalist. I think it's a good sign if people keep wishing it were just a little less minimalist.

masklinn 16y ago
If you read the post instead of just the funny tldr, you realize that many of the demands would make Go simpler and/or more orthogonal and/or smaller.
- enneff 16y ago
  Can you flesh that claim out a bit more? I read the post and it was almost all extra stuff that would make the language spec longer, not shorter.
  - grogers 16y ago
    One example was that tuples elegantly handle multiple return values anyways, so you don't need to bother with them if you have tuples (and tuples are good in their own right). Another is that generics already exist in the language - map works even for user defined types. But since you can't make your own generics, map is all you get. With generics map is just a standard library feature rather than a core language feature, and you could write your own containers too if you wanted. These might not make the language spec strictly shorter, but definitely more orthogonal.
    - deleted 16y ago
      [deleted]
- uriel 16y ago
  If you have actually used Go, you would realize that many of his demands display seriously lack of familiarity with the language. For example, he completely missed defer.

papaf 16y ago

I mostly program in Clojure now and I have only used Go a little bit. However, I really like Go. I have a lot of respect for the people who developed Go. I'm sure in their many years of designing operating systems and languages that the features described in these obvious criticisms were considered. That is not to say the language shouldn't be criticised but, in this case, a little research would have made the article a more interesting read. To take two examples. Constructors are easy to write in GO: http://sites.google.com/site/gopatterns/object-oriented/constructors http://sites.google.com/site/gopatterns/object-oriented/cons... An exception-like mechanism has been proposed: http://groups.google.com/group/golang-nuts/browse_thread/thread/1ce5cd050bb973e4/8bc45b58a32aed25 http://groups.google.com/group/golang-nuts/browse_thread/thr...

uriel 16y ago
> An exception-like mechanism has been proposed: Proposed and implemented almost six months ago. But that doesn't stop people from writing criticisms of the language and asking for their pet features after a cursory watching of Rob's original (and very superficial) talk. sigh
- vilya 16y ago
  Exception-like is not the same as proper exceptions. From what I've read about it (there's the caveat: I haven't used it yet), the error handling model in Go sounds pretty badly broken.
  - papaf 16y ago
    the error handling model in Go sounds pretty badly broken Broken in what way and what have you read? I'm genuinely interested. I don't want to end up doing language advocacy for a language I hardly use, but you seem to be confusing error handling with exception handling - something the design of the exception-like mechanism was designed to prevent. As I understand it, in this approach, errors are things you expect to happen (but are errors) and exceptions are things you never anticipated.

gmaster1440 16y ago

Give ooc-lang.org a try ;)

nickik 16y ago

In general I think he is right but he has to start use D not Go.

SeanDav 16y ago

He mentions BitC. Any comments about this language as I have never heard about it before?

Avshalom 16y ago
I don't have a lot to say about it personally but it came up fairly often on LtU http://lambda-the-ultimate.org/search/node/bitc http://lambda-the-ultimate.org/search/node/bitc

jimbokun 16y ago

"Now when you need to read from a file, you just do: ReadFile(filename, func(file) { fmt.println(file.Read()) }); Now you’re safely guaranteed to close the file when the operation is done. This works because Go has lexical closures, a really nice feature. But the syntax for this is ungainly. Ruby addresses this with block arguments. Translated to Go, they could look something like: ReadFile(filename) do(file) { fmt.println(file.Read()) } " He does realize, that all he did was replace "func" with "do", and moved some parentheses around, right? Are there other examples where the difference is more dramatic than this?

barrkel 16y ago
Of course he does. And yes, this small syntactic difference does have effects in the real world; rename 'func' to 'delegate', and with the addition of a semicolon (at the end of the println() call) this is valid C# code today - but almost noone writes their resource protection using this idiom because it's ugly.
- masklinn 16y ago
  > this is valid C# code today - but almost noone writes their resource protection using this idiom because it's ugly. Incorrect (and you don't need delegate, C# has lambdas now). It's because C# doesn't use that for its stdlib and instead has a (redundant) special form and defined protocols.
  - barrkel 16y ago
    It is correct to say that replacing the func with delegate and adding the semicolon makes it valid C# syntax. The correctness of that statement is completely independent of C# lambdas, which are neither a complete subset nor a complete superset of C# anonymous delegates. And it is ugly. It's ugly because the argument list visually expands across more than one line, including whole statements. The "redundant" forms of "using" and "lock" are both more limited than the closure-passing approach, but their limitations haven't been pressing enough to overcome much of tthe ugliness of the closure-as-parameter approach for this specific case of passing a statement block.

vinutheraj 16y ago

The discussion over at golang-nuts, the official mailing list - http://groups.google.com/group/golang-nuts/browse_thread/thread/4ac917c9cf43e529 http://groups.google.com/group/golang-nuts/browse_thread/thr...