[jacmoe]

Because they are not competing with another! :)

Taken from Dave Cheney's https://dave.cheney.net/2015/07/02/why-go-and-rust-are-not-c... ->

"Rust competes for mindshare with C++ and D for programmers who are prepared to accept more complex syntax and semantics (and presumably higher readability costs) in return for the maximum possible performance. For example, micro controllers, AAA game engines, and web rendering engines."

"Go competes for mindshare in the post 2006 Internet 2.0 generation of companies who have outgrown languages like Ruby, Python, and Node.js (v8) and have lost patience with the high deployment costs of JVM based languages."

[pjmlp]

With a sub-millisecond GC pauses there are many overlapping use cases.

For example, while you might need Rust to target a PIC or a ESP-32 class processor, Go will run perfectly fine on a ARM Cortex-M3 which also has hardware vendors selling Java compilers, e.g. MicroEJ OS (http://www.microej.com/).

[pcwalton]

GC pause time is not the only criterion, and focusing on it to the exclusion of all else is problematic.

I used to have to explain this in a HN comment every time it came up, but now Mike Hearn has written up [1] better than I ever could, so I can just link there :)

[1]: https://blog.plan99.net/modern-garbage-collection-911ef4f8bd...

[pjmlp]

I agree, but still Go can be usable in quite a few scenarios.

Sure it has quite a spartan type system and I would rather use something else for my own work.

On the other hand, as an ex-Oberon user I am aware of many use cases that Go can easily fulfil and like to make people aware of it, more Go less C is good.

[blub]

There are many things that are not AAA games, browser engines and micro controllers where C++ is used and where the Rust community would like Rust to be used.

Rust and Go might compete in that area, assuming that Go programmers will have interest in such projects.

It's not in the interest of the leaders of each community to admit that though.