Graphical toolkits do a lot to help application developers avoid the complications of concurrency where possible. For example, a button's click handler will typically run on the thread that controls graphical updates; this means that simple cases of user feedback or displaying data as a result of a user action can be done without worrying about multi-threading complexity. A simple callback function for an Android application may be as simple as the following code:

button.setOnClickListener(new View.OnClickListener() {
    public void onClick(View v) {
        button.SetText("Updated!");
    }
});

However, even a modest application is unlikely to avoid these complications for long. Consider a simple RSS newsfeed application; all it does is set up a GUI, load the contents of a newsfeed from a set URL, and display the results in a list in the user interface. To remain responsive, the graphical interface must be presented when the application loads, before requesting the contents of the news feed. As the feed downloads, it can be parsed and the items displayed. However, because this is executing as a background process, it is not allowed to simply make changes to the interface, such as adding list items. Instead, it must identify the items to be added and pass this information back to the main (or event dispatch) thread to show the updates to the user. Such code can be difficult to read and will often lead to debugging complexity, as concurrent software may not always behave in the same way. In the next chapter, we will look at how Go's design for handling concurrency can simplify this for us.