One can go job hoping as alternative, but then good luck jumping jobs everytime one has to deal with stuff we dislike.
Thankfully I seldom have to deal with Go anyway.
As post 2000 language, its design isn't that appealing.
The language would have been as mainstream as Oberon and Limbo were, if the authors weren't working at Google.
Yes. I have been working with Go for close to a year now, and I still don't get why we use it, if not for the inertia of times past – and I still don't get why it was chosen in the first place.
If we wanted a fast, down to the metal language, Rust would IMHO be better.
If we preferred a higher-level language with a Gc, Java/Kotlin/C# would be, IMHO, much better.
And both paths offer the same level of tooling, so it's still a mystery to me.
Writing code in Java\Kotlin requires quite some investment into the language and tooling (at least that's my Java impression).
With Go - you can start getting the job done from day one most of the time. Some parts of Go may be harder than the others, even challenging maybe, but not as hard as Java.
Lack of OOP (at least in Java's traditional scence) also helps quite a lot (but that depends on project of course)
However, I would not weight too much the time-to-first-makefile of a language if a project is supposed to live for years.
Just put a .netrc file in your homefolder with your username + token and use GOPRIVATE env variable. No need to change any git settings.
After go modules became mainsream most go packaging issues where out of question, imo. At least for me the 'private repo packages' was the only issue.
I'm pretty sure that there are millions of js projects out there, many of them been there for years and will be there for many years to come, all despite npm and js packaging issues in general...
At the same time Go provides enough stdlib to forget about dependencies completely if you are afraid that use of some of them (or packaging system in general) may result in some negative scenario.
This is where Go shines: it can offer enough to be powerfull without becoming java. But without a doubt Go has many things to improve too.
Lol yes, let's just put sensitive information in plain text in my home folder and change the machine-wide configuration, because Go guys decided that if it worked in 1970, it is good enough for today.
> the 'private repo packages' was the only issue.
That's quite a big one for a language targeting companies.
> I'm pretty sure that there are millions of js projects out there
Sure, if your gauge is the JS ecosystem...
> At the same time Go provides enough stdlib to forget about dependencies completely
Go stdlib is decent, that's it. It does not even has basic data types such as sets (no, map keys are not a decent replacement for a set), queues or stacks.
That't just your login and a token that gives read-only access to some repo. Hardly an issue imo. At least if this is your work PC. (also - while home folers is the default the file can be places somewhere else)
>Sure, if your gauge is the JS ecosystem...
Why not? Because some guys on HN is salty about it? JS is extremely popular and widespread. Much better gauge than something being used by a few guys.
>It does not even has basic data types such as sets (no, map keys are not a decent replacement for a set), queues or stacks.
I'd argue that channels are your queues. Maybe sets and stacks will be added now that generics are part of the language.