• msd@infoserv.dk
  • +45 21402120
  • Go right

From Go to Nim

I have been using Go to build small project for a while, and I'm now looking into Nim.

Coming from Go to Nim gives certain challenges.

  • Go compiles directly to a binary. Nim compiles to c/c++ and depend on a c-compiler to compile to binary.
  • Go used { } to define blocks of code. Nim uses indention to define blocks og code, like Python.
  • In Go there are one primary terminal command go to manage packages, compile and run your project. Nim has nim for compilation and nimble for package management.
  • go.mod is in Nim called projectname.nimble.
  • go get both download a library and add this library to the local go.mod file. Using nimble install, Nimble downloades a library, but you must manually add the library to the local .nimble file to be able to use it in the project.
  • Go usually has few ways to do something and Nim seems to have many ways to do the same thing, making the code less readable:
    • parentheses can be omitted
    • method can be called with obj.method(x) or method(obj,x)

Go does not warn about modifying content in methods. If the method has a pointer receiver it works, if not, its just changes in the local copy and discarded when the method ends.

It can’t Go on

I have been using Go as my primary language the last 4 years. I have developed several internal tools using Go and for most parts I really like it.

The good.

Its fast on all sides. Fast development time (OK, not Python fast). Fast compile time. Fast executeables.

It's strongly typed. I like to be able to see what a function accepts and returns. It's simple.

It has a really good standard library. Most of the time i have been able to get by using only the standard library. When the standard library is not enough, it has a nice package manager.

It can be updates without breaking code or deployment. I really like the Python language, but the way that Python updates can break virtual environment really nags me. Nice when your code just keeps running.

The bad.

Go tends to be a bit too verbose or detailed. I would prefer a little highter level of abstraction. I have a small library of helper functions to accomplish the most used functions without using Go's low level standard library.

The ugly.

Go is lacking in some language constructs that I would like. Mainly macros, but also optional function parameters.
I understand the value of dumb down the language for large teams, but for personal projects I would like to make such decisions, not have them forced by my programming language.