It's probably faster to verify that your Go code is working as intended, but many would argue that dynamically typed/interpreted languages are faster to write code in than statically typed/compiled languages. Others would argue that the pure "writing code" part isn't the majority of what takes up a developer's time. There's no one right answer.

Go wasn't a serious option for Instagram though. According to Wikipedia Instagram launched in 2010, Go launched in 2009. That would have made them very early adopters, was the library support there back then like it was for Python?

Just because there may be better tools now, should they scrap their working code that earned their fortune?

Well, OCaml, Haskell or maybe Scala would've been mature options in 2010, combining safety with language-level productivity that's comparable to Python, though the extent to which web frameworks available in those languages at that time were Django-equivalent is arguable. (Personally I would - and did - happily choose Scala with Wicket over Django in 2010)

In terms of what Instagram should do now, I'd say they should do what Facebook did: introduce thrift or similar, gradually move business logic into backend services written in more suitable languages, leaving the Python to eventually become just a thin web frontend. Retrofitting types onto code involves a lot of the same effort as rewriting it into a better language, and the rewards for the latter are higher, IME.

I'm not talking about Instagram, I'm answering the parent comment, which talked about developer productivity in general.

Empirically? Doesn't seem like it. But it's hard to run a good controlled experiment. The confounding effects of the team members, the project goal, and the vagaries of business are too noisy.

We're getting into a world where languages finally have type systems that dont suck for fast development. This wasn't the case until very recently. And many of the current options only became realistically viable in the last few years (or months!).

We still have to work with the world as it exists. Not as it should be or will be. And even with the crop of modern languages, its often still faster to start with less optimal languages and fix shit in the 1/10 chance you're actually successful.

What are you talking about? Haskell is 30 years old.

You must have missed the part about "the world as it exists" and "fast development" and pretty much the entire point of the post you're replying to.

Haskell remains impractical for many use cases, it is not used much outside of academia, it's not documented to be used outside of academia, and it didn't even have a working package manager until a few years ago.

Yeah. And you need 20 language extensions to sit at the top of your every file to do anything useful with it.

Many in the Haskell community talk about being guided by their types, perhaps you're seeing a similar benefit?

Not sure why the negative vibes toward this comment, I think it's fairly sensible (of course, this is a very subjective subject).

I think a lot depends on how solid your requirements are. If there's no need for further design as you develop, types are great. If you're writing one to throw away, they're a waste. If you're chopping and changing as you write, it can go either way.