4 ms·

True, but can you really work day by day in a language and still not understand its appeal? I mean, not like it, but at least understand why others might choose

• pjmlp 4y ago
  I see Go's appeal as a better C for userspace code, and the language is quite nice had it been released during the days Oberon and Limbo mattered in the mid-1990's. 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.
• shakow 4y ago
  > True, but can you really work day by day in a language and still not understand its appeal? 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.
  • konart 4y ago
    >If we preferred a higher-level language with a Gc, Java/Kotlin/C# would be, IMHO, much better. 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)
    • shakow 4y ago
      To be honest, I think that go packaging is ghastly (just accessing dependencies in private repos requires changing global git settings, which is an abomination), but I can see how Java can be very heavy on that. However, I would not weight too much the time-to-first-makefile of a language if a project is supposed to live for years.
      • konart 4y ago
        >just accessing dependencies in private repos requires changing global git settings, which is an abomination 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.
        • shakow 4y ago
          > Just put a .netrc file in your homefolder with your username + token 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.
          • 4y ago