aligning client tooling around Go

[Rodric Rabbah <ro...@gmail.com>]

I pulled out this part of Matt's previous email into a separate thread so
as not to derail the other thread's discussion.

> My first thought was that we were trying to align all our client (CLI,
etc.) tooling around GoLang as it is, in theory, easier for developers to
contribute to and in addition had fewer Java dependencies/legal
complications for binary distribution. [1]

I think the current implementation of the CLI in Go is very difficult to
work with (I can give several reasons why) and in that sense, is not easier
for contributors.

If we are going to build more tooling that is Go based, we need to really
take a look at the current engineering of the CLI and "Client" SDK and
address a number of issues --- because in my view, the choice of language
is secondary to ease of contribution when the code is well engineered.

At the risk of wading into a religious debate on language, I would also
posit that CLI tooling in a language like Python, which can be cross
compiled to Go and also be shipped in binary form, is challenging to beat
in terms of its agility and malleability. That makes it easier to penetrate
for contributors.

-r

[1]
https://lists.apache.org/thread.html/fc52f7934f38bc91961ddaad1869da739dd8b493d6cb0f51e330db6d@%3Cdev.openwhisk.apache.org%3E

Re: aligning client tooling around Go

[Matt Rutkowski <mr...@us.ibm.com>]

Actually, I was surprised when I joined the project that plans were being 
made to move away from Python...

Kind regards,
Matt 




From:   Rodric Rabbah <ro...@gmail.com>
To:     dev@openwhisk.apache.org
Date:   06/05/2018 01:57 PM
Subject:        aligning client tooling around Go



I pulled out this part of Matt's previous email into a separate thread so
as not to derail the other thread's discussion.

> My first thought was that we were trying to align all our client (CLI,
etc.) tooling around GoLang as it is, in theory, easier for developers to
contribute to and in addition had fewer Java dependencies/legal
complications for binary distribution. [1]

I think the current implementation of the CLI in Go is very difficult to
work with (I can give several reasons why) and in that sense, is not 
easier
for contributors.

If we are going to build more tooling that is Go based, we need to really
take a look at the current engineering of the CLI and "Client" SDK and
address a number of issues --- because in my view, the choice of language
is secondary to ease of contribution when the code is well engineered.

At the risk of wading into a religious debate on language, I would also
posit that CLI tooling in a language like Python, which can be cross
compiled to Go and also be shipped in binary form, is challenging to beat
in terms of its agility and malleability. That makes it easier to 
penetrate
for contributors.

-r

[1]
https://lists.apache.org/thread.html/fc52f7934f38bc91961ddaad1869da739dd8b493d6cb0f51e330db6d@%3Cdev.openwhisk.apache.org%3E