11 ms·

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was

A good twelve years. Go really changed the way I think about programming. I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible; huffman encoded better than even gzip could imagine. And I'd feel great about it. I'd imagine people reading it and thinking "wow, there's no way I'll ever be as smart as jrockway, I should nominate him for Extreme Excellence And Awesomeness award!" Sadly, there is no such thing. Go taught me that it's just structs, for loops, and if statements, and if you want someone to be impressed, they should be impressed by what the program does for them, not what language features you used to implement it. It has also ruined other programming languages for me. "go get" doesn't print 30 lines of text telling me that a new minor version of "go get" is available, and that I should stop what I'm doing, rm -rf node_modules, upgrade it, and then resume what I'm doing. It just pauses for a bit, and then I have the library. (I also love reading about the node community's push to make installing libraries not run arbitrary code on your machine. Yeah, I've been doing that for years with Go. It's great. I can use a library and it can't print a "hire me!!!" ad at install time. What an innovation!) I also remember struggling for years with not being able to run other people's software. There was an RPM package, but not a Debian package, so I have to build it from source. ./configure; make; oh no, the c compiler I have can't compile this code. With Go, you can just emit a binary for every supported platform dump the binary somewhere, and everyone in the world can download it and run it. No installing packages, no finding the right version of Go (that doesn't exist in your Linux distribution because they never ship up to date versions of programming languages). Just software, running, forever. It's really good stuff. Go is the tool that lets me make software, and not worry about bullshit. And that's revolutionary, even 12 years later.

leoc 5y ago
If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?
- ignoramous 5y ago
  Well, at some level you could say Go (pre 1.18) is Java 1.44 but with speed as a differentiator. Development speed, build speed, deploy speed, and runtime speed. If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)
- Zababa 5y ago
  Not having to wrap your imperative code in classes is a big plus.
- jerf 5y ago
  I have often thought that if you could travel back in time and make Java's interfaces work like Go, there would be no Go today. The first-order effects of that change may not seem like much, but the second-order effects of that change is profound. In Java, interfaces must temporally precede their implementations; in Go they don't have to. This turns out to be huge in practice. It turns out that huge swathes of all that boilerplate and frameworkitis that Java is so well known for are just trying to get around the consequences of that mistake, because all the interface-based structure has to be laid down in advance. It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born. In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem. It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.
  - kaba0 5y ago
    Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success. As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.
new_stranger 5y ago
> I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?" What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the same thing.
- _0w8t 5y ago
  Most perceived verboseness of Go comes not from the language or libraries but from the formater that does not allow to compress 3 lines of the error check down to single if err != nil { return err }
  - throwaway894345 5y ago
    If this is the case, I think the fault here lies with flawed perception and not the formatter.
    - _0w8t 5y ago
      The formater in many cases essentially doubles the number of lines. That requires to scroll much more frequently than with more compact formatting.
      - throwaway894345 5y ago
        I understand, but I take issue with the implication that compression makes code more readable.
  - pxue 5y ago
    Compressing this into 1 line provides absolutely nothing for the reader, in fact, it absolutely takes away reability.
    - The_Colonel 5y ago
caente 5y ago
> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible (...) they should be impressed by what the program does for them, not what language features you used to implement it. Interestingly, what made me go through similar evolution was the very language in which I was trying to do all those things, namely Scala. After a few years of trying to be "smart", I realized that the problem was usually bigger than the language. So perhaps, it wasn't Go, nor Scala, who helped us in our realization, but life and experience?
- throwaway894345 5y ago
  Our individual lives and experiences don't make the package manager better, though. Rather, Go's package manager (and its overall philosophy more generally) is good because Go was developed by people who had a lot of "life and experience". And it seems intuitive to me that someone who uses a language with a strong, mature philosophy would influence even more junior users.
- agumonkey 5y ago
  I believe he has a point. Go was from day one trying to walk a different path. It was wisely dumb, pragmatic, simple (even though yeah verbose on many fronts). It changes your focus on external value rather than internal value.
throwaway894345 5y ago
Agreed. It still surprises me that so many other languages fail at the fundamentals (minimal learning curve, static binaries, fast builds, reproducible dependency management, great tooling, great stdlib + ecosystem, etc) and yet many devotees of those languages have positively hyperventilated about Go's error handling and type system for 12 years. Go is finally getting generics and I'm sort of cautiously excited about it (like I was when Apple added the TouchBar to MacBook Pros), but any net benefit is going to be positively negligible in comparison to the degree in which Go raised the bar on the fundamentals.
- kaba0 5y ago
  I’m not arguing that there are languages where the state of tooling is bad to say the least, but how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages?
  - throwaway894345 5y ago
    There's a lot to like about Java and C#, but here are a few things that Go improved upon that spring to mind. Note that in some cases, Java and C# may have caught up in the interim. Note also that some things (e.g., low-latency GC) understandably weren't available from day 0 in Go, but followed quickly: * Static binaries by default * Single, straightforward build system (no DSLs) * Single, ubiquitous code formatter * Minimal learning curve * Zero-work package publishing * Zero-work documentation generation and publication * Testing framework out of the box * Production-grade HTTP server out of the box * Low latency GC out of the box More generally, C# and Java have always seemed to have a philosophy of "make everything as abstract and configurable as possible, and make the user understand every configuration option in order to do anything (overwhelm the user with configuration)". Granted, I haven't used C# or Java seriously since Go was open sourced, so it's possible that these are among the things that improved in C# and Java following Go's release.
  - sangnoir 5y ago
    > how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages? For me, Go being combination of being well-thought-out, opinionated and batteries included took away the futile fanboi flamewars/bike-shedding: JBoss or WebSphere? Tabs or spaces? Struts or Spring? For these reasons and more, Go is offers a more pleasant experience when working in a team. When reading code other's wrote,I encounter fewer surprises in the logic and project structure. Go codebases are easier to grok, IMO.
the_gipsy 5y ago
> With Go, you can just emit a binary for every supported platform dump the binary somewhere, and everyone in the world can download it and run it. Does this hold true? Don’t you need to switch to musl or something, to build a static binary?
- mdaniel 5y ago
  I believe you may be thinking of `CGO_ENABLED=1` which causes golang binaries to fail to run on musl distros So yes, your comment is probably right, but I get the impression the grandparent was a tiny bit tongue in cheek anyway
- moondev 5y ago
  It's actually easier now. On your target platform just "go run <import path>
tdeck 5y ago
> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. This happened to me too, without using Go. I think I just got older.
- throwaway894345 5y ago
  The nice bit about Go is that this maturity is baked into the philosophy and thus the language, the tooling, and the ecosystem where it benefits even younger developers. For example, your own hard-earned wisdom is great but it doesn't automatically make your language's package manager (or any other software you depend on, including libraries) better. But when that kind of wisdom is idiomatic, everything is better even when it's built by more junior developers.
  - tdeck 5y ago
    Oh, I'm not necessarily suggesting that my lack of curiosity about new language designs is a good thing. In fact I think it's kind of a mixed bag. I'm only clarifying because I don't want to seem to be implying something negative about younger developers.
    - throwaway894345 5y ago
      I didn't think you were implying anything about younger developers, I was noting the rather significant difference between "I've matured as a programmer" and "maturity was baked into the language I use and its idioms, tools, ecosystem, etc".
      - tdeck 5y ago
        Yeah, my point was that "matured" and "wisdom" are value-laden words and that's not necessarily the connotation I wanted to convey. Ideally I would get excited about both the problem and the tools. I completely understand the point you're trying to make about the ecosystem though.
- adamc 5y ago
shaan7 5y ago
> Just software, running, forever. Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".
- msie 5y ago
  Ah, but what if the updated shared lib broke other apps depending on the old version? Pros and cons.
  - shaan7 5y ago
    > Pros and cons Exactly. Which is why I don't get the "static linking is the best solution for deploying applications". You need to be able to do both. For example when building a C/C++ application you can decide if you want shared libs or static builds.
grumpyprole 5y ago
I'm happy to entertain the idea that Go is a sweet spot for many, but please let's not pretend language features are universally bad. After all, Go benefits enormously from a garbage collector and its language-level support for Hoare's CSP. Two very important features that e.g C and C++ do not have (they do however have structs, for loops and if statements). IMHO Go certainly chose wisely when it left out many OOP features of questionable value. And perhaps in doing so, it avoided the whole OOP culture, which has produced a lot of over-complicated software and tools. The culture of simplicity in Go is a really good thing and worth defending. However, we should be open to the idea that one or more additional language features might help to further this goal.
uncomputation 5y ago
Go’s package and dependency system is actually the only reason I have never started using it more. The lack of true versioning, unspoken assumption of GitHub, package system, and all of the confusion between god mod, go get, go install, etc. just hurts my brain. I think Rust actually has this perfect. It’s clear. You just specify the name and version and features in the Cargo.toml file and it is pulled from crates.io. No installation-time execution either. As far as binaries, I think Rust beats it out here too. Take path separators for example. It’s completely possible to have a binary in Go that uses the entirely wrong path separators for the OS. Rust forces you to handle this.
- amscanne 5y ago
  > The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.
  - pjmlp 5y ago
    Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings. As it should be.
    - amscanne 5y ago
      I’m not sure I follow. I assume “as it should be” refers to crates, with no mechanism for name ownership other than first-come, first-served. You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.

leoc 5y ago

If you think there's some virtue in writing verbose and inexpressive imperative code, what does Go provide in that department that you couldn't have got from Java 1.44?

ignoramous 5y ago
Well, at some level you could say Go (pre 1.18) is Java 1.44 but with speed as a differentiator. Development speed, build speed, deploy speed, and runtime speed. If Russ Cox ever proposes to rename Go to JavaScript, I guess no one would complain. ;)
Zababa 5y ago
Not having to wrap your imperative code in classes is a big plus.
jerf 5y ago
I have often thought that if you could travel back in time and make Java's interfaces work like Go, there would be no Go today. The first-order effects of that change may not seem like much, but the second-order effects of that change is profound. In Java, interfaces must temporally precede their implementations; in Go they don't have to. This turns out to be huge in practice. It turns out that huge swathes of all that boilerplate and frameworkitis that Java is so well known for are just trying to get around the consequences of that mistake, because all the interface-based structure has to be laid down in advance. It isn't the only difference between the two, but I think it would have consumed enough of the oxygen of the niche Go is currently in that Go might never have been born. In practice, I find Go to be just slightly harder than working with dynamically typed languages, rather than a huge step, and the benefits I get in return make me prefer it for almost any task above 200-ish lines. I definitely can not say the same about Java, because of this difference and the second-order effects it has on the entire ecosystem. It is still completely practical to create a production-level Go project by just cracking open a text editor and typing "package main" into your editor and typing away. I get the impression most people would not consider that a practical way to start a production-level Java project.
- kaba0 5y ago
  Java’s nominal typing is both better and worse at the same time - but go is not novel in that area, plenty of similar languages existed before as well, so I don’t think having it contributed to go’s success. As for your last paragraph, I feel like we often mean something different between a production-level go and java project. Non-IDE java development is entirely possible, but I think a prod project usually means something much larger than it does in case of go.

new_stranger 5y ago

> I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible Which is also the hardest part of convincing people to use Go for me: "Why can't I just .map()/.filter()/.find()?" followed closely by "Why do I always have to check for errors?" What is odd to me is that while yes, my Go code is more verbose than my node services - I always end up writing less Go for the same thing.

_0w8t 5y ago
Most perceived verboseness of Go comes not from the language or libraries but from the formater that does not allow to compress 3 lines of the error check down to single if err != nil { return err }
- throwaway894345 5y ago
  If this is the case, I think the fault here lies with flawed perception and not the formatter.
  - _0w8t 5y ago
    The formater in many cases essentially doubles the number of lines. That requires to scroll much more frequently than with more compact formatting.
    - throwaway894345 5y ago
      I understand, but I take issue with the implication that compression makes code more readable.
- pxue 5y ago
  Compressing this into 1 line provides absolutely nothing for the reader, in fact, it absolutely takes away reability.
  - The_Colonel 5y ago

caente 5y ago

> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. I'd spend hours condensing 10 lines of perfectly working code into 1 line of the most concise text possible (...) they should be impressed by what the program does for them, not what language features you used to implement it. Interestingly, what made me go through similar evolution was the very language in which I was trying to do all those things, namely Scala. After a few years of trying to be "smart", I realized that the problem was usually bigger than the language. So perhaps, it wasn't Go, nor Scala, who helped us in our realization, but life and experience?

throwaway894345 5y ago
Our individual lives and experiences don't make the package manager better, though. Rather, Go's package manager (and its overall philosophy more generally) is good because Go was developed by people who had a lot of "life and experience". And it seems intuitive to me that someone who uses a language with a strong, mature philosophy would influence even more junior users.
agumonkey 5y ago
I believe he has a point. Go was from day one trying to walk a different path. It was wisely dumb, pragmatic, simple (even though yeah verbose on many fronts). It changes your focus on external value rather than internal value.

throwaway894345 5y ago

Agreed. It still surprises me that so many other languages fail at the fundamentals (minimal learning curve, static binaries, fast builds, reproducible dependency management, great tooling, great stdlib + ecosystem, etc) and yet many devotees of those languages have positively hyperventilated about Go's error handling and type system for 12 years. Go is finally getting generics and I'm sort of cautiously excited about it (like I was when Apple added the TouchBar to MacBook Pros), but any net benefit is going to be positively negligible in comparison to the degree in which Go raised the bar on the fundamentals.

kaba0 5y ago
I’m not arguing that there are languages where the state of tooling is bad to say the least, but how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages?
- throwaway894345 5y ago
  There's a lot to like about Java and C#, but here are a few things that Go improved upon that spring to mind. Note that in some cases, Java and C# may have caught up in the interim. Note also that some things (e.g., low-latency GC) understandably weren't available from day 0 in Go, but followed quickly: * Static binaries by default * Single, straightforward build system (no DSLs) * Single, ubiquitous code formatter * Minimal learning curve * Zero-work package publishing * Zero-work documentation generation and publication * Testing framework out of the box * Production-grade HTTP server out of the box * Low latency GC out of the box More generally, C# and Java have always seemed to have a philosophy of "make everything as abstract and configurable as possible, and make the user understand every configuration option in order to do anything (overwhelm the user with configuration)". Granted, I haven't used C# or Java seriously since Go was open sourced, so it's possible that these are among the things that improved in C# and Java following Go's release.
- sangnoir 5y ago
  > how did Go raise the bar compared to something like Java or C#, the actual “blue-collar” languages? For me, Go being combination of being well-thought-out, opinionated and batteries included took away the futile fanboi flamewars/bike-shedding: JBoss or WebSphere? Tabs or spaces? Struts or Spring? For these reasons and more, Go is offers a more pleasant experience when working in a team. When reading code other's wrote,I encounter fewer surprises in the logic and project structure. Go codebases are easier to grok, IMO.

the_gipsy 5y ago

> With Go, you can just emit a binary for every supported platform dump the binary somewhere, and everyone in the world can download it and run it. Does this hold true? Don’t you need to switch to musl or something, to build a static binary?

mdaniel 5y ago
I believe you may be thinking of `CGO_ENABLED=1` which causes golang binaries to fail to run on musl distros So yes, your comment is probably right, but I get the impression the grandparent was a tiny bit tongue in cheek anyway
moondev 5y ago
It's actually easier now. On your target platform just "go run <import path>

tdeck 5y ago

> I used to be excited by programming language features instead of what problem I was actually trying to solve with programming. This happened to me too, without using Go. I think I just got older.

throwaway894345 5y ago
The nice bit about Go is that this maturity is baked into the philosophy and thus the language, the tooling, and the ecosystem where it benefits even younger developers. For example, your own hard-earned wisdom is great but it doesn't automatically make your language's package manager (or any other software you depend on, including libraries) better. But when that kind of wisdom is idiomatic, everything is better even when it's built by more junior developers.
- tdeck 5y ago
  Oh, I'm not necessarily suggesting that my lack of curiosity about new language designs is a good thing. In fact I think it's kind of a mixed bag. I'm only clarifying because I don't want to seem to be implying something negative about younger developers.
  - throwaway894345 5y ago
    I didn't think you were implying anything about younger developers, I was noting the rather significant difference between "I've matured as a programmer" and "maturity was baked into the language I use and its idioms, tools, ecosystem, etc".
    - tdeck 5y ago
      Yeah, my point was that "matured" and "wisdom" are value-laden words and that's not necessarily the connotation I wanted to convey. Ideally I would get excited about both the problem and the tools. I completely understand the point you're trying to make about the ecosystem though.
adamc 5y ago

shaan7 5y ago

> Just software, running, forever. Until your users realize that if there was a security vulnerability which was fixed, a system upgrade is not enough. They will have to either hope that you haven't moved on, or build things themselves. But then, thats not a problem with Go specifically, thats a general issue with "static link all things".

msie 5y ago
Ah, but what if the updated shared lib broke other apps depending on the old version? Pros and cons.
- shaan7 5y ago
  > Pros and cons Exactly. Which is why I don't get the "static linking is the best solution for deploying applications". You need to be able to do both. For example when building a C/C++ application you can decide if you want shared libs or static builds.

grumpyprole 5y ago

I'm happy to entertain the idea that Go is a sweet spot for many, but please let's not pretend language features are universally bad. After all, Go benefits enormously from a garbage collector and its language-level support for Hoare's CSP. Two very important features that e.g C and C++ do not have (they do however have structs, for loops and if statements). IMHO Go certainly chose wisely when it left out many OOP features of questionable value. And perhaps in doing so, it avoided the whole OOP culture, which has produced a lot of over-complicated software and tools. The culture of simplicity in Go is a really good thing and worth defending. However, we should be open to the idea that one or more additional language features might help to further this goal.

uncomputation 5y ago

Go’s package and dependency system is actually the only reason I have never started using it more. The lack of true versioning, unspoken assumption of GitHub, package system, and all of the confusion between god mod, go get, go install, etc. just hurts my brain. I think Rust actually has this perfect. It’s clear. You just specify the name and version and features in the Cargo.toml file and it is pulled from crates.io. No installation-time execution either. As far as binaries, I think Rust beats it out here too. Take path separators for example. It’s completely possible to have a binary in Go that uses the entirely wrong path separators for the OS. Rust forces you to handle this.

amscanne 5y ago
> The lack of true versioning, unspoken assumption of GitHub, package system, These aren’t true. There is true versioning and no assumption of GitHub. Shouldn’t this be a complaint about the assumption of crates.io? > No installation-time execution either. This is also not true. There is no installation-time execution.
- pjmlp 5y ago
  Nope, there is no relation between a package name and where it is hosted, nor any need to create remappings. As it should be.
  - amscanne 5y ago
    I’m not sure I follow. I assume “as it should be” refers to crates, with no mechanism for name ownership other than first-come, first-served. You name any Go package based on a URL you control (and you can refer to any underlying source control by returning appropriate metadata from that URL). Package names that are URL-based is an arbitrary decision, but it seems like it at least solves that problem. Personally I’m much more a fan of that, since otherwise you need to put far too much faith in a single provider (crates), and enable a whole class of attacks and ownership squabbles. Better to just punt this to the already-solved DNS and web ecosystem. I just can’t agree that a single centralized repository is “as it should be”.