Any info on the motivation for making an entire language instead of a library for an existing language (e.g. for C, Python, or Go)?
Especially if the syntax mimics C-like languages, what important advantages do we get?
Especially if the syntax mimics C-like languages, what important advantages do we get?
The precedent to consider is shader languages. A language like GLSL constrains what the programmer can do, with very good reason: the probability a newcomer will write a performant-enough and correct-enough shader in a general purpose programming language is low.
Similarly with audio programming. Not blocking the audio thread is hard! Heck, just dealing with multithreading itself is hard. JUCE tries to make audio programming much simpler, but at the end of the day it's still C++, and footguns abound.
So I like to think of SOUL as a sort of shader language for audio. We built https://soul.dev/playground/ to be a sort of "Shadertoy for Audio."
The main TL;DRs are:
- this needs to get JITed to compete with C++ performance, so dynamic and interpreted languages are out.
- it needs to stop people doing anything which is real-time unsafe, so any language which involves a heap or GC is out
- it needs to be secure enough to not pose a security risk if deployed to an embedded bare-metal device, so C is out.
- it needs to be super-easy to learn for all programmers, and especially for grizzled old C/C++/Javascript/C# people who aren't into any of that fancy functional nonsense
- it needs to strongly enforce and represent a graph structure at a syntactic level, so.. pretty much all existing languages are out.
... except languages designed for real-time signal processing based on dataflow graphs such as Kronos (https://www.mitpressjournals.org/doi/pdfplus/10.1162/COMJ_a_...), Céu (http://www.ceu-lang.org/chico/ceumedia_webmedia16_pre.pdf), Antescofo (https://hal.inria.fr/hal-01585489) and the oldies such as SIGNAL, Lustre, Esterel, etc... :p
..but we are attempting to do something that nobody else is, which is to provide a platform they can use as a target.
If we can do the hard work and graft of turning this into a super-portable runtime that can target whatever low-latency hardware the user has (and create a market for new audio accelerators that don't yet exist), then we expect it to be attractive for all those existing frameworks to use SOUL (or our IR) as the thing they emit, rather than using LLVM's JIT or WASM or just interpreters as they do now.