Go is sufficiently trivial that anyone who dares call themselves a programmer can learn it in two weeks if they already have experience in some even remotely-related language.
As others have noted, this is one of the areas Go really shines at (and I am not a Go fan). The lack of language features really forces most code into a limited form of TOOWTDI and because it has pretty opinionated choices about loops, conditionals, errors etc... you really don't see much Go code that makes you scratch your head.
Plus - at least so far - it hasn't aged; they are reluctant to make backwards-incompatible changes, and right now they're really humming and harring about whether or not to add generics. The biggest changes you'll see in Go codebases from 10 years ago vs modern will be Go's module system / dependency management and the `context` package sprinkled as an argument to some of the API methods.
Compare that to other languages (from the top of my head, don't pin me down on details or inaccuracies please):
- Java: Added generics, annotations, lambda expressions and streams, new date/time libraries, modules, switch expressions and multiline strings.
- Javascript: Classes, ES6 features (arrow functions), imports, and offshoots like Flow, Typescript.
- Obj-C / Swift; ARC, Swift itself (4 versions), I haven't been up to date with this much.
TL;DR, most languages really shift over time, often 'borrowing' features from other languages, but Go resists these changes because it's intended to still be read and compile in ten, twenty years' time.
Personally, I'm working on a management interface for a network application; the existing UI has been around since 2012, I'm trying to build this to last at least as long, probably longer, and I think Go is a great choice for it. The old application was built in PHP 5.2, which is vastly outdated now (and updating is challenging because on the one hand, the versions of RHEL used in production don't supply newer packages, and on the other there's 65K lines of badly written PHP that would likely need to be updated).
Conversely, the new Go back-end is standalone and self-contained, I try and maintain the habit of updating the Go version and all dependencies monthly; so far I've never had to make any code changes or had to rethink my architecture because of Go adding a new (architectural) feature. (I probably have the benefit that it started after `context` and the module system were in place though). I feel a lot more confident in its future proof-ness. And I feel confident that anyone looking at the code can maintain it, although that said I'm cautious about the more magic parts like GORM, which I should probably swap out with lower-level SQL at some point but I don't really want to.
I did just this, learning Go to do MITs Distributed Systems course. It has the speed and easy of dynamic scripting language plus a ton of sane defaults where JS and Python have quirks, and is compiled. My understanding is the major downside is the performance has stalled at 2-5x C++ which is not enough for systems infrastructure projects.
I think he means C++ is 2x to 5x faster to run than Go. I saw many benchmarks and not sure if that is true though. Go is still one of the fastest out there.
That is already pretty fast, and I guess the difference in practical scenarios would be even smaller since external systems like DB's won't change their speed if you call them with another programming language and because production code is not always as optimized as benchmark code.
This project might not have a million lines of code but how maintainable is the codebase going to be in a few years once the original authors have moved on to other projects? Is the code organized to be easily readable? Java is very expressive but that's a good thing from a maintainance standpoint.
Also, the ecosystem is very young so you don't know which libraries will still be around in 3 or 5 years. You might find yourself reworking large parts of the code for betting on the wrong horse.
I've been coding for decades and Go is the best language I've used in terms of being able to easily read and understand other peoples code. It also "feels" very maintainable to me, but it's hard to speak empirically about that.
I've also found that most libraries in go hold up well over time. In fact, I just recently needed to write a go program that could use some code i wrote many years ago and haven't touched in nearly as many years which used a few external libraries. I literally copy and pasted my old code into my new project and it just worked.
One part of the ecosystem and community is that they tend to pull up their nose at using too many libraries, especially if they're too different from the standard library. A lot of people come into e.g. the Go slack channel and ask "What is the best web application framework?", because that's the go-to thing when you do e.g. Java; the common answer is "YAGNI", because the standard library is good enough. If not, there are some really lightweight libraries on top of the stdlib that do things like adding route matching, or slight conveniences to do SQL.
> Also, the ecosystem is very young so you don't know which libraries will still be around in 3 or 5 years.
This is precisely my concern. It's all good and well that we have these "Google level engineers" taking over government projects. But when the boredom runs out (or they go back to the private sector), who takes over?
I suspect the first people who wrote gov't applications in COBOL felt the same way...and you know how that story ends.
I think the obvious answer is to make it compelling for those kinds of engineers to consider civil service as a long-term option. Right now, 18F positions on the general schedule, which is probably where ICs would land, are time-limited up to, I think, four years.
That said, we should perhaps not have Google engineers live the meme of bringing their flavor of complexity everywhere they go, but I feel that having permanent FTE positions within government agencies specifically for bolstering up the competency and cost-effectiveness of information technology projects is overall a good thing.
My suspicion is that the majority of the projects that agencies like the GSA undertake (through its TTS arm, of which 18F is a constituent part) are ho-hum boring business IT projects, where most of the complexity comes not from the technology itself but from having to deal with getting a handle on the meandering specifications laid down by stakeholders (read: the plebiscite via representation in Congress).
I further suspect that the engineers that are recruited by 18F and the USDS tend not to go into the weeds on immediately building out, e.g., systems like Chubby and Stubby and D/GFS and Bigtable for the sake of it but rather tend to focus on trying to solve the problem at hand. I feel that the requirement to submit timesheets (and, hence, justify time spent) every week tempers that "every problem is tempting" feeling. Anecdotally, it did for me when I worked at a similar three-letter organization, albeit in the private sector, for the better part of half a decade.
You could have said the same about pre-generics Java. The problem is that when the language is simple and minimalist, people do things with the language that are byzantine and arcane, and you can't learn those in two weeks. Example: classic Spring's XML configuration inner platform.
No you couldn’t. I watched both Java and Go since they got released and Java really quickly went into the over-engineering and complexity camp long before generics. I worked as a consultant doing Java long before generics and the culture of over-engineering was already there. The language also really encourage it.
Go is an entirely different beast. The language, libraries and whole community is really worshipping simplicity in a way Java never did.
Just look around a bit at the standard library. There are pretty much no setters and getters. No inheritance hierarchy to speak of. Not even constructors most of the time.
It is not without reason that Go angers a lot of people that think they know how to do software. It breaks all the rules they have kept sacred, that they think all “real” programmers should follow.
Think about it this way. If Java is SLS assembled in a clean room never getting done, then Go is more like SpaceX assembling a rocket in open space with guy who normally weld water towers. It isn’t how it is supposed to be done but it works and they get shit done 20x faster.
I don't think so. Go looks to be focusing mostly on systems-level problems and the kinds of applications that orbit that concern.
Java, on the other hand--at least when you control for the confusion around whether "Java" referred to the JVM, the language, the base class library, or the security model--was looking to take on C++ and the kinds of software people were looking to write in 1996 in C++.
You can write line of business software in Go, but that doesn't really feel like its purpose in life. The language fights you a little bit when you try to do that.
News flash: this is what they said about COBOL, C, C++, JavaScript, closure, etc. as well as architectural patterns such as OOD or functional programming. Every language, and every platform has it’s nuances. You can do silly, non performing things in any language or platform. To assume a particular language will solve all your woes is outright naive and exhibits no memory of past software engineering concepts.
You are basically saying that no language is a silver bullet and any of them can go badly wrong, which is trivially obvious and not a productive addition to the discussion. If you have specific criticisms of this approach, that would be much more constructive.
Nope. Java complexity came straight from Sun and friends. J2EE / EJBs (came in 2000) did not come from some randos, it was official Sun specification and supposedly standard way to develop any enterprise application.
I think Go has held up pretty well on this front, and I've also found a good heuristic to detect if libraries aren't doing this well. Check and see if they use the empty interface type a lot (this is the All or Any type in go). It's a code smell for me if I see a library using it a lot.