Just because the compiler may not compile to something doesn’t mean the programs it cross-compiles to it don’t work with full support, quite often it’s just a lack of platform primitives that a compiler needs like a filesystem or dynamic memory or so. 
If something is in tier 2 or tier 1, you can be guaranteed it will work or it is a major bug, and to those ends those are all quite well used platforms. At the absolute worst case you can compile rust to base machine code without using any stdlib and as long as LLVM can compile to that arch then rust likely can too. Rust does not do undefined behaviour in safe code, hence why if you stick to safe code you can be assured the program will work if it compiles as you programmed it or it is a major bug in the compiler itself and should be reported.
Heh, that’s the thing about it, using a GC is a major mistake and prevents Go from being used in a lot of areas, but its too far in to change it now, hence that’s the issue. ^.^
Ah but this is a great example as to why both Elixir and Go are not very opinionated, or rather they are opinionated in the wrong ways. Especially with Go the ‘opinionated’ nature of it has to do with design and nothing to do with safety or maintainability, and this is why every project I’ve PR’d to so far gets Interface{}'splosions everywhere with crashes half the time (hence the PR’s). Even Kubernates was the prime example of Go being such a bad language that they actually built a new typing system on top of it just to get it manageable.
In comparison, Rust is extremely opinionated, but it’s opinions are to force you to write code that actually works, it doesn’t care much about your design or what you want to write, only that what you write won’t crash because of poor coding but rather that is only possible because of explicit, not implicit, decisions by the programmer themselves. Go’s error surface is utterly ginormous compared to Rust. Elixir’s is as well though that’s primarily owed to its dynamic typing, the OTP helps buffer that a lot.
Eh, both Go and OCaml have GC’s, thus they will never be suitable for microcontrollers regardless of the optimizations that they have. At best if you could pre-alloc all memory needed before hand as a static chunk and could keep it highly constrained to that then it would help, but you are still losing efficiency on the memory handling and it will eat up extra memory overall. Like OCaml is significantly more safe than Go, programs you write in it are like rust in that you can be pretty sure they are stable (Rust is more stable though I have to admit), but the GC adds significant overhead that cannot be ignored at the small scales.
If you have a language that can actually choose the machine code it outputs in detail, then you have a language that can do absolutely everything in some form. That doesn’t mean choice is bad, and they have been very good at choosing the libraries that work the best of a given ecosystem to bring in to the stdlib, but if Rust got a builtin, say, good transaction based memory synchronization across threads model, do you really want that to mean that the Actor model (Elixir’s model) should be disallowed (as an aside, Rust has a fantastic actor library called Actix)? Choice is good. I do agree though that there should generally be one obvious choice for a given purpose, and in Rust that was more fuzzy in the past due to how new it was but most areas are very well set now. Even just recently a multitude of Rust game engines have just recently been coalescing around the gfx-hal library for the rendering backend and thus it has become The Standard for the GPU interface layer (gfx-hal is really cool actually, it supports Metal, Vulkan, DX12, and OpenGL (mostly, webgl is still needing more work), and it exposes a vulkan-like API that works with them all very efficiently, it’s kind of like bgfx in the C++ world but far better made and very used now).
But nah, the standard library has all the usual containers very well optimized. Of course there are use-case-specific-optimized versions like statically sized vectors and so forth as libraries but in general the stdlib has what you need.
C++ is a…special case, it’s standard library did not have the advantage of looking at others at the time to know what was good design, and hence why libraries out there tend to do better than the standard in almost every way. Rust, like Go, does not have that issue.
Proper editor/IDE support does not make a 4-deep embedded loop with Interface{} 'cast-and-pray’ing any cleaner though (yes that was one of the PR’s I had to fix up because that code had a bug 
). ^.^;
