Go + Services = One Goliath Project
Ok this is going to sound ignorant, as my only experiences in backend services have been Go and Python. I don&#x27;t like either. Is there something I&#x27;m missing? For simple CRUD apps, both are sufficient. But (in my limited experience), the moment I&#x27;ve wanted to create more complex business logic with stricter constraints, neither has been quite up to the task.<p>Go doesn&#x27;t make things easy. It asks you to repeat yourself. I don&#x27;t like the lack of basic functions like a generic map &#x2F; filter function.. I know Rob Pike just says &quot;use for loops&quot;, but it feels so unnecessarily unexpressive. When I see map, I know what&#x27;s going on almost immediately. For loops take more reading to understand. Nil pointers shouldn&#x27;t be, yet still are, a thing (developers aren&#x27;t perfect - why can&#x27;t the type system help?). It feels like a straight downgrade from Python from a code clarity perspective. And it&#x27;s typed, sure, but the type system doesn&#x27;t let me express constraints that other languages allow me to do that would prevent entire classes of bugs. It doesn&#x27;t feel worth it compared to Python. Yes, the core language ends up being comparatively &quot;simple&quot;, but simple building blocks doesn&#x27;t guarantee a simple overall system. And my company is very diligent from an architectural perspective.<p>But then when I look at Python, I&#x27;d rather just use Javascript with Lodash, esp. when it comes to the treatment of functions as first class objects[0]. Throw Typescript in there, and you get, in my opinion, a better type system than Go, so unless language performance is a major constraint (which it hasn&#x27;t been for my company, our DB usage patterns it the biggest thing instead), why would I want to use either of these rather than Typescript?<p>[0] Edit: Dumb and wrong, I meant its treatment of anonymous functions. I don’t like lambdas.