People who say Rust is hard are probably skipping on reading the really well written Rust book. I'm not a genius in any shape or form, but I am able to write decent Rust apps just fine. I've written an IRC bot in Rust and am working on a file utility now.
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.
> not a play toy for people looking to write small scripts.
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.
I encourage everyone in this thread to not take things personally. Rust vs. Go conversations are going to cause a lot of angst on both sides. I also encourage people not to assume or read into comments, where someone states that "Rust is not a play thing", they are not implying that Go is.
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.
I did not mean to imply that Go is a toy language. The Go developers are very smart engineers and they made a great language. Sorry if it came across that way. I was more making a point about putting some effort into learning Rust. I did not mention Go anywhere in my comment but I understand why people thought I intended to slight Go. I didn't.
Adding a quick opinion here: I worked for one of these companies (working with libraries written by all of these) and it's just a matter of personal taste. Docker, CoreOS, Hashicorp, etc. are "successful" (which is hard to confirm for now) because they can gather a lot of open source contributions thanks to the easy Go learning curve. I don't think this would be the case if they used Rust instead. Go is definitely not a play toy and you can build scalable and reliable software with it. The problem with Go in my opinion is also its ease of use, it's incredibly easy to write sloppy/buggy code with panics/data races that become increasingly hard to debug. I've had my fair share of frustrating experiences debugging concurrent code with hundreds of goroutines or investigating random data races on complex distributed systems code. I've yet to see that happening with Rust after four months of using it, the compiler does an incredible job at preventing these.
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.
Go is a language that is used to write on top of things. Rust can, maybe, be used to write the things Go are written on top of.
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.
> not a play toy for people looking to write small scripts.
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.
The big thing for me in this regard is not worrying about dependencies (in a lot of cases). With Rust, when someone asks me for a script that does X, I can compile and ship a binary and they run it end of story. With python, I say "ok, now install python version whatever, then install pip, and then pip install all this stuff, and finally run my script"
You could store them as source files with a hashbang, and make something like "rustrun" which compiles a single Rust source code file and runs the resulting executable? That should take ~15 minutes.
"being interpreted" in not enough to have useful repl. You also need to be dynamic and introspectable. There are interpreters for C, but it doesn't make it suitable to use with repl.
there's nothing bad about interpreting a systems language. there are C interpreters available, too. i'd argue it'd be a very useful feature since the compile times of rust are one of its biggest pain points right now.
There is a dead project named `rusti` (fails to build on Rust nightly >= 2016-08-01) that can interpret Rust source, and a newer project named `miri` (last commit 3 days ago) that interprets MIR output from the compiler. Several of us in the community, me included, would like a REPL, so I'd keep an eye on these projects to see if they go anywhere.
I've went through the rust book, unfortunately I learn better through actually trying to do things while looking at the API reference. And the rust documentation is frustrating for that, simply because everything is expanded by default and there's no concise list of functions available.
(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 otherwise
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).
Yeah one of the best things about Go is how familiar it is, you can pick it up and run with it very quickly.
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.
> 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).
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.
I think that focusing on how long it takes to be productive is a mistake, within reason at least. How well does it hold up once I'm knowledgeable with the language matters a lot more. If it takes me 4 days or 3 weeks to be productive, ok, that's fine, but it needs to be a good solution once I'm there, because I'll spend years using it potentially.
The really, really important thing about the time it takes to be productive in a language is selling the language to other people. If it takes 3 weeks to learn enough Rust to make interesting projects, then it's going to be absolute hell convincing a team of largely ambivalent co-workers to use Rust, because 3 weeks is equivalent to months of weekend tinkering. You're restricted to using Rust either when it has mass adoption, it interests your devs, or the domain needs provable safety guarantees.
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.
Do you really want people on your team who think that having to read a free book and investing 3 weeks to learn a new language is too much of an effort?
Firstly, when the initial impression of a language is that it's not fast to code in, people seem to assume that it will remain unproductive in regular use. This is clearly the case with ESR, and is a problem that's relevant to the Rust community in general.
Secondly, as per the Rolling Stones, you can't always get what you want.
Maybe they are spending those three weeks learning something else. There are thousands of things that "every programmer should know" and thousands more that "every human should know", and you will never have time to learn them all.
It may very well be out of your hands. I wasn't able to convince my coworkers to use Kotlin for an android app, even though at the end of the day I was the only one coding it. And Kotlin takes a few hours to pick up if you know Java.
If you've come from an ML background you'd need a good book to be productive in Go, and jump straight into Rust. Go is more C-like which makes it easier to pick up coming from C, not absolutely easier.
Do you have the sources for your IRC bot somewhere? I have a bot written with Ruby in a quite big channel and I have this tendency of writing it with a new language every couple of years. An IRC framework with Rust and Tokio would be fun...
I have the source, but it was more a process of me learning than something intended to be used by others. The source code is not online. It can read from a toml config and connect to multiple servers and respond to commands. It's pretty cool. I had it up at Github for a bit, I can put it back up, but this is an anonymous account so I wouldn't share it from my Github. I'm not sure how to share it. :\
Instead of writing an IRC bot, I have written an IRC client in Rust here: https://github.com/FreeFull/ircclient . Beware, I haven't put much effort into making the code clean or well documented. Writing an IRC bot would be easier than a client, because you wouldn't have to deal with reading from stdin, and you'd be able to keep everything single-threaded. The IRC library I use doesn't have any tokio support yet.
I could see how this statement could be construed as inflammatory, but I don't think he was implying that Go is a play toy. He was implying that you can't make a judgment on the language based on making play toys (the toy IRC client mentioned in the article).
Yes this is correct. I do not in anyway think Go is a toy. It's a fine language. I love kubernetes and it's written in Go. A lot of people took that statement to mean that I thought Go is a toy and I didn't mean that, so I apologize.
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.