Swift and Go

I have experience in software static analysis and a great curiosity for programming languages. Having some time, this week I could (finally!) take a in-depth look into swift and golang.

Both are sponsored by big companies (apple and google), and there is nothing experimental about them. At the beginning of 2016 there are plenty of big professional projects based on both swift and golang.

I have to confess: I know C and C++, but I come mostly from java world. I’m still a big fan of a modern java based on vert.x, rxjava, quasar: if you can forget (or forgive) the embarrassing job Oracle is doing evolving its standards, there is a big space to use it in a modern way, using its robust and amazing JVM.

But there are worlds where it makes sense not using a traditional virtual machine:

  • Google developed ART for android, to avoid JIT compilation and have less lagging in its apps
  • Apple developed swift to have a more modern language than ObjectiveC for their iDevices
  • Google developed golang for internal use, thinking about its big backend projects

Swift on the dark side

When published, I studied the swift language specification, and I fell in love with it. In the early phases I never had the opportunity to really write swift code, because I’m not a fan of Apple policies: I do not own a mac, and I find it such a closed world. Until Apple open sourced the language itself.
I downloaded and compiled it for linux (my main development environment), and even an unstable windows version.

My conclusion was: swift is a perfect language for backend. It’s functional and object oriented, a little bit a-la-scala, but mostly it reminds me of C#. It’s really really great. Coming from java and other garbage collected languages, I really need to get used to ARC memory management, but that is my problem, and it’s not a limit itself for developing server apps: it probably can be seen as an advantage.

Anyway, it’s already happening: IBM is pushing swift on server with kitura and bluemix. A Ruby on Rail’s inspired framework is on the wild as well.

IMHO, we still need something to happen in order to have a fully operational swift environment on servers:

  • Apple’s package manager will be soon the standard, so it needs to be ready and stable in order to have a decent work flow (similar to npm, for example)
  • Language and library stability: versions must reach some kind of stability, or at least it should be standardize – both for mac and linux – how to install different swift versions (sometime backwards incompatible). Backend development is much more sensible to this issue than mobile development. We can’t accept something like: this is a closed world, we decide, so you must move forward. We really don’t want another pyhton3 vs pyhton2 war!
  • Developer tools, independent from Apple’s dominion
  • Some further attention and care about concurrency

Go on the shiny side (GUI)

My first reaction to go was completely different: I hated it. The first impression was a superficial “Visual Basic” feeling. ARGH! I didn’t spend any time on it more than reading some examples…

But now, after spending some time on it, I really liked many things: the feeling of general simplicity, the ability to have enough low-level control of things, the interaction with C, the opinionated vision on embedding, and concurrency.

It’s somewhat interesting that golang went for a garbage collected memory model. A very interesting choice: I think it’s because it’s easier to deal with concurrency that way. For me it’s definitively a plus, even if there are some caveats (for example C interaction possibilities is limited by the garbage collector presence)

Go for frontend development? at the beginning there was nothing like that, just some unmaintained/experimental projects, but then:

And some other options are available:

  • go-gtk – Go bindings for GTK
  • goqt – Golang bindings to the Qt cross-platform application framework.
  • gotk3 – Go bindings for GTK3.
  • sciter – Go bindings for Sciter: the Embeddable HTML/CSS/script engine for modern desktop UI development.
  • ui – Platform-native GUI library for Go.
  • walk – Windows application library kit for Go.

AFAIK, frontend development in go is still in a experimental stage, but I could be wrong, and I would really like to hear about some professional/big projects developed with it!


Both Apple and Google are betting on static typed languages, both compiled to native, and both great languages, for different reasons. What I really love is the effort that the community is making to free them from the cage they were born in.

Backend and Frontend development: are they so different? Well, yes… and it’s probably a title for a whole book: the problems you face are sometimes very different, but the programming language should not be involved in this fight. Most of the times the differences has more to do with different mindsets, background and history of developers, different maintenance issues, but look at javascript: nodejs and react-native are winning the war, they are crossing borders and they are allowing big companies to reuse their workforce for backend, web and mobile development.

I hope that great languages like go and swift can keep up with this mentality, being widely used not just because of their sponsors, but because of their flexibility.

Original URL: http://feedproxy.google.com/~r/feedsapi/BwPx/~3/mxxxAxOJ5No/

Original article

Comments are closed.

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: