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 type 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.
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 type 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.