From dev-return-4192-archive-asf-public=cust-asf.ponee.io@openwhisk.apache.org Thu Jul 18 12:44:07 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id E78C618063F for ; Thu, 18 Jul 2019 14:44:06 +0200 (CEST) Received: (qmail 76596 invoked by uid 500); 18 Jul 2019 12:44:06 -0000 Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openwhisk.apache.org Delivered-To: mailing list dev@openwhisk.apache.org Received: (qmail 76580 invoked by uid 99); 18 Jul 2019 12:44:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Jul 2019 12:44:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4EFEBC0750 for ; Thu, 18 Jul 2019 12:44:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=sciabarra.com header.b=4qL5hohN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e8YH+vea Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id G85gKRV3wbgG for ; Thu, 18 Jul 2019 12:44:01 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=66.111.4.29; helo=out5-smtp.messagingengine.com; envelope-from=michele@sciabarra.com; receiver= Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id DE5EDBC7D4 for ; Thu, 18 Jul 2019 12:44:00 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 97ED622303 for ; Thu, 18 Jul 2019 08:43:54 -0400 (EDT) Received: from imap36 ([10.202.2.86]) by compute2.internal (MEProxy); Thu, 18 Jul 2019 08:43:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciabarra.com; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=lDZWF ScN38dbWmWOu6iPAGFnFnT66SRILcNJw7cMUWE=; b=4qL5hohNaKh3JkYXtA9uN 9APmOK62Lj+BZN9KC9NnYpr3TrbCzAOzkUEDsMG0763o49QUx/iMwYAvIcnFU+jY a+oLTKkB/lZdqOO9ePLtXzJqgCcP0c//+NiWpfU5CtERp/VDeDAOav0CnDSnwZb+ qdM4G4LItZSAHZdQbeBkYte4RFsh2UmXZWiQrw545HmhHPHJly9B7YN8YoMG/tgX qtp1hfo1OEyRRiSAV+ltj01JzMXz+ZW3IDSu0Kk/IkqTTqWYYTJHa9wSKl43e0fq uhPgUGvkQzrdeGSuhEYuNlVScxnFj0mX21Yvy4wljmCqtlOR6U7GshS2eQfLud/a g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=lDZWFScN38dbWmWOu6iPAGFnFnT66SRILcNJw7cMU WE=; b=e8YH+veaAfjiMcpjtgYYoFyvaTycNBR/4ZYYYiD1IG8z5H1Zw2nrxz7DC OjZknJiFaP/+0Dd0z1kYWnxg566X1x94uGD1GKxmsuYW3cZhJC68uKrPUrWzVsKg xea0UZLL5TJrM8+9GtZPECPV0rJMZd6DU9grAK2D6DrY5GOq2SSg7cxVK06P1Dzt 3GF9jXH2qnPO3MyeUmhDGQlYdpV+P0FdXB3JG7BIHyGhZXAbiL/ZAKpRtpdQSS// imF1n9rud3lRyJoH7RWos4ybrPI4A/DNJmAP5TrR+KKVwr8QHXOh+cShz5DyLixo GlM/rHLatbSh2L7n5TWzI4lKXHn+A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofhitghhvghlvgcuufgtihgrsggrrhhrrgdfuceomhhi tghhvghlvgesshgtihgrsggrrhhrrgdrtghomheqnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmihgthhgvlhgvsehstghirggsrghrrhgrrdgtohhmnecuvehluhhsthgvrhfuihii vgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F099012200A2; Thu, 18 Jul 2019 08:43:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: <606e628b-ad92-4d10-a586-c55d61d0c13f@www.fastmail.com> In-Reply-To: References: <0129338c-2bdd-4479-bf09-30e5f1d17544@www.fastmail.com> <8D316028-9CB2-46F0-AE5A-08D82F48603D@web.de> <16208a87-08b9-4523-b5f3-85d4e489bcf8@www.fastmail.com> <634bad1f-3675-409c-aed6-6c9a2b418a1a@www.fastmail.com> <73623606-e416-48e1-a3ea-74dce43dddd2@www.fastmail.com> Date: Thu, 18 Jul 2019 14:43:53 +0200 From: "Michele Sciabarra" To: dev@openwhisk.apache.org Subject: Re: Using Rust for the KnativeWhisk controller Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok, sorry for the rant. I hope I did not violate any code of conduct wit= h this. I hope it is acceptable to say I feel coding in Go is painful for me, yo= u have to care of a lot of small details, and I prefer to stick maintain= ing 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 o= f 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 T= ekton 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 OpenWhi= sk, and I can do this with a simple temporary script. It is also possib= ile to to that with the current controller, but still, it is not what I = want to work on now. --=20 Michele Sciabarra michele@sciabarra.com ----- Original message ----- From: "Markus Th=C3=B6mmes" 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 me= ss" others built with it. I have used the "lower barrier to entry means also a proliferation of ba= d 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 fro= m 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 should= n't be about personal preference either but a discussion about what's best f= or 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 i= s > wrong with Go. > > Go is terribly bare-bone and expressing everything that is a bit compl= ex > is an excercise in patience. And a REST server is already too complica= ted > for Go. Give a look to the mess that is the prototype kwsk. > > The pattern "if err !=3D nil" everywhere is just plainly silly, you ha= ve 3 > more lines in your code, 2 of them useless, for each error. Yes of cou= rse > 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 w= hen > 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, bec= ause > Go does not have any optional parameter and unless you write a functio= n > with a ton of parameters, there are no other options. > > You have to do basically the same for any swagger generated server, a= nd > unfortunately the current prototype of OpenWhisk for Knative is gener= ated > with swagger, and it is an absolute mess of boilerplate code and manag= ing > 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 disagr= ee. > 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 belie= ve 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" program= ming > but since unfortunately it covered the niche of being a "compiled" lan= guage > 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=C3=B6mmes" > 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 communi= ty > does > > not like it, I give up. > > > > I just wanted to quickly get back to this: I am not proposing to not u= se > Rust in this context because the community does not like it. It's rath= er a > conscious decision to foster engagement in the community. Experience t= ells > 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 senti= ment > 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 wi= ll > > probably just use a script to do that. > > > > -- > > Michele Sciabarra > > michele@sciabarra.com > > > > ----- Original message ----- > > From: Dascalita Dragos > > To: dev@openwhisk.apache.org > > Subject: Re: Using Rust for the KnativeWhisk controller > > Date: Wednesday, July 17, 2019 10:59 PM > > > > I=E2=80=99m 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=E2=80=99s my only argument for Scala, but this argument alone i= s 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 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 > > > > wrote: > > > > > > > > Ok guys, I give up with rust. Will use Go. > > > > > > > > > > > > -- > > > > Michele Sciabarra > > > > michele@sciabarra.com > > > > > > > > ----- Original message ----- > > > > From: "Markus Th=C3=B6mmes" > > > > 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 hig= her > > than > > > > that of Scala even. As much as I like the language's design, fro= m 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 (especiall= y > 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 perfe= ct > 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 Redha= t > 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 Life= cycle > > > > > Manager: > > > > > https://github.com/operator-framework/operator-lifecycle-manag= er > > > > > (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 mainte= nance > > > > > 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 action= looop > > > 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 redh= at, > > > 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. Ju= lia > is > > > really > > > > > awesome, Python simplicity and Go speed, but I feed the commun= ity > > would > > > > > disagree on using Julia. Of course if I am wrong... let me kn= ow > > > because > > > > > that would be my preferred choice. > > > > > > > > > > > > However, I feel that, given our Scala background, Rust woul= d be > a > > > much > > > > > better choice for the KnativeWhisk controller. So I propose t= o use > > > Rust > > > > > for the KwhiskController. > > > > > > > > > > > > What does the community think of the proposal? > > > > > > > > > > > > > > > > > > -- > > > > > > Michele Sciabarra > > > > > > michele@sciabarra.com > > > > > > > > > > > > > > > > > > > > > > -- > > > Matt Sicker > > > > > >