Hacker News Reader

Comment by c0balt | Hacker News Reader

It may be true that for most high level development a high level programming language will suffice but don't just write off any other languges, because you don't like their ecosystem and/ or design. Languges like C++ or Rust are in no way competing with Clojure since their aims and target market are vastly different. Nobody should write a kernel in clojure, but maybe in rust (Redox) or C++ (Linux).

View on HN

Please note I said "Clojure/ClojureScript projects, or any other lisp-like languages". I'm in no way limiting myself to just Clojure, any lisp-like language will do, say Common Lisp if performance is needed, ulisp if it has to run on a microcontroller, Babashka/Fennel/Janet if fast startup time is required and so on.

As long as it's s-expressions and interactive development oriented, I'm probably fine with it.

But for the last 4-5 years, I have literally not found a single use case where I'm forced to use C++ or Rust since multiple other (lisp-like) languages has the same target market and the ergonomics are just so much better.

> 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!

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.

I don't understand why you gave the example of C++ (Linux)

Linux is written in C, and, perhaps someday, Rust.

Linus doesn't like C++ and has explicitly objected to, among other things, its enthusiasm for implicit allocation. Rust's implicit allocation all lives in libraries and so the Rust for Linux project ripped that out.

Reply on news.ycombinator.com