I’ve barely used Go, and I agree with your rant. I usually just summarize by “no parametric polymorphism” and the language geeks can fill in the blanks of what type of language that results in.
In that regard, I’d support using Go only in the areas where it makes sense. I’ve found it to be useful for a quick C alternative or for some script like glue code. Domain services and such seem absolutely painful for the reasons you describe. On Thu, Jul 18, 2019 at 06:36, Michele Sciabarra <mich...@sciabarra.com> wrote: > 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> > > > > > > -- Matt Sicker <boa...@gmail.com>
