You are here: SE » ThesesHome » ThesisProgammingCulture

Investigation of Cultural Differences between Rust and Go Programming Communities (B)

Goal

The aim of this thesis is to find factors that could be indicative of social differences between developers using Rust and Go. The most promising - or the only - factors are then investigated further in hope to find ways to determine whether they are actual indicators for cultural differences and what kind of impact they could be having.

If possible, find an approach that has the hope of being applicable for conducting similar studies. Ideally, it should help point out particular cultural values like beauty, efficiency, versatility, collaboration, or uniformity.
  • Which of such goals might programmers of one group want to achieve that the other doesn't?
  • What do they want to avoid?
  • How do they do it?

Approach

An iterative study design alternating data acquisition and reflection was selected with the aim of increasing the researchers sensibility for differences and for suitable methods over the course of the project.Resources of the Go and Rust platforms and interviews were used to provide guiding hypotheses that were either abandoned or gradually refined during each iteration. The interviews were considered to provide the most valuable data.

These were the steps that were considered going into the project:
  1. conduct interviews to learn more about potential differences / look for them
  2. test those difference hypotheses using methods like polls and/or analysis of existing material
  3. try to judge which methods worked well and which didn't

Findings

Cultural Differences

The values expressed by participants aligned, in most parts, with those of the respective platform. The most notable difference that doesn't relate to the platform and programming itself regards the stance on the community itself. It appears that Go programmers value their community differently and view Go in a more pragmatic way than Rust developers do with their platform and the respective community.

There is reasonable evidence for the claim that Rust programmers having chosen to invest a significant amount of time into Rust relates to an underlying acceptance, preference, or even enjoyment of technologically compex solutions. Go programmers, on the other hand, appreciate the simpleness of Go and how easily they are able to learn and understand it to create programs that are comparably safe (to Rust programs).

A less developed, but promising, difference regards both platforms relation to hacker culture. Rust programmers might be inclined towards technically interesting solutions in a way that's similar to how (not necessarily intrusive) hackers approach technology. Quite possibly, Go is more popular among actual security experts and is actively used for real-life malware.

Methodological Successes and Failures

Interview data proved the most valuable to advancing the understanding of differences between the two cultures - at the same time, their execution was riddled with difficulties. The interviews were originally intended to last only about 10 minutes but most were extended because fruitful information kept showing up.

Ideally, interviews, research using public resources, and re-orientation could have alternated in regular intervals. Instead, both the scarceness of suitable candidates and the highly varying times from first contact to agreeing on an appointment led to an inability to keep up a steady rotation.
To still be able to make proper use of the alloted time, the phases for research using publicly available documents were prolonged and chat discussions were added in - to keep getting feedback and in an attempt to procure more interviews. This was done rather hastily, no structured notes were taken, chat partners weren't asked to consent to their responses being used for research, and no one agreed to an interview - despite the convenient option to turn a chat into a voice call on Discord.
It was decided that the information gained from those discussions was not useful outside of a gain in sensibility and, rather, only the more appropriate interview data was used.

The platform documentation and other resources created by authorities turned out to be highly useful despite their inherent risk of pointing towards differences that depend more on the platform than on the individual. There is still sufficient disregard of guidelines set by the platform ("don't be clever") for them to be seen as purely causal influences on an individual's behavior. Rather, the community association itself can be seen as an expression of cultural preferences (given that programmers weren't forced to use the platform by their employer or teachers).

The iterative approach is seen has having contributed greatly to the ability to procure ideas for differences. A downside to this is that, while waiting for the interviews to confirm, revise, and discard hypotheses, a lot more ideas have been generated than was possible to cover in a reasonable amount of detail.

An attempt to set up mini-surveys to post online was abandoned for probably taking to long to get right.