openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Using Rust for the KnativeWhisk controller
Date Wed, 17 Jul 2019 14:25:41 GMT
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 <michele@sciabarra.com> wrote:
>
> Ok guys, I give up  with  rust. Will use Go.
>
>
> --
>   Michele Sciabarra
>   michele@sciabarra.com
>
> ----- Original message -----
> From: "Markus Thömmes" <markusthoemmes@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.henke@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 <michele@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
> > >  michele@sciabarra.com
> >
> >



-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message