I had a recent project that I built with go 1.3. It was a small project ( < 4 weeks ) but it had some interesting requirements -- my app had to be deployed to ARM (raspi), and on an OSX laptop for control, and I use a linux laptop.
The cool part was that it "just worked".
GOARCH=arm go build myapp.go
GOOS=darwin go build myapp.go
go build myapp.go
All three "just worked" with absolutely no surprises, including use of the http engine, json, and a third party serial port library. The native binaries run like a champ.
Looking forward to the continued evolution of golang.
> All three "just worked" with absolutely no surprises
Jeez. That's pretty incredible. As someone who absolutely hates dealing with build configuration it's almost tempting enough to take a closer look at go, despite the fact it's garbage collected and I'd never be able to use it (or, if we're being completely honest, want to).
It's a minimilist, practical language that picks a set of features much different than most popular languages today.
I wouldn't pick it for code golf or a programming competitions, but as someone who's been programming for a long time and haa come to value the ability to make clean, simple code that doesn't break (eslecially in weird ways at bad times), I really enjoy Go and think it actually is a really good, if in certain respects unambitious, language.
They are the people you hear from. A lot of people are neutral. People who get it, but don't care either way. They don't write opinionated blog posts every Sunday to lament or idolize the newest feature in Go.
Indeed, although I feel like there isn't enough of a language to hate. It's so simple and yet packs such a punch when combined with the tooling and stdlib.
I'm an old python hacker, and while I appreciate C/C++ the most I've done with them is set up bridges with ctypes so I can call compiled libraries from python.
Go, to me, feels like it has some of the expressiveness and discoverability of python, with the added bonus of type safety and raw performance of C (for my purposes, at least). For most of my small projects, it fits a nice niche. Any time I need a lightweight HTTP/JSON API to talk with a fancy javascript frontend, Go is slowly becoming my tool of choice -- especially if it may end up on other platforms (including Windows).
When I wanted to learn Go I set aside a Saturday to grok the docs and "getting started" guide, and was surprised to find I finished by 10am (including a coffee break). The language itself is very small, and I found myself successfully "guessing" at structs and function signatures very early.
It's at least worth exploring, especially given the tooling for web, opengl, and android.
It's worth mentioning that I fully expect it to "just work" on windows as well (judging by past testing experience). The only caveat in this particular case is I'm not sure how or if my third party serial port library has been tested on Windows. I'd expect it to run just fine but need tweaking to find the correct handle for the serial port since it won't be as easy as opening "/dev/tty.x"
Back in the day, writing cross-platform code meant knowing the ins-and-outs of each platform you wanted to support and coding specifically for each one. Interpreted languages (like Python) and runtimes (like JRE) take a lot of the pain away, but that means all those programs have a dependency: the interpreter or runtime.
Go isn't interpreted and bundles its runtime inside the executable. That has always been pretty great, but with Go 1.5, the programmer won't even have to run `env GOOS=... GOARCH=... make.bash --no-clean` before compiling for another platform.
With veteran OS and systems engineers working on the language, this is why we can have nice things.
> Back in the day, writing cross-platform code meant knowing the ins-and-outs of each platform you wanted to support and coding specifically for each one.
If you mean C and C++ POSIX behavior, yes.
If you mean native languages with rich runtimes like Ada and Modula-2, not really.
Finally Go doesn't get rid of OS specific stuff like pathnames, security, ...
I'm really looking forward to see more tools ported to go. The simplicity of copy/paste deployment is really something you don't realize until you've experienced it.
Now, the simple idea of installing python and dependencies then doing pip install for wal-e installation, made me search for an hour on git in hope for a standalone golang binary.
How well does this work in practice? I mean for a web server don't you still have to hook up _something_ in the server (at least to start up the binary)?
I mean in _theory_ setting up a Django webserver is just a ./manage.py runsrever but in practice there's a lot of stuff to fix up
Super easy to setup - way easier than manually writing init scripts - and it'll handle things like auto-restarting the process if it dies (if you want it to).
It also supports dependency chaining (e.g. before starting the web service, start the DB)
I concur - just set up a couple of sites (written in go) and use Supervisor - its a nice tool and pretty intuitive. Using conf file to specify run app as particular user, set environment variables, logs, autostart etc.. - good to have in one place.
Go includes a really good http lib that you can use to handle incoming http connexions. So really, my whole deployment for now is one apt-get for postrges, a golang binary and one json file for configuration, period.
For the service itself i wrote a basic init.d file, but i'll probably use something better ( i see supervisor mentionned, i'll try that).
One could make an argument that with PHP, copy-paste deployment is popular. Of course, it's not quite the same thing, as you'll need Apache/etc. setup, however that is one of PHP's strengths. It's good to see another language doing something similar, but in a nicer, far more performant way: specifically for web development, the way Go does stuff is brilliant in my opinion.
Ah, I was not clear. I mean copy/paste without the need of a runtime. With Delphi (go?) you just ship the exe (and can even put inside it the resources).
Having a kind of packaging for shipping is more or less popular now...
In theory it's also true of ASP.NET. You have a magic folder of CLR-compiled binaries you drop into the IIS site root folder and it "just works" (or doesn't, as the case may be).
If your site does not have a single static or template file, this is true. I agree that the binary is nice but scping it to the server and calling it a day still doesn't work.
In case someone wants to try out this cleanly in a docker or virtualbox without breaking their host machine's golang install, it is now available as a commented-out ansible role in the vagrant box I created over the weekend:
(Instructions for enabling the Go 1.5 role in the repo README ... but in short, just uncomment "- golang-1.5" in playbook.yml, and comment out "- golang" instead, before running "vagrant up docker" or "vagrant up virtualbox").
I haven't checked in a while. Does cross-compiling now support libraries that are implemented in C? As this includes some of the standard library, this seems like a rather large stumbling block.
The cool part was that it "just worked".
All three "just worked" with absolutely no surprises, including use of the http engine, json, and a third party serial port library. The native binaries run like a champ.Looking forward to the continued evolution of golang.