[collectd] RFC: Should we maintain plugins written in Go?

[Florian Forster]

Hi Nick,

thank you very much for your perspective! I wasn't previously aware of 
the collectd-plugin crate, thank you so much for creating it!

De-coupling plugin releases from daemon releases was something that we 
discussed for C-based plugins, too. Unfortunately detangling those 
plugins is quite a bit of work.

The Go code depends on some collectd-internal symbols, likely very 
similar to the Rust crate. I don't currently plan to support ancient 
versions of collectd, but I routinely build against 5.8, the version 
shipped by Debian. While the abstraction is certainly leaking through 
into Go, many C API changes can probably be hidden, resulting in a 
stable Go API.

Speaking of the above, the daemon should export a "version" symbol so 
that the ABI/API can be determined at runtime. Not sure if we should go 
full ABI-versioning, but I'll open a bug so we can discuss there.

Lowering the barrier to entry is certainly an important aspect. Go is 
especially strong when talking to REST- and other web-based APIs, which 
are very popular with the kids these days ;)

All the points we discussed so far equally apply to Rust-based plugins. 
Could / should these live in a "rust-plugins" repository under the 
"collectd" organization?

Best regards,
—octo
-- 
collectd – The system statistics collection daemon
Website: http://collectd.org
GitHub:  https://github.com/collectd
Twitter: http://twitter.com/collectd