The Lounge - CodeProject

Go Johnny Go!

Original or Judas Priest's cover?

GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X

If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver

When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani

In either case:
Johnny be good! Poke tongue | ;-P

If you (a programmer) are discussing pros and cons, then that means the decision is not up to you anyway

I think its time for new essay...

Go too Considered Harmful Wink | ;-)

(I'll fetch my coat)

"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.

Rob Grainger wrote:
(I'll fetch my coat)

Thanks Rob but don't worry. I will get it for you.

I did laugh though......

THX

"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980

Looked at it & did a little test harness with it a while back, but (despite some really nice features like goroutines) it didn't quite hit the mark for me. I'm currently writing some stuff in Rust[^], which I like for a variety of reasons - one being the strong, static type system. Oh - and the surrounding tooling (Cargo[^], the all in one project scaffolder/package manager/build tool/test runner, and rustup[^], which lets you manage installed versions of the compiler toolchain) is excellent.

Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p

modified 8-Jul-16 3:48am.

At my last employer, a colleague and I had to learn Golang (what Go is usually called online, because have you ever tried to google a two letter word? I doesn't work out well, usually) to build a API interface for our employer's cloud hosting API. It was to allow another company (Rancher) to be able to deploy Docker containers onto our employer's infrastructure fairly seamlessly.

Learning it and using it was both maddening and enlightening at the same time. First off, we were able to learn it well enough to write our interface after the first week. We then spent another couple of weeks building the interface, then another week polishing it, writing unit tests, etc. Over a few succeeding months we had to make a few changes here and there, but overall it was done and "ship-able". My only regret during the whole exercise was that we were pair-programming to learn and support each other during the entire project, and it was under my colleague's account - so my name hardly (never?) appears in the github project. Oh well, c'est la vie I guess.

It was maddening because Golang enforces the most strict rules you can imagine on you as part of the idea of avoiding bugs by not introducing any. One that really "got us" was the fact that you can't declare a variable, then never use it. You must use it subsequently, or the compiler will hate you. There are ways to get around this, but such means actually make things more difficult for you in the end.

There was also the weird way of how the language isn't object oriented - it is closer to being a modularized functional language (think Javascript and Require.js) than anything else; wrapping our heads around that took a bit of cringing and whining, but we didn't have a choice in the manner, so we soldiered on.

There was another issue we ran into, that had to do with data structures. Golang is fairly strict there; how they are organized on the Golang side (and typed) needs to be the same as what you were pulling from elsewhere; if they didn't match, you had to fix one or the other. Our problem was that our employer's API was originally developed in PHP (we also had a small hand in it - that was our main job - but most of it was there long before we were employed there - legacy code, right?) - and the RESTful interface spat back JSON encoded data that wasn't consistent from call-to-call. This was maddening - we couldn't change the results from the API to make it easier for the Golang side, because that would have broken anyone's code who used the original PHP and RESTful API call. We couldn't coerce the Golang side of things, because the compiler would barf on that (it really didn't like things we tried). In the end, we had to write a "shim wrapper" in PHP to sit in front of the API, and then it would recognize when we were calling that wrapper, and coerce the output into something manageable. Not pretty, but it worked. It also taught us that concise and consistent data structures are damn important. This isn't something we didn't know already, but it was something the original coders of that API didn't know; honestly, we wanted to re-write the entire API, but you can imagine how that sat with management...

That said, over a relatively short amount of time, we grew to appreciate and love this rigidity of the compiler. This system did it's job, in our opinion. It was designed to up-front prevent common coding errors and problems, and not allow you to compile the code into a runnable executable until you had fixed that code. Furthermore, unit testing was pretty much built into the language, and made setting up and working with such tests a breeze (compared to what we had experienced using PHPUnit - which, unfortunately, was a problem from the beginning, because of the way it was implemented in our employer's system - not really a fault of PHPUnit). In time, using Golang showed us just how bug-prone and ridden our PHP code was, and how much better it could be, if we followed certain practices that were explicitly enforced by Golang's compiler.

We tried to adopt these practices, to encourage our direct team to use them (all of them were on board), but we couldn't completely convince our direct supervisor, and we didn't really have the time to fix our entire codebase either - so the effort withered on the vine. Ultimately, the company got sold, the developers were re-hired by the new company, and my direct supervisor and I left (I don't know his situation, but they basically offered me over 10 percent less in salary than I was making, and I was already far below industry standard in my current job market).

After leaving, two months passed and I managed to find another job making close to 30 percent more than I was there, and I now work for a company I hope values me for my skills and abilities. But I am not so naive as to think that is completely true, and that I won't be dropped like a rock should business needs change or something else occurs. Sad, but that's reality.

Overall - give Golang a shot - play with it. I think it to be a worthwhile language to experience and have on your toolbelt for the future. You may never use it at an employer, but then again - if you work with Docker (or any company using Docker tools) - you very well might. I hope this helps!

Wales by a whisker!!

I'm just wondering what percentage of CP members can't pronounce "Cymru".

I'm betting that the number would start with a lot of nines.