On Tuesday, 18 January 2022 at 20:28:52 UTC, bachmeier wrote:
>from rewriting a plotting library from scratch. It's not common that you're plotting 100 million times for each run of your program.
It is not uncommon to interact with plots that are too big for matplotlib to handle well. The python visualization solutions are very primitive. Having something better than numpy+matplotlib is obviously an advantage, a selling point for other offerings.
Having the exact same thing? Not so much.
>You can replace the pieces where it makes sense to do so. The goal of the D program is whatever analysis you're doing on top of those libraries, not the libraries themselves.
You don't get a unified API with good usability by collecting a hodge podge of libraries. You also don't get any performance or quality advantage over other solutions. Borrowing is ok, replicating APIs? Probably not. What is then the argument for not using the original language directly?
The reason for moving to a new language (like Julia or Python) is that you get something that better fits what you want to do and that transitioning provides a smoother work flow in the end.
If everything you achieve by switching is replacing one set of trade offs with another set of trade offs, then you are generally better off using the more mainstream, supported and well documented alternative.
So where do you start? With a niche, e.g. signal processing or some other "mainstream" niche.
>We call C libraries all the time. Nobody thinks that's a problem. A bunch of effort has gone into calling C++ libraries and there's tons of support for that effort.
So, libraries are often written in C in order to support other languages and they are structured in a very basic way as far as C code goes. C-only libraries are sometimes not as easy to interface with as they rely heavily on macros, dedicated runtimes or specifics of the underlying platform.
I also think the C++ interop D offers is a bit clunky. It is more suitable for people who write C-like C++ than people who try to write idiomatic C++. D has to align itself more with C++ semantics for this to be a good selling point.
I am somewhat impressed that Python has many solutions for binding to C++ though, even when Python is semantically a very poor fit for C++… (e.g. Binder). D's potential strength here is not so much in being able to bind to C++ in a limited fashion (like Python), but being able to port C++ to D and improve on it. To get there you need feature parity, which is what this thread is about.
We now know that C++ will eventually get more powerful parallel computing abilities built into the language, supported by the hardware manufacturer Nvidia for their hardware (nvc++). That said Apple has shown little interest in making their versino of C++ work well with parallel computing and the C++ standard lib is not very good for numeric operations. Like, the simd code I wrote for inner product (using generic llvm SIMD) turned out to be 3 times faster than the generic C++ standard library solution.
Yet, we see "change is coming" written on the horizon, I think.
So either D has to move in a different direction than competing head-to-head with C++ or one has be more strategic in how the development process is structured. Or well, just more strategic in general.