> Ultimately people use TS on the back end because they want to simplify hiring and reduce context switching loss in developers mostly
In my experience this hasn’t panned out particularly well, but I believe it works for some teams.
> because their application is isomorphic
This is one case where it had worked out okay for me. The scope has tended to be relatively limited and there was a framework in place which was generally good at gluing things together and ensuring people work along the same rails.
> I wouldn’t write most services in rust…
No, me either. I tend to teach for Go for web services these days, but I do like rust for CLIs and situations where optimizations are crucial. Admittedly I don’t even like Go as a language that much, but it’s great at what it does if I’m willing to put my head down, deal with the quirks and verbosity, and crank something out. It’s not a language of cleverness or elegance, but the results tend to be excellent and easy to maintain.
In my experience this hasn’t panned out particularly well, but I believe it works for some teams.
> because their application is isomorphic
This is one case where it had worked out okay for me. The scope has tended to be relatively limited and there was a framework in place which was generally good at gluing things together and ensuring people work along the same rails.
> I wouldn’t write most services in rust…
No, me either. I tend to teach for Go for web services these days, but I do like rust for CLIs and situations where optimizations are crucial. Admittedly I don’t even like Go as a language that much, but it’s great at what it does if I’m willing to put my head down, deal with the quirks and verbosity, and crank something out. It’s not a language of cleverness or elegance, but the results tend to be excellent and easy to maintain.