1. Use Unicode identifiers for everything.

As you probably know if you ever went to the first page of the Go tour, Go supports using Unicode characters as identifiers. But have you ever thought about how much disk-space you could save by using Unicode?

With the source code pictured above saved as UTF-8 encoded, the English string “people” is represented by the six bytes {0x70, 0x65, 0x6F, 0x70, 0x6C, 0x65}, whereas the Chinese character ‘人’, which according to Google Translate means “people”, can be represented by the three bytes {0xE4, 0xBA, 0xBA}. That is three bytes of saving every time the identifier is used! Assuming that you use that identifier at least

Also, I’m certainly no historian, but ancient Egyptians used hieroglyphics to record information and managed to build gigantic pyramids. Coincidence? I think not.

You can even use Egyptian hieroglyphs if you want! (U+13000 — U+1432F) Though you’ll need to find a font that supports them…

2. Use the built-in printing functions!

Tired of that pesky import “fmt” line mucking up your imports? Or the dreaded `imported and not used: “fmt”` compiler error after removing your only call to the fmt package? Just use the built-in printing functions!

Now, when you start sending your first few pull requests using these built-in’s, you’re bound to get some response like:

No! Don’t EVER use that! That is for debugging only and is not guaranteed to stay in the language. It says it in the docs!!

All I can say is this: Don’t worry about these people, they’re what we like to call “purists” in the underground Go community. They are the same people who say that Go is perfectly fine without generics, and then proceed to tell you that its fine to pass around an interface{} whenever you run into a problem that needs generics.

3. Pass by interface{}

Let me start by saying that Go is perfectly fine without generics. But if you run into an issue where generics is needed like a function that can add uint and int types together, its perfectly fine to just pass arguments by interface{} and do type assertions.

I recommend passing arguments by interface{} whenever you can, as it allows you to extend the function later on to support more types.

4. Replace all named structs with struct literals.

I don’t need to explain much here, the readability of the code speaks for itself. One less type name = one less type that you have to maintain, document, and deal with.

5. Monkey patch for more power.

Sometimes the built-in functions and standard packages aren’t enough. Have a noisy package constantly calling fmt.Println that you want to filter out? Or maybe you want to make a importable package that replaces the word “people” with “birdpeople” whenever fmt.Println is called? Lucky for us, there is a simple library ( github.com/bouk/monkey)to do exactly what we want! Use this to gain super-powers in Go!

Unfortunately, it doesn’t work on Windows. Although, it should be pretty easy add support for it, just use VirtualProtectinstead of mprotect.

6. Have fun with it.

Nobody likes boring old code that is easy to read and understand. Have some fun with it and give the reader a challenge! Throw some bit operators in there, have an octal or 0002. Show them your power!

type __ *[]*__
 __ := &[]__{[]__{{}}[0]}

+. Finding a showcase example.

Now, I can’t just recommend all these things without showcasing how well they work together in a full program, so I needed to make an example.

I wanted my example to be something real world, cutting edge, and would fix a problem that someone was having somewhere. I immediately recalled an issue I noticed back in 2015 on a blog post about gophercon by Dave Cheney. There was one specific paragraph that really bothered me:

GopherCon does not have a quota for minority speakers. Each speaker chosen for this year’s programme was done so on the merit of his or her proposal. But to be clear, when considering proposals of equal merit it was my policy that women, people of colour, and other underrepresented minorities, were given priority over white men.

It’s just wrong. So wrong. I’m sure that at this point me, the writer of this article, and you, the reader, are thinking the same exact thing: The words “it was my policy that …” implies he chose manually and didn’t automate it!?!?!?!

Don’t worry, reader, I’m just as horrified as you. But we can fix this, we can automate this!

I came to read this code, which I think is a fairly reasonable approach to the problem, but it has a few issues. The biggest issue being that the code quality is simply poor. Too many named structs, a priggish lack of interface{}, usage of the fmt package when there is no need, etc, Additionally, who wants to sit down and write down a numerical ‘merit’ value for each paper, and the gender, coloured-ness, and otherUnderrepresentedMinority-ness of each author? We need something better.

+. Paper Automatic Diversity Metric Évaluator (P.A.D.M.É. for short)

The goal of this is simple: When an author submits a paper, they must also submit a string of emoji they think best represents them. P.A.D.M.É. will then generate a diversity score based off of emoji skin color, gender, ethnicity, and sexuality, also taking into account ZWJ’s with skin tone and gender modifiers.

The scoring is a bit complex, but it generally follows the priority of the original quote “women, people of colour, and other underrepresented minorities, were given priority over white men.” As such, the scoring priority is women -> people of coulour -> other underrepresented minorities -> white men. I haven’t tried all of the possibilities, but in all of the test cases I’ve done, I have yet to find anything ranked worse than a white heterosexual male (score of -5), nor anything better than a dark-skinned headscarf-wearing lesbian women (score of 100). It seems to match the original quote pretty well.

Feel free to use this program, I think it could save us all some time. A few warnings in-case you do though: Make sure to be careful about the difference between ᛁ(U+16C1) and ߊ(U+07CA),