Sadly, it won't teach you what happens if you fail to consider something.
This means, long hours of tracing, debugging, leak checks etc.
The lesson is: never ever rely on compiler, framework, language or other potentially buggy tools to think for you. Even with Rust's "hard" approach, you can get complacent and hemorrhage performance and memory until there's no turning back.
Those things were written by fallible people without hard mathematical proof everywhere, after all. Rust and especially its libraries too.
Understand libraries, their implementation and design trade-offs if you're using them.
> This means, long hours of tracing, debugging, leak checks etc.
But you don't have undefined behavior to debug, and that makes debugging easier. Trying to reverse engineer from a corrupted memory dump from a production system what the compiler did to your code and relate that back to where it went wrong is something you will have to do in C++, given enough time. You don't have to do that in Rust.
I found learning Rust to be a lot easier having learned C++11 first. Move semantics, RAII, borrowing (const references), mutable borrowing (references), option-types (pointers), and iterators are all C++ concepts. The big advantage Rust gives you is that the compiler handles a number of things that required manual bookkeeping or coding conventions in C++, and doesn't let you screw them up.
But you could equally say that all those C++ concepts are really Rust concepts. So I don't see how that's an argument that C++ is easier to learn than Rust. The strict checking seems to me to be a win, because the compiler tells you what you did wrong instead of having to debug undefined behavior (e.g. dereference after move of unique ptr).
I'm not arguing that C++ is easier to learn than Rust (I actually believe the opposite). I'm arguing that learning C++ helps with learning Rust.
If it were a completely green-field environment, I'd much rather write in Rust than in C++. (But then, in a completely green-field environment, I'd much rather write in a language suitable for prototyping like Python or Javascript than Rust, and then port it over to Rust when I have an idea what the shape of the problem is.) We don't exist in a completely green-field environment. The main advantage of C++ is that you can look at any number of open-source databases, GUI frameworks, servers, compilers, browser engines, and libraries and see how they chose to design their object models and ownership systems.
> suitable for prototyping like Python or Javascript than Rust, and then port it over to Rust
In all my years, every time someone prototypes, it either never gets used, or it does, its successful and then it never gets rewritten because there's no time for technical debt.
Now I prototype in the language I plan to use long term, but what that means is stubbing out sections, or putting in todos if there are spots that can be better. The prototype should be able to scale into your real application, otherwise your just building something that will haunt you.
A prototype is supposed to never get used. The point is to learn - to explore the territory so you have an idea of what's a good idea and what's a bad when you start implementing the real thing.
I just threw out a prototype last week, and started on implementation for real. I was able to cut about 70% of the features, throw out a couple third-party libraries and bleeding-edge language features that turned out to be more trouble than they're worth, identify 2 areas that really needed to be firmed up and made more robust before they'll support a "real" system (and have about 20 concrete examples of the first and 80 of the second, so I can design the features with actual data), and revise the API 4 times, for 5 weeks of work. It helps that I'm both CEO and only developer and so have the political clout to do this. And I'm under no illusions that this is the "final" revision - I'm doing this incarnation with somewhat more robust development practices, but I still expect I'll have to throw it out in a year or two. But it certainly beats doing those 4 revisions over a year (with a 7-person team) and then going out of business, as happened in a startup I'd previously worked at.
It's a lot cheaper buying a macbook if you can get a 20% off credit, which you can get by buying a new porsche. Spend $100k, save several hundred dollars!
Saying that learning C++ helps with learning Rust is almost certainly true in a banal way. Learning any N languages will make the incremental cost of learning language N+1 a little lower, even if those languages are not closely related.
Are you actually claiming that, if you knew someone who knew, say, Python and JS, but no statically compiled unmanaged language, and that person needed to know Rust by 2017, that your advice would be to spend the first several months learning C++? I find this implausible.
C++ is a baroque language with way too many conflicting features, conflicting cultural standards, and general all-around cruft. Isn't it?
Disclaimer: I know so little C++ that we should assume that I don't know it, and I haven't written any Rust yet.
No, of course not. If your goal is to learn Rust by 2017, go learn Rust. I don't know how this became about Rust anyway, the article is about C++ in 2016.
I also won't disagree that C++ is a baroque language with too many conflicting features, conflicting cultural standards, and general all-around cruft. There's certainly plenty I hate about it, and it's rarely the first choice I'd reach for starting a new project these days.
I'm claiming that if you are a brand new programmer that's remotely interested in HPC, games, finance, search, compilers, databases, or system software and want to build solid fundamentals for a career, learn C++. Because:
1.) It will provide access to jobs in those areas, where you can be mentored by experience programmers.
2.) It will provide access to open-source codebases in those areas, where you can learn the structure and development processes of a large, existing body of software.
3.) It will teach you language concepts that transfer over to other languages.
4.) It will teach you why certain language features didn't make it into other languages, and the pitfalls of using a language that grew by accretion over 25 years, and the many ways that you can shoot your foot off with these language features, and how to debug it once you do.
A very small portion of programming is in the language. Over the course of your career, you'll use dozens of languages - hell, I've only been doing this professionally for 12 years and I've shipped software in a dozen languages. What matters a lot more are the patterns - being able to recognize why you might use a certain technique, and how the same technique manifests differently in different languages. In the fields that it's still widespread in, C++ will open a lot of doors to learn these.
> C++ is a baroque language with way too many conflicting features, conflicting cultural standards, and general all-around cruft. Isn't it?
This is a really common sentiment, but when pressed to name a specific thing that should be removed (ignoring backwards compatibility), people really struggle.
The standard library has a lot of cruft and poor legacy decisions, but it's several decades old. Any code that's been around for several decades is going to have cruft. Any language that is as successful as C++ will have the same problem when it reaches the age of C++. It's inevitable. Anything looks elegant and free of cruft when its only a few years old and has low enough usage that the maintainers can make breaking changes without breaking billions of lines of code.
Not sure what the op is saying, but I'll say that given programmer A who knows Python and JavaScript, and programmer B who knows c++, B will have an easier time learning Rust than A will.
It's both. It's also because they don't require you define your data structures up-front, and have a clean, concise syntax with lots of sugar, and no compile times.
When you start a green-field project, you usually have no idea what the overall "shape" of the software will look like. You don't know what your data-structures will look like. You don't know what their lifetimes will be, or where they'll be accessed from. You don't know what functions you will need to write, or which ones will be leaf functions and which will be branch ones. You don't know which functions will end up calling each other. You don't know where code will be duplicated, where it'll be shared, and which subtle variations will be required in different places.
All of these are really important to learn to come up with a "proper" software architecture.
The value of a dynamic language like Python or Javascript is that you can just hack your way around these problems to make further progress. Forget a field in a data structure? Just add it in the code that computes it. Need a function to take multiple kinds of objects? Make sure they have all the requisite fields (adding forwarding properties/methods if necessary), and then just pass it in, Python doesn't care. Make a mistake in your module system? Just call the damn private method, the language won't prevent you. Have slight variations in behavior? Attach a closure to the function or data structure and invoke it.
All of these are bad practices for designing a major system with lots of developers, and yet all of them come up all the time when a system is young. The value of prototyping is that you can make more forward progress, ideally getting something up on the screen or even in front of users, and then you have a concrete laundry list of problems to fix in the next version.
I disagree. I use the compiler's dissatisfaction with my code to guide the refactor I need when my model is wrong. In a language with a good type system, the typechecker is like a built in set of unit tests.
I think the more general point he makes is about design, its hard to have the design nailed down from the beginning for most projects, why not hack something up quickly and in the process discover lots stuff that you probably wouldn't had thought of in the beginning. But if you know a language that lets you iterate very fast and you are highly productive in it, that it also has great library support so don't you don't have to reinvent the wheel all the time and lets you refactor just as easily then sure ;)
My point is that I can hack things up quickly and in the process discover lots of stuff without needing to be able to run the hacked together code, because typechecking it is enough to guide me in how to reshape it.
In dynamic languages you can also hack things together and run them (manually or through tests) to see how your hacks aren't fitting together right. I'm not saying untyped languages are bad, I'm saying that they are not inherently better for prototyping in my experience.
Libraries are important, but totally outside the scope of this conversation and I think its rude of you to raise an implication about them here. Everyone knows Rust is a young language and has the libraries that come with that.
