1 of 34

The Go Workbench

Bridging the chasm��adg@golang.org

2 of 34

The new user experience

3 of 34

New users don't understand our tools

4 of 34

Let's install Go.

5 of 34

6 of 34

7 of 34

Nice! That was easy!

8 of 34

Uhh… now what?

​

​

I guess I'll check the docs again.

9 of 34

Let's see now…

​

I don't want to read about "workspaces" just yet, but I can create a directory. OK.

​

​

Environment variables… that's like PATH right? I can do this… I think.

​

​

​

Hey, I understand this code. Go is cute!

​

​

​

Hm, "install" to build. I guess that works.

Oh look, I made it say "Hello, world". Cool!

​

​

Well, I suppose I should read that doc now...

10 of 34

​

​

​

Oh my gosh. What IS this?

​

​

​

​

​

​

​

I don't have time for this.

​

​

​

​

​

Maybe I'll just write a Python script.

​

(At least I understand that.)

11 of 34

Why is it so hard to get started?

There's nothing inherently complex about our tools,�they're just not what people expect.

The docs are even pretty decent.

New users just need a little hand holding to get started.

​

12 of 34

The intermediate user experience

13 of 34

Intermediate users love our tools…�once they know about them!

14 of 34

Intermediate users love our tools…�once they learn how to use them.

The go tool documentation is good, but it only documents some of the available tools.

Some of the go tool sub-commands are documented elsewhere in other ways.

Other tools are available only through "go get", and are documented on godoc.org.

There is no centralized point of reference for our tools.

15 of 34

The expert user experience

16 of 34

Expert users love our tools

But nobody is born an expert.

This document proposes a tool that unifies our tools and creates experts.

17 of 34

Filling the gaps

Assisting the transition: new -> intermediate -> expert

18 of 34

What if after this...

19 of 34

...the user could continue without reading a doc?

20 of 34

Introducing the "Go Workbench"

21 of 34

On first run, it guides the user through setting up a workspace.

22 of 34

23 of 34

Critically, it tells the user exactly what it did.

24 of 34

25 of 34

26 of 34

27 of 34

28 of 34

Hitting the ground running

Using the Go Workbench, a newcomer can get their workspace set up and start hacking on a basic program.

Other "project templates" could be provided, so that newcomers can get an idea of best practices. For example:

  • Web app (HTTP handler, HTML template, etc)
  • Command-line tool (flags, read from stdin, write to stdout)

Experienced gophers might want to set up their own templates.

29 of 34

To address the discoverability problem,�the features of the various tools are made obvious in the UI.

30 of 34

Demo

31 of 34

Potential features

  • "Watch" packages for changes, automatically re-build/test.
  • Be VCS-aware ("at git revision X").
  • Assist with refactoring and vendoring.
  • Documentation viewing.
  • Source code navigation and search.
  • Many more ideas...

The scope for this tool is potentially huge.�I intend to keep the scope very narrow for V1.

32 of 34

Guiding principles

  • Command-line centricity. Any operation you perform within the workbench should have a corresponding command that is available to be copied and pasted into a terminal.
  • Build on existing conventions. The workbench should not introduce any new mechanisms, but rather use those that already exist (GOPATH, etc).
  • Low barriers to entry and exit. If you're using Go already, the workbench should just work for you. If you stop using it, you should be able to switch to other tools without making any changes to your workflow.

33 of 34

Non-goals

  • No text editor. This is not an IDE.
  • No console. This is not a terminal emulator.

​

34 of 34

What do you think?

Let me know.

adg@golang.org