IMO this tone or slights against Go will hardly endear Rust to people. Rust's superiority should stands on its own. Not just you I have seen this sentiment many times by Rust enthusiasts on reddit and elsewhere.
Go already has successful companies like Docker, CoreOS etc literally built using Go. There are 100s of companies using Go productively. Very large software like kubernetes, docker, etcd are written in Go and they are not toy scripts.
For some people who've spent the time with it, Rust is a godsend, but that does not mean that by believing so they implicitly hate Go in anyway.
Go clearly has a lot of people who love it as much as people who love Rust, and because they overlap, there will constantly be a conversation of which language to pick for cases where it looks like both could be used. As such, the learning curve for Rust will always be an impediment, to its adoption, which is sad, b/c in all my experience it's the only language that I've used which inherently answers every core issue or fundamental bug that I've encountered in my career. This is why I'm really excited that the Rust core development team has decided to focus on development experience heavily this year.
While Go's frustration often comes from debugging sloppy concurrent code, the frustration with Rust is often about having your code to compile. But once it compiles, it runs beautifully. Some prefer the former, I personally prefer the latter. Also, I think the argument of increased productivity with Go should not be the main argument, because the time you save writing a large program, you will probably lose trying to debug a deadlock (which could still happen in Rust but harder to make happen) or a random data race that the race detector couldn't catch (or in a vendored library).
If I had to define the experience with both languages, Go is the instant gratification option, you feel productive quickly, the language is easy to learn with a forgiving syntax sometimes at the expense of correctness. Rust is the delayed gratification option, frustrating at times, very hard to learn and master but offering strong safety guarantees with an elegant syntax (which is a personal opinion).
Also it's a controversial topic in the Go community but the lack of generics...
Rust has its downsides too, for example the slow compile times or the lack of maintained libraries for some core functionalities but overall, programming with Rust is a much more enjoyable experience once you start getting ahead the learning curve.
One last thing: It is hopeless trying to learn Rust in four days without very good resources/books. I recommend "Programming Rust" from OReilly if you really want to dig into the language. It's incomplete at the time of writing but still one of the most useful resource out there (with the free Rust ebook). My knowledge of Rust dramatically increased after reading it and I felt much more confident writing larger programs.
This sentiment (or slight) is the same as always said of C and C++, that they are used to make real things (systems and infrastructure, foundations), and the sentiment (and slight) is there because there's a lot of truth to it.
Which language was used to write our *nixes, windows, the biggest web servers (apache, nginx, IIS), haproxy, mysql, postgresql, oracle db, etc, etc? C/C++, of course. What else?
Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C). You can write, what's essentially just automation tools, like this in any language.
I don't think what you write in this post is a testament to any strength of Go. If currently there exist a testament to its strength it must just be the fact that it's used; adoption rate/popularity, although I have not seen the numbers.
That's actually a perfect example of "systems programming", in the true sense of the phrase. And it is done in Go, because it can be done in Go.
Docker and CoreOS are not really successful companies...it's hard to say if any of the companies in that space will be successful.
That's actually a reasonable beginner's use for Rust though [0]. It's easy to do and will expose you to enough of the language to be a learning experience, but not so much that you could get badly stuck. And the benefit is that it's a lot easier to share binaries than it is to share scripts that rely on a particular interpreter being installed.
[0] http://www.chriskrycho.com/2016/using-rust-for-scripting.htm...
I do wish there was an actual Rust interpreter.
(In my case, I wanted to print out the name of the executable. Having to convert OsStr to something I can print, I understand - the filesystem encoding can be different from the console encoding. But it took longer than it should to find a path between the two.)
I never had to print an osstr yet but it seems fairly straightforward when looking at the docs? There are three obvious functions one could use, each for different use cases: https://doc.rust-lang.org/std/ffi/struct.OsString.html
os_string.to_str() // returns Option<String>
os_string.to_string_lossy() // returns Cow<String>, replacing illegal characters
os_string.into_string() // returns Result<String, OsString> - String if the data is valid, stays OsString for error handling otherwiseI'd be better doing it in another language, I'm doing it mainly to keep getting familiarity with the language.
Do you need to read a really good Go book to be productive in Go? If not, I think the OP's point stands, no?
There are certain languages which are different enough from traditional semantics to need an explanation. While others are similar enough to be "obvious" if you've used a semantically similar language before.
To give a specific example, Powershell. It is semantically a very different scripting language from almost anything else in the market. Extremely well designed and powerful, but you'll want to sit down and read an actual book on how it works to get to handle on it because you won't have the mental map already to do so.
Overall this is why the programming language market is so predisposed for new languages looking and feeling like old languages. People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).
One of the best things about Rust is that it's a paradigm change, it takes time to get your mind around it but it is worth it if the language fits your use case.
I'm not sure that's fair. It seems more likely that people who choose "boring" languages do so because they have things to build, and want to pick a language with a good risk/reward value. Not out of some academic interest or comfort calculation.
On the other hand, if someone can pick up Go and produce a side project with two weekends worth of messing around, they're much more likely to be supportive of the language.
Obviously this isn't ideal, but I don't know how you'd fix the problem.
Secondly, as per the Rolling Stones, you can't always get what you want.
It's strange the short term focus that is accepted in what are nominally professionals.
> Rust is a systems programming language with a focus on security and performance, not a play toy for people looking to write small scripts.
If you're suggesting Go is a play toy, you're wrong.
It took me longer than 4 days (almost two weeks) to just read the rust book (part time), so yes you're not going to get from 0 to 100 in just four days. If that's your benchmark, how fast you can get going, then you're right Rust isn't for you. But nobody would expect anyone to get up to speed with C++ in just four days.
Rust is a systems programming language with a focus on security and performance, not a play toy for people looking to write small scripts.