search

roots / roots-cli

*Pre-alpha* Start a new Roots project with one command
https://roots.io/
MIT License
41 stars 6 forks source link

Decision to use Go #3

Closed austinpray closed 8 years ago

austinpray commented 9 years ago

In response to some questions and concerns about using Go that came up internally and externally: I thought it would be a good idea to discuss why we are using Go for this project.

Concerns about Go

The primary concern about using Go is that by using a language unfamiliar to our target audience (WP devs), we will discourage external contributions. Also: I am the only one on the team who has experience with Go in production.

Another concern is that our projects already require three languages locally: Python, PHP, and JavaScript. So it follows that we should reuse the existing requirements and education so as not to add yet another burden of knowledge on our users.

What problems am I solving by using Go?

Our projects do not rely on any particular runtime, so this project cannot rely on any particular runtime

Our full stack of tools (roots-example-project) touches a lot of tools and runtimes. Trellis requires Python to run Ansible. Sage requires Node and NPM for its build process. Bedrock requires PHP for Composer. One thing we have done a really good job of doing is putting out projects that have low coupling and high cohesion. Although Bedrock, Sage, and Trellis gel extremely nicely together, people can and do use these projects without each other.

If people can use these projects without each other, then it follows that they will use the functions of the CLI independently. For instance: a theme builder might use the CLI to scaffold out a new Sage project with their desired CSS framework. A full-stack or DevOps developer might use the CLI exclusively for its Trellis orchestration capabilities.

Go is a compiled language. As such, it spits out a self-contained binary. A user does not have to know anything about the implementation of our program to run it. They simply have to download the binary (or have a package manager download it).

The Roots CLI not having any dependencies besides itself is a huge, huge benefit for our intended use-case. Let's make our CLI extremely easy to install and then have it act as our agent as far as getting people started with our projects. When starting a new project with the CLI, we can do things like check for the proper dependencies and walk the user through the steps on how to install them. If their dependencies are failing, we can even direct them to discourse and tell them not to file an issue. Hell, we could even have it search our discourse for the error message and spit back helpful results.

The entire Roots team knows how much trouble we have supporting our user's problems with NPM. Let's make the CLI our first line of defense against this type of stuff. We can't do this if we use Python, Node, or PHP. Go is uniquely suited for this task.

Go has a rich standard library for CLI type applications

Go is built with CLI apps in mind.

We have a great body of work to look at for inspiration as well

A valid argument is that using Go will discourage external contributions. However, I am not concerned about this.

  1. This first version will be implemented mostly by me. I am very proficient with Go.
  2. Go is easy to use and learn by design. A casual look at https://golang.org/doc/code.html reveals that developing with Go is very straightforward and pragmatic. Many decisions usually left up to the developer were made at language design time. Someone who has never worked in Go before does not have to waste time immersing themselves in the ecosystem, they can just get to work. Combine that with the fact that, historically, our most helpful contributors have not been scared of stepping outside their comfort zone with technologies.
  3. Making a sweeping change to the Roots CLI will require a lot of coordination with the Roots organization as a whole. The CLI's functionality relies on the source code and implementation in the individual project repos. The easy part is writing the code for the feature; the hard part is talking through its impact on all our projects as a whole.

    Conclusion

I am going to go forward with the decision to use Go for this project. For the current requirements and requirements on the horizon, Go is uniquely suited for the job.

Let me know what feedback you guys have!

QWp6t commented 9 years ago

Unconvincing argument. PHP > Go. :trollface:

kalenjohnson commented 9 years ago

I am going to go forward with the decision to use Go for this project.

Does this mean it's actually open for discussion?

austinpray commented 9 years ago

@kalenjohnson Yeah it's absolutely open for discussion. However, in the meantime I will be slinging some Go so we can prototype the CLI out and help flush out the requirements. I'm not afraid of porting <500 sloc if it comes to that haha.

nathanielks commented 9 years ago

:clap: :clap: :clap:

heyfletch commented 9 years ago

Can't wait to Go. ;) Count me in for beta testing.

stevefloyd commented 9 years ago

🙌

cmosguy commented 8 years ago

@austinpray just listened to your podcast, I think you guys are on the right track with this. I know you are busy dudes, but was just wondering how stable this was and if you had any precompiled binaries? How much more do you have to go?

swalkinshaw commented 8 years ago

@cmosguy we have done literally nothing.