brandur / org

A now defunct project that served my personal site.

org

This is a defunct project that served my personal site. I've since moved everything over to a static site whose sources are located at brandur/sorg (see a justification piece that I wrote on the subject).

org's Issues

"Quirky Syntax" refers to non-syntactic issues

Quirky syntax: Go is littered with quirky syntax that’s fine once you know it, but is unnecessarily opaque. Some examples:
The distinction between new, make, and initialization with composite literals.
Interfaces are always references.
Symbols that start with capital letters are exported from packages.
Channels created without a size are blocking.
select blocks with a default case become non-blocking.
You check if a key exists in a map by using a rare second return value of a normal lookup with square brackets.
Named return values.
Closing a channel causes any Goroutine that was listening on it to fall through having received a zero value of the channel’s type.
Comparing interfaces to nil is allowed by the compiler, but apparently not a good idea, and can lead to some strange bugs.

A good number of these could be considered semantics: they don't have much to do with odd grammatical construction. Some are both.

Just wanted to comment on Notes on Go

Hi!

Great article: https://brandur.org/go - thanks for writing up your experience. Hope you don't mind if I comment on a few things. Feel free to close this issue anytime 😄

Dependency management: It took me a while to warm up to Go’s design around dependency management, but not having to run and manage everything through a slow and complex system like Bundler hugely improves the development experience. It also makes it very easy to jump into foreign libraries and examine their implementations when necessary.

Really glad you recognized this. Makes the Go experience much more enjoyable!

Error handling: I like that generally my programs don’t crash, but dealing with errors requires an incredible level of micro-management. Worse yet, the encouraged patterns of passing errors around through returns can occasionally make it very difficult to identify the original site of a problem.

Returning errors is an elegant way to handle them. Let the error bubble up the stack to the first function that has enough context to handle it properly. If you want to trace its origin, you can wrap each return with something like this:

if err := doSomething(); err != nil {
    return fmt.Errorf("could not do something: %v", err)
}

I've found this to be an effective way to handle errors in my own applications, and to know pretty precisely the flow of the program and where the error came from.

The community: Reading the mailings lists can be still be pretty depressing. Every critique of the language or suggestion for improvement, no matter how valid, is met with a barrage of either “you’re doing it wrongs”, or “only the Go core team that can have thoughts that are worth consideration” Previously this level of zealotry had been reserved for holy crusades and text editors.

You'll find those types anywhere, it's definitely not only from text editor debates. You should try the Gophers Slack and the Go Forum. Both are great places to be a part of the Go community.

Anyway, hopefully this feedback is helpful. Thanks again for your post!