My Contribution to LLM Knowledge?

When I first started to learn Go many years ago, I wrote a Wator simulation with Go and uploaded the code to a Github repo.  A few months ago, I wanted to learn how to write a 2D game with graphics so I decided to do a new implementation of Wator using Go and Ebitengine.

There was a bug that I got stuck on and because LLMs are all the rage, I decided to ask Google's Gemini 1.5 to assist me.  Gemini generated some code output in response to my request but as I was looking at what it produced, it seemed awfully familiar.  I went back and looked at my old Wator code and sure enough it was very similar (including a bug that was in the original code).  When I asked Gemini for some of its sources for coming up with the answer it listed my repo as one of them.   

Basically,  I asked an LLM a question and it responded with my own answer.  There weren't many examples of Wator in Go so it wasn't because I had written something great, but I still found it neat and funny this happened.

WebAssembly (WASM) with Go (Golang) Basic Example

I first wrote about using Go for WebAssembly (WASM) 6 years ago right before the release of Go 1.11 which was the first time Go supported compiling to WASM.  Go's initial support for WASM had many limitations (some I listed in my initial article) which have since been addressed so I decided to revisit the topic with some updated example of using Go for WASM.

Being able to compile code to WASM now allow:

• Go programs to run in the browser. 
• Go functions to be called by JavaScript in the browser.
• Go code to call JavaScript functions through syscall/js.
• Go code access to the DOM.

Setup

Go's official Wiki now has an article on the basics of using Go for WASM including how to set the compile target and setup.  

A quick summary of the steps to the process:

Compile to WASM with the output file ending as wasm since it's likely that the mime type set in /etc/mime probably use the wasm extension.

> GOOS=js GOARCH=wasm go build -o <filename>.wasm

Copy the JavaScript support file to your working directory (wherever your http server will serve it from).  It's necessary to use the matching wasm_exec.js for the version of the Go being used so maybe put this as part of the build script.

> cp "$(go env GOROOT)/lib/wasm/wasm_exec.js" .

Then add the following to the html file to load the WASM binary: 

<script src="wasm_exec.js"></script>
<script>
    const go = new Go();
    WebAssembly.instantiateStreaming(fetch("main.wasm"), go.importObject).then((result) => {
                go.run(result.instance);
    });
</script>

Keeping It Running

It is a good starting point but the Go code example is too simplistic.  It only demonstrates that the WASM binary that is created by Go can be loaded by having write a line to the browser's console.  The Go program basically gets loaded by the browser, prints a line and exits.   Most of the time, it's probably desirable to have the WASM binary get loaded and stay running.  This can be achieved by either having having a channel that keeps waiting:

c := make(chan struct{}, 0)
<- c

or even easier:

select {}

Have either of these at the end of main() will keep the program alive after it gets loaded into the browser.

In Place of JavaScript

Being able to access the DOM excites me the most because it allows me to avoid writing JavaScript followed by being able to run Go programs in the browsers.  While I think the inter-op between Go and JavaScript is probably the most practical application, it's not something I've had to do much since I'm not a front-end developing doing optimizations or trying to reuse Go code between the front-end and back-end.

I don't mind using HTML for UI development or even CSS, I'm just personally not a fan of JavaScript.  This isn't to say that it is bad, just I prefer other languages just like some people prefer C++, Java, Python, etc.  I don't have fun writing JavaScript like I do with with Go if though I know JavaScript.

Take a basic example of a web app (index.html) with a button to illustrate:

<!DOCTYPE html>                                                                 
  <html lang="en">                                                                  
  <head>                                                                          
      <meta charset="UTF-8">                                                        
      <meta name="viewport" content="width=device-width, initial-scale=1.0">        
      <title>Example</title>                                         
  </head>                                                                           
  <body>                                                                          
                                                                                  
      <button id="myButton">Click Me</button>                                                                                                     
                                                                                  
  </body>
  </html>

JavaScript is used to attach an event to it so that when the button is clicked, an alert message pops up:

    // Select the button element                                            
    const button = document.getElementById('myButton');                     
                                                                                  
    // Attach an event listener to the button                               
    button.addEventListener('click', function() {                           
       alert('Button clicked!');                                           
    }); 

With WASM, the JavaScript can be replaced with Go code:

 package main                                                                       
                                                                                     
  import (                                                                                                                                                   
                                                                                     
      "honnef.co/go/js/dom/v2"                                                       
  )                                                                                  
                                                                                  
  func main() {                                                                   
                                                                                  
      document := dom.GetWindow().Document()                                      
           
      // Select the button element                                                                       
      button := document.GetElementByID("myButton")                               
                                                                                  
      // Attach an event listener to the button
      button.AddEventListener("click", false, func(dom.Event) {                   
          dom.GetWindow().Alert("Button clicked!")                                
      })                                                                          
                                                                                  
      select {}
  }

In this case, the Go code looks extremely similar to the JavaScript code because I'm using the honnef.co/go/js/dom/v2 package.  It is a Go binding to the JavaScript DOM APIs and I find that it makes it more convenient than using syscall/js directly.

Why do I prefer this over writing JavaScript especially when they look so similar?   The main reason is that most code is not just calling an API.  There's other logic that are implemented and for those, I can use Go and Go's libraries along with the benefits of a compiled and type safe language. 

There are still things that needs to be considered before just using Go and WASM for general consumer production web app.  The binary size can be large so it needs to be considered for your audience, but if I'm doing my own hobby project for myself or corporate apps where I know the user have fast connections, or if app performance and functionality outweighs the initial download and memory usage, I'd try to use it.

Using AI/LLM to Implement a News Headline Filter

There are news topics that I'd rather avoid being bombarded with, but options for filtering headlines on the news sites are generally very limited.  You can tell Google News to block certain sources and there's an "fewer like this" option which doesn't seem to do anything, but neither will block topics (e.g."politics", "reality TV shows", etc. ) so you still end up getting bombarded with things you don't want to see even in your "personalized" views.  Fortunately, sites like Google News provide RSS feeds that makes it easier to get the list of headlines, links and descriptions and avoid trying to scrape websites which can be brittle as the sites can change their layout at any time.

I decided to write my own filter take out things that I'm not interested in and publish the result to a site that I can access from any browser.  The simplest way (and one that doesn't even need site to host the result) is to have a list of blocked words and drop any headlines with those words.  As long as the app can access the RSS feed even a mobile app can easily handle this kind of filtering, but creating and maintaining an effective block list becomes a challenge.  A political news article isn't going to be "Political Article on City Council Votes On Artificial Turf at Parks.  This is a good use case for using a language model to categorize a headline instead of using a keyword filter.

I created a prompt in natural language explaining what I don't want to see along with some additional details to add to common definitions and then sent my instructions with the list of headlines to the language model and have it return a filtered list:

Remove all political headlines.  Headlines that includes political figures, and celebrities who are active in politics such as Elon Musk should also be removed.

Being able to use natural language to handle categorization makes it so much easier to build the app.  The categorization would've been the most challenging part of the project, but the LLM allowed me to get good results very quickly (took just a few minutes to get the first results but some more time to tweak the prompt).  Another benefit with the large language models such as Gemini is that it understand multiple languages so while I gave my instructions in English, it can filter headlines in French, Chinese, Japanese, etc.

Using an language model does mean giving up some control such as relying on what the model interprets "political" to mean.  Prompts can help refine the model's interpretation but sometimes a headline makes it through the filter and it is not as easy to determine compared to being able to see the algorithm and determine the reasoning.

I encountered a problem where the LLM's response stopped midway.  This was because  LLMs have limits on input and output tokens (how much info you can send out and the size of the response it will send back).  The input token limit is so high that I'm not likely to have enough headlines to even remotely approach it's limit (Gemini is 1 million tokens for the free tier and 2 million tokens for the paid tier and I'll be using around 20,000).  The output limit is much smaller (~8k) so if I wanted it to send back the complete details of the filtered headlines (title and link) it won't be able to.  To address this problem, I send the LLM the headlines with an index and have it return just the index.  If it was a 100 headlines then size of the output is less than 200 tokens.

A cron job will execute the program and write the result as JSON to the server where the web page will load the JSON  and display the headlines:

The code is on Github and you can see it is very simple program.

Add Build info to a Go Binary

Having the build info directly in a binary is useful in helping to identify one binary from aonther especially if you do a lot of compilations.  Manually updating that information in to the source before build is cumbersome and error prone so it's better to automate it.

This can be done in Go using -ldflags with the build command.  For example, if you have a main.go file such as this:

package main                                                                    

import "fmt"
var(
    build string
)

func main() {
    fmt.Printf("build date: %v\n", build)                            
 
)

Then you can build it with -ldflags to change the value of build with the current date when using the go build command:

go build -ldflags "-X main.build=`date`" main.go

Be careful that other parts of your program doesn't change the value during runtime since it is just a variable.

To make it a little safer, you can put the variables into another package and don't allow it to be updated.   You can, for example, create a package called "buildinfo"

package buildinfo                                                                      
                                                                                   
var (                                                                              
    builddate = "0"                                                                
)                                                                                  
                                                                                   
func GetBuild() string {                                                           
                                                                                   
    return builddate                                                               
}                                                                                  

that is called by your main.go:

package main                                                                       
                                                                                   
import (                                                                           
    "fmt"                                                                          
                                                                                   
    "example/buildinfo"                                                                
)                                                                                  
                                                                                   
func main() {                                                                      
                                                                                   
    fmt.Printf("build date: %v\n", build.GetBuild())                                                             
                                                                                
}

You will then build your application with:

go build -ldflags="-X 'example/buildinfo.builddate=`date`'"

Running the program will now output something like this:

build date: Thu Jan  5 12:33:38 PM

Keep Go Module Directory Clean with GOMODCACHE

Go makes downloading projects and their dependencies very easy.  In the beginning there was go get which will download the project source code and its dependencies to $GOPATH/src.  With modules, all the dependencies are downloaded to $GOPATH/pkg/mod.  The ease of downloading and the lack of management control in the go command means that is easy for the two directories to grow in size and to lose track of which project led to the download of a particular package.

I recently started to play around with the Fyne UI toolkit.  I didn't initially know what other packages it would download so I wanted to have Fyne and its dependencies in their own area.  The go command has a flag -pkgdir that is shared by the various commands.

The build flags are shared by the build, clean, get, install, list, run, and test commands:

...

-pkgdir dir

install and load all packages from dir instead of the usual locations. For example, when building with a non-standard configuration, use -pkgdir to keep generated packages in a separate location.

This didn't work as I expected because it didn't seem like it did anything at all.  Using the command

go build -pkgdir /tmp

resulted in all the downloaded package still going to $GOPATH/pkg/mod.

What did work (thanks to seankhliao) is to set the GOMODCACHE variable which sets more then the cache location but also the package location:

GOMODCACHE=/tmp go build

All the downloaded dependency packages will now be downloaded to /tmp rather then $GOPATH/pkg/mod.  

Honestly, I'm not really sure what -pkgdir is really suppose to do.  Maybe it is only for things that the build command generates?  Why does it do when using with go get?

Local Go module file and Go tools magic

I really value that when working with Go there are no "hidden magic" in source code.  Go source code are essentially WYSIWYG.  You don't see decorators or dependency injections that might change the behaviors after it is compiled or run that requires you to not only have to understand the language and syntax but also having to learn additional tools' behavior on the source code.  While this is true of the language it is not true of the go command for Go's module system.

I've personally found Go modules to be more confusing then the original GOPATH.  I understand that it solves some of the complaints about GOPATH and also addresses the diamond dependency problem, but it also adds complexity to the developer workflow and under-the-hood magic. Maybe that's to be expected when it is going beyond source code management and adding a whole package management layer on top, but I'd be much happier to have to deal with this added complexity and burden if the solution was complete (how about package clean up so my mod directory isn't growing non-stop?)!

Modules adds the go.mod file that tracks all a project's dependencies and their versions.  This introduces a problem when one is developing both applications and libraries since it is possible that the developer have both the released production version and in-development version of libraries locally.  To point your application at the library without constantly changing the import path in source code, the replace directive can be used, but when committing the code it is not ideal to submit the go.mod with the replace directives in it as it will likely break the build for someone else checking out the code and can expose some privacy data (the local path that might contain the user name).

Now developers have to add the replace directives locally, remove them right before submission and then put them back (without typos!).  Fortunately, in Go 1.14, the go commands (build, clean, get, install, list, run, and test) got a new flag '-modfile' which allows developer to tell it to use an alternative go.mod file.  The allows a production version of go.mod file to not have to be modified during development/debug and a local dev version of go.mod that can be excluded from getting committed (i.e. .gitignored).  

This can be done on a per-project level by adding -modfile=go.local.mod to go [build | clean | get | install | list | run | test]:

go build -modfile=go.local.mod main.go

Note that whatever the file name is, it still has to end on .mod since the tool assumes to create a local go.sum mod based on a similar name as the local mod file except with the extension renamed from .mod to .sum.

To apply the use of go.local.mod globally, update "go env":

go env -w GOFLAGS=-modfile=go.local.mod

go env -w will write the -modfile value to where Go looks for its settings:

Defaults changed using 'go env -w' are recorded in a Go environment configuration file stored in the per-user configuration directory, as reported by os.UserConfigDir.

So the flow that Jay Conrad pointed out in this bug thread would be as follows:

1. Copy go.mod to go.local.mod. 
2. Add go.local.mod to .gitignore.
3. Run go env -w GOFLAGS=-modfile=go.local.mod. This tells the go command to use that file by default.
4. Any any replace and exclude directives or other local edits.
5. Before submitting and in CI, make sure to test without the local file: go env -u GOFLAGS or just -modfile=. 
6. Probably also go mod tidy.

Building GUI applications with Go (Golang)

Go is my favorite programming language.  I have mostly used it for writing command line programs or server-side services so I was not familiar with using it for writing GUI desktop applications.  Questions about using Go for writing GUI applications come up periodically on Reddit or Hacker News with some saying that Go is not appropriate for GUIs while others argue the opposite.  

I decided to take an existing command line program that I've written and put a graphical interface on it using different GUI frameworks/tool kits that are available.  The program's purpose is very simple.  It checks for the latest stable version of Go for your system and if there is a newer version then it downloads it.  Once the file is downloaded, it verifies the checksum to make sure that it correctly downloaded a good file.  The UI will simply show the information (where to save, the version to download, the checksum) and a button to start downloading.  During download, a progress bar indicates what is happening. 

The code can be found at https://github.com/lazyhacker/getgo with the GUI files in the internal/gui package.  gtk.go and fyne.go are for GTK and Fyne respectfully.

TLDR;

Go is perfectly capable for writing GUI application as far as functionality.  There are tried-and-true toolkits such as GTK and QT and emerging ones such as Fyne and Gio.  The former being more polished but with an extra layer of non-Go code between the app and the graphics layer and a higher learning curve.  The latter's tooling, visualization documentation and functionality are less developed.  

Where all of the options fall behind some other languages is in its developer friendliness in the form of documentation.  

GTK do have a lot of documentation and many users who have posted answers on forums, but the documentation is based on another programming language.  

Gio and Fyne are more lacking in documentation and tutorials so it can be more frustrating for beginners looking to learning or find answers.  Although the general concepts might be more easily understood since they aren't as big of a system as GTK.

All the toolkits I tried rely a lot of providing code examples as a form of teaching, but the examples aren't very well documented or discoverable making them less friendly to developers.

Binary size for my simple program are:

• command-line only ~6M
• command-line + GTK GUI ~9M
• command-line + Fyne GUI ~14M

GTK does require for the shared libraries to be available on the system (they aren't compiled into the above binary) so they will need to be bundled in.

It took me about a day to write the Fyne version and about 2 days for the GTK version.  I also had to spend a day to figure out how to get both to compile and run on Windows.

Choices

There are actually many choices available to Go developers for building GUIs.  I think the perception that Go isn't a "GUI" language could be because:

1. A number of GUI projects have been abandoned.  
2. There is no single "blessed" GUI framework from the Go team.  
3. There are no fully native Go implementation of a GUI toolkit.  

(1) I don't think this is unusual given the complexity of developing a GUI framework that there are a lot of abandoned GUI projects.  What is more important is what is available that is actively maintained since there are always many abandoned projects in any language so don't let the noise give you the wrong impression.

(2) Although there are some languages that comes with a GUI toolkit as part of the language (e.g. Java, Swift), most language don't.  Go can feel like its a "batteries included" language with its rich standard libraries (e.g. it basically comes with a HTTP server) so with no GUI options it could lead to the misconception that the Go team doesn't believe that Go should be used for GUI apps.  However, a lot of languages don't have one either (C/C++, Python, etc.)

(3) This really depends at what is the definition of a fully native Go implementation:  

• Can app developers everything in Go?  Can it be written in an idiomatic way?
• Can the entire project just depend on the Go tool chain?
• Is the whole tech stack built with Go?

With the exception of the tool kits whose philosophy are to combine Go for backend logic and another language for the front-end GUI (e.g. javascript), most of the options let the developer write everything in Go.  The Go tool chain includes cgo for interfacing with C code so even if the toolkit is dependent on C libraries (e.g. OpenGL, GTK/Qt, etc.) the app developer don't really have to deal with other tool chains except maybe have some be installed for cgo to access. 

Having the whole stack be written in Go is not realistic.  With the exception of C, every language at some point have to deal with the lower level of the system (whether it be the graphics subsystem or OS) that is written in another language).  

Personally, as long as everything I write is in Go and only the Go tools are used than that is "native" enough for me.  As an applications layer developer, I don't expect to be working on the GUI underpinnings that would require to combine languages and tool chains.  That means there are plenty of options for Gophers (developers that uses Go ) and my evaluation criteria is on some subjective qualities such as how intuitive it is and whether it is easy to learn/use, and some quantitative attributes such as stability. 

With this in mind, the most often mentioned options are Qt, GTK, Fyne and Gio.  Between Qt and GTK, I chose GTK.  Both are these are popular production-level GUI toolkits written in C/C++.  The reason I picked GTK is that I use Linux and Gnome and the admittedly self-perception that installing GTK is easier then installing a Qt dev environment.

I also wanted to try either Fyne or Gio as these are two toolkits that were built with Go.  Both rely on go-gl (which in turn depends on OpenGL) to deal with the graphics subsystem to draw the interface and widgets so they don't that extra layer between the app and graphics system being occupied by another framework like GTK and Qt.

Gio (https://gioui.org)

The first GUI toolkit that I tried to look at is Gio.  It wholeheartedly embraced everything Go and the latest-and-greatest.  It allows compiling to desktops, mobile, and WASM (web assembly).   It supports Go modules (common) and drops GOPATH support (uncommon).   Its embrace of immediate mode GUI programming is kind of Go-like in its belief that it's not always necessary to give up control to a framework.

Installing Gio to be ready to use is very easy.  Make sure the system already installed the wayland/X11 and OpenGL development libraries.  A simple 1-line install from dnf, apt or whatever Linux package manager will likely suffice.  Then it is a simply importing the package in your Go code and during the first compile, Go will pull down Gio and all its dependencies through Go modules.

However, I quickly moved away from Gio for a couple of reasons:

1. It lacked documentation to help a new user understand how to use it and I found the existing documentation to poorly organized.  It primarily relies on code examples and API comments and then leaves it to the users to figure out for themselves how to use it.
2. While immediate mode gives more control to the developers, building GUIs is one area where there's enough complexity that I don't necessarily mind handing it off to a toolkit to take care of things.  I wonder whether immediate mode is actually more useful to developers who build GUI tool kits then developers who use the tool kits.

I might come back to Gio some day when I have more time to learn it.

Fyne (https://fyne.io)

Fyne is a more standard retained-mode GUI tool kit that is easy to install.  It is similar to Gio in that you just need to use your package manager to install the graphical development libraries and then just import Fyne to have it download all the necessary packages and dependencies.  Unlike Gio, it also support the traditional GOPATH method if you don't use Go modules.

The document was much more comprehensive feature an quick beginning walk-through, tutorials and API documentation.  What holds by Fyne a little is in the organization of the documentation which required me to do quite a bit of jumping between sections to understand something.  For example, one section talks about a widget but it is somewhere else where it shows what the widget actually looks like.

I was able to put together a basic interface pretty quickly with Fyne thanks to its basic tutorials.  While getting something working quickly is a plus, I'll admit that I did not find the graphical elements very attractive.  It seems to be embracing material design in some form but feels like it's incomplete.  Extending the look and feel is also difficult at the moment. 

Although I mentioned that I got a working GUI up quickly, I was immediately met with a bug.  The app would start and all the components would draw in the window before it would suddenly turn blank.  Resizing or hovering over a particular widget would bring the interface back.  I only saw this on my Linux system.  I reported this to Fyne and got a response pretty quickly asking me for more info and some follow up questions.  It's good that the Fyne developers are keeping an eye on bug submissions!

Microsoft Windows 

To compile and run on Windows basically requires installing Windows version of gcc.  Fyne's install instructions gives 3 options (msys2+MingW-64, TDM, and Cywin) for GCC.  I went with msys2 + mingw64 as msys2 is also the recommended way to install GTK.

Once msys2 was installed, I installed the mingw64 gcc package through the msys2 shell:

> pacman -S mingw-w64-x86_64-toolchain base-devel

Note: If you want to use the GCC outside of the MingW shell (e.g. with cmd.com), you need to add:

• C:\msys2\mingw64\bin
• C:\msys2\usr\bin

to the Windows PATH variable.

After getting MingW GCC installed, I tried to compile and promptly ran into a compilation error about undefined references.  After much digging, I found the solution to be deleting the go-build cache that is in %USERPROFILE%/AppData/Local/go-build.

Gotk3 (https://github.com/gotk3/gotk3)

To use GTK 3 with Go requires gotk3 which provide Go bindings to GTK's APIs (including glib, gdk, and others).  There is also go-gtk which provides GTK 2 binding.

gotk3 has installation instructions on its wiki.  Installing on Linux and MacOS is very simple similar to Gio and Fyne.  For Windows, as with Fyne, it requires installing msys2 + mingw-64.

Although GTK has extensive documentation and tutorials, it's mostly for C or Python.  gotk3's documentation, unfortunately, consists of mainly of comment that is just the C function name.  It doesn't even provide a link to the C documentation so you're required to find it yourself.  For the few APIs that has it's own gotk3 comments, they dropped the C function name so you will have to figure what the Go function maps to. 

gotk3 also follows the "read the code" school of teaching.  Here they have a directory of example code but little explanation of what it is an example of of.  The user is left to decipher all the example codes to form an idea of how the gotk3 works and what is available.   What I ended up doing was to go through and learn GTK in C first and then try to map the concepts to the gotk3 APIs.    This isn't the most friendly way to introduce a Gopher to GUI development with gotk3 but might be okay for a C GTK developer coming to Go.

Of course, on my very first compilation, I get an error message:

go: finding module for package github.com/gotk3/gotk3/gtk

go: found github.com/gotk3/gotk3/gtk in github.com/gotk3/gotk3 v0.5.0

# github.com/gotk3/gotk3/gtk

../../gopath/pkg/mod/github.com/gotk3/gotk3@v0.5.0/gtk/gtk.go:5369:14: _Ctype_struct__GIcon can't be allocated in Go; it is incomplete (or unallocatable)

Fortunately, there was already a bug filed and a solution was already committed.  I had to force Go to use a newer version of gotk3 then what's has been tagged as the stable version:

**Update for go 1.16 4/3/2021**  Another bug came up when trying to use go 1.16 and it looks like a fix made it to the master branch so the same workaround for the previous bug will now also work.

In the project directory:

go get github.com/gotk3/gotk3/gtk@master 

Microsoft Windows

While getting GTK installed on Linux was trivial, it takes a bit more effort on Windows, but the GTK page is very clear.  If you'll be doing everything within msys then there's not much more to do.  If you want to use build in another terminal such as cmd, then you'll need to add the mingw bin path to the %PATH% variable.

There seems to a compatibility issue between gotk3 and GTK that requires remove the -Wl flag from gdk.3.0.pc which is captured in the gotk3 wiki for installing on Windows.

Google Pixel Slate - Mobile Workstation

I found myself needed a new tablet when my Pixel C tablet died.  The Pixel C was a very nice Android tablet and I've gotten used to that form factor (10").  I mainly use a tablet at home and primarily for consuming content such as reading and watching videos as well as handling some home automation controls.  For Android, I prefer the stock Android experience which I'm most comfortable with, but with Google having stopped making Android tablets (including the Pixel C) there aren't many options out there so I decided to give the Google Pixel Slate a try.

Pixel Slate & ChromeOS

Despite sharing the "Pixel" name the Pixel Slate is a ChromeOS device and Google's first (and only?) ChromeOS tablet.  I'm a big fan of ChromeOS but have only used it as a laptop.  Even when I'm using the Pixelbook, which can flip to be used in tablet form, I've only used it as a laptop since I find  it too bulky to use as a tablet.  The Slate doesn't come in a 10" form factor (ASUS has released a 10" ChromeOS tablet that has been excellent) and is only available with a 12" screen.  While the Slate can be viewed as a Pixelbook without a keyboard, that doesn't do it justice since it feels a lot more comfortable when held then a keyboard-less Pixelbook.  Still, I was somewhat hesitant to use a 12" tablet, but there are additional advantages with the Slate that ultimately led me to get it: Android support, Linux support and laptop mode.

When a keyboard is attached, it behaves just like a ChromeOS laptop.  This is essentially a 2-in-1 device which is useful when traveling since I don't need to bring a tablet and a laptop with me.

ChromeOS also don't get re-skinned like the Android launcher by OEMs so the experience is the same across all devices across all manufacturer.

Android Apps

ChromeOS now supports running Android apps so I can still access my Android apps although I prefer to use the web version since I now have a full Chrome browser.  In tablet mode, though, some apps are much more intuitive to use the Android version.  It's pretty clear that many web applications assume the user is using a desktop machine rather then one that uses touch as it's main interaction mode.   These are the times when the Slate will give the impression that ChromeOS is not very polished when compared to Android but in general it seems to be more on the app developer then the OS.

I have noticed that sometimes Android apps tries to start and either takes a while to come up or run into an issue.  I usually restart the tablet in these situation and the issue is fine.

Linux

ChromeOS is now capable of running Linux so I can do all my software engineering work without having to switch to developer mode. 

This a big deal for me as this allows me to just bring the Slate instead of a tablet and a laptop pair.

Accessories

I mainly will use laptop mode when I'm traveling.  While the on-screen keyboard works fine when I'm  using the Slate at home as a tablet, when doing a lot of typing it is still easier to have a physical keyboard.  I bought the Brydge C Bluetooth keyboard.  This keyboard can also be connected directly to the Slate and used in wired mode.

For a mice, I use the Microsoft Surface mouse and I have a Pixel Pen.

At home, I use a hand strap to make holding the tablet with one hand a little more secure and when traveling I use an Incipio Carnaby Google Pixel Slate Folio  case for a little bit of protection, to stand up the Slate and can hold the pen.

Performance

The knock against the Pixel has been (1) performance and (2) sometimes it doesn't feel very "tablet" like.  The latter is primarily because the web apps often are built assuming you're using a mouse+keyboard and android apps often are designed for such a big screen.  I personally found it to be fairly minor but if you use Android apps exclusively then sticking with a Android tablet might be better.

For the former, most of the negative stems from the low end Pixel Slate that were too under powered.  I have the i5 model and the performance has been fine.  The only time where I felt the Slate is slow is when powering on.   It takes a few seconds after hitting the power button before seeing the Google logo appear (this is when the Slate is completely turned off).  Recovering from Sleep is fast and the screen can be unlock with your finger print.

Conclusion

The Pixel Slate is a great dual purpose device.  When used as a tablet it works pretty well but starting Android apps don't feel as fast.  When used as a Chrome laptop, add the keyboard, mouse and folio case and it will be a very serviceable laptop especially for traveling or as a secondary computer (and primary tablet).

Upgrading to Fedora 28

It's time to do another Fedora upgrade. 

I generally use the command line tool to upgrade from Fedora 27 to Fedora 28.  The first upgrade went without a hitch.  On a second machine, I ran into a dependency problem requiring that I install the Fedora 28 version of the nss-pem package before starting the upgrade

# dnf install nss-pem-1.0.3-9.fc28 --releasever=28

Fedora 28 has the latest version of Go (version 1.10) which is very nice.  I haven't paid attention to what the previous versions of Go Fedora comes with since I also install the latest version that is released on golang.org.

Go with WebAssembly Early Examples

Update:  I've since written an updated article about Go and WASM since a lot of have changed in the time since this article was posted.

WebAssembly (WASM) is the most exciting technology in web development in a long time from my perspective.  It represents the first true steps in breaking the monopoly of Javascript as the language for the browser even though the WASM folks emphasize that isn't the intention.  In my previous post, I mention that Go will support compiling to WebAssembly in version 1.11.  This post shares some of my experimentation with Go's WASM support and to see what might be possible.  Let me emphasize that the code is very hacky.  I wrote them quickly mainly so I can try out WASM. 


There are multiple ways to use WASM for web applications:

1. Optimization for JavaScript-driven applications - This is the scenario most emphasized for the current level functionality provided by the initial (MVP) release of WASM.  Instead of writing everything in pre-compiled Javascript, optimized WASM modules are called by JavaScript.  These modules can be written in JavaScript or other languages that can compile to WASM.
2. Porting existing code bases over to the browser - This is most often demonstrated with porting existing C/C++ code bases over to WASM through Emscripten and running what might previously been an exclusively desktop/native app (e.g. Autocad, games, etc.).
3. Writing an web app completely in a non-Javascript language - This is what I'm most excited about!  Instead of having Javascript be the primary language, the application is completely written in another language such as Go.  At the time of this writing, this isn't completely possible since WASM doesn't support WASM modules from directly calling the browser APIs (e.g. DOM APIs, XHR, etc.).  This will be coming and is currently covered under the Host Binding proposal for WASM.  Until then, the Javascript can be abstracted away in a language-specific binding.

The current state of Go WASM doesn't fit the first scenario very well.  There doesn't seem to be a way to expose methods individually for Javascript to call directly.  The Javascript code can execute each Go program's main function and when main() is done the module is done running.  Given that each WASM module has the complete Go runtime including garbage collection, I'm not sure how practical it is to have a bunch of Go programs that are essentially meant to be single methods to the Javascript code.

Go WASM does provide the ability to define callback methods and attach callbacks to browser events.  This requires that the module is running because once it exists it's not longer available to the browser call call.  Because of this, Go WASM is currently most appropriate for scenarios 2 & 3.

The browser executes Javascript and WASM in a single threaded manner.  When the WASM module is running, the browser's front end will block until it is completed.  This will appear to the end user as if the browser is frozen: no way to type input, click button, etc.  With Go WASM, control is given back to the browser when using time.Sleep or when the Go code is blocked.  This has to be done manually by the developer so it's important to keep it in mind.  Unless the apps expect to have completely control of everything in the browser while it is running developers need to remember to periodically sleep itself to give some control back to the browser.   I hope this gets improved in the future because it makes the code ugly, error prone and honestly isn't something developers should need to do in a multi-tasking environment.

Example 1

Complete source is here. See it running here.  

This is a very basic example of writing a Go WASM module that defines a method that gets attached to a HTML button's click event, change some attributes of the document's elements, waits a few seconds then executes a Go routine that draws to the canvas in the browser.  The keepalive() function prevents the module from quitting until it gets a quit signal that happens when the Quit button is clicked and the cbQuit method is invoked because the button click event is triggered.  Also note that when the browser's Alert dialog is triggered, it blocks everything until it is dismissed whether it's called by JavaScript or by the Go code.

The keepalive() can also simply be

select {}

if the intention is just not let the module exit.

--- ---
The basics of having Go drive the web page (rather then it being Javascript) is all there.

Example 2

Complete source here.  Running example here.

This example was inspired by what was presented at GopherCon by Hana Kim when gomobile was first announced.

Instead of re-writing Rob Pike's Ivy Interpreter for Android/iOS/command-line the example showed that the existing Go library was reused.  Just like her example, this example shows that existing Go libraries can be used in WASM.

--- ---

The resulting WASM module is about 4MB but when compressed, the whole web app was only about 1 MB.

This example really doesn't show anything that the previous example didn't already show. I wanted to try against a larger code base and didn't want to write it myself.  It mainly just demonstrates an existing Go library being used with no changes needed to make it work.

The Ivy code is easy to port but if something is expecting to access a file system or make HTTP calls then the browser environment doesn't match.  There isn't any standard file system and outbound calls uses XHRHttpRequest rather then the current HTTP package.

Conclusions

It is possible to use Go to write web applications even though it currently still needs to rely on JavaScript to access the brower's APIs.  Things like Go routines work but developers have to handle sleeping themselves in order to not block the UI.  However, the possibility of ending JavaScript's monopoly for being the browser's language is definitely there!

Browsers themselves still need to do some optimizations.  Each WASM module's byte code still has to be compiled so there's always a delay before the module starts running.  It still starts faster then JavaScript but it'd be much better if the browsers caches the compiled WASM the first time.  My understanding that it'll likely come in the near future but not there yet.

I'm very excited to see this land in Go 1.11 and look forward to see what other developers use it for!

WebAssembly (WASM) with Go

This is the first time that I've tried to compile the Go compiler so I figure that I'll document it here for others who might be wanting to try WASM with Go before the official Go release in August.

The next release of Go (1.11) is scheduled for Aug and it will be first time WebAssembly (WASM) will be supported.  WASM will be a build target much like how one builds a binary for other machine and operating systems except that in this case the machine is a "virtual" machine that runs inside the browser.

I've been very excited for WASM and I've been eagerly waiting for the time when I can use Go to write WASM.  The branch for the 1.11 release has is now locked for only bug fixes so I figured that it might be a good time to try writing a WASM code with Go.

Note that this first release for WASM isn't going to be "production" ready.  I don't think it'll be very optimized and WASM itself is only at its MVP release it doesn't allow WASM code direct access to the DOM or the browser APIs so all calls is still going through JavaScript.

Unfortunately, as of this writing, the code in the Go repo doesn't work for WASM.  The work on WASM for Go is primarily being done by Richard Musiol (neelance), the author of GopherJS, so I decided to get the version Go from this GitHub repo.

First, you will need a version of Go on your system to compile the source.  The easiest way is to download and install the binary distribution from the main Go website.

Until 1.11 is released to get WASM is to build from source.

git clone https://go.googlesource.com/go
cd go

Once you have the source, it's time to compile it.

cd src
./all.bash

If everything is built correctly then there will be a new "go" binary in ../bin.  Also, there are two files to help you get started with loading future WASM files in ../misc/wasm.

Create a test.go file:

package main

func main() {
    println("hello, wasm")
}

Compile to WASM with:

GOOS=js GOARCH=wasm go build -o test.wasm test.go

Make sure you're running the go command that you've just built and not the version that you installed originally.

In the same directory with your test.wasm file, copy over wasm_exec.html and wasm_exec.js from misc/wasm.

The browser will expect the test.wasm file to be served with a MIME of application/wasm so you'll need to add the following to your /etc/mime.types file:

application/wasm wasm

To run it in your browser, you'll need to have a web server.  Creating one with Go is easy, or you can also use Python with the following command.

python -m SimpleHTTPServer

Point your browser to your web server and load wasm_exec.html.  Click on the button and you should see "hello, wasm" appear in the browser's console.

I've been experimenting with WASM here.

My First GopherCon

Being a member of the Go team allowed me to attend my first GopherCon in Denver from July 13 to July 15. This is the 4th GopherCon to be held and previously I’ve only watched the recordings of the sessions on the Gopher Academy Youtube Channel.

Moving from Blogger to Hugo

I really liked Blogger and I’ve hosted my blog on it since 2011. It was free (still is), but still had all the essentials features for a blog at the time and I like that it was integrated with Google.

My blogging needs haven’t changed since then but the world have evolved and Blogger no longer have all the essential features necessary for a blogging platform. Specifically, I’m talking about Blogger’s lack of support for SSL/TLS for custom domains. I could accept the dated editor controls, quirkiness in the WYSIWYG UI, and limited customization of themes, but there’s no excuse for not having https enabled on a web site anymore.

I’ve now moved Lazy Hacker Babble from Blogger to Hugo + Google App Engine. Hugo is a static site generator written in Go. It takes your markdown file and generates an entire web site consisting of static files so it doesn’t require databases runtimes, extra libraries, etc. Since it’s written in Go, Hugo comes as a stand-alone binary so there is no need to install a bunch of extra software in order to run it.

Setting up HTTPS on App Engine With a Custom Domain

The Go programming language provides a great tool, go get, to fetch packages.  A common use case is to get a package that is hosted on Github:

Updating VIM for Go (Golang) Development

Since my last post, setting up Vim for Go development is not only easier but also makes developing with VIM much more powerful.  Just a single plugin, vim-go, is all that is needed for the Go-specific stuff and a host of new tools is now available to handle things like refactoring, linting, error checking, and more.

Go Tools

Make sure that you have Go installed and then get the various Go tools.

goimports

Go provides a lot of use packages that can be imported but it doesn't like it when you import a package and not use it.  Goimports will automatically insert the right imports for you by looking at your code and will remove unused imports from your source.  It's a great time saver!

go get golang.org/x/tools/cmd/goimports

godef

Godef lets you jump to the location where a symbol is defined.

go get -v code.google.com/p/rog-go/exp/cmd/godef
go install -v code.google.com/p/rog-go/exp/cmd/godef

golint

Golint will lint your source and warns you of potential issues.

go get github.com/golang/lint/golint

gorename

Gorename helps to refactor Go code.

go get golang.org/x/tools/cmd/gorename

errcheck

Errcheck checks your code for actual errors that isn't just lint issues.

go get github.com/kisielk/errcheck

gocode

Gocode provides autocomplete of your Go code.  When combined with vim-go and YouCompleteMe plugins, it allows autocomplete to appear as you're typing.

go get -u github.com/nsf/gocode (-u flag for "update")

It's a bit different for Windows so follow the instruction from the link for more details.

gotags

Gotags generate tags for Go code.  Combined with Tagbar, it will provide a pretty display of the tags in your code.

go get -u github.com/jstemmer/gotags

Guru

Guru is a tool that integrates with editors to help it understand Go code.

go get golang.org/x/tools/cmd/guru
go build golang.org/x/tools/cmd/guru

Oracle (Deprecated and replaced by Guru)

Oracle is a source analysis tool for Go program.

go get code.google.com/p/go.tools/cmd/oracle

Vim Plugins

It used to be that you would manually install a vim plugin for each of the various Go tools as well as using the the plugins that comes with Go itself.  Now, everything has been consolidated into a single Vim plugin, vim-go, and that's all you really need when it comes to Go-specific plugins.  A few other plug-ins such as Tagbar and YouCompleteMe are useful to complement your development environment, though.  I highly recommend that you use Vundle to manage your plugins.

vim-go

Vim-go brings together all the various plug-ins and feature for Go development in VIM including autocomplete, snippet support, improved syntax highlighting, go toolchain commands, etc. in a single package.

YouCompleteMe

YCM is a fast code completion engine for VIM that works as you type.  YCM requires VIM 7.3.584 or above and CMake (you'll need to compile the extension after it's downloaded).

Tagbar

A great way to view the tags in your code.  This requires that you have Exuberant Ctags and gotags installed.

Bufexplorer

My favorite plugin for navigating between VIM buffers.

.vimrc

" Go Specific Stuff
                                                             
au BufRead,BufNewFile *.go set filetype=go                                     
autocmd FileType go setlocal softtabstop=4
autocmd FileType go setlocal shiftwidth=4
autocmd FileType go setlocal tabstop=4

" go-def settings
let g:godef_split=2
let g:godef_same_file_in_same_window=1

" go-vim settings
let g:go_fmt_command = "goimports"
let g:go_highlight_functions = 1
let g:go_highlight_methods = 1
let g:go_highlight_structs = 1

" tagbar settings                                                                  
let g:tagbar_type_go = {
    \ 'ctagstype' : 'go',
    \ 'kinds'     : [
        \ 'p:package',
        \ 'i:imports:1',
        \ 'c:constants',
        \ 'v:variables',
        \ 't:types',
        \ 'n:interfaces',
        \ 'w:fields',
        \ 'e:embedded',
        \ 'm:methods',
        \ 'r:constructor',
        \ 'f:functions'
    \ ],
    \ 'sro' : '.',
    \ 'kind2scope' : {
        \ 't' : 'ctype',
        \ 'n' : 'ntype'
    \ },
    \ 'scope2kind' : {
        \ 'ctype' : 't',
        \ 'ntype' : 'n'
    \ },
    \ 'ctagsbin'  : 'gotags',
    \ 'ctagsargs' : '-sort -silent'
\ }