[aeyes]

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.

[jshen]

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.

[Cthulhu_]

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.

[mbesto]

> 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.

[nrr]

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.