4 ms·

I really wish that we, software developers, apply Lindy rule while choosing library/framework/language/SaaS tool etc., Lot of developers underestimate the value

I really wish that we, software developers, apply Lindy rule while choosing library/framework/language/SaaS tool etc., Lot of developers underestimate the value of collective brain power that has gone into making a system mature, not to talk about community and ecosystem support. I was extremely hesitant to get onboard Golang bandwagon 5-7 years ago. I reluctantly said OK to try it out in a non critical service and all my concerns turned out to be true. I also apply this rule while buying car and choosing a bank. It's been interesting to see all the fintechs who badmouthed incumbent banks now going through exactly same challenges that banks went through and addressed.

lexoj 3y ago
Care to elaborate on the Go issues you encountered? Nowadays Go is very well established, unless you specifically meant that the issues happened 5-7 years ago.
- vishnugupta 3y ago
  Of the top of my head: 1) Lack of libraries. 2) Little to non-existent tooling & observability support. 3) Lots of challenges around gRPC. That it needed a discovery service such as etcd was a big source of pain. I remember two or three massive downtimes where an adjacent team went through hell for a day just to get back a high throughput system back online. gRPC + etcd was very susceptible to thundering herd problem. 4) Lack of experienced developers who would guide others idiomatic way of doing things. And related, go routines need a different mindset and somewhat a grounds up re-learning. The code would routinely get into deadlock sort of scenarios. I conceded that most of the above are not inherent to Go but to any new system/language. I'm sure they all have been addressed now as the language and ecosystem has matured. That was the point I was trying to make though; don't jump onto a new bandwagon. Of course you want to learn it on your own and experiment that's totally fine but to use it in production is fraught with risk IMO.

lexoj 3y ago

Care to elaborate on the Go issues you encountered? Nowadays Go is very well established, unless you specifically meant that the issues happened 5-7 years ago.

vishnugupta 3y ago
Of the top of my head: 1) Lack of libraries. 2) Little to non-existent tooling & observability support. 3) Lots of challenges around gRPC. That it needed a discovery service such as etcd was a big source of pain. I remember two or three massive downtimes where an adjacent team went through hell for a day just to get back a high throughput system back online. gRPC + etcd was very susceptible to thundering herd problem. 4) Lack of experienced developers who would guide others idiomatic way of doing things. And related, go routines need a different mindset and somewhat a grounds up re-learning. The code would routinely get into deadlock sort of scenarios. I conceded that most of the above are not inherent to Go but to any new system/language. I'm sure they all have been addressed now as the language and ecosystem has matured. That was the point I was trying to make though; don't jump onto a new bandwagon. Of course you want to learn it on your own and experiment that's totally fine but to use it in production is fraught with risk IMO.