openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodric Rabbah <>
Subject aligning client tooling around Go
Date Tue, 05 Jun 2018 18:57:03 GMT
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.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message