Most C++ developers won't easily develop systems in Rust because of lack of well-known libraries and a stable ecosystem(profilers, static analyzers, concurrency tools, many skilled and mediocre developers, etc). C++11 and subsequent versions have a good amount of memory safety(though not as safe as Rust).
Rust is a modern language with very good concepts and features. It's quite complicated to learn.
My answer is it will be a good language, but won't be a top language.
I'm not sure what "concurrency tools" are. Profiling tools that work on C++ should work on Rust just as well; "perf" and "sysprof" do, at least. "static analyzers" are far less important in Rust since the compiler prevents most of the bugs that C++ static and dynamic checkers look for. Having said that, ASAN and TSAN do work with Rust!
As for "complicated to learn" ... Rust does have a significant learning curve. However, so does C++, and the C++ learning curve never ends:
http://whereswalden.com/2017/02/27/a-pitfall-in-c-low-level-...https://bugs.chromium.org/p/chromium/issues/detail?id=683729...
I've been programming in C++ for over 20 years, plus I have a PhD in programming language tech, yet there are many dark corners of the language I don't understand, and more keep getting added all the time. "Complexity budget" is not a phrase you hear in the C++ community.
I suspect many C++ fans aren't bothered about this because their knowledge has grown with the language. I pity someone trying to "learn C++" in its full glory.
It's really great. Even if I know Qt and C++, I spent some time in ElectronJS. ElectronJS <<<<<<<<<<<< Qt + WebKit.
This javascript is a weird language and killed a lot of time by simply providing many choices, some of which are horrible, but widely used.
The only questions an interviewer can ask is how to build a graph and do graph operation(to test data structure skill). Graph Theory is too specific and many programmers never use any graph algorithms in their life.
You can always ask these questions to reject a candidate because you don't like his body odor.
In modern gcc, std::variant doesn't look like a competent replacement for old-fashioned tagged unions.
On x86_64 Linux, it looks like a function with signature `void f(std::variant<int, char>)` expects its (8-byte) argument to be passed by reference, whereas `void f2(tagged_union_of_int_and_char)` passes its argument in rdi.
gcc (-O3) also generates miserable code for calling f(42):
std::optional seems to have the same disease; the ABI is different from a plain struct containing a bool and the value and you get worse initialisation code. There's also a build time penalty to using std::optional; on my machine, including the code that uses optionals makes my trivial test program take 320ms to compile and link rather than 50ms.
These look like yet more new C++ features that are worse than what they're trying to replace.
I suspect the issue is that variant<int,char> is not trivially copy constructible (at least when I tested on godbolt), so the ABI believes it is not allowed to pass the object by value. (this is a guess only, correct me if you know better!)
Now why it is not trivially copy constructible is another question. But the latest standard draft does not require it [variant.ctor] though it does require the destructor to be trivial if all type destructors are trivial [variant.dtor]. The GCC implementation also seems to ensure only trivial destructor not copy constructor (the code is here [1] if anyone likes to see).
EDIT: I did a small experiment that agrees with this - adding a copy constructor causes passing by pointer.
https://godbolt.org/g/UG0YXJ
Unfortunately the abi requires non-trivially copyable/destructible types to be passed by (hidden) reference.
It should be possible to implement std::variant in such a way that it is trivially constructible and destructible as long as all elements are, but apparently stdlibc++ doesn't. This is GCC choice and other compilers apparently do differently. Unless GCC changes it before finalising their c++17 implementation, the choice will be unfortunately set in stone for them as they guarantee abi stability of the library.
P0602R0 is a proposal to require trivial copy/move (but strangely not destruct), don't know whether it has been accepted though.
std::optional is nice if you have a class with invariants that you want to always maintain (i.e., you don't want to deal with the pesky "uninitialized" state). You can build a class that always requires proper parameter in its constructor, and then you apply optional<> only when you defer initialization.
In most cases, I imagine the performance penalty would be dwarfed by the cost of actually using the class.
Another cool feature, on top of steveklabnik's comment: rustc is actually smart enough to collapse `Option<T>` where `T` is a borrowed reference (pointer) to a single word. Basically, the compiler knows that the pointer can never be null (borrows are always valid when in scope), so it can use the non-null values for `Some(...)` and the null value for `None`.
In other words, the compiler can turn an Option into a null-pointer convention by reasoning from first principles.
(I think this optimization works for enums in general, and is somehow related to the `nonzero::NonZero` type, but I could be wrong about that.)
Eh, I get that one of the points of C++ is to minimize abstraction penalty even when you do use abstractions, but these things are compromises. In almost all real-world software development the advantages of abstraction far outweigh micro-optimizations that shave off individual cycles...
Writing ad-hoc tagged unions and two-element 'optional' structs is a completely straightforward mechanical task---exactly the sort of thing that a programming language ought to automate. Why does there need to be a "compromise" between boilerplate and performance here? Why should I have to pay performance to use standard tagged unions and optionals, or conversely, pay by writing boilerplate in order to get performance?
If the individual cycles don't matter, you can use a safer language than C++ which compiles faster and provides more static and dynamic guarantees. If you choose C++ for a new project in 2017 it's because you need all the cycles and would have chosen assembly if you thought you could write the asm fast and cheaply enough.
First of all, the world isn't that black and white. Second, the advantage of C++ is that you are not forced to use these abstractions. You can pick and choose when to use them and pay the performance penalty.
For the parts of the codebase where you can use abstractions that have runtime costs, you can also choose a safer language that imposes similar runtime costs. I bet it would be easier to write maintainable code in the safer language than in the version+subset of C++ on which your team agrees.
For the parts of the codebase where you count cycles, you often want to carefully lay out the data and then use hand coded SIMD. Possibly use a specialized code generator that writes the SIMD asm for you, with less chance of error. If you can't do SIMD, I would just use C, but use a safety-critical code standard for the C part.
Existing codebases and existing investment into learning C++ arcana complicates these decisions, but I truly believe C++ is not worth it for new projects.
"I truly believe C++ is not worth it for new projects."
So what would you use if the constraints for the project are of the usual C++ kind? I.e. language has industrial support, proven toolchain, loads of potential candidates who can write the language, the code will compile 20 years in the future, can tightly integrate with a gui ... etc. Honestly, if there is a better language where I percieve C++ to be the best language I would dearly like to know. Half of the reasons I use C++ have nothing to do with the language itself but of the modern computing ecosystem.
Many other languages have industrial support, a proven toolchain, and are known by a lot of candidates: Java, C#, modern C... this is if we restrict ourselves to only the most popular languages with compile-time type enforcement, which is fairly arbitrary.
It's okay to admit that you like C++, it's what you know best, and that it's not unsuitable for the things you want to do. The same as someone else says that about F# or Lua.
Yes, there are many alternatives. None of which offer the same advantages as C++.
If one can swallow the costs, by all means, be my guest and use whatever language you want, no one will care much, unless you end up using 13% CPU rendering a blinking cursor.
But that's not what you and others are arguing here... instead you're arguing that there are no reasons to use C++ and one should use other languages instead. Which is pure nonsense.
It would really depend on what the project is (3d shooter game vs database server vs high frequency trading). But I think many projects can be broken into two parts:
One is a limited number of "computation kernels" (processing packets, processing transactions, computing a photoshop filter) that need to be very fast but can be carefully generated/handcoded in C or SIMD asm or whatever that has very simple behavior/API, for example it should not allocate memory.
The other part is the complicated part that has all the complex behavior (a lot of code, changing business requirements, opportunity for abstraction) that configures the kernels and feed data into them and interacts with the user and the network but takes a small part of the CPU time.
The second part must be organized so that it will not inhibit the first part in any way, so that means the second part can't use a language that won't let you layout stuff in memory in exactly the way you need or that has poor cffi performance.
The second part can be done in something as slow as cpython! (though it doesn't have to be quite that slow).
You started with an absolute statement "C++ should not be used in 2017 for new projects" and in the following comments slowly but surely admit that the above statement is false.
It would be simpler next time to just state that C++ is not a must for all software. But we already know that, so maybe the whole discussion can be skipped.
You are putting words in my mouth. I did not say "should not be used". I wrote about my option and what I do. I did not mean this advice applies to everyone in every situation.
I think your approach is "default to C++ because of very broad support, write the cold code and the hot code in C++, optimize the hot code" and implicitly you also say "and damn the security and maintainability implications".
My approach is "use the safest and most maintainable language for all code that can tolerate the performance impact", so I would prefer to write everything in a higher level language than C++ and optimize using cffi, asm, etc. only the inner most loop.
Maybe modern C++ can overcome the weight of backwards compatibility and create a truly modern subset that is as safe and as pleasant to work with as newer languages. Then your approach would definitely be better. But I don't think we're there.
For example, I think of things like a web server, where the AES-GCM has to be assembly, the HTTP parser should be generated by a special tool and the rest should be in a memory safe language to avoid Cloudbleed. Can modern C++ be that memory safe language? If yes, I'm wrong.
Your whole argument falls apart when one considers that performance needs aren't split just between SIMD + careful data layout and anything goes.
C++ isn't used only for generating the fastest possible code, but also to generate code with predictable performance, code that is default-fast and code that can be optimized without the fear of having to change programming languages to reach a performance goal.
And the disadvantage is that you have to pick and choose them after learning about all of them, and you have to deal with the choices made by whatever other code you have to work with, and you have to reason about all the combinations. For most tasks, this is overkill, which is why C and languages other than C++ persist even though C++ has everything.
I've seen this kind of misconception before and it should be corrected. Your premise is wrong, there are other reasons to pick C++ besides performance:
* it's platform-native on the major platforms and many others
* it's an international standard and has excellent backwards compatibility. i.e: it's not controlled by some corporation and it's very unlikely that a 2v3 Python-style fiasco would happen.
* it has a huge ecosystem. The only comparable ones are Java and maybe C#, but while there's overlap, each ecosystem has its focus. Java's is focused on the back-end and enterprise development.
* it's a flexible and powerful language
* it's basically the default option in certain domains
That SO question has barely any code examples but mostly links to sometimes quite technical documents. I'd really love to see a comprehensive list of all features (if possible c++11, 14 and 17) together with small explanation + code samples: even though I am already using a lot of the new features I still feel like I'm missing out on certain things just because I don't know they exist and because the information is shattered. (e.g. I'm fairly sure SO has Q&A on like every new feature, but it would take an insane amount of time to go through every question tagged [c++17]).
I don't know if similar things existed for C++11/14. But, it doesn't exist for C++17.
I faced the similar problem. I invested some money in Effective Modern C++(Scott Mayer). It covers the language part. I borrowed a book for C++11 concurrency. But, modern C++ lacks high-quality material at one place like Golang/Rust(the language guys have very good documentation, not boring and good enough to learn quickly). There are tons of scattered example.
cppreference.com usually has [c++XYZ] marks on features introduced by a specific version of C++ and it is usually current with updates while having some basic examples for most things. The site doesn't have a comprehensive list of all the features introduced in the specific version of C++, but which ever feature is interesting to you should be easy to find there.
I know many people who studied life science subjects like Chemistry or Physics and got jobs in top cs companies. Most of them were self taught(physics dudes use some level of programming )
To be a programmer, you need to have a solid problem-solving skill. Pick up a language(invest money in books in any one programming language, DS and Algo, OOPS) and invest time in websites like hackerrank.
You can easily build anything on the above skills. No matter how well you studied basic database and os stuffs, you will always need a google search before using in real life.
There are many languages for backends and tons of libraries. But there is hardly any substitute of Java in Android(if you don't consider JS solving every problem in this planet). If JetBrains only concentrate on building an ecosystem for android, it can become "the real Swift for android".
I built a dummy app for android in Kotlin. It was great. The same thing I tried in Scala(it didn't go very well).
That map is nonsense. The first, second, and third world designations have always been political divisions. First world being western, second being communist, and third world being everything else. Even more inexplicable is that they note this fact in the text and then just disregard it.
I mean I sort of understand what they are trying to do and I know other people sometimes make this mistake but it just ends up being confusing.
Mexico and Thailand aren't second world countries unless you just arbitrarily decide to misrepresent what the phrase means, since the whole point of the damn distinction in the first place was to represent the global battle for supremacy between capitalist modern countries (first world) and communist planned economies (second world). The big issue in the cold war was which of those two worlds would win the battle for the third world countries.
So when a former third world country modernizes and becomes more market driven with a more western style economy but you mark it as a second world country, you've literally described the opposite of what actually happened.
Thailand is upper middle income like Mexico and china. Nepal is low, like much of Africa, other poorer countries in South Asia. In comparison, India is lower middle income, so richer than Nepal and poorer than Thailand.
