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 < mich...@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 > 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: Thursday, July 18, 2019 12:54 PM > > 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> > > > > > >
