openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michele Sciabarra" <mich...@sciabarra.com>
Subject Re: Using Rust for the KnativeWhisk controller
Date Thu, 18 Jul 2019 12:43:53 GMT
Ok, sorry for the rant. I hope I did not violate any code of conduct with this.

I hope it is acceptable to say I feel coding in Go is painful for me, you have to care of
a lot of small details, and I prefer to stick maintaining the Go runtime but I do not feel
also coding  a controller with it. There is already one in the work, not sure what is the
status. And lot of  Go entusiasts so I  am sure many will want to pick the task, if it is
needed.

I just need to "put" in some way the code in a git server to feed to a Tekton build and that
is all. And it is only for a prototype I am working on. My goal is only to port the actionloop
runtime, not rewrite OpenWhisk, and I can  do this with a simple temporary script. It is also
possibile to to that with the current controller, but still, it is not what I want to work
on now.


-- 
  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: Thursday, July 18, 2019 2:21 PM

I share none of these sentiments. Neither on Golang being barebones nor on
a few of the examples you mentioned making me "want to die" nor on
"absurdities", "silliness" in the languages design or on an "absolute mess"
others built with it.

I have used the "lower barrier to entry means also a proliferation of bad
code" argument myself in the past. There are other angles to look for in a
language where you want contributions outside of your team, aka a
community. That being said: The barrier of Rust does not prevent you from
writing bad code with it. The same is even more true for languages like
C++, where it's easy to make very low level mistakes.

Again: Both languages are absolutely fine for what they are. This shouldn't
be about personal preference either but a discussion about what's best for
this project specifically. Using Golang in the Kubernetes/Knative space
simply easily buys you the most mindshare by far.

Am Do., 18. Juli 2019 um 13:36 Uhr schrieb Michele Sciabarra <
michele@sciabarra.com>:

> Sigh! Having used Go for over one year and half, and being the one who
> built the Go runtime and applied to another 5 languages, I know what is
> wrong with Go.
>
> Go is terribly bare-bone and expressing everything that is a bit complex
> is an excercise in patience. And a REST server is already too complicated
> for Go. Give a look to the mess that is the prototype kwsk.
>
> The pattern "if err != nil" everywhere is just plainly silly, you have 3
> more lines in your code, 2 of them useless, for each error. Yes of course
> if can write a function that will "panic" for each error but also this is
> not better than ignoring all the errors and panicing when you meet it.
>
> Parsing JSON is another absurdity, you have to declare a full struct when
> you just need to access to a single value and ignore the rest... or
> navigate/cast/navigate/cast the struct until you get there.
>
> If you give a look to the AWS api for example, you would like to kill
> yourself: for each function call you need to create a full struct, because
> Go does not have any optional parameter and unless you write a function
> with a ton of parameters, there are no  other options.
>
> You  have to do basically the same for any swagger generated server, and
> unfortunately the current prototype of  OpenWhisk for Knative is generated
> with swagger, and it is an absolute mess of boilerplate code and managing
> every call with a lot of verbose code involving complex structure that maps
> all the JONS of the API.
>
> I gave a look to the Project DD and I want to die the amount of messy
> boilerplate code there is. People says that Go is readable... I disagree.
> You  have to dig into the code a lot until you find what you need. All thee
> documentations are huge list of functions with very long names. Go is a
> zero structure programming language,  and gives me the feeling of PHP.
> Lower barrier to entry means also a proliferation of bad code. I believe it
> is not strange that while C++ is one of hardest language is also the
> language used by the best programmers developing the greatest apps.
>
>
> Go makes sense only in a limited ecosystem with "system level" programming
> but since unfortunately it covered the niche of being a "compiled" language
> in a world where Java is losing favour because of the mismanagement of
> Oracle, and Docker provides enough isolation where having a jvm in a
> container in a virtual machine is  total nonsense...  So there is a
> comeback to "native" code
>
> Yes of course there is a library to make it dynamic, there are code
> generator, there are tons of tools to overcome the limitations of Go... but
> there is also a solution: use a better language.
>
>
> --
>   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: Thursday, July 18, 2019 12:54 PM
>
> Am Do., 18. Juli 2019 um 10:04 Uhr schrieb Michele Sciabarra <
> michele@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
> >   michele@sciabarra.com
> >
> > ----- Original message -----
> > From: Dascalita Dragos <ddragosd@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 <boards@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 <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