Oh wow, I didn't even know about the Scala repos myself; I need to dig around the code more! I really like Scala, though it has been a barrier to entry for several other projects that aren't Scala-specific (i.e., servers, databases, applications in general; for concrete examples, see Kafka and Spark).
Go makes sense from an ecosystem point of view, though I don't have any strong opinions on that language other than it's still lacking parametric polymorphism, but so is C, so whatever. It's much easier to use and learn than C, so that is a huge plus for attracting more developers. It's also far easier to use than C++, another bonus. Rust sounds like a fantastic language, though without a larger developer community around it yet, it might not be appropriate for anything major or we'll end up with even less contributors than in the Scala case. Java also has some things in the pipeline for this which might be useful to consider if there's any desire to gradually port the Scala code to Java or something like that. On Mon, 15 Jul 2019 at 11:33, James Thomas <jthomas...@gmail.com> wrote: > > +1 to what Matt has said. I've had this feedback multiple times from > developers that the usage of Scala is a barrier to getting involved in the > project. I understand the historical reasons for chosing Scala and realise > the language does give us lots of benefits for stability & productivity > once learnt. However, for new projects I'd +1 on using Go in the future. > > On Mon, 15 Jul 2019 at 17:20, Matt Rutkowski <mrutkow...@apache.org> wrote: > > > IMO, one of the largest barriers to getting more (back-end) developers > > into OW has been the use of Scala (sig. learning curve will not even > > consider mounting) is by implementing in languages where the pool of active > > developers is lower. It seems that nearly 100% of Serverless technology > > "in the open" is being done in GoLang. If we wish to attract developers > > from Knative, OpenFaaS, Kubeless, Fission, Fn, IronFunctions, etc., they > > ALL use Go (which is not surprising as everyone is more-or-less looking at > > a Kube stack, also Go, for CN apps with Serverless being a subset). > > > > Personally, after experiencing Go, for wskdeploy/CLI it was a joy to learn > > (despite some tooling annoyances) and have listed it as a top requirement > > developers training. In fact, I had assumed that as we seek to mainstream > > on a Kube deployment we would want to unify around Go to continue to be > > relevant in the Serverless developer community in order to lower the > > barrier to entry/growth. > > > > My 2 cents. > > > > On 2019/07/15 09:58: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 > > > > > > > > -- > Regards, > James Thomas -- Matt Sicker <boa...@gmail.com>
