Go is significantly more popular than Rust. But if what you want to learn is a popular language, you shouldn't be looking at either Go or Rust.
Disclaimer: I'm a Rust developer.
In the same spirit as https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
Go is not a very complicated language. The main difficulty of writing a Go compiler would be to write the garbage collector, but you can easily skip that part by not collecting any garbage :)
1. How to manually manage memory more safely with aid from a borrow checker. 2. If you don't already have experience with an ML/Haskell descent language, it will teach you about more powerful static type systems. 3. General low-level programming concepts that you wouldn't know without experience in C/C++.
Whereas Go doesn't really have much to teach you. The community says it themselves: Go is a very simple language. Even if you needed to learn it for a job, onboarding new workers onto a Go project is really easy. So I don't think you'd add much to your resume just by tacking Go onto the list of languages you know. What Go can teach you about:
1) CSP - Communicating Sequential Processes. I believe this is the concurrency model behind goroutines and channels. But you can learn about CSP in other languages.
Besides, C++ is still the big player, more than all others. Even Apple's new language Swift is written in C++. It's a good language to know something about.
It also sets you into a different category of programmers, from what I have found recently, since C++ techniques are not taught much in college programs any more (based on my conversations with recent CS grads), which really surprises me. It's a special skill that would set you apart if you know it.
What is interesting is that with the release of Java 8, a lot of Scala early adopters and cutting back their investment in Scala in favor of Java (for exampled LinkedIn). This is despite the fact that Scala is widely used in production, has a killer app in Spark, and allows pretty seamless use of the Java library.
Now compare this to Rust. Rust also provides an 'improved' language in the same space as C++ utilizing LLVM. However, what is interesting is the nature of the improvements. The biggest feature of Rust is the memory safety. However, the memory safety is not a productivity improvement as more of a safety improvement. Unlike garbage collection where you just do not have to think about memory allocation issues, Rust forces you to think about ownership and mutability. That same exact thinking will allow you to pretty much get the same memory safety in C++ using unique_ptr and shared_ptr and const. The difference is that the compiler makes you think about it in Rust. Much like Scala inspired the adoption of features for Java, you can see C++ adopting pretty much the borrow checker as a tool - see Herb Sutter's talk at CppCon 2015 - https://www.youtube.com/watch?v=hEx5DNLWGgA .
As the experience with Scala shows, the adopted features of the established language do not have to perfectly match the 'improved' language to convince people to migrate back to the established language. The adopted features just have to be in the ballpark. I think the new C++ tooling will be in the ballpark in much the same way that Java 8 is in the same ballpark as Scala and remove much of the impetus for moving to Rust from C++.
In addition, Rust is not as well positioned as Scala. Scala is actually deployed in production and has a killer application. Rust has no major production deployments of which I am aware and no killer application (the equivalent of Spark). In addition, while Rust can interface with C libraries, Rust cannot interface with C++ libraries unlike Scala which can interoperate with the Java standard library.
Rust has some brilliant aspects just like Scala has some brilliant aspects. However, C++ (like Java) is not sitting still but has been incorporating the best ideas. In addition, when people choose a system language, they are inherently conservative because the system they are creating will typically be long lived and mission critical. If you are writing something that you hope will power your company for the next 20 years, do you want to go with a language created and driven by Mozilla with no major use in production, or with the language that powers Google, Microsoft, Apple, and Facebook?
Here is what I recommend. Learn C++11/14/17. Learn Haskell to really open your mind to what is possible. Learn Rust to learn about the borrow checker. Then apply what you have learned to make yourself a better C++ programmer. Some of the best, most insightful C++ programmers I know are people who are actually well-versed in other languages, especially functional programming languages.
Go, on the other hand, has a lot of adoption. So if you're looking for a language to use on the job today, it's gonna be Go.
I think that the production tooling for Rust is pretty good. For example, it has a package manager that everyone uses, with features like lockfiles that are specifically designed for production. Not many languages have this.
It's undeniable that Go is more popular than Rust, but I think "production tooling" is not the reason.
Rust is elegant and the future of serious programming, but not mainstream yet.
> there's not much production use yet
That said, if you haven't already, I think you should learn Haskell instead. Learning Haskell, for me, was the biggest departure from my previous programming experience. It forced me to re-examine more of the things that I thought I knew about organizing my thoughts into a program. And while I don't feel that I ever really got good at Haskell, I feel that my time learning Go and Rust has been so much more valuable for having learned Haskell first.
It's very unlikely that you'll find a job programming Haskell...there are a few, but not many. But I feel confident in saying that learning Haskell will make you a better programmer in whatever language you do end up getting paid to write.
That said, if the choice is really between the two, I'd probably say learn Go. 3-4 months into programming Go and you'll probably be quite adept with it. 3-4 months into programming Rust and you may just be getting past the phase where it takes you 10 minutes of fighting the borrow checker to get relatively simple code to compile. I'm a couple months into Rust and I feel like I'm a least 6 months away from being productive with it.
Currently, I'm writing a website with Yesod. In Yesod, the URLs on the site are grouped in types and database queries are constructed from these checked types. Any change in database scheme will simply give a compile error.
Rust also sounds attractive, but I think the web stack is not as nice as Yesod yet.
This exactly is why I can never get past the first couple weeks of playing with Rust. Every few months I revisit it and every couple weeks after that I put it aside again.
When I was first learning C++ I spent a huge amount of my time inside the debugger trying to figure out why a pointer wasn't ... pointing. There was always a reasonable explanation that way my fault and if I had just understood what my code was really doing I would have coded things right and it wouldn't have crashed.
Now we have Rust that essentially takes away that entire problem. Just wipes it out by way of a clever compiler. Only now we substitute this same learning curve "debugging" the compiler rather than debugging memory space. (Probably a better trade-off in the long run. Rust sort of bets on that being true anyway.)
Go does not suffer from either of these traits. For me, Go is not often a "fun language" to code in but it's eminently practical and is remarkably fast to pick up for what it does express. I've ported a couple pieces of C# application systems to Go and they've worked really well. But it's kind of a grind unwinding the higher level abstractions from C# into the more primitive Go space.
I wish there was some way to bury Rust's borrow checker for those parts of an application where you don't want to care about it and then surface it gradually when you do want it. Because the elegance of the rest of the language is what pulls me back every few months.
Walmart, Apple, Facebook, eBay, Intel, Google, Mozilla, IBM, Microsoft, DigitalOcean, Zynga, Yahoo, BBC, VMware, Uber, GitHub, Getty Images, Twitter, Stack Exchange, Docker, SpaceX, Baidu, Qiniu, Imgur, CloudFlare, Bitbucket, Dell, Twitch, Dailymotion, bitly, Cisco, Verizon, Dropbox, Adobe, New York Times, HP, Canonical, Cloud Foundry, 99designs, BuySellAds, CoreOS, MongoDB, Basecamp, Rackspace, Booking, MalwareBytes, Kingsoft, Iron.io, OpenShift, Heroku, Square, Spring, Tumblr, VMWare, Symantec, Comcast, CBS, SendGrid, Digitally Imported, Pivotal, Couchbase, Koding, Shopify, Shutterfly, MaxCDN, Linden Lab, SolarWinds, IMVU, EMC, Teradata, and I'm sure many more which I'm unaware of, are all using Go to some capacity.
Between Go and Rust, I think you should pick Go because there are a significant number of developers from Python/Ruby/JavaScript enjoying programming Go. Many startups start using Go[1] and couple of universities use Go in their classes[2]. Rust targets system development primarily occupied by C/C++ developers. Many still prefer C++ and I rarely see Rust job.
[1] https://news.ycombinator.com/item?id=10822019
[2] https://github.com/golang/go/wiki/Courses
Edit: I may be biased since I enjoy programming in Go.
Rust is more challenging, and there aren't many jobs available yet. But there is a possibility for Rust to displace C/C++ for certain classes of applications, and that is a very big deal. Also, skill in a more difficult language is a scarce commodity. If Rust does take off and you're one of the relatively few people who understand it well, this would make make you quite valuable.
But as others have said - pick the one you think you'd enjoy the most. Learning anything is good. And why not try a bit of both?
(Spoken as a contributor to the Rust ecosystem)
Pick the one you enjoy most.
Not sure if that was intended, but that was one epic pun!
I think part of this is due to Google initially trying to position Go as a systems programming language and sorta like an easier C.
In reality, Go is so far distant from C or C++ that it would be better to describe it as Java related honestly.
The real question is what do you want to do or why do you want to learn.
Do you want:
* Something where you can quickly produce working code
* Something with a large, complex, and questionable quality ecosystem (as ruby/python have, but a smaller scale)
* Something that's pragmatic, but not elegant
* Something that's well suited for writing a webserver, cli tools, or daemon
* An ecosystem of people who do not like complicated languages and rarely talk about complex language-theory concept
* Something that fills a similar role to python, ruby, java
* Something that has a massive foothold in the docker/container ecosystem
* A language driven by a semi-opaque "open source" process with a big company and closed doors at times
* Really easy to use concurrency (but also easy to shoot yourself with)
* Nice editor integration, autocompletion, etc.
Well, Go wouldn't be bad to learn
Do you want:
* Something where you'll actually learn new concepts, ideas, and be challenged in some ways
* A fledgeling library ecosystem where the libs that exist are decent quality, but most just don't exist
* Lots of opportunities to contribute
* A community-driven project where your opinion can make real changes happen
* A powerful macro system
* Actual type safety! With real algebraic types!
* No GC pauses
* Elegant error handling and abstraction powers
* Something it's hard to write working code in, but once it compiles it's probably pretty good
* Something great for writing an OS or low level tools in, and mediocre for webserver, cli, etc currently
* Something to replace C++, possibly D, possibly ocaml
* A language that is technically an ML but doesn't feel like one
* A super-smart community willing to talk about some of the coolest topics in language design and CS
Rust could fit for you
Grain of salt, I write lots of Go and am working on getting to know rust better still.
To all the people saying "Go is used professionally, rust isn't, don't learn rust from career perspective"... there's another axis!
You also have to consider what skills you'll pick up with each. Learning Rust will improve your ability to write safe C++ and help you reason about some types of problems in all other languages, so even though rust itself isn't directly marketable, the skills you get will be helpful regardless.
Learning Go will help you reason about actors a little and some problems in other languages, but not nearly as many and, frankly, the community for Rust will teach you a lot more about everything.
- Python
- Ruby
- JavaScript
- PHP (especially for WordPress if your focus is web)
- C#/F# and the .NET ecosystem generally (especially for corporate)
- Java (especially for corporate)
- VB.Net if you want a government job
- C/C++
- Enough SQL to do whatever you want with the above
Go is actually very diverse in its applications, but certainly has the edge on rust for building web type applications.
I learnt Go in 2014 (largely by doing HackerRank puzzles) and its good to have it in your repertoire,
But right now I'm interested to learn Rust, because its a total different approach to anything I've ever done before.
Far as this one, the only correction I have is regarding the slide that says you can't write an OS in Java. Several have been written w/ JNode and JX OS coming to mind immediately. JX is my favorite given its interesting architecture is mostly compatible with high assurance requirements. Just needs a high assurance implementation. A re-write of such an architecture in Rust might be interesting. Or SPIN OS as it was done in Modula-3 before.
I'd really like an OS built this way to become competitive. 64 bit flat address spaces and fully type safe designs really let you simplify things a lot in some fundamental ways. And you'd be able to run existing Java desktop apps without much in the way of porting effort.
Unfortunately all the Java OS's out there are hobby/academic projects that never got very far beyond a basic window manager.
Singularity, esp Midori per Duffy's blog, were the biggest pushes into an inherently better OS's for desktops. I hope we see more Midori move into Windows or other tech.
What does let mean ?
let x : u32 = 0;
let f = \x -> x + 1 in f 2