Edit: For clarity, I'm not saying Go is the best choice. But when Lua, Python, and Java are in the running, it's surprising that Go wasn't. Especially when the article calls out the learning curve of Rust as a downside.
Just a heads up, this is not from the bitbucket team. That's just where it's hosted.
Not sure why bitbucket is promoting this particular guest post.
concurrency, not parallelism, and even there it doesn't have anything similar to immutable data structures or java.util.concurrent or System.Collections.Concurrent
> support for safety
Not more than any other available GC'd languages.
> some things really can't be done without efficient GC, and Go gives you that
Only if you care about pause times at the expense of throughput, and you don't have to deal with very large heaps
> We needed a language that was fast enough to allow minimum real-time latency and use limited resources of a SoC device.
It sounds like the evaluated their options, added in a few that they were never really going to consider anyway, came to the conclusion that C++ was best but then made up some reasons to use rust anyway.
It has support for concurrency, not parallelism.
> and safety
It's not any safer than other GC'd language available today, and likely quite less so compared to languages with immutability and proper persistent data structures in them (Scala, Java, F#, etc.)
Goroutines are scheduled on different processors, and do run in parallel.