4 ms·

Isn't it faster to write everything in Go, for example, that has a compiler guiding you all the way and you rarely get runtime errors? I feel my developer time

Isn't it faster to write everything in Go, for example, that has a compiler guiding you all the way and you rarely get runtime errors? I feel my developer time very much "optimized" when writing backends in Go than when I wrote then in Python (I also tried Node, which was a disaster).

xapata 9y ago
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.
jimnotgym 9y ago
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?
- fiatjaf 9y ago
  I'm not talking about Instagram, I'm answering the parent comment, which talked about developer productivity in general.
- lmm 9y ago
  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.
shados 9y ago
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.
- mbid 9y ago
  What are you talking about? Haskell is 30 years old.
  - rspeer 9y ago
    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.
  - dmitriid 9y ago
    Yeah. And you need 20 language extensions to sit at the top of your every file to do anything useful with it.
switchbak 9y ago
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).
deleted 9y ago
[deleted]
meowface 9y ago
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.
AlexCoventry 9y ago
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.

xapata 9y ago

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.

jimnotgym 9y ago

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?

fiatjaf 9y ago
I'm not talking about Instagram, I'm answering the parent comment, which talked about developer productivity in general.
lmm 9y ago
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.

shados 9y ago

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.

mbid 9y ago
What are you talking about? Haskell is 30 years old.
- rspeer 9y ago
  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.
- dmitriid 9y ago
  Yeah. And you need 20 language extensions to sit at the top of your every file to do anything useful with it.

switchbak 9y ago

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

deleted 9y ago

[deleted]

meowface 9y ago

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.

AlexCoventry 9y ago

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.