Question: why no user-side golang code for the tasks / playbooks?

[dreamcat4]

Hello there.
You project seems to be the only CMS written in Go at the moment. So it would be nice to hear some elaboration on this bit of your README file:

don't wish to runtime eval any golang code

As being something important / worthwhile to comment about in terms of feasibility, some technical analysis.

The thing is that I do find ansible can be very slow... and it's based on python. It would be great to keep the successful ideas of ansible while improving the performance / execution time. Maybe you do already achieve right now quite a good performance with your stated Lisp interpreter. Unfortunately I can't cope with lisp myself. And I suspect it's also a view shared by many others. Tried lisp with emacs and just hated it. Too many ((())) brackets.

So my question really is: what would a GO-based CMS actually look like if it were like Ansible?

We would need the host control machine to have golang (in the same way that ansible requires python as a dependancy). In order to compile user code fragments (modules, user tasks, playbooks) into runtime executable(s). Perhaps cached. Then to run them either locally on the control machine (to exec sequences of SSH cmds / copy over shell scripts) or else to transfer them onto the target machine to be executed directly there. Depending if the target machine's architecture can be compiled or not.

It is feasible? Well I don't know that. Would it work? Don't know. But I think that using the popular implementation language GO throughout may help to gain more interest / community momentum from outside contributors.

[evanphx]

Hi!

My statement about not wanting to runtime eval go code is golang is not a scripting language and thusly taking user code and running it requires harnesses, code generation, and running the compiler. All those things are untenable to do on a client machine, they won't have the go compiler properly.

The current architecture downloads tachyon to the client machine and then it runs whatever needs be done. I opt'd to use a lisp out of shear connivence: there was a couple lisp interpreters and it was easy to integrate them. If tachyon had a custom scripting language to use that was more like python or ruby, I think that would be fine. I mostly didn't go down that road because that takes up a lot of time to make happen and I was interested in pushing on the concepts of CMS rather than the scripting language at the time.

My feeling is also that writing snippets of go to control tachyon would be a bit odd. There are random places where executing user code is required, and spinning up a compiler for a single expression is going to make it really slow and cumbersome.

Does that help clear things up?

[dreamcat4]

Ah ok. Yes that's a good explanation and justification of these things. Thanks you.

Was looking for something much closer to ansible.