Why I love Rust(speakerdeck.com) |
Why I love Rust(speakerdeck.com) |
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 2You're yet to display that. Half a year is too short time to give that confidence.
On the first point, we've set up a lot of tools and process to deal with stability, including testing releases against all open source code in existence. It's not perfect, but it does demonstrate commitment.
The second is the actual follow through. Due to said tools, we can calculate exactly how good we've done at it: so far, it's something like 97% of all code that was ever published still builds with 1.5. I'm on mobile so I don't have the real number on me. And that breakage was due to soundness updates, which we introduce over multiple releases, starting with warnings, so there's time to adapt.
Yes, it's early days, but that doesn't mean that you can't say anything.
Rust is trying something new and Go tries to only use the stuff that worked in the past.
It's no surprise that people favor Go instead of Rust.
Also the last time I saw a video about a low level language discussion, only Rust had a dev there nobody really knows. C++, D and Go had prominent people speaking for them.
The tooling really isn't the problem, as far as I can tell, Cargo is really one of the best package manager out there.
They were each represented by a prominent member of their language design team. Its tragic that more people don't know of Niko Matsakis, but his blog is one of the best resources on the design of the Rust language: http://smallcultfollowing.com/babysteps/
That has nothing to do with anything.
"Rust is trying something new and Go tries to only use the stuff that worked in the past. It's no surprise that people favor Go instead of Rust."
That's a good point. Anyone doing something critical wants low risk. Using a proven tool or one with proven concepts is lower risk. Go's methods were proven in Pascal, Oberon, etc. So, Go is less risk.
Not to knock Rust in any way with the above. Might be safer in long run due to design and improving toolchain. However, there is a risk perception and a real issue of new concepts taking time to spot then eliminate problems. So, I encourage Rust for systems use on less critical stuff right now but was shocked Dropbox uses it in storage functions.
Totally disagree. Rust's ideas are tweaks of decades-old research. These tweaks are what make it interesting and constitute research in their own right, but Go did that too with their tweaks to CSP and interfaces.
Every single feature of Rust, with the exception of the borrow checker, has been around since the 80s.
Even the borrow checker is based on linear / affine types that had been researched in other languages at least over a decade ago.
I think that you extrapolate from an incorrect analogy. Java is a relatively simple language (except the mess introduced by generics through type erasure), that is mostly understood by regular practitioners. Java suffered far more from the lack of modern language features than technical debt. Consequently, it benefitted from language extensions tried first in Pizza/Scala, etc.
C++, on the other hand, is a very complex language as a result of inheriting C, the lack of deprecation of misfeatures for compatibility, and perhaps questionable design choices. C++ suffers not so much the lack of language features (though support for real algebraic data types and modules would be nice), but from complexity. Complexity of the language can only be reduced by breaking compatibility.
I disagree. It frees you from chasing safety bugs and allows to invest more time in the features and that's clearly productivity win. For example rust does not suffer from compiler bugs as much as compilers written in C/C++ used to. Chrome and firefox developers spend a lot of time fixing buffer overflows and are likely to do this for many years to come. They certainly could do something more productive for everyone's benefit.
I have a lot of questions about this tool, both in terms of soundness/expressivity (how do you deal with shared_ptr and similar things if your goal is to statically guarantee no-alias on function entry) and in terms of practicality (the massive subsetting it requires basically makes ISO Core C++ an entirely new language).
Also, Herb's claims about the ISO Core C++ lifetime profile requiring fewer annotations than Rust were incorrect.
I gave basically this exact answer last time you posted a variant of this same comment on the last Rust thread.
Java 8 lambdas are fundamentally broken due to checked exceptions, and the likelihood that checked exceptions are going to be removed from the language is essentially nil.
Likewise, Rust error messages are already better than C++ compiler error messages, and the nature of C++ template expansion makes that unlikely to change.
Learn what you want to learn... not what large companies have decided to adopt (or not) based on a number of factors that have nothing to do with the quality of the language or its educational value.
> you can see C++ adopting pretty much the borrow checker as a tool
> Rust has no major production deployments of which I am aware
http://spectrum.ieee.org/static/interactive-the-top-programm...
You can break it down by classes of development (web, mobile, enterprise, embedded) as well as weighting (Spectrum, trending, jobs, open, custom). Spectrum's index (even though it's from 2014 and includes things TIOBE doesn't like SQL) isn't so very different from TIOBE's index.
"In order to filter out false positives, two mechanisms are used. First of all a confidence is defined for a language. By default the confidence is 100%, but for some difficult search queries such as "Basic Programming", the confidence will be lower. Apart from the confidence, sometimes also exceptions or mandatory additions are used to weed out false positives."
What they do is that add the term "+Google" to the search terms, yet for the other incredibly popular word "Rust", they don't add "+Mozilla". TIOBE is laughable.
Its based on search engine 'search' text typed by users. 'Go' and 'Rust' are both words used for a wide variety of purposes apart from programming languages. Same with Python.
Don't trust TIOBE on these things.
I think it's a risky move. I'd have first deployed existing, native code along with Rust in parallel using the data splitting technique so some is saved with original and some with Rust. Any compiler or library related issues on Rust side would be caught without data loss. I wonder if they did this in alpha stage and how long that lasted.
I mean, I love seeing Rust in production and some success stories would be great. It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool. I'd be testing on the middle or front-end layers first given they're usually stateless(ish).
> It's just... wow, that's pretty mission critical for what I gather is still a beta-phase tool.
I think this is very '90s thinking. Extreme "if it's not C++, you can't deploy it!" conservatism about programming languages hasn't been true for well over a decade. Paul Graham has written some nice essays about this very phenomenon.
Also, Rust is not "a beta-phase tool".
New languages are much easier to deploy since the PL Renaissance. There are a few holdout industries that still stick with C++ no matter what, such as games, but they'll come around eventually. :)
> I'd have first deployed existing, native code along with
> Rust in parallel using the data splitting technique so
> some is saved with original and some with Rust.
The project was a whole team of engineers working for almost a year, with extensive testing. At least, that's what I've heard. So like, I think they did exactly what you said, it's just that it's ready by now.
> bury Rust's borrow checker for those parts of an application
> I spent a huge amount of my time inside the debugger trying
> to figure out why a pointer wasn't ... pointing.
The trick, IIRC, was to have some smart people create a series of programming exercises that are complex enough to be a learning experience, teach a subset of the language at a time, and gradually let the concepts sink in. Practical Common LISP and Land of the LISP do this pretty well for a very confusing language. Rust will probably benefit from such a work, even more than CL. Just a suggestion in case someone's not working on it. ;)
That stuff works wonders for ease-of-adoption but such writing takes talent to produce. Takes someone with strong, tech skills who can also break anything down into English a layperson can understand. As in, it's really a series of consistent abstractions that form an effective, mental foundation for using and applying the language. Not regular definitions and examples but a true, gradual, practical process. Hopefully, you've seen such a great work vs a regular, language guide so you know what I'm talking about.
> I'd have expected Rust proponents to have a link on-hand for this to
> a guide that teaches this stuff in a way to reduce the effect.
Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)
Whereas Rust uses a combination of proven primitives and exotic techniques to achieve its goals. The exotic stuff, integration strategy, and implementation are new territory that exposes a level of risk a tried-and-true method (eg knock-off Oberon) doesn't have. It's new and unfamiliar territory to programmers at large even if some methods were seen in academia (eg Cyclone). It must be shown to be effective in terms of daily usage, standard libraries, and tooling because it's such new and unfamiliar territory.
When it is, as I have confidence in the team(s), it will then have a different argument where it eliminates way more risks than it introduces. Already has it at application level if compiler is robust. Overall thing needs more deployment, though, so people can see if it lives up to it, how much, and in what scenarios. That's the risk perception I'm talking about. Right now, it's a big unknown to many outsiders compared to traditional languages and platforms.
Thanks for the confirmation, though. I do look forward to reading the experience report. Hoping they include data on all key attributes vs prior language: productivity, debugging time comparison, CPU use, memory use, integration issues, and any changes in defect rates. Community evaluating Rust needs that data for something at this level.
Rust sort of went public around the same time as Go which automatically "made it" a competitor AND actually is a programming language you would use when you need to talk to metal.
So now people have tied them up in a PR battle.
Also, until about a year before 1.0, Rust had heavy focus on lightweight concurrency (à la goroutines), a garbage collector built into the language (or at least plans for one, complete with syntax), a mandatory runtime to manage those things, etc. You had to give up on the standard library if you wanted to use Rust code as a shared library in non-Rust programs. That changed fairly rapidly, and the last bits of that (like runtime removal) only hit a few months before 1.0, so people's first impressions of Rust were much closer to that of Go.
They're very different languages today. It is technically true that for both of them they are better than C++ for some things people have traditionally used C++ for, but once you get beyond that they're not that similar.
Hell, people wrote OS's in Haskell, Java, and C#. JX partly put the device drivers in Java. I'd be shocked if Go was only one that couldn't handle it.
I guess the real answer is, if you want to learn "the language that people will be using instead of C in ten years"... learn both of them.
Right, very difficult to move the inertia in any direction. The same is true about Java too.
But there are fewer reasons for any starting a new project to do it in C or C++.
Newer stuff replaces older stuff, Heck when C came along, there were languages with billion $ industry around them. C replaced them.
If anything, the current trend is moving more low level (rather than higher level, which these languages both are), as techniques like data oriented design becoming more mainstream.
> (rather than higher level, which these languages both are)
In that case some one just code "GoRust" language ^_^
Concurrent Pascal (1975) by Brinch Hansen http://brinch-hansen.net/papers/
...Concurrent Pascal used in Solo OS. It supported human review via readable syntax, type safety, safe ops on memory, and a concurrency system that caught race conditions at compile time. The runtime underlying the OS was about 4K with the OS itself concise enough to put in one PDF in source form. So, Hansen for the [1975] win in the GoRust competition?
I see what you mean, though, if it's just rules you have to memorize and apply in many situations. Might be potential for my proposal but I'll take your word for now.
"Anyway, like I said, I'm doing my best. More experience reports is the only way that I can do that, basically :)"
Makes sense.
http://chrismorgan.info/blog/rust-ownership-the-hard-way.htm... and http://codrspace.com/buntine/aha-understanding-lifetimes-in-... are two blog posts that I can remember.
Back to beta-phase claim, you're saying the core features and compiler of Rust are no longer in development or testing? Totally stable now with only extensions, library features, and optimizations being added? If so, that's good news and I'll drop that claim in the future. Otherwise, it's in the beta phase. Another hint would be existence of any bugs with core functionality in your compiler or libraries.
Again, though, if the spec and core functionality are frozen with all bugs fixed then I won't call it beta. Is it there yet?
"All bugs fixed" rules out every language in existence except CompCert, so I don't think that's a very interesting metric.
I certainly won't expect it to be bug free. Nice comeback with CompCert, though. ;)
You're probably much smarter or more dedicated than me if you feel this level can be reached in a much shorter time.
But you can most certainly learn all the basics of writing good C++ code, and interop with great C++ libraries and get real stuff done, in fairly short time. It took me about a month to go from Objective-C to C++ and start publishing iOS apps written almost entirely in C++. And if you don't need that, you can start writing command-line utilities in a few days at most.
Wow, in that case I don't think I've ever worked with anybody who's ever managed to reach "junior level" in any language. What do you call someone with, for example, just a PhD in the relevant field, 6 or 7 years of professional programming experience and several successfully shipped products under his belt. And what do you call the guy that is obviously his junior?
This is nonsense. Perhaps it's true to some degree if you try to "learn" C++ from tutorials of dubious quality rather than from a decent book.
In any case, these rules do not fall under what I'd call "junior-level" C++ programmer as the OP wrote.
This is ludicrous. Depending on your back-ground and the amount of time you spend working in the language each day, a journeyman level competency can be had in just a few months. Honestly this sounds like a comment from someone who has not done much C++. Please correct me if I'm wrong.
I guess it can be summed up as: C++ is extremely good at making people think they're writing safe programs.
This feeling of safety is virtually always incorrect in the case of large-scale software, and the huge stream of memory-related vulnerabilities that virtually all popular network-facing C++ applications have and continue to have is proof of this. There is no reasonable way to argue against this; the fraction of popular network-facing C++ software written by a large team that have had memory safety problems rounds up to 100%.
"Edit: also worth adding that he Rust core team has been amazingly friendly and helpful. We've had several meetings with them where they came to our office and basically said "how's it going? what do you need? open up your laptop and show us your biggest problem." The project is under very good management."
When Rust was being developed, the two languages that got me most excited as next-gen, systems tech were Julia mainly and Nim somewhat. They had a great choice of features balancing all sorts of attributes as PL's that might get easy adoption as C++ alternatives. Thing is, many blog posts reported their communities and dev teams were downright vicious on everything from questions to compiler bugs (wtf!?). That made it a no-go as there's an upper-bound on how good those projects can get building on such a creaky, hostile foundation.
That leaves Rust as my default recommendation for new, non-critical projects in this space. Like Dropbox employee, what I've noticed is the two of you on Rust teams here are unusually helpful and respectful compared to many in PL communities defending their work. Even pcwalton when he's clearly less than happy with my comments. ;)
The combination of brilliant design and seemingly (from my little exposure) excellent community is why I promote Rust. So, keep up the great work all of you! :)
Ideally, one would learn Rust and C++ both and see how they differ, and why.
It's not going to be a particularly interesting thread if everyone who works in a language that trends higher than Go on Google chimes in to say "you should learn my language instead, because it's more popular".
> Ideally, one would learn Rust and C++ both and see how they differ, and why.
Aside from uninteresting language-specific details, C++ essentially doesn't teach you anything that Rust doesn't.
I think C++ is unique in that it is really not as popular as many new languages, not as trendy and as much in the news, and not even taught as much in college programs, yet, it remains the language where so many jobs are. This gives anyone with the desire to learn it a good and marketable skill that can make it possibly easier to find work and continue making a living doing software development. That does not apply to Rust, so I think it's a fair point to make to anyone who is asking about what languages are good to learn.
As for whether C++ has any techniques to teach that Rust does not, C++ is definitely a unique experience to go through and certainly gives a developer more insight into the actual machine they are working on in a way that few languages do.
So, anyone following your argument should skip C++ and learn COBOL because COBOL is easier to learn, in widespread use, and has jobs available.
>In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software. 36% of managers said they planned to migrate from COBOL, and 25% said they would like to if it was cheaper. Instead, some businesses have migrated their systems from expensive mainframes to cheaper, more modern systems, while maintaining their COBOL programs.
This is exactly right, and it's been true for many years now. That your old codebase is written in C++ is a totally legitimate reason to use C++.
But really, what's the point? The reasons you'd learn a low-level systems language are to learn how to manage memory and resources, to learn how to explicitly lay out data and to understand how to program without a runtime. Both Rust and C++ will teach you these.
Main vendor even has it on Visual Studio: http://www.microfocus.com/solutions/cobol/index.aspx
The job is boring, predictable, and 9-5-ish at most places. Exactly what some types of people are looking for. They figure they can play with the fun stuff at home. One person even jokingly made a web framework for it: COBOL on Cogs. So, yeah, I throw COBOL at anyone using the "use language X for users or jobs" argument to see how they react to what they're actually arguing.
Interesting that you at least looked it up and didn't go into denial mode. I'm impressed. ;)
However, modern AAA game dev is largely about customising and upgrading large existing game engines, which are all C++ based. Rust could be used for them, but isn't, and the extra features Rust brings are not compelling enough to rewrite huge amounts of working code and suffer (re)training costs.
This is a hole many new languages find themselves in. JetBrains have come up with a very clever solution for their Java/Scala competitor Kotlin: the language was carefully designed from the ground up with perfect Java interop in mind (Java/Kotlin call into each other seamlessly, the IDE can refactor across languages, Kotlin uses the same standard library etc). And quite amazingly, the IDE can automatically rewrite Java into Kotlin. This isn't a party trick, it works very well.
I think if Rust wants/wanted to be a serious competitor to or upgrade path from C++ it'd have needed to take at least some level of C++ interop into account from the start such that Rust and C++ could be intermixed freely. AFAIK though, the best you get is a typical C export/import layer which is too trivial to be compelling.
Of course, it's a lot harder than connecting with Java because of the way C++ stuff is defined using header files. But at least basic interop could have been done.
The issue with interop is on the C++ side, unfortunately, not our side. Until C++ has a well-defined ABI, it's not really possible.
Isn't Swift looking heavily into C++ interop? It might make sense to collaborate with them to get it to work in both languages.
On GCC/LLVM based platforms it's standardised in specification documents. On Windows, I think the Visual C++ ABI is the de-facto standard.
Regardless, there are only a handful of top C++ compilers. Interop with even one of them would be of tremendous value.
"The" language where so many jobs are? It's one of many.
> As for whether C++ has any techniques to teach that Rust does not, C++ is definitely a unique experience to go through and certainly gives a developer more insight into the actual machine they are working on in a way that few languages do.
Can you name, specifically, a way in which C++ gives you "more insight into the actual machine" compared to Rust?
And, perhaps most significantly, there are a wealth of C++ libraries out there that have no equivalent in other languages, and being able to use them is an education in itself.
So, learning to code professional C++ will not help you understand machines more. You'd have to learn C, basic OS/CPU structures, and which compilers produce for certain C statements. Maybe read Write Great Code by Hyde or some online articles. Learn C++ to understand machines? Not happening unless you microprogram a CPU for it on a FPGA.
If you want to understand what is actually happening on the machine, I do not think it is the best choice. C would be much better.
Given that you didn't answer the question, I think it's pretty clear at this point that you haven't used Rust. Rust is a low-level language with low-level control over memory and resources.
The original assertion was:
> ...gives a developer more insight into the actual machine...
For better or worse, Rust feels like a reference is a proper abstraction over a memory location whereas C drives home that it really is just a number. Perhaps I don't know Rust well enough but, without unsafe, I'm not sure how I would refer to an arbitrary memory location or use pointer arithmetic to access memory locations relative to a known memory location in Rust. Vector indexes in Rust appear to be more than just syntax sugar for addition whereas C allows both array[2] and 2[array]. And I know that Rust will prevent me from accessing memory that's already been freed since it's one of the selling points of the language.
Now you can argue that Rust is mostly saving you from unpleasant consequences, and you'd be right. But the fact that C forces you to understand those unpleasant consequences teaches you something about the nature of the underlying machine. C makes you realize just how much of a "wild west" situation exists at that level. It would be very easy for someone to learn Rust without being confronted with that fact.
Variadic generics and template templates are hardly interesting compared to concepts, pattern matching, and lifetimes. I use those every day in Rust, they simply don't exist in C++, and with the exception of lifetimes plenty of other languages have them too, so they're broadly useful to know. Variadic generics and template templates, on the other hand, are useful for a small subset of advanced library authors who have been programming in C++ for years.
To be concrete, I could envision some sort of bolt-on "inline C++" feature that libclang would expose to all LLVM-based languages. It wouldn't have to be principled interop any more than Objective-C++ is principled interop. It'd just need to get the job done.
(This of course also affects Rust as well; we don't have a defined ABI either.)
Supporting C++ value types, even without templates, would in turn be enough to support quite a lot more. For instance Unreal Engine defines its own string types, as do Qt and so on.