[toastercat]

Kinda devil's advocate, but I've met several senior-should-be-junior cargo-culting devs who swear by popular tools that are objectively slower than alternatives, instead of actually taking the time to evaluate the less popular alternatives to see if the lack of surrounding ecosystem will actually affect their project. The result is a death by a thousand cuts, because they auto-pilot to "what is everyone else using"?

[sorokod]

Putting aside who-wants-to-be-what, a change in a common tech stack is a serious change with all sorts of implications. Arguments for and against should be carefully considered, and yes "going faster can't hurt" is not an argument.

[toastercat]

Mostly agree; if you're a Java shop, maybe stick to Java instead of confusing all of your engineers just because you read on HN how much faster Golang can be. But again, YMMV.

[leeoniya]

> to see if the lack of surrounding ecosystem will actually affect their project

for projects of any significant size, that answer is a resounding "yes".

[toastercat]

I think engineering is more nuanced than that, personally.

[leeoniya]

it's really only nuanced when you have small team and a very tightly scoped project.

for anything that can plausibly grow in scope and team size (which, let's be honest here, is most complex projects), it almost never makes sense to go without an existing ecosystem. it becomes difficult to hire, difficult to train, difficult to pass off maintenance, slows down velocity of shipping, makes your team gradually re-invent a worse version of the framework/tooling you initially tried to avoid, etc.

i've been on both kinds of projects. when i build something solo it's a work of art in code size, API consistency, and performance...and that feels truly amazing. but unfortunately it's not something that is feasible with bigger and more diverse-skillset teams. ever-growing scope and shipping features quickly usually means giving up performance and well thought out design.