- Save time by going with C#
- Use saved time for pushing compute-heavy algorithms to GPU instead
This is exactly what is happening at my job currently (MRI scanner). Most of the user-facing code is moving from C++ to C#. More and more of the high-performance code is moving from C++ to CUDA and the likes.
How would C# save my time? What about Java? Does it save time too? Python?
I may save some time and effort, but then I will hit the C# limitations I mentioned above!
Its an important distinction that we're talking not about core code here, we're talking about the stuff that lets the user drive the application and then displays what they've done, we're talking about interacting with networks and services, files, etc. Generally, those things are much more painful in C++ than in C# either because of standard language features (e.g. delegates, threading, and more) or because of the much larger standard library -- C++ has many libraries, but its a hodge-podge that can sometimes be an extra burden to make work together. C# is as good at this kind of thing as C++ is as good at the kind of things you forst mentioned.
CAD is certainly a high-performance graphics application, like games, but its also a good deal more regular. With a smaller set of problems, there's been a lot of concentrated effort in studying CAD techniques. That helps CAD developers push more and more of the computationally-heavy stuff onto the GPU, making the absolute performance of the CPU-side code less and less critical, as it is given less difficult responsibilities and simultaneously more time to do them in. I can easily imagine that a modern CAD application could be written basically in C# from the UI all the way down to a Job Queue, which would run job kernels either on the CPU written in C++, or on the GPU written in whatever GPGPU language flavor -- and maybe supporting data structures also in C++.
No sir, I'm not talking about reading files or parsing strings, or even accessing system services. I'm talking about using something like CGAL high performance CSG libraries, and ray tracing SDKs.
Fine -- which you don't need in the layers that interact with a human, or the OS, or networks and files; and probably most of which's applications could be tucked into those jobs I talked about, or surrounding data structures, or maybe just the whole core of your app. I'm not saying to eschew C++ entirely, I'm saying you could do as much of the heavy lifting as you'd like in C++ or on the GPU, with the *rest* of the application in C#. I'm saying it could save you time to not have to wrestle with C++ in those human/OS/Networks-and-files issues, and that there's no performance argument there to justify the effort. I'm saying that the hodge-podge of C++ libraries makes it harder to hire a dev who's already familiar with your technology stack than centering around C# standards for the same. I'm saying you could hire three C# programmers to focus on those layers for the price of just two C++ programmers. I'm saying C# and its standard library are very well suited to those areas, and are a viable avenue to save you time in the long run over what setting up a hybrid C#/C++ project costs up front.
And despite of all I'm saying in favor of this arrangement, I'm still only saying its a consideration and a viable approach -- not a mandate, nor even a best-practice. If you and your shop are happy with C++, and you can hire enough good C++ people, and your margins can support the salaries they demand as you and your local competition bid up offers competing for a scarcer and scarcer resource, then cool to. You do you. What people are taking issue with is your seeming insistence that full-stack C++ is the only way to achieve performance -- its not, and I think C++ need not go as far up the stack as you'd guess if you're leveraging GPUs.
