Am Do., 18. Juli 2019 um 10:04 Uhr schrieb Michele Sciabarra < mich...@sciabarra.com>:
> Actually, I am not going to rewrite the controller in Go. > There is already one here: https://github.com/projectodd/kwsk > > I proposed to use Rust instead since looks like it is growing fast, so I > could "prototype" in Rust to see where we get. But since the community does > not like it, I give up. > I just wanted to quickly get back to this: I am not proposing to not use Rust in this context because the community does not like it. It's rather a conscious decision to foster engagement in the community. Experience tells us that Scala has already been quite a burden for many to learn. My personal preference is of second order in this case. No negative sentiment against Rust was intended, quite on the contrary: Designwise I prefer Rust over Golang everyday. The reach and impact of Golang in the community this is targetting (Knative and thus Kubernetes) is undeniable though. > > My goal is to port the actionloop runtime to be "init-less" and able to > build docker images with Tekton Pipelines that can be deployed to Knative > Serving. > > I "only" need a way to get action code, send it to a git server and > trigger a Tekton Build and then a Knative Serving deploy. > > As long as I can access the runtime I am done for this project. I will > probably just use a script to do that. > > -- > Michele Sciabarra > mich...@sciabarra.com > > ----- Original message ----- > From: Dascalita Dragos <ddrag...@gmail.com> > To: dev@openwhisk.apache.org > Subject: Re: Using Rust for the KnativeWhisk controller > Date: Wednesday, July 17, 2019 10:59 PM > > I’m inserting my +1 for Go, based on the community adoption of Go; my > perception is that it found its place as the de-facto language for managing > infrastructure. Akka is amazing for distributed programming model ... > that’s my only argument for Scala, but this argument alone is not strong > enough to go against the stream. > > > What Controller functionality are you looking to re-implement ? The API > used by WSK CLI ? Or more ? > > > dragos > > > On Wed, Jul 17, 2019 at 3:25 PM Matt Sicker <boa...@gmail.com> wrote: > > > Ah, yes, Rust would be good for any performance-sensitive code or > > modules needed. I haven't kept up to date with C++ since pre-'10, but > > I'd imagine that it's easier to learn Rust than the latest version of > > C++ at this point. > > > > On Wed, 17 Jul 2019 at 08:06, Michele Sciabarra <mich...@sciabarra.com> > > wrote: > > > > > > Ok guys, I give up with rust. Will use Go. > > > > > > > > > -- > > > Michele Sciabarra > > > mich...@sciabarra.com > > > > > > ----- Original message ----- > > > From: "Markus Thömmes" <markusthoem...@apache.org> > > > To: dev@openwhisk.apache.org > > > Subject: Re: Using Rust for the KnativeWhisk controller > > > Date: Wednesday, July 17, 2019 9:16 AM > > > > > > +1 to all arguments. Rust's barrier of entry is considerably higher > than > > > that of Scala even. As much as I like the language's design, from a > > > community attraction point-of-view we should absolutely opt for go, > > > especially for things that are built around Kubernetes. > > > > > > That's of course to be taken with a grain of salt: If we have a > use-case > > > that requires the performance characteristics of Rust (especially that > > of a > > > lacking garbage collector), we should absolutely choose for the > > > implementation. Implementing a controller however sounds like a > > > business-as-usual REST talk-to-a-database thingy and Go is perfect for > > that. > > > > > > Am Di., 16. Juli 2019 um 08:53 Uhr schrieb Martin Henke < > > martin.he...@web.de > > > >: > > > > > > > Michele, > > > > > > > > Two thoughts: > > > > > > > > 1) For writing a controller in Knative I recommend to choose Go > > instead > > > > of Rust (even when I like Rust more). > > > > With Go you can leverage the fantastic Operator SDK from Redhat which > > > > makes writing controllers fairly > > > > simple (I had my first one up and running in under an hour). > > > > Link: https://github.com/operator-framework/operator-sdk > > > > > > > > The getting started guide is a good starting point: > > > > https://github.com/operator-framework/getting-started > > > > > > > > It also addresses the lifecycle of an controller with the Lifecycle > > > > Manager: > > > > https://github.com/operator-framework/operator-lifecycle-manager > > > > (I have not yet used this myself) > > > > > > > > > > > > 2) I think we should clearly separate the Knative work from Openwhisk > > and > > > > stay there with a strict Scala only policy > > > > (with the existing exceptions). > > > > Introducing more languages would in my opinion lead to maintenance > > > > problems and the waste of build up skills. > > > > > > > > Regards, > > > > Martin > > > > > > > > > > > > > On 15. Jul 2019, at 11: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 > > > > > > > > > > > > > > > > -- > > Matt Sicker <boa...@gmail.com> > > >
