Golang feasibility

[NorbertHauriel]

Hello CLAP community,

Since Go is a popular and relatively easy language to pick up, how feasible is it to develop CLAP plugins with it?

What makes go a great language for CLAP plugin development:

• Both Go and CLAP follow the same mindset: open source, KISS, efficient development workflow.
• Go has native parallel processing (goroutines & channels) that is amazing when implemented in a performant way.

What worries me is:

• The garbage collector's overhead. It's being optimized all the time, but still...
• Whether Go's parallel processing can be taken advantage of in the API and DSP.

If the worry points are not blockers according to experts, I could try implementing a Go API binding.

[robbert-vdh]

As sort of a rule, languages with stop-the-world garbage collection simply cannot be used for realtime programming. There may be ways to avoid triggering the GC, but it either still needs to run at some point, or you're essentially writing a completely different language at that point (like if you're writing Haskell, but you're implementing the entire plugin in Cmm, GHC's C-- dialect).

[baconpaul]

Robbert is correct on the plugin side

I’ve thought about a python hosting api which could be very useful for debugging and the like and started sort of banging it together. Go is similar in that people may want to access clap plugins from go, although again a gc language is probably not suitable for authoring the audio thread

but we made the Abi simple and small so many languages can access it! Go for it! (As it were) just remembering that it is probably not the language in which to write a performant audio thread activity

[abique]

There are new GC which do not requires to stop the world for Java: https://www.youtube.com/watch?v=WU_mqNBEacw

[baconpaul]

Yeah there have been incremental gcs for a while. They still don’t have good predictable collection though right?

But look I think the more languages which can do clap the better! My guess is a language like python would be a super useful host and a terrible plugin layer; I know go less well but also would be very careful writing a production audio loop in it right? But it could be a very useful host language

[abique]

I'm not GC expert and I actually think GC are hidden cost as soon as you realize that with Java you still have to do resource management but you also have to do GC black magic, and even if you have a GC you can have memory leak...

Yet I think that with ZGC you can control which thread runs the GC and that one doesn't stop the others yet maybe it affects them because of the pointer coloring. Maybe it goes into the wall, but maybe it works to some extents, let's say for offline processing.

[abique]

Another approach maybe is to disable the gc while the plugin is active.

[baconpaul]

Yeah Gcs are tricky and there are strategies for real-time or near real-time which kind of amount to sort of not using the gc and understanding it well

but to the original question: I think language bindings for multiple languages are useful! Even if you wouldn’t use it to write surge or diva!

(and again I think that interpreted and slower languages for hosts could be very useful)

[NorbertHauriel]

Thank you all for the responses. I had this idea but wanted to ask before starting to work on something that turns out not so useful. This still is a great community strenghtening idea to support as many languages as possible, but I wouldn't want to help attract the 'wrong' kind of devs. Rust seems to be the only modern language fit for this task, and Go falls short even in debugging, because python at least has a REPL.

[abique]

https://ziglang.org/ could be worth a look as well. https://dlang.org/ too as the gc can be turned off.

[baconpaul]

I rust is indeed a natural target. There’s a lot of delphi/pascal too and both are in production now.

I’m also thinking some about wasm and javascript / typescript but the js would be a host indeed (although wasm is a good target for plugs perhaps). There is already a web tech host in anklang.

And languages like Faust target llvm directly; a Faust 2 clap could be very useful.

I think I before tackling a language answer the use case question though is indeed smart! I don’t know go well enough to do that myself!

[tim-janik]

@abique wrote:

Another approach maybe is to disable the gc while the plugin is active.

Disabling GC isn't really going to work well, the plugin code might not execute in time to disable the GC right at the start of process(), or it cannot disable the GC at all (JS), or it might leak memory that way - GC languages can also produce "garbage" alongside regular execution, where C++ wouldn't do an allocation, such as e.g. function invocations.

That said, the main research in GC these days is going into concurrency, incremental and generation improvements. JVM and V8 are at the forefront there in my experience, and both allow well performing soft realtime applications, mostly by reducing latency incurred by incremental GC steps.

@baconpaul wrote:

There is already a web tech host in anklang.

Rigfht, but Anklang uses "web tech" (JS + DOM) only for the GUI rendering, i.e. instead of Qt or Gtk+. No audio is rendered in the browser or via wasm. There is an IPC+websocket layer between the audio engine (C++) and the browser frontend, so the GUI for the audio engine can actually be displayed by Electron and simultaneously in a Firefox tab.