The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.
It's time to halt starting any new projects in C/C++
91–100 of 929 posts
Re: It's time to halt starting any new projects in C/C++
#92Is he actually doing it? Making a plan and a policy to replace the bone marrow of MS with Rust? Or is this just a pie in the sky tweet? I don't know what Mark is like as a CTO, so I really don't know what to expect here.
Re: It's time to halt starting any new projects in C/C++
#93Imagine how much impact we could have if we used all the effort gong to develop Rust and port everything over to Rust to instead just improve the wrinkles that exist in C++.
Most of the worst issues with C++ can't actually be fixed without backwards incompatible changes that would break large amounts of existing code. Google spent several years advocating for the approach that you're suggesting, but was unable to persuade other members of the C++ standards committee and recently announced that they're working on a replacement language. The rationale for Carbon goes into great detail on why fixing C++ isn't a viable option.
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
Re: It's time to halt starting any new projects in C/C++
#94I don’t feel that his opinion is all-encompassing. If Rust is being used in the name of security and reliability, then C/C++ should remain king of game development, where those two aren’t as important.
Have you tried working with Bevy at all? It's very good: https://bevyengine.org/learn/book/getting-started/ecs/
Re: It's time to halt starting any new projects in C/C++
#95Earlier quoted context omitted.
As pointed out, the C ABI is stable. If companies absolutely feel the need to distribute Rust shared libraries and cannot guarantee the compiler being used, then it's a reasonable choice. I suspect that isn't very common, however. More realistically, the answer is to change the interface: Rust is pretty popular in software architectures where the unit of operation is a networked or IPC'd service; vendors can distribu…
> vendors can distribute binaries that communicate at that layer instead. they could do this in C++ also but they overwhelmingly don't, I don't see why they would in any other language for the same target applications
For one, because it's easier in Rust (this goes back to the developer experience and tooling again). But we've now gone from "here's how Rust and C++'s ABI guarantees differ" to "proprietary vendors might not have the easiest time in either language," which is a significant deviation.
Re: It's time to halt starting any new projects in C/C++
#96Earlier quoted context omitted.
That's a fairly recent thing that some people do as a kind of virtue signaling. The "C/C++ Users Journal" was a very popular publication and no one took issue with its name. Nor do people take issue with Dr. Dobbs which has a "C/C++" section with articles from highly influential members of the C/C++ community. C++ is a complex language, so people invent ways to show how dedicated they are to it, and nowadays that mea…
C/C++ is undefined if C is an instance of an integral type.
it's just 1/++
Re: It's time to halt starting any new projects in C/C++
#97The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.
The old C/C++ and other code in popular languages is forever with us. Look at what happened to COBOL, it's still relevant and IMO, will be relevant in 20 years.
Re: It's time to halt starting any new projects in C/C++
#98LOL... Two of the most successful Windows tools I've seen in a long time are both written primarily in C/C++. Winget and Windows Terminal. Please let me know when Microsoft has a major Rust-win, because so far they haven't.
Re: It's time to halt starting any new projects in C/C++
#99The volume of existing C, C++, Objective-C, and C# code is phenomenal. Even if this strategy is generally adopted there will continue to be lots of this legacy code for many years to come. In particular there will continue to be such legacy code right up until 2038 at least.
carbon, and the newly announced alpha stage efforts called cppfront, can potentially act as a "typescript" for c++, new compiler can enforce memory safety at an upper layer before they're converted to c++, maybe there is hope for c/c++ code for years to come as long as they keep fixing issues along the way.
Re: It's time to halt starting any new projects in C/C++
#100Earlier quoted context omitted.
> How is Rust so much more secure and reliable than *modern* C++? Rust catches things like use-after-free at compile time. *modern* C++ still lets things slip through e.g. #include #include #include int main() { std::string s = "Hellooooooooooooooo "; std::string_view sv = s + "World\n"; std::cout
If by "slip through", you mean "warns you about by default", then yes it lets it slip through. clang++ -std=c++17 test.cc a.cc:7:29: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] std::string_view sv = s + "World\n"; ^~~~~~~~~~~~~ In any case, I think the philosophical differences between C++ and Rust are well understood, and the different views of the cost/be…
No post body was provided.