9 ms·

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years.

by aws_ls 11y ago

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusing via a long chain of navigation between sites. 2) Boredom after nearly a decade with Java programming. 3) Memory usage of Java in our conditions was much higher compared to other languages (C, C++, Go) 4) Not Java's problem, but whenever one thinks of hosting a HTTP service in Java, thinks of using a container (e.g. tomcat, jetty, Jboss etc.). Go seemed to have made making services very easy. Its possibly just a perception issue, but its there in my experience. So we wanted to move, and Go looked stable at the time from all my HN readings. C was too bare bones(even string handling was a pain to me, after a gap), and even C++ would not have matched some of the things which Go has inbuilt. Few examples: 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code. 2) Great HTTP client and server libraries, which make very easy to write your own standalone services, as well as write http crawlers. (I am quite excited that Go 1.6 will have HTTP/2 support for both, as per this birthday blog). So, in nearly three years of usage, with largely no regrets[1]. It is what they say it is: a bare-bones, fast (both compile & run) and stable (hardly get any errors after you have coded stuff, one of the stablest programming paradigms in error handling, etc). Thank you, Go team! Hoping to use it for many years, as default server side language. [1] Some of the 3rd partly libraries, we use are still not ported over to Go. They have Java, C++/C versions.

eterm 11y ago
You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?
- aws_ls 11y ago
  Good question. Small team of 2 developers, so I had that kind of luxury, which I am sure is not there when you have larger teams.
- nickbauman 11y ago
  Yeah odd choice in that Go is a very boring language (and its enthusiasts consider this a feature).
  - pconner 11y ago
    What's "boring" about it? I'd argue that the possibilities for crazy concurrency patterns make it exciting.
- StevePerkins 11y ago
  If he were honest, I'm sure the weights for each factor really look like this: * * * * * * * * * * * * * * * * * * (2) (1) (3) (4) (5) (all others)
- skrebbel 11y ago
  Best reason ever! Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun. If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides there are, but it counts! The whole idea that "fun" isn't allowed to be an important argument in a business decision feels horribly outdated to me.
  - Lambdanaut 11y ago
    Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.
    - krisdol 11y ago
      Do you really thing it's fair to blame a whole language for making your project unmaintainable, when you admit you were just learning it -- and you had come from PHP?
      - eterm 11y ago
        php is much maligned here on HN, but it doesn't mean that it automatically makes for a bad programmer. Here's another exmaple for you: Over the years, the project I work on has used the following: vb .NET C# .NET WCF asp Webforms MVC2 MVC4 The result is a maintenance headache (it's not a nightmare, but we do have to pause every time we unexpectedly encounter VB!), and that's where we've been disciplined enough to stay within the MS/ASP stack. Had developers been allowed to really go off-piste then we no doubt would have even more choices, and as a result be even less maintainable. Yes, you might not be attractive to a certain subset of programmers if you are seen to be not using a trendy new language or framework, but there's the other side that by often switching you are left with a long laundry list you need to satisfy when you're recruiting so they can maintain the older parts. We already don't require vb experience, and we expect that people can pick it up well enough to maintain it, but a side-project in "go" might seem fun now, but if it becomes part of the business then you might find that in 5 years you have to take a bad choice in recruiting because otherwise you're left without anyone who can maintain that application.
- scotty79 11y ago
  > You based a business decision to switch language on "boredom"? Not just boredom but Java induced boredom. In case of Java boredom is symptom not the essence.
coldtea 11y ago
>It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 year old language with tiny adoption compared to it (outside of echo chambers), an arbitrary roadmap as set by the core team which might involve anything coming the time for a 2.0 release, and whose majority of development depends on a handful of people Google pays their salaries?
- aws_ls 11y ago
  Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making: 1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like Lisp, etc were out, and had to look for a C like language. 2) My boredom with Java was also because of years of using, YMMV ofcourse. Also we were seeing issues in containers we hosted on, and that entire deployment paradigm seemed liked that of 2000s. As I said, in another reply, thankfully I had the luxury to choose, which is often missing in Enterprisey setups. And my co-programmers were also excited about it. 3) One thing which I forgot to mention in my parent comment is channels. It really appealed to me as a model, compared to the Barrier style of programming in Java's util.concurrent. We use that feature heavily in our now migrated Go services, and its ultra stable. 4) At the time of the switch, I wanted to move to a more bare-bones language, which is C-like. So did some benchmarks with C, C++ and Go. And Go was found to take a little more memory than C/C++, C was the least. But it was good enough. And as a successful validation of the move, I have been able to recently move to AWS compute instances from the standard instances (m3.large -> c3.xlarge to be precise). So we are getting more compute power, by paying roughly equal, because of lower memory requirements. So I made due effort to find the right language, outside the "echo chambers" you see. And this "echo chamber" is also not so actually, honestly speaking, I learn a lot from guys like you on a regular basis :-) edit: typo
chimeracoder 11y ago
> 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code. Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson https://github.com/ChimeraCoder/gojson This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.
- elcct 11y ago
  That is cool! Thanks
- jaytaylor 11y ago
  I've used gojson several times and highly recommend it. Originally I'd planned to make the tool myself but found you'd already created precisely what I envisioned! /me tips hat to you :)
pjc50 11y ago
4) is actually quite important. People wonder why PHP is so popular, and it's because the deployment overhead is tiny compared to, say, Tomcat. Especially on shared hosting.
arbe 11y ago
honestly I have hard time comparing go to java and finding any valuable reason to switch from one to another. Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base. If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social network, well Java would be the natural choice. Java has a much larger community, libraries, tools, ide and a whole ecosystem that makes Java and JVM a solid platform for writing application at scale (large team, large code base).
- Roboprog 11y ago
  MAYBE. But maybe not: what if your app has a Javascript based rich client, and the back end is primarily micro-services? Does Java still shine for that kind of a stack? (OK, I would still avoid C, but that's not saying much)
yandrypozo 11y ago
Thanks for your comment! Thanks Go team !

by aws_ls 11y ago

eterm 11y ago

You based a business decision to switch language on "boredom"? What size team are you working with, that you were able to switch from Java to Go?

aws_ls 11y ago
Good question. Small team of 2 developers, so I had that kind of luxury, which I am sure is not there when you have larger teams.
nickbauman 11y ago
Yeah odd choice in that Go is a very boring language (and its enthusiasts consider this a feature).
- pconner 11y ago
  What's "boring" about it? I'd argue that the possibilities for crazy concurrency patterns make it exciting.
StevePerkins 11y ago
If he were honest, I'm sure the weights for each factor really look like this: * * * * * * * * * * * * * * * * * * (2) (1) (3) (4) (5) (all others)
skrebbel 11y ago
Best reason ever! Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun. If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides there are, but it counts! The whole idea that "fun" isn't allowed to be an important argument in a business decision feels horribly outdated to me.
- Lambdanaut 11y ago
  Voice of dissension here. I switched from: * Mysql to MongoDB * PHP to Python * Javascript to Coffeescript All because I was bored of the old tech. and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that. Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.
  - krisdol 11y ago
    Do you really thing it's fair to blame a whole language for making your project unmaintainable, when you admit you were just learning it -- and you had come from PHP?
    - eterm 11y ago
      php is much maligned here on HN, but it doesn't mean that it automatically makes for a bad programmer. Here's another exmaple for you: Over the years, the project I work on has used the following: vb .NET C# .NET WCF asp Webforms MVC2 MVC4 The result is a maintenance headache (it's not a nightmare, but we do have to pause every time we unexpectedly encounter VB!), and that's where we've been disciplined enough to stay within the MS/ASP stack. Had developers been allowed to really go off-piste then we no doubt would have even more choices, and as a result be even less maintainable. Yes, you might not be attractive to a certain subset of programmers if you are seen to be not using a trendy new language or framework, but there's the other side that by often switching you are left with a long laundry list you need to satisfy when you're recruiting so they can maintain the older parts. We already don't require vb experience, and we expect that people can pick it up well enough to maintain it, but a side-project in "go" might seem fun now, but if it becomes part of the business then you might find that in 5 years you have to take a bad choice in recruiting because otherwise you're left without anyone who can maintain that application.
scotty79 11y ago
> You based a business decision to switch language on "boredom"? Not just boredom but Java induced boredom. In case of Java boredom is symptom not the essence.

coldtea 11y ago

>It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 year old language with tiny adoption compared to it (outside of echo chambers), an arbitrary roadmap as set by the core team which might involve anything coming the time for a 2.0 release, and whose majority of development depends on a handful of people Google pays their salaries?

aws_ls 11y ago
Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making: 1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like Lisp, etc were out, and had to look for a C like language. 2) My boredom with Java was also because of years of using, YMMV ofcourse. Also we were seeing issues in containers we hosted on, and that entire deployment paradigm seemed liked that of 2000s. As I said, in another reply, thankfully I had the luxury to choose, which is often missing in Enterprisey setups. And my co-programmers were also excited about it. 3) One thing which I forgot to mention in my parent comment is channels. It really appealed to me as a model, compared to the Barrier style of programming in Java's util.concurrent. We use that feature heavily in our now migrated Go services, and its ultra stable. 4) At the time of the switch, I wanted to move to a more bare-bones language, which is C-like. So did some benchmarks with C, C++ and Go. And Go was found to take a little more memory than C/C++, C was the least. But it was good enough. And as a successful validation of the move, I have been able to recently move to AWS compute instances from the standard instances (m3.large -> c3.xlarge to be precise). So we are getting more compute power, by paying roughly equal, because of lower memory requirements. So I made due effort to find the right language, outside the "echo chambers" you see. And this "echo chamber" is also not so actually, honestly speaking, I learn a lot from guys like you on a regular basis :-) edit: typo

chimeracoder 11y ago

> 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code. Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson https://github.com/ChimeraCoder/gojson This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.

elcct 11y ago
That is cool! Thanks
jaytaylor 11y ago
I've used gojson several times and highly recommend it. Originally I'd planned to make the tool myself but found you'd already created precisely what I envisioned! /me tips hat to you :)

pjc50 11y ago

4) is actually quite important. People wonder why PHP is so popular, and it's because the deployment overhead is tiny compared to, say, Tomcat. Especially on shared hosting.

arbe 11y ago

honestly I have hard time comparing go to java and finding any valuable reason to switch from one to another. Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base. If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social network, well Java would be the natural choice. Java has a much larger community, libraries, tools, ide and a whole ecosystem that makes Java and JVM a solid platform for writing application at scale (large team, large code base).

Roboprog 11y ago
MAYBE. But maybe not: what if your app has a Javascript based rich client, and the back end is primarily micro-services? Does Java still shine for that kind of a stack? (OK, I would still avoid C, but that's not saying much)

yandrypozo 11y ago

Thanks for your comment! Thanks Go team !