In reply to @piegames:matrix.org
Either way, we also need to talk about scripting. The project will need a scripting language, whatever it may be. There are a few custom languages for this purpose, but there is also Python that works great together with Rust. I have no idea how scripting looks like in the Haskell ecosystem (I think Haskell can be interpreted too?)

In reply to @piegames:matrix.org
If you go for Rust, please don't let it be your first serious project. The odds of things getting painful are rather high on that path.

In reply to @schnecfk:ruhr-uni-bochum.de
Probably for high flexibility of the automations. While I prefer a DSL or something structural, the system that HA uses is rather weak and often requires workarounds like template sensors

In reply to @instantepiphany:matrix.org
I'm not disagreeing, just curious - what use case is there for an interpreted language?

So a few use cases that you may want to consider that would make good use of a scripting language:

• User can write a few lines of code to create automation behavior
• Plugin system
• Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.

In reply to @piegames:matrix.org

So a few use cases that you may want to consider that would make good use of a scripting language:

• User can write a few lines of code to create automation behavior
• Plugin system
• Dynamically loading modules. Let's be frank, if you want to load Rust code at run time you won't have fun.

I think the first might be covered by allowing any executable to be called as long as it follows the API. This could be bash, or python, or whatever.

Definitely agree for third.

However for plugins, I was thinking we could do that through the config - e.g the config supplied by the user would specify what protocol should be used to communicate with the target, and set various rules for the automation. I would like to keep as much logic in the config as possible.

In reply to @joerg:bethselamin.de
What other components do they plan to make stateful?

In reply to @schnecfk:ruhr-uni-bochum.de
Afaik they want to migrate always from the YAMl configuration completely, making the while configuration of all integrations stateful

In reply to @joerg:bethselamin.de
Do you have a source for that? This reads different: https://www.home-assistant.io/blog/2020/04/14/the-future-of-yaml/

In reply to @schnecfk:ruhr-uni-bochum.de
The section about ADR0010 explains that in the long term, YAML will fade out, as new integrations won't be allowed to use of YAML (except in rare cases)

In reply to @hexa:lossy.network
oh, you mean on the home-assistant side

In reply to @hexa:lossy.network
also they're talking about doing this because then they have control over config migration