See, in not so sure about that. Go has a lot of issues, things it doesn’t do well, but one thing it is good at is being simple. I would argue that it’s certainly not more complex than JavaScript, and in many cases, is easier simply because there are fewer “gotcha” edge cases that impact new developers. And Go is slowly eliminating those gotchas (such as the loop variable shadowing issue).
Your argument holds for Rust v JS; the Rust learning curve is higher, and you have to understand many more technical computing topics to write good code. But I don’t think the same holds for Go. Anyone capable of learning JS is capable of learning Go, in nearly the same time.
Maybe you’re saying that there’s a veritable legion of JS script monkeys, and so it’s cheaper because of supply and demand. I’d agree with that. JS programming skills are certainly far more fungible between companies, which encourages new developers to choose it. I just don’t think it has as much to do with language complexity or difficulty.
There’s also Dart with its similar syntax to JS, strong type and null safety, and ahead of time compilation with hot reload. And yet it only really started getting adoption after being chosen as the language for Flutter.
I said nothing about the difficulty of learning. JS/TS developers are easier to find and are cheaper, and the current climate wants everybody to be full-stack developers. The cost savings of Go isn’t there :(
You’re right, you didn’t mention difficulty, but you did say
Abundant nodejs developers can pump shitty code faster, therefore delivering features faster.
I don’t believe developers can write code faster in JS than that can in Go. And the truism is still true: just as 9 women can’t make a baby in one month, at a fairly early point you can’t develop an application faster just by throwing more people at it.
I object to that basic premise: that dumping a hoard of developers on a problem is somehow going to get it done more quickly, or more cheaply. In fact, the only guarantee of that approach is that the quality of going to suffer.
I fully agree. Sadly, in reality, mid-level managers will happily sacrifice quality for speed, and before the whole thing falls apart, they move to another company with better pay.
This is so universally true across domains, I wonder if the collapse of the Career Employee model - motivated mostly by companies, but workers have also had a hand in this - isn’t a huge factor in the enshittification of products. In the US, at least.
It really does cross careers. My wife is dealing with someone at work who’s making horrible (for the company) decisions for his organization because they buy him short-term benefit and will probably result in a better bonus for him this year. But it’s almost guaranteed to be a shit show someone’s going to have to clean up in 5 years, but the guy in question doesn’t give a fuck about 5 years because his plan is to retire within the next 3. It’s a specific interest of a more general issue: nobody expects anymore to be in the same job, and maybe not in the same company, 10 years from today, and companies are are bad about applying consequences over periods longer than a year.
Everybody bitches about the mess the previous person left them, but nobody gets penalized for a bad decision they made 5 years ago. And people aren’t stupid; they know this.
See, in not so sure about that. Go has a lot of issues, things it doesn’t do well, but one thing it is good at is being simple. I would argue that it’s certainly not more complex than JavaScript, and in many cases, is easier simply because there are fewer “gotcha” edge cases that impact new developers. And Go is slowly eliminating those gotchas (such as the loop variable shadowing issue).
Your argument holds for Rust v JS; the Rust learning curve is higher, and you have to understand many more technical computing topics to write good code. But I don’t think the same holds for Go. Anyone capable of learning JS is capable of learning Go, in nearly the same time.
Maybe you’re saying that there’s a veritable legion of JS script monkeys, and so it’s cheaper because of supply and demand. I’d agree with that. JS programming skills are certainly far more fungible between companies, which encourages new developers to choose it. I just don’t think it has as much to do with language complexity or difficulty.
There’s also Dart with its similar syntax to JS, strong type and null safety, and ahead of time compilation with hot reload. And yet it only really started getting adoption after being chosen as the language for Flutter.
I said nothing about the difficulty of learning. JS/TS developers are easier to find and are cheaper, and the current climate wants everybody to be full-stack developers. The cost savings of Go isn’t there :(
You’re right, you didn’t mention difficulty, but you did say
I don’t believe developers can write code faster in JS than that can in Go. And the truism is still true: just as 9 women can’t make a baby in one month, at a fairly early point you can’t develop an application faster just by throwing more people at it.
I object to that basic premise: that dumping a hoard of developers on a problem is somehow going to get it done more quickly, or more cheaply. In fact, the only guarantee of that approach is that the quality of going to suffer.
I fully agree. Sadly, in reality, mid-level managers will happily sacrifice quality for speed, and before the whole thing falls apart, they move to another company with better pay.
This is so universally true across domains, I wonder if the collapse of the Career Employee model - motivated mostly by companies, but workers have also had a hand in this - isn’t a huge factor in the enshittification of products. In the US, at least.
It really does cross careers. My wife is dealing with someone at work who’s making horrible (for the company) decisions for his organization because they buy him short-term benefit and will probably result in a better bonus for him this year. But it’s almost guaranteed to be a shit show someone’s going to have to clean up in 5 years, but the guy in question doesn’t give a fuck about 5 years because his plan is to retire within the next 3. It’s a specific interest of a more general issue: nobody expects anymore to be in the same job, and maybe not in the same company, 10 years from today, and companies are are bad about applying consequences over periods longer than a year.
Everybody bitches about the mess the previous person left them, but nobody gets penalized for a bad decision they made 5 years ago. And people aren’t stupid; they know this.