IMO, one of the largest barriers to getting more (back-end) developers into OW has been the use of Scala (sig. learning curve will not even consider mounting) is by implementing in languages where the pool of active developers is lower. It seems that nearly 100% of Serverless technology "in the open" is being done in GoLang. If we wish to attract developers from Knative, OpenFaaS, Kubeless, Fission, Fn, IronFunctions, etc., they ALL use Go (which is not surprising as everyone is more-or-less looking at a Kube stack, also Go, for CN apps with Serverless being a subset).
Personally, after experiencing Go, for wskdeploy/CLI it was a joy to learn (despite some tooling annoyances) and have listed it as a top requirement developers training. In fact, I had assumed that as we seek to mainstream on a Kube deployment we would want to unify around Go to continue to be relevant in the Serverless developer community in order to lower the barrier to entry/growth. My 2 cents. On 2019/07/15 09:58:58, "Michele Sciabarra" <mich...@sciabarra.com> wrote: > Hello all, > > In my efforts to work a Kanative Whisk, I reached the point where I have a > kit with tekton-pipelines, knatve-serving building an actionlooop based > runtime. Now I need to implement a controller, in order to use the existing > wsk tooling. > > I know there is a prototype kwsk implementation made by redhat, written in > Go but looks like it is obsolete and unfinished, and to the best of my > knowledge, abandoned. > > I would like to resume the effort of writing an updated controller. I > actually already have a prototype using the Julia language. Julia is really > awesome, Python simplicity and Go speed, but I feed the community would > disagree on using Julia. Of course if I am wrong... let me know because that > would be my preferred choice. > > However, I feel that, given our Scala background, Rust would be a much > better choice for the KnativeWhisk controller. So I propose to use Rust for > the KwhiskController. > > What does the community think of the proposal? > > > -- > Michele Sciabarra > mich...@sciabarra.com >
