Hacker News Reader

Comment by cjaybo | Hacker News Reader

> I have literally not found a single use case where I'm forced to use C++ or Rust

I use C++ to write realtime audio processing applications, especially DAW plug-ins. This is hardly C++'s primary market, but AFAIK there are no lisp-like langauges that can compete with C++ here. I'd be happy to learn something new if this isn't the case!

View on HN

Common Lisp performance can be about the same as C++, so performance considerations won't stop you there at least. Common. You can also call C and C++ functions from Common Lisp, so the ecosystem shouldn't stop you either.

It would help if you outlined what's missing from for example Common Lisp in order for it to compete with C++, then maybe I'll be able to give more helpful suggestions that will help you.

The reason people use C/C++ for audio is because a kind of 'soft realtime' performance is required. The thread producing audio cannot block for an unbounded amount of time, ever. If you are late to produce an audio buffer, a nasty audible glitch will be the result. This means no file access, no waiting for mutexes, and certainly no garbage-collection pauses.

This is why managed languages like Lisps are rarely (if ever) used for the DSP in audio applications. I am an audio programmer who loves all things lispy, so believe me, I wish this weren't the case.

Fast is unimportant -- latency and determinism are paramount. It's true that GC'ed languages have been used in realtime applications but it's always an uphill battle. There are also low-latency GCs that are being rolled out. I think there's patent issues there but whatever. Might as well just do resource management at compile time.

Reply on news.ycombinator.com