research!rsc: Coroutines for Go
This post is about why we need a coroutine package for Go, and what it would look like. But first, what are coroutines? Every programmer today is familiar with function calls (subroutines): F calls G, which stops F and runs G. G does its work, potentially calling and waiting for other functions, and eventually returns. When G returns, G is gone and F continues running. In this pattern, only one fu
research!rsc: The Principles of Versioning in Go (Go & Versioning, Part 11)
This blog post is about how we added package versioning to Go, in the form of Go modules, and the reasons we made the choices we did. It is adapted and updated from a talk I gave at GopherCon Singapore in 2018. Why Versions? To start, let’s make sure we’re all on the same page, by taking a look at the ways the GOPATH-based go get breaks. Suppose we have a fresh Go installation and we want to write
research!rsc: Our Software Dependency Problem
For decades, discussion of software reuse was far more common than actual software reuse. Today, the situation is reversed: developers reuse software written by others every day, in the form of software dependencies, and the situation goes mostly unexamined. My own background includes a decade of working with Google’s internal source code system, which treats software dependencies as a first-class
research!rsc: Go += Package Versioning (Go & Versioning, Part 1)
We need to add package versioning to Go. More precisely, we need to add the concept of package versions to the working vocabulary of both Go developers and our tools, so that they can all be precise when talking to each other about exactly which program should be built, run, or analyzed. The go command needs to be able to tell developers exactly which versions of which packages are in a particular
research!rsc: Glob Matching Can Be Simple And Fast Too
Here's a straightforward benchmark. Time how long it takes to run ls (a*)nb in a directory with a single file named a100, compared to running ls | grep (a.*)nb. Superscripts denote string repetition and parentheses are for grouping only, so that when n is 3, we're running ls a*a*a*b in a directory containing the single file aaa...aaa (100 a's), compared against ls | grep a.*a.*a.*b in the same dir
research!rsc: My Go Resolutions for 2017
’Tis the season for resolutions, and I thought it would make sense to write a little about what I hope to work on this year as far as Go is concerned. My goal every year is to help Go developers. I want to make sure that the work we do on the Go team has a significant, positive impact on Go developers. That may sound obvious, but there are a variety of common ways to fail to achieve that: for exam
research!rsc: Version SAT
Dependency hell is NP-complete. But maybe we can climb out. The package version selection problem is to find a set of dependencies that can be used to build a top-level package P that is complete (all dependencies satisfied) and compatible (no two incompatible packages are selected). There may be no such set, because of the diamond dependency problem: perhaps A needs B and C; B needs D version 1,
research!rsc: The Generic Dilemma
Generic data structures (vectors, queues, maps, trees, and so on) seem to be the hot topic if you are evaluating a new language. One of the most frequent questions we've had about Go is where the generics are. It seems like there are three basic approaches to generics: (The C approach.) Leave them out. This slows programmers. But it adds no complexity to the language. (The C++ approach.) Compile-t
research!rsc: Go Data Structures: Interfaces
Go's interfaces—static, checked at compile time, dynamic when asked for—are, for me, the most exciting part of Go from a language design point of view. If I could export one feature of Go into other languages, it would be interfaces. This post is my take on the implementation of interface values in the “gc” compilers: 6g, 8g, and 5g. Over at Airs, Ian Lance Taylor has written two posts about the i
research!rsc: Hacking the OS X Kernel for Fun and Profiles
My last post described how user-level CPU profilers work, and specifically how Google’s pprof profiler gathers its CPU profiles with the help of the operating system. The specific feature needed from the operating system is the profiling timer provided by setitimer(2) and the SIGPROF signals that it delivers. If the operating system’s implementation of that feature doesn’t work, then the profiler
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
research!rsc