5 ms·

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 im

by 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".
- barrkel 16y ago
  The rationale "You shouldn't be told 'you can't do that because you might get it wrong.'" applied to language design is always suspect. Almost all features added to languages above raw assembler are there to prevent you from doing things that you might get wrong. The flipside of that is having particular syntax that lets you opt in to doing the potentially dangerous thing. Safe by default, dangerous by responsible choice.
  - InclinedPlane 16y ago
    More to the point, a languaage that doesn't provide the tools to manage when, where, and what "dangerous choices" you make is much less worthwhile than a language that does. C#, for example, doesn't let you modify objects passed in as parameters, unless you highlight that behavior on the method signature and the call itself with the appropriate keywords. There are many other examples in many other languages. "Do what you want, use convention to keep safe" is a recipe for trouble that has caused innumerable very serious defects in software (buffer overflows, security vulnerabilities, etc.) "Do what you want, and you have all these tools to keep track of it" is a much better choice, even if in the end the code does the same exact thing. Banking on humans not making mistakes is not robust.
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.

by sid0 16y ago

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".
barrkel 16y ago
The rationale "You shouldn't be told 'you can't do that because you might get it wrong.'" applied to language design is always suspect. Almost all features added to languages above raw assembler are there to prevent you from doing things that you might get wrong. The flipside of that is having particular syntax that lets you opt in to doing the potentially dangerous thing. Safe by default, dangerous by responsible choice.
- InclinedPlane 16y ago
  More to the point, a languaage that doesn't provide the tools to manage when, where, and what "dangerous choices" you make is much less worthwhile than a language that does. C#, for example, doesn't let you modify objects passed in as parameters, unless you highlight that behavior on the method signature and the call itself with the appropriate keywords. There are many other examples in many other languages. "Do what you want, use convention to keep safe" is a recipe for trouble that has caused innumerable very serious defects in software (buffer overflows, security vulnerabilities, etc.) "Do what you want, and you have all these tools to keep track of it" is a much better choice, even if in the end the code does the same exact thing. Banking on humans not making mistakes is not robust.

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.