8 ms·

"There are no changes to the language." It's the calm before the storm. But I love that. :) 10 years in, Go is still my favorite language when it's the right

• _wldu 6y ago
  What storm? Generics?
  • mseepgood 6y ago
    Yes, the proposal was accepted this week: https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
    • _wldu 6y ago
      But is that really bad for Go? I'm not sure it is. Go1 will always be useful just as it is.
      • mseepgood 6y ago
        > But is that really bad for Go? No, I don't think so.
      • cpuguy83 6y ago
        I don't think the op intended "storm" to be negative here. Just to say that there are loads of changes coming soon.
      • throwaway894345 6y ago
        One of the features of Go is that everyone writes code the same way, which means anyone can easily read anyone else's code; there's only one paradigm; idioms and conventions are strong across the community. This property exists precisely because Go isn't very expressive, but the generics proposal will make Go more expressive and in all likelihood the ecosystem will become more diverse accordingly. Whether this is a positive or negative depends on how much you value expressiveness versus standardization.
  • mholt 6y ago
    Yeah. To clarify, I'm not suggesting it's either good or bad -- just that it's a big deal. To some, it's controversial. I personally think Go's proposed implementation of parametric polymorphism a great feat of modern software engineering, and a testament to the open source process. Anyway, they'll probably land in Go 1.18.
    • _wldu 6y ago
      Thanks. I could take them or leave them. I've used generics a lot in C++, but as long as I can continue writing Go1 programs as I have been for the last 10 years, I'll be happy.
      • craigching 6y ago
        Oh, come now, calling C++ templates generics belittles their power. :p Honestly, the one thing I miss in any language is the complete power of C++ templates, but I definitely understand others' reluctance to include something like them in their language. Something that allows me to write simple generic functionality a la Java generics and not have to write the same code multiple times is good enough for me in go. Luckily I do have some ability to use C++ at my current job, so I can get my fix again there :)
    • benhoyt 6y ago
      I'm looking forward to them, and definitely agree it's a great feat of software engineering ... though I'm not sure about "testament to the open source process". Go is open source, but most of the core developers are Google employees, and definitely the folks that worked on generics (Ian and Robert, mainly) are full time at Google. I don't actually think that's a bad thing: I love it that Google pays people to work on Go full time, and don't mind the language being spear-headed by a tight team with a vision (who happen to work at a commercial entity). I'm impressed with their direction, and ability to say no.
      • nemo1618 6y ago
        Yeah, let's be real -- just as with Go Modules and the "try" proposal, there is no "open source process" when it comes to major language changes; the decision is always ultimately made by the core team, not the community. And I agree with you -- this arrangement is fine! I strongly prefer it that way. The Go devs have an excellent track record of getting it right, even when it went against the prevailing wisdom. Personally, I'm opposed to adding generics, but if we have to...I trust the Go devs to do it better than just about anyone else.
• btreecat 6y ago
  >Go is still my favorite language when it's the right tool for the job. Forgive my ignorance, when would you recommend go? As in what problem domains have you seen it excel at? I have thought about trying it in the past and even tinkered with a project for a bit but didn't quite find it useful enough to be worth the tooling cost (at the time). Would like an excuse to check it out again.
  • fileeditview 6y ago
    My guess is web servers for one, since he is the author of the Caddy web server (written in Go). Btw thanks for that.. I recently moved to a new VPS and migrated from nginx to Caddy.. I love it.
    • mholt 6y ago
      Awesome, glad to hear it! :)
  • hellcow 6y ago
    Not GP, but I choose Go for webservices as well as devops tooling. I use it whenever possible. I've been very happy with the decision to use Go over the past 4 years at my company.
  • mholt 6y ago
    It's easy to learn and and great for getting something useful deployed pretty quickly. In both undergrad and grad school, I often chose Go and my projects -- using the same algorithms as classmates -- were finished sooner, ran faster, had less bugs, and used less resources. Go is pretty good for almost anything server-side. I wrote a web server in Go that a lot of businesses use in production. It's a very practical "get things done" language and is generally associated with developer satisfaction/happiness. Almost anywhere you use C/C++, I would try to use Go. It's progbably easier to enumerate what Go is not good at: native GUIs, C interop, some kinds of data science (though I used it as much as Python in college), and some kinds of very low-level programming (though it can be good for embedded systems, if you can stomach large binaries).
• bborud 6y ago
  I am unreasonably happy for the standard library support for embedding files. I'm not kidding. This makes my life so much easier. :-)
  • dvirsky 6y ago
    +1 this is so nice. I actually think this is a bit too much magic: > import _ "embed" > //go:embed hello.txt > var s string > print(s) But the embed.FS example looks much nicer, I'm glad we can have both.
    • xyzzy_plugh 6y ago
      It's a balancing act. It's the least amount of magic necessary, IMO. I think it's a great solution over all!
      • TheDong 6y ago
        I don't think it's the "least amount of magic". A lesser amount of magic would be what rust has: let s = include_bytes!("./file.txt"); As a bonus, if you typo the "include_bytes!" macro, as say "includ_bytes", you get a compiler error. With the go one, if you typo it as "//gp:emebd hello.txt", then you get no compilation error, just an empty string. If someone compiles your program with an old version of the go compiler, they get no error, just a totally broken program. Meaningful comments are some of the worst magic you can add to a language IMO. It's far simpler to reason about compiler-checked preprocessor instructions or macros, both of which are valid alternatives the go team could have added just as easily.
        • mseepgood 6y ago
          Um, macros are a huge amount of magic. You basically give language design in the hands of users.
          • TheDong 6y ago
            The go authors could do what they originally did with generics: only let the compiler/stdlib have macros. Also, go users have _already_ started parsing comments for magic strings, so it's not like setting an example of using comments is stopping users from doing this crap too. A macro language which is defined in a clear and consistent way definitely seems less magic than a macro language which has no real definition, other than examples of comments.
• christophilus 6y ago
  Agreed. I'm kind of regretting using Node for my current project. Every time I look at package-lock.json, I die a little. I really like the way Go projects tend to have very few dependencies.