Sunday, June 17, 2012

#first impressions on the GO programming language

disclaimer: this article will not show much, other than submitting a surface look over the language.


after doing the tour at golang i can say that i like the language a lot. i've also enjoyed watching some lengthy lectures. the syntax is mostly c based, while it grabs a little bit from other languages, yet also introduces some new concepts with an old-school twist.

- easy to get into for everyone with a little bit of background in languages like c, c++, java, python etc. it took me a couple of days to memorize a decent portion of the syntax and library calls.
- the compilers are bit wip at this point, but already very potent at the same time
- easy string and array manipulation
- functions are objects
- adding methods is possible to every type (e.g. primitives - int, float)
- concurrent programming with the goroutines and channels is pretty cool
- package download and install is very easy with the 'go' tool (go get / go install)
- its possible to easily wrap c libraries and program in go (see the winapi example bellow).


there are some huge articles on the web that explain some of the negative sides of go. for me personally i would point out:

- garbage collected - the argument here is that modern runtime execution, can handle heap allocation quite easily. i would say that this is pretty much true for modern machines, but not the case if the same program is brought to older computers. while an optional garbage collector might be a cool feature, to my knowledge this might be a complication. on the other hand, modern java and actionscript 3.0 are proofs that garbage collectors are pretty efficient. i think thought, that this feature alone might be a deal breaker for some purists.
- large executable sizes - not a big issues, but since the go runtime runs on top of an os, which is probably build in c, it statically links all its libraries into one big executable. not that big, but >= 1.x MB, which makes it not suitable for size-programming - e.g. demoscene material. but certainly not a deal breaker for a large group of developers and considering the disk sizes available.
- at this point, remains slower than well optimized c (e.g. gcc -O3) - comparisons

a WINAPI test:

  file: testwinapi.go

  go! winapi test using "go-winapi":

// this package
package main

// package imports
import (

// variables
var (
  oldWndProc winapi.HWND

// constants
const (
  winWidth   int32 = 300
  winHeight int32 = 200

// string to int16(utf) helper function
func _S(_srt string) *uint16 {
  return syscall.StringToUTF16Ptr(_srt)

// window procedure
func WndProc(hwnd winapi.HWND, msg uint32, wparam uintptr, lparam uintptr) uintptr {
  switch msg {
    case winapi.WM_CLOSE:
    case winapi.WM_DESTROY:
  // call original procedure
  return winapi.CallWindowProc(uintptr(oldWndProc), hwnd, msg, wparam, lparam );

// main
func main() {
  var message winapi.MSG
  var hwnd winapi.HWND
  var wproc uintptr

  // create a message box
  winapi.MessageBox(0, _S("some text"), _S("tittle"), 0)

  // create an edit window
  hwnd = winapi.CreateWindowEx(
            _S("test window"),
            (winapi.GetSystemMetrics(winapi.SM_CXSCREEN) - winWidth) >> 1,
            (winapi.GetSystemMetrics(winapi.SM_CYSCREEN) - winHeight) >> 1,

  // create callback, set procedure, show window
  wproc = syscall.NewCallback(WndProc)
  oldWndProc = winapi.HWND(winapi.SetWindowLong(hwnd, winapi.GWL_WNDPROC, int32(wproc)))
  winapi.ShowWindow(hwnd, winapi.SW_SHOWDEFAULT)

  // dispatch message
  for {
    if winapi.GetMessage(&message, 0, 0, 0) == 0 {

  // print handle and exit
  fmt.Println("hwnd =", hwnd);