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 <rod...@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
