Remix.run Logo
kybernetikos a day ago

I think this is exactly the right way to understand Go - it's targetted at building servers in environments where having strong consistency of code and a short ramp up time for junior engineers is valuable - i.e. it's perfect for all the big corp scenarios that Java was used for.

I think maybe the more common, but less helpful comparison of go vs rust comes from the fact that they are both part of a new wave of languages and that they both default to producing staticly linked binaries.

monksy a day ago | parent [-]

> consistency of code

There are many stylecheck tools that should be apart of a good stack. Accepting the creator's style is putting a lot of weight on their opinion. Most organizations have their own preferences for good reason.

> short ramp up for junior engineers

Junior engineers aren't a place you're concerned on being productive. Most of the time at that stage in someone's career they should be learning more, getting up to speed with professional practices, tools, and trying to learn code bases+patterns. Ramp up time for a language is a very minor consideration.

Both of those things have very little to do with server environments.

Bigger corporations struggle with Go's module system and forced reliance on seperate repos for separate modules. (Can you bundle multiple modules in the same repo.. yes but you're going to have a bad time)

kybernetikos a day ago | parent [-]

> Both of those things have very little to do with server environments

My experience of bigcorp is that they need lots of servers (http is the modern bailer twine) and want developers to act as far as possible as indistinguishable resource. They will have rotating, high churn, globally distributed teams of vendors, contractors, consultants, internal staff and the teams will encompass a vast range of skill levels and abilities.

Some languages amplify skill level disparity, some attenuate it.

monksy a day ago | parent [-]

This is where I would argue that it's a terrible language choice for the environment. (The need for rest frameworks) There aren't a lot of established or mature options for this, and a lot of them don't give you very much to work off of. It's going to be a bumpy road for exploits in this area.

> act as a indistinguishable resource rotating high churn, globally distributed teams of vendors, contactors, consultants, internal staff...

So this is a huge organizational problem that isn't helped by Go. This is more of a higher level problem and the lack of technical leadership in the company. Any language you go with .. you're not going to do well by trying to utilize everyone there. Picking a language that gives you the impression that you can blend the skill levels will end up with a disastrous mistake with a lot of slippage on the development side. Will you generate a ton of code? Yes, the language encourages it.

What I do agree with you: It does encourage the mass hiring of developers with low to no expectations of performance. (Seems like that's google's focus these days) But that's a bad thing for the developer who wants to achieve a lot of results (not just write lines), and to develop our teams.