3 ms·
Looks like the author is very focused on maximally optimizing some very compute-heavy signal-processing code, and doesn’t care much what is used outside of the
by pornel 3y ago
Looks like the author is very focused on maximally optimizing some very compute-heavy signal-processing code, and doesn’t care much what is used outside of the compute kernel.
So it may be very true that for their work it’s all the same whether they use C++, or Python with numeric libraries, or some niche DSL, or a macroassembler.
But use of C++ is much broader than pure compute, so this perspective does not generalize to C++ or Rust as a whole.
- pjmlp 3y agoBut that is the thing, actually. Little by little, domains where either C or C++ would be the option to go during the 1990's, with exception of areas where VB and Object Pascal (Mac/PC variants) were enjoying adoption, have been slowly taken away from them. Bjarne created C with Classes for his distributed systems research at Bell Labs, nowadays the majority of CNCF project landscape is written into something else. C++ GUI frameworks were all over the place during the 1990's, nowadays one has to go to third parties, as platform vendors rather focus on managed languages. Even C++/WinRT going into maintenaince is an acknowledgemnt from Microsoft that outside Redmond XAML / C++ was a failure in regards to adoption. Long term we might be left with LLVM, GCC, Unreal, Skia, CUDA, and a couple of other key projects that keep C++ relevant and that is about it.
- lamontcg 3y agoYeah if you define the utility of C++ so narrowly to these very highly micro-optimized use cases then Rust can easily capture 100x the mind share of C++ because programmers generally just don't need to care that much. And really seeing what advanced Rust programmers can do when armed with godbolt I'm not convinced even those use cases demand using C++.