1 of 24

Go�Good Intentions, Bad Outcomes

I know you mean good, but….

2 of 24

Who Am I ?

Senior Director of Software Engineering in Dynatrace
Debugging Addict
Low level geek and polyglot

CONFIDENTIAL

2

3 of 24

What we’ll talk about ?

What’s “Good Intentions, Bad Outcomes” ?
Real world examples
Go examples
How to cope with those outcomes

CONFIDENTIAL

3

4 of 24

Good intentions, Bad Outcomes

You meant well
You thought hard
The real world showed up

CONFIDENTIAL

4

5 of 24

What you usually meet

CONFIDENTIAL

5

6 of 24

The Laffer Curve

Increase taxes
Get more money or lose money?

6

One classic example of increasing taxes resulting in less tax collection is the Laffer Curve concept, which suggests that there is an optimal tax rate that maximizes revenue. If tax rates are too high, they can discourage work, investment, and spending, leading to a decrease in overall tax revenue.

A real-world instance of this is Sweden in the 1970s and 1980s. During this period, Sweden had very high marginal tax rates, which led to tax avoidance and evasion, as well as reduced economic activity. As a result, the government collected less tax revenue than expected. In response, Sweden reformed its tax system in the late 1980s and early 1990s, lowering tax rates and broadening the tax base, which ultimately increased tax revenue

1

.This example illustrates how excessively high taxes can sometimes lead to lower overall tax collection due to changes in taxpayer behavior.

7 of 24

Ballmer Peak

CONFIDENTIAL

7

8 of 24

CAFE (Not the drinking kind)

Corporate Average Fuel Economy
Improve fuel consumption and save the world

Shift to Larger Vehicles
Increased Emissions
Safety Concerns

8

Good Intentions: The CAFE standards were introduced in the 1970s to improve the average fuel economy of cars and light trucks produced for sale in the U.S. The goal was to reduce energy consumption by increasing the fuel efficiency of vehicles, thereby decreasing dependence on foreign oil and reducing greenhouse gas emissions.

Unintended Consequences:

Shift to Larger Vehicles: The regulations set different fuel economy standards for cars and light trucks (including SUVs). Manufacturers found it easier to meet the less stringent standards for light trucks, leading to a significant increase in the production and sale of SUVs and larger vehicles. These vehicles are generally less fuel-efficient than smaller cars, counteracting the original goal of reducing fuel consumption.
Increased Emissions: As a result of the shift to larger vehicles, the overall fuel economy improvements were less than anticipated, and in some cases, emissions increased. The popularity of SUVs and trucks has contributed to higher greenhouse gas emissions compared to a scenario where more fuel-efficient cars were produced and sold.
Safety Concerns: Larger vehicles are often perceived as safer for their occupants, but they can pose greater risks to other road users, including pedestrians and occupants of smaller vehicles. This has led to debates about the overall impact on road safety.

This example illustrates how well-meaning regulations can sometimes lead to outcomes that are contrary to their original objectives due to the ways in which industries and consumers respond to the incentives created by those regulations.

9 of 24

No Exceptions

Go has no exceptions
Developers like exceptions
Developers will do anything to get their exceptions

9

func tryFunction() {

defer func() {

if r := recover(); r != nil {

fmt.Println("Recovered from panic:", r)

}

}()

throwingFunction()

}

10 of 24

No Exceptions

Rebels among us

https://github.com/mitranim/try

Try proposal

https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

10

11 of 24

Error Handling Explosion

Make error handling visible and clear
Gotta handle each and every error

Ignore errors when handling them
Too hard to follow and read
Inconsistent error handling

11

Go's error handling approach is a great example of "good intentions, bad outcomes":

Good Intention:

Explicit Error Handling: Go's design encourages explicit error handling by returning errors as values. This makes error handling more visible and predictable, reducing the likelihood of unhandled exceptions and improving code robustness1
.

Bad Outcome:

Verbose Code: The need to check and handle errors explicitly after every operation can lead to very verbose and repetitive code. This verbosity can make the code harder to read and maintain1
.
Error Ignoring: To avoid the verbosity, some developers might be tempted to ignore errors altogether, using the blank identifier (_) to discard error values. This can lead to silent failures and bugs that are hard to trace2
.
Inconsistent Error Handling: Without a standardized way to handle errors, different projects and libraries might adopt different error handling patterns, leading to inconsistencies and making it harder for developers to work across multiple codebases

12 of 24

GDPR and Cookies

Make users aware of their privacy
Make users agree to anything

12

13 of 24

Go Routine Abuse

Easy concurrency and efficiency
If it’s easy and accessible, should we really use it everywhere?

Resource Exhaustion
Leaks
Complex Debugging
Unintended Blocking

13

The use of goroutines in Go is a great example of "good intentions, bad outcomes" when they are abused:

Good Intention:

Concurrency and Efficiency: Goroutines are designed to be lightweight and efficient, allowing developers to easily create concurrent programs. They enable the execution of multiple tasks simultaneously, improving performance and resource utilization
.

Bad Outcome:

Resource Exhaustion: If goroutines are not managed properly, they can lead to resource exhaustion. Creating too many goroutines can overwhelm the system, causing high memory usage and potential crashes
.
Complex Debugging: Excessive use of goroutines can make debugging and maintaining the code more difficult. Issues like race conditions, deadlocks, and synchronization problems can arise, leading to unpredictable behavior and hard-to-trace bugs
.
Unintended Blocking: Improper use of channels and synchronization mechanisms can cause goroutines to block each other, negating the benefits of concurrency and leading to performance bottlenecks3
.

This example highlights how a powerful feature like goroutines, when misused, can lead to significant challenges and unintended negative consequences.

14 of 24

Betamax VS VHS

Superior quality closed-sourced format Betamax
Open-sourced free-for-all VHS

Everybody manufactured VHS
Closed-sourced lost

14

15 of 24

Git Repository Package Management

Let’s be transparent and collaborate
Higer complexity in proprietary code and sensitive 3^rd party libraries

15

GOPRIVATE

GOPROXY

GONOPROXY

GONOSUMDB

GOSUMDB

Go's package management system, which relies on Git repository URLs, has both positive intentions and some unintended negative outcomes:
Good Intention:

Transparency and Collaboration: By using Git repositories, Go encourages the use of open-source libraries. This promotes transparency, collaboration, and community-driven development. Developers can easily inspect, contribute to, and benefit from a wide range of open-source projects.

Bad Outcome:

Limited Access to Proprietary Code: This approach can be restrictive for organizations that rely on proprietary or closed-source libraries. It makes it challenging to manage and distribute private packages securely and efficiently. While there are workarounds, such as using private Git repositories or third-party package management solutions, these add complexity and can be less convenient than a built-in solution.

16 of 24

Go cross compilation

Go is architecture dependent
Just cross compile and have no worries

Testing limitations
Users meet bugs first
Increased complexity

16

The ability to cross-compile in Go is a powerful feature, but it does come with some challenges:

Good Intention:

Cross-Platform Development: Go's cross-compilation capabilities allow developers to build binaries for multiple operating systems and architectures from a single development machine. This simplifies the development process and makes it easier to support a wide range of platforms1
.

Bad Outcome:

Testing Limitations: While cross-compiling is convenient, it doesn't address the need to run tests on the target architecture. This can lead to issues where code that compiles successfully might still fail at runtime due to architecture-specific bugs or differences in the environment. Without the ability to run tests on the target architecture, developers might miss critical issues until deployment2
.
Increased Complexity: Ensuring that tests are run on the correct architecture often requires setting up additional infrastructure, such as emulators or physical devices for each target platform. This adds complexity and can slow down the development and testing process2

17 of 24

The Australian Cane Toad

Cane Beetle problem?
Let’s just throw some toads at them
A whole new problem rises

Agriculture damage
Killing multiple predators

17

18 of 24

GOMEMLIMIT

Let’s solve OOMs
What about that CPU ?

Performance Degradation
Complex Configuration

18

GOMEMLIMIT, introduced in Go 1.19, is a feature designed to help manage memory usage more effectively by setting a limit on the amount of memory the Go runtime can use. While the intention behind GOMEMLIMIT is to prevent out-of-memory (OOM) errors and improve performance, it can lead to some unintended consequences:

Good Intention:

Preventing OOM Errors: GOMEMLIMIT aims to prevent applications from consuming excessive memory and crashing due to OOM errors. By setting a memory limit, developers can ensure that their applications remain within safe memory usage boundaries1
.

Bad Outcome:

Performance Degradation: If the memory limit is set too low, the garbage collector may run more frequently to stay within the limit, leading to increased CPU usage and performance degradation. This can result in slower application performance and higher latency1
.
Complex Configuration: Managing GOMEMLIMIT effectively requires careful tuning and understanding of the application's memory usage patterns. Incorrect configuration can lead to suboptimal performance or unexpected behavior, adding complexity to the development and deployment process2
.

This example illustrates how a well-intentioned feature designed to improve stability and performance can sometimes lead to challenges and unintended negative outcomes if not used correctly.

19 of 24

Out of order declaration syntax

Let’s make it simple and readable

https://go.dev/blog/declaration-syntax

Why make it simple when we can confuse experienced developers?

19

var x int vs int x

Go's type order and declaration syntax were designed with simplicity and readability in mind, but they can lead to some unintended consequences:

Good Intention:

Simplicity and Readability: Go's syntax for type declarations is designed to be straightforward and easy to read. For example, var x int declares a variable x of type int, which is more intuitive for many developers compared to the C-style int x. This approach aims to make the code more readable and maintainable1
.

Bad Outcome:

Confusion for Developers from Other Languages: Developers coming from languages like C, C++, or Java might find Go's type declaration syntax confusing and counterintuitive. The reversal of the type and variable name order can lead to a steeper learning curve and initial frustration1
.
Complex Type Declarations: While simple type declarations are clear, more complex types, such as function types or nested types, can become harder to read and understand. For example, declaring a function type that takes and returns other functions can be less intuitive in Go's syntax1
.

This example highlights how a design choice aimed at improving simplicity and readability can sometimes lead to confusion and complexity, especially for developers transitioning from other languages.

20 of 24

How do we rewire our brain?

20

Lotus Bridge, connecting RHD Macau and LHD Mainland China

�

Brazil on the left has RHT. Guyana over the Takutu River on the right has LHT�

21 of 24

No Default Argument Values

Make function calling explicit, readability and maintainability
Will the developers get used to it?

21

The lack of default argument values in Go can be seen as a case of good intentions leading to some unintended negative outcomes:

Good Intention:

Simplicity and Clarity: By not supporting default argument values, Go encourages explicitness in function calls. This design choice aims to make the code more readable and maintainable, as it avoids hidden behavior and ensures that all function arguments are clearly specified by the caller.

Bad Outcome:

Verbose Code: Without default argument values, developers often need to write additional boilerplate code to handle optional parameters. This can lead to more verbose and less concise code, especially when dealing with functions that have many optional parameters.
Workarounds: To simulate default argument values, developers might use workarounds such as variadic functions, struct parameters, or multiple function signatures. These approaches can add complexity and reduce the readability of the code.

22 of 24

No Default Argument Values

22

The lack of default argument values in Go can be seen as a case of good intentions leading to some unintended negative outcomes:

Good Intention:

Simplicity and Clarity: By not supporting default argument values, Go encourages explicitness in function calls. This design choice aims to make the code more readable and maintainable, as it avoids hidden behavior and ensures that all function arguments are clearly specified by the caller.

Bad Outcome:

Verbose Code: Without default argument values, developers often need to write additional boilerplate code to handle optional parameters. This can lead to more verbose and less concise code, especially when dealing with functions that have many optional parameters.
Workarounds: To simulate default argument values, developers might use workarounds such as variadic functions, struct parameters, or multiple function signatures. These approaches can add complexity and reduce the readability of the code.

23 of 24

Nature always finds a way

CONFIDENTIAL

23

24 of 24

All Gophers created with Creative Fabrica�https://tech.creativefabrica.com/

CLOUD DONE RIGHT