[Maro]

Thanks for the link, I upvoted you.

I'm a C++ systems programmer, so I'm trying to understand some of the issues here. I'm not familiar with either language, please forgive the ignorant questions.

Null: Why is null evil? Doesn't Go use it in the Java sense of releasing a reference to the object?

Global GC: Seems more like a runtime implementation choice?

Shared mutable state: Doesn't seem so bad for someone approaching a systems programming language. I don't always want to make copies and send it over as a message to the other threads?

My higher-level point is that, perhaps these languages could do a better job of selling, differentiating, explaining themselves. I know it's hard, that's why I'm trying to help by posing my stupid questions. Btw. if they're planning to write Firefox in this, maybe the author should maintain a minimal browser written in Rust to show how the language fits its original design goals.

[pcwalton]

Note that we don't forbid shared mutable state entirely (we don't forbid anything really, as we have an unsafe sublanguage that allows all the pointer tricks that you can do in C++), but we want to contain data races. Basically, as the FAQ says, "you can break the rules, if explicit about where and how".

We've learned that, especially when it comes to concurrency, there really is no one model that supports everything you might want to do. Instead, the idea is to support safe, data-race-free language constructs, and to make those the easiest ones to use. Data races (and memory unsafety) are clearly marked in "unsafe" blocks, with the idea that if you find a concurrency bug in your software, you can grep for that keyword and go over those blocks only, instead of having to crawl through the entire codebase.

The same principle applies to null. You can get nullable pointers (use option<T>), but you have to declare that that's what you want. You also have to declare some strategy for handling the null case every time you use the pointer, or at least communicate your intent to fail on null via the .get() method. The vast majority of pointers in any program aren't nullable, so in practice we've found that this eliminates a lot of bugs.

[tomp]

Null: Null is not evil, but programmers often fail to take it into account. If you see type `string`, it might not be immediately obvious that you can get either a `string` object, or `null`. It could be useful (for preventing bugs and for speed) to have different annotations for nullable and non-nullable variables/parameters (e.g. `string?`, or `string | null`, or `union(string, null)`).

Global GC: It's hard to do GC without stopping the world. If different threads have different heaps, only a single thread needs to be stopped at any given time for the GC to be performed (on this thread's heap). AFAIK, Rust also supports manually managed references.

Shared mutable state: I believe that is more of a language restriction, not VM (i.e. sending messages could be implemented without copying). Simplifies debugging and makes some abstractions much easier (distributed computing in particular).

[sanxiyn]

Null is evil because it forces programmers to constantly check for null when compilers can do that much better. There can be situations when null is handy, but it shouldn't be the default. C++ reference can be used for similar purpose.

Global GC is definitely a language issue. It affects language semantics.

Avoiding shared mutable state does not mean making copies. If you can statically check there is no other reference you can avoid copying. Think advanced move semantics.

[eli_gottlieb]

Null is evil because any pointer could be null, and the semantics of dereferencing a null pointer are either NullPointerException or just plain undefined.