A design that adds generic functions and types.
(Obviously for Go 1.17.) Why you might find this approach interesting: Type variable declarations are implicit Type arguments for functions are implicit Type variable constraints can be omitted for the empty interface Methods can be generic Operations are represented with generics as normal methods It can simplify the Go language specification Check out the More ideas section at the end for things beyond generics. Define comparison operations for all types For the types that don’t yet have them:
The use of self-compilation speed as a benchmark seems like a great way to target and then maintain a balance between complexity and the performance benefits of optimizations in a compiler. Complex optimizations where the cost of optimization in terms of code complexity, outweigh the benefits of faster binaries could be clearly recognised with such a metric. An interesting idea for seeing the tradeoffs between compiler design/implementation complexity and speed.
Anthony Alaribe: Firstly, a NoSQL key value store is fast, much faster than a comparable relational database. Its speed comes from its simplicity. A key value database stores a data record using one primary key. The key means the record is uniquely identifiable, and can be directly accessed. Other than this, it’s up to the developer to architect any more complexity in accessing data. I love the Dark Side meme.
Rounding in Go is hard to do correctly. That is, given a float64, truncate the fractional part (anything right of the decimal point), and add one to the truncated value if the fractional part was >= 0.5. This problem doesn’t come up often, but it does enough that as of this writing, the second hit on Google for golang round is a closed issue from the Go project, which declined to add a Round function to the math package.
By popular request, ./… no longer matches packages in vendor directories in tools accepting package names, such as go test. To match vendor directories, write ./vendor/…. Finally! This removes the need for any kind of vendor-aware Makefile. I was worried when the suggestion of adding a -vendor flag was rejected.
My little suggestion: Viewing documentation on struct fields is now supported with go doc struct.field.
The requirement of setting a GOPATH has been a major issue for Go users who installed the Go tools for the first time and got the “you have to set a GOPATH” error in their initial experience with the tools. Explaining the GOPATH is and instructing how to set this env variable were both distracting new users away from using Go. This was especially true for users who are not necessarily developing in Go but using go get to download commands.
Apparently compress/bzip2 is the only Golang compression standard library that doesn’t have a Writer counterpart for its Reader. Lame.
Go raised the bar for new language distributions: UTF-8 code Testing, benchmarking, and profiling built in Single command line tool Build tool that leaves code directories clean Package manager Package doc browser Standard code style and formatter Fast builds Language spec with grammar and thorough library documentation Uniform, batteries-included standard library Concurrency support and automatic parallelism, sync and atomic libs, race detector Interfaces, not inheritance Vendoring support Cross compilation Static linking only for simple deployments Tabs, not spaces No semicolon line terminators Trailing commas in lists to minimize diffs Static types Default values for uninitialized variables Built-in comparisons and hashing Safety (e.
My Golang program to check whether Sudoku solutions are correct. It works for any valid Sudoku board size (1x1, 2x2, 4x4, 9x9, 16x16, etc.)
A very nice tutorial for transforming Golang ASTs by Tim Clark.
Dave Cheney: In my mind, of all the possible candidates that Go has removed, it is the removal of threads that will be its most profound contribution. This is not to say that Go programs do not use threads, any more than you can say structured programs are not compiled into branch and jump instructions. But Go programmers no longer have to concern themselves with thread management, or as Uncle Bob would say, Go programmers are restricted from directly controlling the thread their code runs on.
Will Yager on Golang: I like Go. I use it for a number of things (including this blog, at the time of writing). Go is useful. With that said, Go is not a good language. It’s not bad; it’s just not good. We have to be careful using languages that aren’t good, because if we’re not careful, we might end up stuck using them for the next 20 years. This is a list of my chief complaints about Go.
Pretty neat weather report app for the terminal, written in Golang.
Go blog: Go 1.5’s GC ushers in a future where stop-the-world pauses are no longer a barrier to moving to a safe and secure language. It is a future where applications scale effortlessly along with hardware and as hardware becomes more powerful the GC will not be an impediment to better, more scalable software. It’s a good place to be for the next decade and beyond. Really impressive goals. I love the idea of having only one GC “knob” to turn.
A critique of the Golang language, tools, creators, and community by Tyler Treat: I’m cautiously optimistic about Go’s future. I don’t consider myself a hater, I consider myself a hopeful. As it continues to gain a critical mass, I’m hopeful that the language will continue to improve but fearful of its relentless dogma. Go needs to let go of this attitude of “you don’t need that” or “it’s too complicated” or “programmers won’t know how to use it.
Kyle Quest has a lot of good tips for Golang newcomers, and arguably even intermediate ones: A lot of these gotchas may seem obvious if you took the time to learn the language reading the official spec, wiki, mailing list discussions, many great posts and presentations by Rob Pike, and the source code. Not everybody starts the same way though and that’s OK. If you are new to Go the information here will save you hours debugging your code.
An interesting overview by Robert Griesemer of the motivation for gofmt, how it has influenced code formatting in other languages, the things that went well, and the lessons learned. I found this point amusing: gofmt’s style is nobody’s favorite, yet gofmt is everybody’s favorite.
Dave Cheney on bridging from one Golang interface to another: The value returned by io.MultiWriter is an implementation of io.Writer, it doesn’t have the rest of the methods necessary to fulfil the net.Conn interface; what I really need is the ability to replace the Write method of an existing net.Conn value. We can do this with embedding by creating a structure that embeds both a net.Conn and an independant io.Writer as anonymous fields.
A funny and perceptive take on the Go programming language and the Go team. In other words, Go represents a kind of Machiavellian power play, orchestrated by slow-and-careful programmers who are tired of suffering for the sins of fast-and-loose programmers. The Go documentation refers quite often to intolerable 45-minute build times suffered by the original designers, and I can’t help but imagine them sitting around and seething about all those unused imports from those “other” programmers, that is, the “bad” programmers.