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.
>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?
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 :-)
If everyone thought this way, our realistic professional choices of languages would be C, C++, and Perl. The exact same things you're saying about Go were things people said about Java --- a language, by the way, with much more harrowing ownership issues than Go, which is an open-source project top-to-bottom.
What do you feel are the much more harrowing ownership issues? If you google 'goroutine leaking' you get a pile of convoluted stuff. I don't mean to language-war, if anything I find 'stuff proponents and detractors said about Java in its early days' eerily similar (and likely as overwrought) to the same said about Go now.
Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser.
I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.
I don't think there's any 85 year old Cobol though. Most of the S&P 500 is less than 50. It's entirely conceivable the companies that embrace new technologies starting today will, within 50 years, extinguish or acquire most of the of the companies using technologies from 1995.
1995? Are you sure? I started studying maths and computer science in 1993 and Cobol was ever only mentioned as a remote curiosity. I remember Pascal, Perl and C/C++ were common.
Yes but it was still dominant in terms of actual code in production. I remember working at a consulting firm then and we had a ton of work in Cobol and JCL. Banks in particular but also telecom.
Client-server 4GLs were really starting to take off -- PowerBuilder, Visual Basic -- but those got washed away with the web.
I don't think it would immediately kill it. If Google abandoned Go then given it has only a few unique features it would likely fall in amongst the hundred other second-tier languages that are around today.
It is pretty inarguable that a large part of Go's success has been it's affiliation with Google.
Tons of open source projects faltered and died when they lost core contributors. The core will remain open source and available, and you might even see a few commits here and there, but that will be it.
Go for the most part is written by a small team of paid contributors -- it's not certain at all that if they went away, other people would step in their shoes.
If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.
- Do all opensource projects require corporate sponsorship to be viable?
- Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
- Does Java, being under the control of Oracle, present a better option?
- Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
The Go code I write and compile today will continue to work for a significant period of time. If Google stopped paying the committers, this would not change - the language may not evolve, but this is a minor concern on a project of Go's popularity.
Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
We're talking about decisions to adopt a language, so FUD and especially "uncertainty" is a very important factor to consider. This is not 1999 and Microsoft badmouthing Linux.
>Do all opensource projects require corporate sponsorship to be viable?
Not all of them, but a lot of them do. Especially languages. Even something like OCamL needs Jane Street and that french university a lot.
Go is not setup as even a 50-50 internal/external community. While the long tail is, well, long, the majority of commits and all of the steering is from Google devs.
>Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
Rust has Mozilla and lots of paid programmers (all the core team for one). Without it, it would have gone nowhere.
Python and Ruby had had corporate sponsorship themselves too, but they have been far more organic (grass-roots) open source communities than Go from the start.
>Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
Devs/Teams using F# are extremely few and far between compared to any established language such as C#, Java, etc. We're talking probably 2 orders of magnitude or more.
>Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
Fortran is still evolving actually. Also Fortran and COBOL have been always mostly based on commercial compilers -- not community efforts, because that's how stuff worked back in the day.
And it's not like people write green projects in COBOL -- they just rely on it because they have huge important codebases that are 40-50 years old.
It is not FUD. It is a factor to consider, especially if you are thinking of creating mission critical software. There is no doubt that Google has plenty of form in killing projects, some of which were quite popular and/or highly visible. After all what percentage of Google income/infrastructure depends on Go? I presume it is really, really tiny and could become a casualty in corporate politics.
I personally think it is highly unlikely that Google would kill Go, but I do think one has to consider the possibility before betting the farm.
Yeah, where the owner is suing one of those multiple implementations, and playing silly buggers with J2EE certification. That really lends a fuckton of conifidence.
> 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
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.
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!
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.
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?
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.
> but it doesn't mean that it automatically makes for a bad programmer.
I came to PHP late from proper languages circa 2008/2009ish been programming since I was a kid in the 80's, I've no great love for the language, it's purely a tool and once you ignore the rusty bits it's not a bad language for a lot of web stuff but I've never been concerned with purity/beauty for it's own sake I just care about what I can do in a language, these days I use PHP a lot on the web, Python for just about everything else (even my build system for automating browserify is in Python using Envoy) and I play with Go and such on the side.
All that and there is a lot of work in PHP clearing up after others (if you like those kinds of engineering problems which I do) which is also nice.
<quote>All because I was bored of the old tech.
and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that.</quote>
I think the blame would logically reside with you.
MongoDB I can see, but Coffeescript is just sugar on top of Javascript, and I struggle to see how it could make any code unmaintainable – but i'd be interested to know why!
What's the problem with document databases, really? To be honest, for 80% of the projects I've ever worked with, fixed-schema rdbms's fitted just like... a square peg in a round hole!
Heck, even for advanced analytics, I find mongo aggregates and mongo map reduce 10x more intuitive and SQL that inevitably ends up using zillions of non-portable tricks, stored procedures and god knows what. And atomicity and whatever else transactions guarantee you in theory can be easily emulated with some good db structure design tricks and app design tricks in practice.
And the smarter a RDBMS is, like Postgres, the more dangerous it becomes for maintainability: it's a zillion times easier to maintain 'logic expressed in app code' (because you have basic stuff like version control, tests and so on), than 'logic trapped in the db' (good luck explaining to a new developer how "X automagically happens because of trigger Y and stored procedure Z, so there is no app code for X that you can instantly tweak to change how it works"). This is why I at least have some respect for mysql: it's retarded enough that it forces you to put the login in the code, where it f belongs!
Really, give me a dumb document db like mongo any day! And if I want something "less dumb" there're things like arangodb and rethinkdb that can also do joins and graphs. And there're also "true graph-dbs" for index-less "joins"/traversals, like neo4j and orientdb, for when the relationships for when you actually end up doing more than 3 to 4 levels deep joins...
Imho the development of "high-end rdbms" like postgress and oracle has been a huge waste of human brainpower and all the benefits supposedly provided by these pieces of technology were actually from the clever app-level code that mostly worked around their inappropriateness...
I was not referring to document databases as a whole, just to MongoDB in particular. You can use PostgreSQL as a document database. I heard too many stories with Mongo where people were dealing with locks or broken data instead of solving their business problems.
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.
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).
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)
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.