Also, do y’all call main() in the if block or do you just put the code you want to run in the if block?

    • addie@feddit.uk
      81·
      2 days ago

      Well now. My primary exposure to Go would be using it to take first place in my company’s ‘Advent of Code’ several years ago, in order to see what it was like, after which I’ve been pleased never to have to use it again. Some of our teams have used it to provide microservices - REST APIs that do database queries, some lightweight logic, and conversion to and from JSON - and my experience of working with that is that they’ve inexplicably managed to scatter all the logic among dozens of files, for what might be done with 80 lines of Python. I suspect the problem in that case is the developers, though.

      It has some good aspects - I like how easy it is to do a static build that can be deployed in a container.

      The actual language itself I find fairly abominable. The lack of exceptions means that error handling is all through everything, and not necessarily any better than other modern languages. The lack of overloads means that you’ll have multiple definitions of eg. Math.min cluttering things up. I don’t think the container classes are particularly good. The implementation of pointers seems solely implemented to let you have null pointer exceptions, it’s a pointless wart.

      If what you’re wanting to code is the kind of thing that Google do, in the exact same way that Google do it, and you have a team of hipsters who all know how it works, then it may be a fine choice. Otherwise I would probably recommend using something else.

      • sping@lemmy.sdf.orgEnglish
        2·
        1 day ago

        I’m now 1 year in to working in Go having been mostly C++ and then mostly large-scale Python dev (with full type annotation).

        Frankly, I bristle now at people giving Python a hard time, having worked with Go and I now hate Go and the de-facto ethos that surrounds it. Python may be slow, but for a lot of use cases not in any way that matters and modern computers are very fast. Many problem areas are not performance-limited, and many performance problems are algorithmic, not from raw statement execution. I even rewrote an entire system in Python and made it use 20% of the CPU the former C++ solution used, while having much more functionality.

        The error returns drive me nuts. I looked around for explanations of the reasoning as I wasn’t seeing it, and only found bald assertions that exceptions get out of control and somehow error returns don’t. Meanwhile standard Go code is very awkward to read because almost every little trivial function calls becomes 4 lines of code, often to do nothing but propagate the error (and errors are just ignored if you forget…). With heavy use of context managers, my error and cancellation handling in Python was always clean, clear, and simple, with code that almost read like whiteboard pseudo-code.

        The select statement can be cool in Go, but then you realize that literally 98% of the times it’s used, it’s simply boilerplate code to (verbosely) handle cancellation semantics via the context object you have to pass everywhere. Again, literally code you just don’t need in exception-based languages with good structures to manage it like Python context managers.

        And every time you think “this is stupidly awkward and verbose, surely there’s a cleaner way to do this” you find people online advocating writing the same boilerplate code and passing it off as a virtue. e.g. get a value from a map and fall back to a default if it’s not there? Nope, not offering that, so everyone must write their own if foo, ok := m[k]; !ok {...} crap. Over and over and over again the answer is “just copy this chunk of code” rather than “standard libraries should provide these commonly needed utilities”. Of course we can do anything we want ourselves, it’s Turing Complete, but why would we want to perpetually reinvent these wheels?

        It’s an unpopular language, becoming less popular (at least by Google trends) and for good reason. I can see it working well for a narrow set of low level activities with extreme concurrency performance needs, but it’s not the only language that could handle that, and for everything else, I think it’s the wrong choice.

      • silasmariner@programming.dev
        31·
        2 days ago

        This is the most excellent summary of Go I have ever read. I agree with everything you’ve said, although as a fan of Scala and in particular its asynchronous programming ecosystem (cats for me, but I’ll forgive those who prefer the walled garden of zio) I would also add that, whilst its async model with go routines is generally pretty easy to use, it can shit the bed on some highly-concurrent workloads and fail to schedule stuff in time that it really should’ve, and because it’s such a mother-knows-best language there’s fuck all you can do to give higher priority to the threads that you happen to know need more TLC

    • yogurtwrong@lemmy.world
      3·
      2 days ago

      I used it for a while and I think it’s been one of the best languages I’ve tried. C for example is too barebones for modern desktop apps. Apps written in Rust are great but most of the time, it’s just not worth the effort. And stuff like Python, JS is… uhh… where do I even begin

      I think Go hits the sweet spot between these. Unlike C, it at least has some simple error/panic mechanism, GC so you don’t have to worry about memory much and some modern features on top of that. And unlike Python it can actually create reasonably snappy programs.

      In any programming language, there will always be multiple cases where you need to link C libraries. CGo, although people don’t seem to be adoring it, is actually… okay? I mean of course it does still have some overhead but it’s still one of the nicer ways to link C libraries with your code. And Go being similar to C makes writing bindings so much easier

      Multithreading in Go is lovely. Or as I read somewhere “you merely adopted multithreading, I was born with it”

      Packaging is handled pretty nicely, pulling a library from the net is fairly trivial. And the standard directory structure for Go, although I’m not used to it, makes organizing stuff much easier and is easy to adopt

      As you would’ve guessed from the amount of times I mentioned C in this comment, I basically see Go as the “bigger C for different situations”