On 15 December 2013 23:25, <"Ola Fosheim Grøstad\" <[email protected]>"@puremagic.com> wrote:
> On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton Wakeling wrote: > >> Again, better I think to create first-class iOS support in D itself. The >> alternative you suggest really feels like sticking one's feet in the flames >> to get out of having to do a firewalk ... :-) >> > > Yes, I thought that too for a while, in general, but then it turns out > that C++ has kind of become a "portable source-level object format" which > most new platforms are claiming support for. And new platforms keep coming > in areas where you least expect them to. Like Chrome PNaCl for the web. So, > it is a moving target. Not being able to generate C/C++ if you later decide > to port is a lock-in unless the runtime is so minimal and simple that you > can make do with generic LLVM IR… > > > If that's the use-case you're looking for, fair enough. What I was >> concerned with was whether you were overlooking other use-cases that might >> potentially benefit you, because while looking at D through the prism of >> "C++ replacement" is valid, it misses a whole load of other things one can >> do with the language. >> > > I am looking for a language that let me do experimental realtime audio. > C++ is not a good fit because of the "experimental" part suggest a clean > language where you can quickly change the code. C++ is a bit > verbose/tedious to be a good fit. There is nothing in D that prevents it > from providing very clean low level support, but I sense that this is not > the direction the language is going. I could be wrong though, maybe I'll > give it a spin after new year. :) > I think D can do this well. D has fairly nice stream constructs and algorithms, and also has reasonable out-of-the-box threading features. Audio involves so much bit-twiddling, I'd never want to do audio work in a non-native language! I only worry about the garbage collector. Audio processing is my biggest fear case when there is a GC involved that is known to execute unpredictably, often taking a very long time in the rare event it does execute. More work, less often, is a workload pattern that is fundamentally incompatible with realtime software. Incidentally, this is a significant factor in the reasoning behind calling for a community music-game side project. I'd like to prove it out.
