1. 29
  1.  

  2. 17

    I just posted that 2 minutes after you. Removed my submission but consider changing your title to the original ‘Program your next server in Go’ and adding a slides tag :)

    Welcome to lobste..rs :)

    1. 14

      I had to laugh (in a kind way) at this slide:

      https://talks.golang.org/2016/applicative.slide#13

      We have one in the Rust world, too, just the axes are different (Control vs. Safety):

      https://twitter.com/Argorak/status/738643796020301824

      1. 10

        It is interesting that the golang axes attempt to be accurate, where as the the Rust one is just the obligatory up and to the right (which may also be accurate, of course!).

        People in my very unscientific survey suggest that Go:

        1. is fun to program in
        2. isn’t perfect
        3. is productive
        4. is suitable for many scripting tasks

        Benchmarks suggest that Go is:

        1. pretty fast
        2. not as fast as C/C++
        3. often faster than Java
        1. 4

          i’m not a huge fan of go viewed purely as a language, but if you consider “fast and fun for humans” as a sum of language + dev tooling + deployment, they’re selling themselves short on that axis, if anything.

          1. 5

            3. is productive

            To a point. There is a lot of copying and pasting, a lot of “verbosity” for the sake of … not sure what, but the don't DRY out quote from one of the posted slides sort of explains it.

            I like go for small projects, for large projects with lots of code it becomes an unrefactorable mess.

            1. 6

              Copy and paste can be productive. Go lacks a lot of the generalized abstractions that make it a good language, but in my experience it’s as fast, or faster to write in Go vs JavaScript or Python.

              I don’t defend Go because I like it, mind you. But, I can’t ignore the speed in which I and others have developed pretty high quality, and scalable stuff with it, either.

              1. 3

                I’m somewhat surprised by the existence of large projects written in go.

                The language is <10 years old - either someone wrote a lot of code in a very short period of time, or we have different definitions of large (my first job after uni had >1million SLOC and ‘unrefactorable mess’ did not begin to cover it).

                1. 2

                  Kubernetes is in that range but i may have counted dependencies.

                  edit: 700k lines without dependencies, 1.2 million with them

                  1. 2

                    There’s no clear definition of “large”. 1 mloc might be considered “very large”.

                    https://en.m.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small

                    1. 1

                      Ours is not large but we’ve had some transitioning of some of our services at gitlab to Go

                    2. 2

                      Go offers several ways to avoid repeating code. Each has its own tradeoffs. Sometimes copy and paste is the most appropriate, but its hardly the default.

                      Re: large systems. I’m just getting there with Go and to remain effective I’ve rewritten a few packages multiple times. I see no evidence unrefactorable messes are inevitable.

                    3. 3

                      Our startup switched to Go almost a year ago and we came to the same conclusions.

                      Can confirm that 4. is indeed very true, we were surprised by how easy it can be to output scripts that are still maintainable/readable and being written on a short timeframe.

                      Regarding 1. and 3. our feeling is that it clearly depends on what is being implemented.

                      As soon as the project requires a lot of business logic, in our experience, expressivity became clearly a problem. We ended with a lot of boiler plate and some rather boring code but it still executes pretty fast so it’s a fair tradeoff. Maybe with more experience this will come better, we’ll see. If anyone could point me toward resources addressing this, that’d be awesome ! :)

                      On the other hand, when it comes to writing stuff that needs to be fast and mostly does one critical thing, the results are speaking for themselves, code is simple and concise and pretty damn fast. It’s not that we couldn’t have written it in C, it’s just that it’s really comfortable to do it in Go and quickly yield clearly solid results (for us).

                      Still our team feel some frustrations regarding the lack of abstractions, but we’re solving this from now on by using Go mostly in the latter scenario.

                    4. 9

                      There’s also Simon Peyton Jones' chart, where the axes are “usefulness” and “safety”.

                      1. 3

                        <3. I love how this is obviously from the time where STM seemed to be the topic of the day.

                        Also: I have a horrible, horrible memory for faces. Is that Erik Meijer in a shirt with just two colors?

                        Also (II): Interesting that the idea of bringing SQL stuff back into the programming languages has worked out.

                        1. 8

                          This is a favorite video of mine, for a couple of reasons:

                          • The acknowledgment that languages readily steal from each other
                          • The fact that these language researchers/developers are friendly with each other (it’s easy to get into this world of language mono-culture where your language is the one true language and the other languages are evil. It’s good to remember that this is silly)
                          • No one puts down any other language (in fact, Simon Peyton Jones is quite self-deprecating toward Haskell, in calling it useless)
                          1. 8

                            As a real world example of #2, I presented at the same conference as this presenter, and he came up before mine to introduce himself, say hi, and ask if we shouldn’t grab some lunch sometime since we both live in NYC. I was very humbled. I wouldn’t say the Rust and Go teams know each other super well, but we’re extremely friendly and respectful of each other’s work, generally speaking.

                      2. 3

                        This slide looks like it was written by someone who doesn’t even know C++. They put Go way above it, but put C only barely below it.

                        This is completely wrong; it should be the other way around. Go is only marginally easier than C++, while C++ is much easier than plain C.

                        1. 4

                          You are aware that this is a slide of a rust core member? They probably know C and C++ quite well.

                          All slides are marketing material and the grouping isn’t scientific.

                          1. 1

                            C++ is much easier to write than C is but not necessarily to read (other’s people’s code). Because of how verbose Go is, it is much easier to read other people’s code.

                        2. 3

                          You can take the golang tour offline since GO 1.6, going to try that on my next long flight :)