I guess people compare Rust and Go because they were released in similar timeframes and people like to view things in competition.
Rust is especially attractive when you can't afford a garbage collector, need deterministic destruction, and full compatibility with C. It's what C++ would be if it could start from scratch.
I think your point needs to be re-iterated more often: if garbage collection and ~2-3x the running time of C is not a problem, OCaml, Haskell, Scala, F#, etc. are the competition of Go. They integrate modern (read: mostly 70ies/80ies) language design insights, while providing approximately the same performance as Go.
Instead, we get an alternative to unsafe, native and safe, scripting languages without most advantages of the best of either. I might still try it out if I do a comparative evaluation of modern work. By that time, it might have gotten better.
I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012.
3 years is pretty big difference.
Of course, but Rust has been in tech news for a while already. E.g., the Rust 0.1 post garnered 82 comments[1], over 3 years ago. Rust seems to be first mentioned in a submission title 5 years ago.
Of course, their inception was not exactly at the same time. But if we look back in 20 years, it's the same timeframe. Just like e.g. Python and Ruby, despite being 4 years apart. Or C and Pascal.
It's not fair to Rust to compare it to Go, as if they are at the same stage of their adoption and development. Several years is makes a big difference in the tech world.
It seems ridiculously reasonable to compare programming languages on the time-scale of modern computing (~70 years). Dismissing the comparison like that is pretty crazy.
However, don't get me wrong: I totally agree that the years between the stable releases of the projects makes a big difference, especially now, while it is such a large percentage of the total lifetime of them.
People get bent around the wheel all the time with the tiny niches but both seem well equipped for writing user land applications and are designed to be safer than C and it's cousins. Both have some legitimate interest in them which is what really differentiates them from like D or Ada. Neither is going to be used for kernels (maybe I should say 'serious kernels') and drivers any time really soon. They have a lot of similarity in those regards.
Seems like a golden era to have 2 competing languages that are aiming at C and C++ and have legitimate community interest.
Whenever Go is mentioned, Rust has to be mentioned somewhere in that same thread. And vice versa. It's practically law.
Perhaps a good indication that the debates tend to be more fashion-driven then about technical points (when the discussion is about new languages itself, that is of course reasonable though).
They also planned to attract C++ programmers, but they've basically been attracting dynamic language programmers instead. Why that was a surprise is beyond me--I can't imagine that anyone currently using C++ would be OK switching to a garbage collected language.
Rust on the other hand, is shaping up to be a C++ replacement.
Sure you can do embedded development with the .NET micro framework because there are embedded systems that don't have hard real time requirements.
If you're building a hobby robot with netduino, you might not care if you have guarantees about input response time--as long as the delays are usually small enough. But if you move beyond that, you're most likely going to need a real time system.
http://www.atego.com/products/atego-perc-pico/
As a language I am not a fan of Go, but on the context of using strong type languages in embedded scenarios. I think the less C the better.
Just like JavaScript JITs, it is always a matter how much companies are willing to invest to improve the quality of the existing eco-systems.
So sure, if you want to use go syntax and build a completely new runtime designed for use in real time systems then go ahead.
As for strong typing in embedded scenarios Ada's been doing that for decades.
That seems like another variable to consider if you're in an environment where you have to somewhat control how much memory you use. But I don't know really know anything about the details of garbage collection, I just figured that that would be one of the trade-offs. So correct me if I'm wrong.
[1] Or whatever technique is used
Just because someone uses Node.js to build a hobby robot, doesn't mean that many people are using it for production embedded systems. If your systems has hard real time requirements, which many systems do (even many hobby robots), a stop the world garbage collector is out of the question.
Let's say you have a legged robot that depends on interpreting sensor feedback to keep from failing over. What happens to your balance when the garbage collector pauses your code for 10ms?
There is some argument that using systems programming the way it is used today is a relatively modern convention. Here is a hacker news thread where this is discussed a bit
Here's a quote from the announcement talk
"And it's a systems language in the sense that we intend it to be used to write things like web servers"
How modern is modern CS?
I took my CS degree around 20 years ago with focus on computer architecture, compiler design and distributed systems.
Distributed systems literature used in the degree went back to the early UNIX days.
The creators of Go were on the team that built UNIX, and they clearly have a different meaning for the word systems.
They were using it to refer to infrastructure, without making a distinction whether it was distributed or local. Something like a compiler would be "systems" program under this definition.
I agree that distributed systems, and systems programming are generally accepted terms of the art in CS now, and even 20 years ago.
Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.
Additionally, they can do what PL/S and certain Ada's did where specific modules were transformed by the compiler differently based on their needs. One might have total safety, one no safety, one a GC'd runtime, one a non-GC runtime, and one no runtime at all. Still using the same language and tools for everything, albeit subsets in some modules with extra worries.
Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right?
On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere.
All the other modules enjoyed access to an OS wide GC.
Closest thing I've seen in a modern product is Azul Systems' Java processors with concurrent GC's. So, at least one company is benefiting from the old wisdom.