サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
dave.cheney.net
This talk is a case study of designing an efficient Go package. I’m going to use the example of building a high performance JSON parser. Supports streaming operations It’s unrealistic to expect to have the entire input in memory. Buffering in memory is a availability risk, input sizes are usually unknown and potentially unbounded. Buffering before processing introduces latency. Streaming reads let
JSON is important, damn near everything that we do as programmers or operators involves JSON at some point. JSON decoding is expensive, if your product talks JSON then performance of marshalling data in and out of JSON is important. This is a talk about designing an efficient replacement for encoding/json.Decoder.
Conventional wisdom dictates that the larger the number of types declared in a Go program, the larger the resulting binary. Intuitively this makes sense, after all, what’s the point in defining a bunch of types if you’re not going to write code that operates on them. However, part of the job of a linker is to detect functions which are not referenced by a program–say they are part of a library of
This is a post about how the Go compiler implements inlining and how this optimisation affects your Go code. n.b. This article focuses on gc, the de facto Go compiler from golang.org. The concepts discussed apply broadly to other Go compilers like gccgo and tinygo but may differ in implementation and efficacy. What is inlining? Inlining is the act of combining smaller functions into their respecti
This article was derived from my GopherCon Israel 2020 presentation. It’s also quite long. If you’d prefer a shorter version, head over to the-zen-of-go.netlify.com. A recording of the presentation is available on YouTube. How should I write good code? Something that I’ve been thinking about a lot recently, when reflecting on the body of my own work, is a common subtitle, how should I write good c
This is a thought experiment in API design. It starts with the classic Go unit testing idiom: func TestOpenFile(t *testing.T) { f, err := os.Open("notfound") if err != nil { t.Fatal(err) } // ... } What’s the problem with this code? The assertion. if err != nil { ... } is repetitive and in the case where multiple conditions need to be checked, somewhat error prone if the author of the test uses t.
The goal for this workshop is to give you the tools you need to diagnose performance problems in your Go applications and fix them. Through the day we’ll work from the small — learning how to write benchmarks, then profiling a small piece of code. Then step out and talk about the execution tracer, the garbage collector and tracing running applications. The remainder of the day will be a chance for
A collection of real world advice for writing maintainable Go programs. Presentations QCon Shanghai 2018GopherCon Singapore 2019 Fundamentals What is the zero value, and why is it useful?The empty structOn declaring variablesGo has both make and new functions; what gives?Should methods be declared on T or *T?Slices from the ground upIf a map isn’t a reference, what is it?A variable’s name should b
This is a post about performance. Most of the time when worrying about the performance of a piece of code the overwhelming advice should be (with apologies to Brendan Gregg) don’t worry about it, yet. However there is one area where I counsel developers to think about the performance implications of a design, and that is API design. Because of the high cost of retrofitting a change to an API’s sig
Go allows authors to write functions in assembly if required. This is called a stub or forward declaration. package asm // Add returns the sum of a and b. func Add(a int64, b int64) int64 Here we’re declaring Add, a function which takes two int64‘s and returns their sum.Add is a normal Go function declaration, except it is missing the function body. If we were to try to compile this package the co
This article is based on my GopherCon Singapore 2019 presentation. In the presentation I referenced material from my post on declaring variables and my GolangUK 2017 presentation on SOLID design. For brevity those parts of the talk have been elided from this article. If you prefer, you can watch the recording of the talk. Readability is often cited as one of Go’s core tenets, I disagree. In this a
This essay is a derived from my dotGo 2019 presentation about my favourite feature in Go. Many years ago Rob Pike remarked, “Numbers are just numbers, you’ll never see 0x80ULL in a .go source file”. —Rob Pike, The Go Programming Language Beyond this pithy observation lies the fascinating world of Go’s constants. Something that is perhaps taken for granted because, as Rob noted, is Go numbers–const
I’m a big fan of testing, specifically unit testing and TDD (done correctly, of course). A practice that has grown around Go projects is the idea of a table driven test. This post explores the how and why of writing a table driven test. Let’s say we have a function that splits strings: // Split slices s into all substrings separated by sep and // returns a slice of the substrings between those sep
This is a workshop style presentation, I’m going to dispense with the usual slide deck and we’ll work directly from the document which you can take away with you today.
Writing a good Go package starts with its name. Think of your package’s name as an elevator pitch, you have to describe what it does using just one word. A common cause of poor package names are utility packages. These are packages where helpers and utility code congeal. These packages contain an assortment of unrelated functions, as such their utility is hard to describe in terms of what the pack
This is a short response to the recently announced Go 2 generics draft proposals Update: This proposal is incomplete. It cannot replace two common use cases. The first is ensuring that several formal parameters are of the same type: contract comparable(t T) { t > t } func max(type T comparable)(a, b T) T Here a, and b must be the same parameterised type — my suggestion would only assert that they
In my previous post I converted httpstat to use Go 1.11’s upcoming module support. In this post I continue to explore integrating Go modules into a continuous integration workflow via Travis CI. Life in mixed mode The first scenario is probably the most likely for existing Go projects, a library or application targeting Go 1.10 and Go 1.11. httpstat has an existing CI story–I’m using Travis CI for
Update: Since this post was written, Go 1.11beta2 has been released. I’ve updated the setup section to reflect this. Russ Cox kindly wrote to me to explain the reasoning behind storing the Go module cache in $GOPATH. I’ve included his response inline. This weekend I wanted to play with Ubuntu 18.04 on a spare machine. This gave me a perfect excuse to try out the modules feature recently merged int
This blog post was inspired by a conversation with a co-worker about using a slice as a stack. The conversation turned into a wider discussion on the way slices work in Go, so I thought it would be useful to write it up. Arrays Every discussion of Go’s slice type starts by talking about something that isn’t a slice, namely, Go’s array type. Arrays in Go have two relevant properties: They have a fi
This post discusses how maps are implemented in Go. It is based on a presentation I gave at the GoCon Spring 2018 conference in Tokyo, Japan. What is a map function? To understand how a map works, let’s first talk about the idea of the map function. A map function maps one value to another. Given one value, called a key, it will return a second, the value. map(key) → value Now, a map isn’t going t
This is an article about compiler directives; or as they are commonly known, pragmas. It’s derived from a talk of a similar name that I gave last year at GopherChina in Shanghai. But first, a history lesson Before we talk about Go, let’s talk a little about pragmas, and their history. Many languages have the notion of an attribute, or directive, that changes the way source code is interpreted duri
If you want to know why your shell abbreviates $HOME to ~, it’s because of the label on the ~ key on the ADM-3A. If you want to know why hjkl are the de facto cursor keys in vi, look at the symbols above the letters. The ADM-3A was the “dumb terminal” which Bill Joy used to develop vi. Recently the ADM-3A came up in a twitter discussion about the wretched Apple touch bar when Bret Victor dropped t
This is an experience report about the use of, and difficulties with, the context.Context facility in Go. Many authors, including myself, have written about the use of, misuse of, and how they would change, context.Context in a future iteration of Go. While opinions differs on many aspects of context.Context, one thing is clear–there is almost unanimous agreement that the Context.WithValue method
This is an experience report about a gotcha in Go that catches every Go programmer at least once. The following program is extracted from a larger version that caused my co-workers to lose several hours today. package main import "fmt" type T struct{} func (t T) F() {} type P interface { F() } func newT() *T { return new(T) } type Thing struct { P } func factory(p P) *Thing { return &Thing{P: p} }
A long time ago, someone–I normally attribute this to David Symonds, but I can’t be sure he was the first to say it–said that the reason for adding generics to Go would be the reason for calling it Go 2.0. That is to say, adding generics to the language would be half baked if they were not used throughout the standard library. I wrote about this in a series of blog posts where I explored what I fe
This is a short post describing the procedure for discovering which version of Go was used to compile a Go binary. This procedure relies on the fact that each Go program includes a copy of the version string reported by runtime.Version() . Linker magic ensures that this value will be present in the final binary irrespective of whether runtime.Version() is called by the resulting program. The value
Fifteen years ago Python’s GIL wasn’t a big issue. Concurrency was something dismissed as probably unnecessary. What people really was needed was a faster interpreter, after all, who had more than one CPU? But, slowly, as the requirement for concurrency increased, the problems with the GIL increased. By the time this decade rolled around, Node.js and Go had arrived on the scene, highlighting the n
This is a thought experiment, what would Go look like if we could no longer declare variables at the package level? What would be the impact of removing package scoped variable declarations, and what could we learn about the design of Go programs? I’m only talking about expunging var, the other five top level declarations would still be permitted as they are effectively constant at compile time. Y
次のページ
このページを最初にブックマークしてみませんか?
『Dave Cheney | The acme of foolishness』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く