3 ms·
As long as we are language trolling, why would anyone start a greenfield project like this in C++ these days? The android, windows, firefox, and now chrome pro
by galangalalgol 3y ago
As long as we are language trolling, why would anyone start a greenfield project like this in C++ these days? The android, windows, firefox, and now chrome projects have all begun to shift towards rust and in the case of Android and Firefox, write a significant amounts of their project in rust. Migrating an existing project like that is difficult. The chrome team in particular lamented the difficulty. But starting a new project? If you have a team familiar with performant c++ the speedbump of starting a greenfield project in rust is negligible, and the ergonomic improvements in the build system and the language itself will make up for that in any project that takes more than a few months. For that speed bump you get memory and thread race safety, far better than any stack of c++ analysis tools could ever provide with a tiny fraction of the unit tests you'd write in c++. And you lose no performance.
- mnrlt 3y agoC++ has a standard, multiple competing implementations and a largely drama-free community. Does CUDA even have Rust bindings, and if so, are they on the same level as the C++ ones? What do you mean by "the windows projects" that shift towards Rust?
- galangalalgol 3y agoMS has started implementing pieces of windows in rust. If you have windows 11 you are running rust. The cuda bindings are good for ml, but missing for cufft and similar. There are people working on better cuda support, but there are even more people working on vendor agnostic gpgpu using spirv and webgpu. It isn't there yet. Right now you are mostly left to your own bindings unless you are doing ml or blas. Edit: I can't argue about the drama part. The competing compilers will get there. A couple gcc frontends in work, and crane lift as a competing back end for llvm and full self-hosting. There is also miri I guess to emit c? People use that to get rust on the C64 or other niche processors.
- pjmlp 3y agoYes they started, yet there is enough C++ to rewrite in the 30 years of Windows NT history. Meanwhile, Visual Studio team released better tooling for Unreal in Visual C++.
- Const-me 3y ago> why would anyone start a greenfield project like this in C++ these days? TLDR: quite often, using C++ instead of Rust saves software development costs. Some software needs to consume many external APIs. Examples on Windows: Direct3D, Direct2D, DirectWrite, MediaFoundation. Examples on Linux: V4L2, ALSA, DRM/KMS, GLES. These things are huge in terms of API surface. Choose Rust, and you gonna need to write and support non-trivial amount of boilerplate code for the interop. Choose C++ (on Linux, C is good too) and that code is gone, you only need well-documented and well supported APIs supplied by the OS vendors. Similarly, some software needs to integrate with other systems or libraries written in C or C++. An example often relevant to HPC applications is Eigen. Another related thing, game console SDKs, and game engines, don’t support Rust. For the project being discussed here, GGML, for optimal performance the implementation needs vector intrinsics. Technically Rust has the support, but in practice Intel and ARM are only supporting them for C and C++. Not just CPU vendors, when using C or C++ there’re useful relevant resources: articles, blogs, and stackoverflow. These things help a lot in practice. I don’t program Rust, but I program C# in addition to C++, technically most vector intrinsics are available in the current version of C#, but they are much harder to use from C# for this reason. All current C and C++ compilers support OpenMP for parallelism. While not a silver bullet, and not available on all platforms supported by C or C++, some software benefits tremendously from that thing. Finally, it’s easier to find good C++ developers, compared to good Rust developers.
- galangalalgol 3y agoThere are existing supported bindings for direct3d from MS, as they themselves are migrating. GLES and ggml also have supported bindings. I like nalgebra + rustfft better than eigen now. Nalgebra still isn't quite as peformant on small matricies until const generic eval stabilizes, but it is close enough for 6x6 stuff that it is in the noise. Rustfft is faster than fftw even. Rust has intrinsic support on par with clang and gcc, and the autovectorizer uses whatever llvm know about, so again equivalent to clang. On the last point, I will again assert that a good c++ developer is just a good rust developer minus a month of ramp, that you'll get nack from not having to fight combinations of automake, cmake, conan, vcpkg, meson, bazel and hunter.
- FoodWThrow 3y agoRust is great when you know what you're building. That qualifier encompasses quite amount of software space, but not all of it, and I would argue not even the majority of it. If you don't know what you are doing, if you are exploring ideas, Rust will just get in the way. At some point you will end up realizing you need to adjust lifetimes, and that will require you to touch non-trivial amount of your code base. If you need to that multiple times, friction will overwhelm your desire to code. I have a pet theory that, the people that find Rust intuitive and fun, are the people that are working on well beaten paths; Rust is almost boring at doing that, which is a good thing. And the people that find Rust gets in their way are the people that like to experiment with their solutions, because there aren't any set, trusted solutions within their problem space, and even if there are, they like to approach the problem on their own, for better or worse. In any case: > why would anyone start a greenfield project like this in C++ these days? The video game industry can single-handedly carry C++ on their back, kicking and screaming, if need be. Rust is uniquely unfit to write gameplay code due to game development's iterative nature. Using scripting languages doesn't cut it either, because often, slower designer made scripts will need to be converted to C++ by a programmer, and pull in the crazy reference hell of the game state into the C++ land. I would say Rust is OK for engine level features -- those don't change that often, and requirements are usually well understood. But that introduces a cadence mismatch between different systems too, so there is a cost there as well. But for gameplay? There's a reason why many Rust based game engines use crazy amount of unsafe Rust to make their ECS. Just not a good fit. And of course, there's the consoles, where Sony seem to have a political reason for not supporting Rust on non-1st-party studios. I have no idea what they are thinking, honestly.