Hacker News Reader

> There's a good argument for immutability by default, but many programmers dislike all the extra declarations required.

That's one little reason why Rust is loved by many: immutability by default. Meanwhile, it's not even possible in Go to declare immutable variables!

I hope it gets added, it adds so much safety to the language. Mind you, Go is not a very safe language in general, its type system is pretty loose compared to e.g. Java or Typescript. I don't believe it wants to be though.

It is possible to add more immutability in Go. There are many proposals for this: https://github.com/go101/go101/wiki/Go-immutable-value-propo....

The main reason nothing happened in this direction is the core team think it is not important enough.

It's tough to retrofit new restrictions to old code. C/c++ code still doesn't have "const" everywhere it could. You have to make the default immutable - write "var" or "mut", not "const" - or it doesn't get used everywhere it should. But that breaks old code.

It's very clear that the reason these kinds of proposals haven't been accepted has nothing to do with the core team not believing they're important enough, but instead because of the impact that they have on the rest of the language.

What impact in your opinion?

Immutability is a fundamental property of a language, it's not something that can be bolted on post-facto in a version update. Go as a language doesn't provide immutability.

If the "for ;;" loop semantics can be bolted on post-facto in a version update, nothing else couldn't.

Go provides certain immutability.

It does not. Believe what you will.

You are not familiar with Go.

Immutable by default is only really possible now that we have gobs of memory though. I'm not even sure it's likely to stay popular: the demands of data processing at scale mean we're all likely to be routinely handling gigantic datasets which we don't want to copy all over the place.

The real problem is just visibility: am I editing a copy of the original? Who else can edit the original? Who's going to?

I'd argue those two questions are what we actually want to know the answer to, and immutability criteria are just an awkward compromise solution.

Immutable by default doesn't mean you have to write your program as a giant copy-aon-write or log-structured architecture. You can still commit all your shared global program state behind a mutex/rwlock crimes when that makes sense. But you can contain write access to that data to the places where it's needed.

And at the function-local level move elision should turn copy-and-modify to in-place modification if the original is no longer used.

"Immutable by default is only really possible now that we have gobs of memory though"

I don't think so, actually. It's just changing the default. A choice to have types like Java's String which are always immutable might drive up memory usage, but just realising that the defaults are wrong and altering the language doesn't impact this at all, instead it makes your programs more explicit about what's actually happening.

Immutability isn’t a new idea, and you don’t need “gobs of memory.” Erlang was developed in the 80’s.

LLVM will transform your mutable program into immutable one anyway because otherwise it's much harder if not impossible to write a lot of optimizations or validations.

You can collapse a lot of the additional copies at compile time even for C

That's not really the same thing though - that's a choice of representation for optimization purposes. LLVM won't turn a pointer access into a value copy - it can't, because that would change program behavior.

The distinction here is that in a lot of cases, you really do want to edit data in one location and there's no good reason for it to be copied except that it makes the program easier to reason about (exceptions apply for when things like cache locality considerations come into play).

I seem to recall that in many cases it is in fact permitted for C compiler (probably C++ as well) to turn pointer access into value copy so long as the rather flexible semantics are still kept.

The main saving grace is that usually you're only dealing with register copies...

The killer IMO is the combination of mutability and implicit references. With either immutability or explicit references, the hazards are greatly lessened. In the absence of mutability, there's no observable difference between passing a reference and passing a value. With explicit references, there's always an indication when objects are liable to nonlocally mutate.

Go and C are quite wise to use pass by value and opt-in references. It avoids the programmer's burden of immutability by default while making it more obvious* when to be aware of potential mutation. A programming style incorporating local mutation also comes very naturally, which is simple, practical, and remains easy to reason about.

*Go and Rust would be wiser if they retained -> from C so that this obviousness would remain without having to check type declarations which may even have been inferred.

Python gets hit the worst by this combination. On top of having mutable references everywhere, it also doesn't make a big deal about object identity (unlike e.g. Java) and has a lot of declarative constructs. Which means you get surprising stuff like this.

  >>> foo = [[]] * 10
  >>> foo[0].append("bar")
  >>> foo
  [['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar'], ['bar']]

  >>> def baz(arg = []):
  ...   print(arg)
  ...   arg.append("qux")
  ... 
  >>> baz()
  []
  >>> baz()
  ['qux']

The one thing I’ve personally wanted in Go is something like final in Java, for structs.

Well, that's another nice thing with Rust. Maybe it's not the saviour language but at least it brings clarity to ownership of values.

I think the same thing could happen in Rust. foo.x = bar will compile if foo is a copy or if it's a mutable reference. As in Go, you'd have to explicitly type 'foo' in order for any compiler error to show up.

Let's work through the example

1. There's a user-defined type named Thing with a String inside it.

2. We've got a function named findThing, which takes an array of Things and a string name, performs a linear search of the array and returns a mutable reference to the Thing with that name or if it's not found it doesn't. In Go, this function accidentally gives back a mutable reference to a copy of the Thing.

3. We make an array of things, use findThing to find one of them and try to mutate it.

We can translate 1 into Rust easily, it's just struct Thing { Name: String } and the compiler will moan because this is deeply unconventional naming in Rust and that warns by default.

We can translate 3 into Rust easily too, the compiler moans about our naming again.

But when we try to translate 2 by writing findThing we struggle. Rust wants to understand what lifetime to associate with this mutable reference we're returning. If we try to make a copy, where does the copy live? Rust doesn't have garbage collection, so if it just goes out of scope the lifetime ends and Rust will reject this function as nonsense - you can't return references which have expired, silly programmer, try again.

If we don't make a copy we can successfuly tie the lifetime to the array, but then we don't have the Go bug, so the thing you say "could happen in Rust" doesn't happen.

Here's a Godbolt link for a working example: https://rust.godbolt.org/z/shKj6rEz7

Now, try to adjust it to have the same bug, I expect it will be much harder to do this wrong.

Ah, I was working on a mistaken assumption about the Go example code (I thought the function returned Thing, whereas actually it returns *Thing). That will teach me to RTFA...

Right, I think Julia would spot that if we get a Thing back, it's clearly not the Thing inside our array, because those are necessarily different Things.

If the function does return Thing, in Rust we can implement the mistake, returning a copy, but there's no plausible way to implement the intended functionality, we can get the matching thing out of an array we're allowed to mutate -- by swapping it, but now some different Thing is in the array of Things instead, that's what swapping means. If we're given the actual array, not a (mutable) reference as a parameter, we can destroy it and keep just the matching Thing to return, but now our caller hasn't got a Things array, it was destructively moved to give us a parameter.

Actually Go is always pass by value. Even when you pass the pointer you’ll get a copy of it.

What matters is that a function can modify the value pointed at, without necessarily returning it.

That is no different than C or C++. A pointer is just another type of value.

> Actually Go is always pass by value.

False, this depends upon the underlying type. The Go 'map' type is always pass (and assign) by reference.

https://go.dev/play/p/ovfuNBNtiza

No, it's definitely passed by value:

https://go.dev/play/p/mIehOwUWz95

A map is implicitly a pointer to the underlying map structure. When you pass a map, you're passing a copy of a pointer.

Technically no, but I get why it feels like this. :-)

I think the confusion stems from the fact that Go hides the distinction of "dot" access vs "pointer dot" access. (eg, the difference between `foo.Bar` and `foo->Bar` in C++). Go knows if an object is a pointer and needs to be de-referenced, and hides the de-reference operation from you syntactically. So you can use a pointer without knowing it's a pointer.

This is the confusion: You never have a "map object that is passed by reference", you instead have a "pointer to a map object that is always passed by value".

This is less confusing for structs the programmer defines themselves, since they can check the type of "foo" see if "foo.Boo" is accessing Bar directly or de-referencing "foo" and then accessing "Bar".

But it's more confusing when applied to builtin type for which you never see the implementation. How would you know if `map[string]bool{}` returns a value or a pointer? You don't!

The map type is passed by value but its implementation is that it is a thin wrapper around a pointer to a struct. Ergo in practice it feels like passing by reference. But Go is technically always pass by value. Map does not get any special implementation in the language.

You can do this yourself. `type MyStruct struct{ data *MyType }`. Now if you pass MyStruct by value, any operations on it are effectively by reference since all operations have to dereference `data` to get at the actual content.

(Same goes for strings, except they are immutable so no one notices.)

This might feel like semantics, but it's important to remember that Go doesn't treat any of those built-ins with special "pass by reference" rules. Instead, it's behaving consistently like it would for any types you defined yourself and one of the learning curves of the language is to think in Go's terms of pointers vs non-pointers and learn which native types are pointers. If you think of it that way, learning Go's built-ins is no different than learning the API methods for a custom struct Go's built-ins just happen to be, well, built-in and thus get syntactic sugar that your custom structs do not.

"Pass by reference" is usually used to refer to the case where you use a value at level N of the call stack, but the code at level N+1 of the callstack decides to make it a pointer. In Go this never happens, instead you technically always had a pointer the whole time!

From Google's Go project blog:

> Map types are reference types, like pointers or slices.

https://go.dev/blog/maps

Did you read my comment?

References are nothing special, they are are simply pointers that hide the pointer and usually the receiving definition makes the decision about whether a pointer of a copy is passed.

In Go the type is just a wrapper around a pointer, making it function like a reference in all cases.

In go some types are simply defined as pointers, so they are technically always passed by value and there is never any magic about whether they are passed by value or referenced. It is always a value consisting of a reference.

A map is a pointer that is passed by value, along with slices and channels. 100% of the time.

Actually, here's an example of precisely why maps are not passed as references:

https://go.dev/play/p/-mEeg2Ud68V

This example cannot re-allocate the original map! If the map were truly passed by reference, it could be allocated in a local function. But it can't, only values within the map can be modified when a map is passed.

This is in contrast with pass by reference in, say, C++, in which case you can assign directly to and modify the reference. ex: https://www.ibm.com/docs/en/zos/2.4.0?topic=calls-pass-by-re...

> This led to classic bugs where the function returns a pointer to a local value. Compilers now usually catch this. C eventually got structure return by copy. Then C++ added return value by move, and automatic optimization for that.

Jesus Christ. Can we now get “return fruit by vegetable?”

Some speedups may not be worth having to memorize standards documents.

programmers who get the job done without needing to memorise standards or dig into hardware specifics are surely happy enough with general optimisations applied by the compiler like tail call optimisation or copy elision ...

not complicated stuff to understand, and doesn’t even need to be understood to use correctly. Just don’t return pointers to locals.