21 ms·

The ecosystem of the Go programming language

204 points by henvic 6y ago

jimmyed 6y ago
I remember Rob Pike talking about how each language has its own way of doing things and it's bad to keep adding all features to all languages. This only makes them all end up being the same he said. The Go way was code generation. After they included generics, I wonder if the go team has let go of that principle.
- shaan7 6y ago
  Code generation only solved part of the problem - saving the trouble of having to write repetitive code. It does not solve the maintainability problem because if something needs to change then you need to manually change all the generated code. I have been using Go since last ~6 years and I'm really excited that the only pain point I had with Go will soon go away \o/
  - abatilo 6y ago
    Wasn't the ability to add a //go:generate comment enough to make it easy to re-generate anything that you needed?
    - isaiahg 6y ago
      Generation is a rather big solution for sometimes small problems. For many things like utility functions I think generics are much more readable and easier to understand while go generate would be heavy handed.
- throwaway189262 6y ago
  Yet Go's code generation is clunky even compared with Java's Annotation Processors.
- hu3 6y ago
  Considering how long and how much discussion it took to implement generics (coming in 1.18 according to FAQ [1]), I'd be inclined to say it supports their principle. I don't think they ever said they wouldn't implement Generics. It was a matter of maturing and consideration of different proposals. [1] https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
- pansa2 6y ago
  Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
  - nerdponx 6y ago
    It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.
    - ozkatz 6y ago
      6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
    - Thaxll 6y ago
      Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
      - nerdponx 6y ago
        Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
- dkarl 6y ago
  You can think of generics as providing support for a simple, common form of code generation in the language itself. That might not be technically precisely correct, but looking at it that way makes it seem like not a radical change at all.
- Thaxll 6y ago
  10 years later the language is still the same, not much has changed, I can't say the same about Rust, C#, Java, PHP, Python etc ... The only major thing that came in the last couple of years was Go module, and it's more on the tooling side than the language itself.
- streblo 6y ago
  > it's bad to keep adding all features to all languages I understand the reasoning behind this take - a lot of modern languages have wound up somewhat bloated, with features that are either non-orthogonal to other features and break the 'one way to do it' principle (Scala comes to mind), or with features that seem tacked-on and feel alien to the language (the latest versions of python come to mind). I understand, in theory, why go tries to buck this trend. The problem is that in bucking this trend, go has (at least historically) not evolved enough to fix some of its own core issues. And it does have some big issues - nils, zero values, and non-thread safe primitives come to mind for me. I'm all for being thoughtful about introducing changes and making sure those changes are idiomatic and don't violate the 'ethos of go'. But avoiding making those changes in the name of 'keeping it simple' never made sense to me in cases where programmers are shooting themselves in the feet and already not having a simple time with your language.
petercooper 6y ago
Just as it's not mentioned there, I've been running a Go newsletter for the past six years at https://golangweekly.com/ https://golangweekly.com/ (yes, RSS is available) - the archive can act a sort of week by week "what happened" for anyone looking back to specific points in Go's history over that time.
- donut 6y ago
  Hey Peter! Thank you for doing this. I'm a regular reader and love what you do.
  - petercooper 6y ago
    Thanks, very kind! :)
- henvic 6y ago
  omg, I can't believe I forgot to add it! Just added :)
  - petercooper 6y ago
    Thanks, no problem! Congratulations on the success of your post!
    - grossemerde 6y ago
      Cdjksnbhhfsbdvfsdbhjgeographiedemerdequifaitchierdansleculcommeunchevaldemerde Kek
yulaow 6y ago
Is this updated? I see in the suggested resources to learn Go there is a book created in 2015... The language and related patterns changed so little that that book is still good? Or anyway, do you have any to suggest?
- q3k 6y ago
  > The language and related pattern changed so little that that book is still good? Pretty much yes, and TGPL/Effective Go are still very good resources to learn the language, if not still the best available. Probably the biggest changes since 2015 were constant stdlib improvements / extensions, and things like the context API becoming standardized across the ecosystem. Oh, and Go modules. Otherwise the language is pretty much unchanged.
  - s-video 6y ago
    I hope they write a second edition, and give the cover a red "GO 2" stamp graphic, like they did with ANSI C on the K&R second edition cover.
    - henvic 6y ago
      Maybe '<decade/year> edition' would be better :)
- petercooper 6y ago
  If you mean The Go Programming Language then yes, it's still a fine book. It doesn't cover new additions like Go modules, of course, but in terms of the core elements of the language, it stands up well. Are you going to probably want more once you've covered the essentials? Yes, but it'll put you in a great position to take on further material.
- wbl 6y ago
  I still use my K&R which proudly proclaims that it includes the new ANSI C 89.
Ashanmaril 6y ago
I've been using Go for a personal project of mine recently. I had briefly used it at the tail end of my internship while getting my degree, but nothing particularly in-depth, and it was some pretty simple server code that never really challenged me. There's definitely some nice stuff about it, but there's also some stuff that's a bit of a pain. For one thing, being straight up unable to compile a program if there's an unused variable, not even a debug compiler flag or anything to allow it while testing. There's a lot of cases where I just want to move one thing around, or I'm partway through writing a function and just want to see what state something is in at a point, so I want to throw a breakpoint on a line and run the program up to that point. But even though my code is technically all valid, because the variable I want to look at is unused, or I commented out a line that makes something else unused, I now can't compile at all. So there's a lot of times I'll have to throw in a random fmt.Print of a random property of index zero of an array or something, which might crash anyway if it's reached, but at least it'll compile. It maybe doesn't seem like it would be that big of a deal, but when you've got a train of thought going, and you're trying to iterate fast, it can really pull you out of the flow of things. There's also a lot of weird situations where I find it hard to keep things clean. For instance, I like using this shorthand: if err := doThing(bar); err != nil { // handle error } But if you're doing it in a case where your function returns a result and an error, i.e. if foo, err := doThing(bar); err != nil { // handle error } That's indeed valid code, but foo only exists in the scope of that error handling. So you'd have to declare it above with its type var foo FooType if foo, err := doThing(bar); err != nil { // handle error } But you can't actually do this because when using type inference, both return values have to not be declared beforehand. So you have to pull err out into a declared var with a type, and remove the type inference altogether like this var foo FooType var err Error if foo, err = doThing(bar); err != nil { // handle error } And from that point on, if you're using this pattern again anywhere else below in that function and you want to continue using that slick error handling shorthand, there's barely any point because err already exists in your scope, and you'd just be redeclaring it. Perhaps there's some tricks I don't know about, but I tend to run into situations like this a lot, and I spend so much time trying to appease weird edge-cases of the compiler's strict rules that is really throws a wrench in my workflow.
- 6y ago
jimmyed 6y ago
Does Go have tail recursion? I'm guessing not since Go isn't big on the "optimization" part.
- fredrikholm 6y ago
  > Go isn't big on the "optimization" part. Care to elaborate?
  - jerf 6y ago
    It's true. Go prioritizes compile speed over a ton of optimization. It does fast ones, but it doesn't do the expensive ones. I don't know whether the Go compiler never does tail-call optimization, but I do know it is never something you can count on. (There's two kinds of tail call optimization... there's the one where the compiler may choose to do it as an optimization step, but you can't ever count on it because at any time for any reason it may stop, so you have to assume it didn't happen. Then there's the kind you can absolutely count on, and program tail-call-based algorithms secure in the knowledge that they won't blow out the stack. I'm pretty sure Go doesn't have the latter.)
    - fredrikholm 6y ago
      Thank you for clarifying. Does this apply to procedural code as well? Go not implementing TCO makes sense as the language is _very_ Wirthian.
- thomascgalvin 6y ago
  Yes: https://blog.usejournal.com/tail-recursion-in-go-fb5cf69a0f26 https://blog.usejournal.com/tail-recursion-in-go-fb5cf69a0f2...
  - jerf 6y ago
    FWIW, I read "tail calls" as referring to the optimization that allows you to rely on the tail-recursive calls not generating stack frames, on the grounds that I'm not aware of any language that specifically forbids tail recursion.
kaladin_1 6y ago
Nice article... Over here I've invested a lot in Java, to be used where static typing is necessary, JavaScript (Node.Js), Elixir and PHP on other occasions. But it's beginning to look like Go will displace Java. So, might be high time we learned Go :/
- panzerboy 6y ago
  Umm ... what exactly makes you say that?
  - kaladin_1 6y ago
    Very soon whoishiring will start a thread for April. I bet you are going to see more Go opportunities than Java.
- thomascgalvin 6y ago
  The only production Go code I ever see is in a kubernetes operator. The backend services I see deployed are probably 75% JVM, 25% Node, and less than 1% something else. Go is popular at Google, but we're kind of past the point where something being popular at Google makes it popular everywhere.
  - Philip-J-Fry 6y ago
    Twitch.tv uses mostly Go AFAIK. Where I work we use Go in all our services. There's plenty of uses of Go. You just won't ever hear about them, because why would you? You see Java and Node because that's all you've ever worked with. I see Erlang, .NET and Go, because that's all I've ever worked with.
    - RSHEPP 6y ago
      Work at a large telecom co., who used to be Java only, I only write Go. Hn threads like this is when you realize it's core user base.
  - kyrra 6y ago
preommr 6y ago
Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn't go away, it's hidden away somewhere. If anybody wants to learn go, ignore everything about how easy it is to learn. Because it's extremely deceptive. Take time to actually read through a lot of the important underlying concepts like how slices work. Ignore comments about how go is simple to write. There's a fair amount of bad go code and people break rules all the time. From official sdks to standard libs. Go can be extremely difficult to both write and read. It's implicit interfaces and judicious abuse of interface{} can make tracing how a library is supposed to work a PITA. Writing go can be difficult because of a lack of some language constructs that leave you unsure how to proceed. If you can, use goland. I use vscode and it's... not pretty. Almost every single thread I've seen on reddit recommends goland. My experience with vscode has been very unpleasant, particularly with go plus. OTOH, things like criticisms about it's error handling are overblown. At best it's a mild nuisance, and more often than not, a good thing that makes error handling explicit and clear. There are many things about go that have made me appreciate it's existence. There are also many things that have left me absolutely baffled at how bad it is.
- randomdata 6y ago
  > Ignore comments about how go is simple to write. Do people say that? I've never heard anyone claim that Go is simple to write. Pike, I believe (may have been someone else), claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read." Go was built on the premise that people spend more time reading code than writing code and Go attempts to make tradeoffs towards reading optimization rather than writing optimization. Whether or not it is successful in that is another topic for another day.
  - Thaxll 6y ago
    Go is very simple to read and to write, I'm not sure how one can argue against that. Without prior knowledge you can jump into any code base and won't be suprised by something you never seen before or does not understand what it does. The language is simple to grasp because it has just a few concepts and keywords.
jonathanstrange 6y ago
I like Go and have no major complaints about it. I especially like the highly performant garbage collector and the fact that there are a lot of libraries for it. With the libraries you have to be careful, though, quality of 3rd-party libraries differs a lot on Github. There is also one point of critique, I believe that Go got its concurrency primitives wrong. I fear people will hate me for saying this, but I say it because almost every library I've tested that uses lots of goroutines fails or produces some serious concurrency errors at one point or another. Not only are there many race conditions in Go code, there are also many libraries that silently fail. For example, scan Github for parallel directory walkers or check out uses of sync.atomic. I personally believe that both transactional memory and the actor model are easier to use although it might be harder to implement and make them efficient. I also think that thread local storage and Goroutine identities would have been useful, despite what the language purists say. Generally speaking, I think Go's choices of concurrency primitives are too low level. (I'm not saying there is anything wrong with them per se, just too low-level for most of Go's users, and I'm not excluding myself in this assessment.)
- dilap 6y ago
  Yeah, bounded channels ended up being more effective as a hype mechanism than a great concurrency primitive, I would say. Coming from Go and kicking the tires a bit on Rust, I was impressed w/ how much nicer it was to write parallel code using Rust + the crossbeam library than Go. At the end of the day Go's concurrency story is just traditional threads and mutexes, with custom syntax for one particular datastructure. But, you do get a great runtime race detector & the M:N scheduler, so you can use lots of goroutines w/o blowing out memory, avoiding async hassles.
- coder543 6y ago
  I agree with a lot of this. I'm especially looking forward how generics should make it easier to build a library of high level concurrency patterns that people can use in Go, instead of everyone trying to build their own. Promises (which would allow you to start a number of parallel tasks, then wait on the results), "parallel for" with controlled amounts of concurrency, etc. The M:N scheduler is great, and the ability to easily spin off Goroutines is really nice, but I think most people shouldn't need to manually launch goroutines most of the time. Goroutines should just be an implementation detail.
isaiahg 6y ago
I really like go. Its simple in that you can learn the language pretty quick. I might get burned in another comment below but it's the language that feels the closest to C to me. Both are really simple languages that can get relatively complicated pretty fast. Inheritance through embedding for one feels a lot like using -fms-extensions in C. However I think the coolest part of the language is the part no one talks about. The inclusion of comments as a major part of a program. // +linux for managing files for specific platforms is just wonderful. //go:embed for embedding files and directories into your program // #include <stdlib.h> import "C" is probably the coolest and easiest ways to use C libraries I've seen. You can write C code directly into your go files and even set complier and linker flags. //go:generate can allow you to automate your build process from within your codebase.
- JeremyBanks 6y ago
  Go: we have so few keywords! Simple language! Also Go: because we shoved them all into comments instead! This seems like an extremely weird choice.
  - vram22 6y ago
    Yes, I agree. Also (with the big caveat that I am not even a little bit of a language designer / implementer / lawyer, just a guy interested in these PL topics from early in my career), the use of comments, which are meant to be ignored by the compiler, to make certain actions happen, seems non-orthogonal and not a good choice. Like shoehorning something into something else it was not meant to be or support.
    - isaiahg 6y ago
      As someone who uses the language. I think it's one of its most overlooked features. By convention comments are ignored, but the truth is they're not by the programmer. Comments are extremely important to keep track of what you're doing and reading other people's code. So I think this is a case where the convention doesn't meet the reality. Also using these features within comments makes it so every use of these extra features is documented and shows up in completions, so you the programmer always know what you're doing. I'm a fan haha
irokita94 6y ago
I see that the technology world got in love with GoLang lately. In the Software House I work we get tons of questions, can we build an app in Go (yes, we can). Is this the Google authority that gets people so eager, to use this specific programming language? And I'm talking about entrepreneurs who know ZERO about app development - yet, they insist to develop their app in Go. Even though most of the time, it would be easier for us to do it in Ruby on Rails we agree to do it in GO. Is this the trust matter of why GO has got such a great PR lately? Nevertheless, dear developers: learn it, because from the business side I see its potential may only rising as it did with other backed by huge corporations languages (Flutter, React Native). PS. Interested in GO benefits written from the business perspective? Check them here: https://blog.railwaymen.org/why-use-golang-to-build-your-business-app https://blog.railwaymen.org/why-use-golang-to-build-your-bus...
synergy20 6y ago
Python is also said to be beginner friendly and easy to learn but in fact there are a lot tricks hidden somewhere and if you want to be a professional python programmer, there are lots to learn and they're very deep. Go is indeed great for web-oriented applications, its built-in network stack is really handy, and you don't need run a nginx, another application server, etc, everything can be one single executable, it's like a docker itself.
- diarrhea 6y ago
  Disclaimer: I don't know anything. > Python is also said to be beginner friendly and easy to learn but in fact there are a lot tricks hidden somewhere and if you want to be a professional python programmer, there are lots to learn and they're very deep. Yeah. I'd add that to become proficient, you are also going to have to learn a bit of C and know your way around Python's bytecode. You'll have to learn the language and the interpreter. I've never used a compiled language (shame on me), but I'm not aware of people learning the Go compiler aside from a couple of its options maybe. The static binary thing is amazing, I love it. By now, a large part of my selfhosted stuff is written in Go and all of it is great so far (no causality, "just" correlation).
lawrenceyan 6y ago
Ken Thompson states that, initially, Go was purely an experimental project. Referring to himself along with the other original authors of Go, he states: > When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.
sdevonoes 6y ago
I find Go the "perfect" programming language except for two things: - the one to one mapping between directories and packages. It feels so inflexible compared to what other programming languages have (e.g., namespaces) - that I have to hardcode "github.com" (or another website) in my source files. Sure I can do "find and replace" if needed, but this kind of stuff shouldn't really be within the `.go` source files. Just add a `dependencies.txt` that maps names (used in code) to urls. Easy Having said that, I enjoy writing Go code.
mrmister00 6y ago
Is it me or did Go fail its original mission to replace systems languages (c/c++), but then somehow achieved victory by loads of Python devs embracing it as a far more performant runtime for their code? Whichever way it is, as a lisper I just find the language tedious and ceremonial, and its csp implementation lacking.
- whimsicalism 6y ago
  I feel like Go is more similar to another Java or C# in the role that it fills in enterprises.
toolz 6y ago
I was writing code in go for maybe a week before I noticed "make" was an overloaded function and subsequently noticing go doesn't allow you to overload your own functions. Things as simple as this seem mundane, but it's painfully obvious discrepancies like this that make me avoid go when I can - if I'm going to utilize a new language, I'd prefer it to have interesting and consistent paradigms that lead developers to a similar understanding of how to use the language. Inconsistency in the core language like this doesn't give me a lot of hope for the longevity of go projects remaining easy to reason about.
- DangitBobby 6y ago
  To me, the fact that there are concepts such as generic containers (slices, maps) but that you aren't allowed to design your own is a concession that generics are useful, necessary, and not too complicated for the language. It confuses me that people then defend the decision to exclude other forms of generics. I was very interested in learning and applying the language at one point, but the inability to make very basic abstractions and the horrific proliferation of either manual or generated boilerplate code made me decide to shelve it permanently, or at least until go 2.0 comes out with generics.
CobrastanJorji 6y ago
This is a great article, but it felt needlessly defensive on the "lack of assertions" thing. Admitting that something is missing makes the rest of the article feel more believable. No need to say stuff like "maybe the lack of asserts makes the test code build faster so it's actually a good thing." Just say "unfortunately, no asserts."

204 points by henvic 6y ago

I remember Rob Pike talking about how each language has its own way of doing things and it's bad to keep adding all features to all languages. This only makes them all end up being the same he said. The Go way was code generation. After they included generics, I wonder if the go team has let go of that principle.

shaan7 6y ago
Code generation only solved part of the problem - saving the trouble of having to write repetitive code. It does not solve the maintainability problem because if something needs to change then you need to manually change all the generated code. I have been using Go since last ~6 years and I'm really excited that the only pain point I had with Go will soon go away \o/
- abatilo 6y ago
  Wasn't the ability to add a //go:generate comment enough to make it easy to re-generate anything that you needed?
  - isaiahg 6y ago
    Generation is a rather big solution for sometimes small problems. For many things like utility functions I think generics are much more readable and easier to understand while go generate would be heavy handed.
throwaway189262 6y ago
Yet Go's code generation is clunky even compared with Java's Annotation Processors.
hu3 6y ago
Considering how long and how much discussion it took to implement generics (coming in 1.18 according to FAQ [1]), I'd be inclined to say it supports their principle. I don't think they ever said they wouldn't implement Generics. It was a matter of maturing and consideration of different proposals. [1] https://golang.org/doc/faq#generics https://golang.org/doc/faq#generics
pansa2 6y ago
Here’s a quote from Rob Pike (in 2015) about what Go was trying to avoid: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." https://www.dotconferences.com/2015/11/rob-pike-simplicity-is-complicated https://www.dotconferences.com/2015/11/rob-pike-simplicity-i...
- nerdponx 6y ago
  It's 2021, the convergence still hasn't happened yet. It's never going to happen. I know Rob Pike is probably smarter than me, but this a bad hot take in 2015, and it's outright stinky in 2021.
  - ozkatz 6y ago
    6 years is not a lot of time if you examine the progress of modern programming languages. These languages are more similar to one another than they were 6 years ago. I don't know if it was meant to be taken literally, but I definitely don't think it's "outright stinky" to claim convergence.
  - Thaxll 6y ago
    Well look at patern matching for example, they're all adding that. Isn't that convergence? https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php https://www.python.org/dev/peps/pep-0622/ https://www.python.org/dev/peps/pep-0622/ https://www.infoq.com/articles/java-pattern-matching/ https://www.infoq.com/articles/java-pattern-matching/ https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/may/csharp-8-0-pattern-matching-in-csharp-8-0 https://docs.microsoft.com/en-us/archive/msdn-magazine/2019/... I could go on with various topics, immutability etc ... It's pretty clear that in the past 10 years language evolved more quickly and borrow concepts from other languages.
    - nerdponx 6y ago
      Languages evolving and borrowing good ideas from each other* is not the same thing as hyperbolically sneering at some of the most popular programming languages in the world because they're supposedly all converging into one single language, which they never were doing and never will do. *Note that the new Python pattern matching has a somewhat controversial design, and it probably won't see significant adoption in the wild for several years, if ever.
dkarl 6y ago
You can think of generics as providing support for a simple, common form of code generation in the language itself. That might not be technically precisely correct, but looking at it that way makes it seem like not a radical change at all.
Thaxll 6y ago
10 years later the language is still the same, not much has changed, I can't say the same about Rust, C#, Java, PHP, Python etc ... The only major thing that came in the last couple of years was Go module, and it's more on the tooling side than the language itself.
streblo 6y ago
> it's bad to keep adding all features to all languages I understand the reasoning behind this take - a lot of modern languages have wound up somewhat bloated, with features that are either non-orthogonal to other features and break the 'one way to do it' principle (Scala comes to mind), or with features that seem tacked-on and feel alien to the language (the latest versions of python come to mind). I understand, in theory, why go tries to buck this trend. The problem is that in bucking this trend, go has (at least historically) not evolved enough to fix some of its own core issues. And it does have some big issues - nils, zero values, and non-thread safe primitives come to mind for me. I'm all for being thoughtful about introducing changes and making sure those changes are idiomatic and don't violate the 'ethos of go'. But avoiding making those changes in the name of 'keeping it simple' never made sense to me in cases where programmers are shooting themselves in the feet and already not having a simple time with your language.

petercooper 6y ago

Just as it's not mentioned there, I've been running a Go newsletter for the past six years at https://golangweekly.com/ https://golangweekly.com/ (yes, RSS is available) - the archive can act a sort of week by week "what happened" for anyone looking back to specific points in Go's history over that time.

donut 6y ago
Hey Peter! Thank you for doing this. I'm a regular reader and love what you do.
- petercooper 6y ago
  Thanks, very kind! :)
henvic 6y ago
omg, I can't believe I forgot to add it! Just added :)
- petercooper 6y ago
  Thanks, no problem! Congratulations on the success of your post!
  - grossemerde 6y ago
    Cdjksnbhhfsbdvfsdbhjgeographiedemerdequifaitchierdansleculcommeunchevaldemerde Kek

yulaow 6y ago

Is this updated? I see in the suggested resources to learn Go there is a book created in 2015... The language and related patterns changed so little that that book is still good? Or anyway, do you have any to suggest?

q3k 6y ago
> The language and related pattern changed so little that that book is still good? Pretty much yes, and TGPL/Effective Go are still very good resources to learn the language, if not still the best available. Probably the biggest changes since 2015 were constant stdlib improvements / extensions, and things like the context API becoming standardized across the ecosystem. Oh, and Go modules. Otherwise the language is pretty much unchanged.
- s-video 6y ago
  I hope they write a second edition, and give the cover a red "GO 2" stamp graphic, like they did with ANSI C on the K&R second edition cover.
  - henvic 6y ago
    Maybe '<decade/year> edition' would be better :)
petercooper 6y ago
If you mean The Go Programming Language then yes, it's still a fine book. It doesn't cover new additions like Go modules, of course, but in terms of the core elements of the language, it stands up well. Are you going to probably want more once you've covered the essentials? Yes, but it'll put you in a great position to take on further material.
wbl 6y ago
I still use my K&R which proudly proclaims that it includes the new ANSI C 89.

Ashanmaril 6y ago

I've been using Go for a personal project of mine recently. I had briefly used it at the tail end of my internship while getting my degree, but nothing particularly in-depth, and it was some pretty simple server code that never really challenged me. There's definitely some nice stuff about it, but there's also some stuff that's a bit of a pain. For one thing, being straight up unable to compile a program if there's an unused variable, not even a debug compiler flag or anything to allow it while testing. There's a lot of cases where I just want to move one thing around, or I'm partway through writing a function and just want to see what state something is in at a point, so I want to throw a breakpoint on a line and run the program up to that point. But even though my code is technically all valid, because the variable I want to look at is unused, or I commented out a line that makes something else unused, I now can't compile at all. So there's a lot of times I'll have to throw in a random fmt.Print of a random property of index zero of an array or something, which might crash anyway if it's reached, but at least it'll compile. It maybe doesn't seem like it would be that big of a deal, but when you've got a train of thought going, and you're trying to iterate fast, it can really pull you out of the flow of things. There's also a lot of weird situations where I find it hard to keep things clean. For instance, I like using this shorthand: if err := doThing(bar); err != nil { // handle error } But if you're doing it in a case where your function returns a result and an error, i.e. if foo, err := doThing(bar); err != nil { // handle error } That's indeed valid code, but foo only exists in the scope of that error handling. So you'd have to declare it above with its type var foo FooType if foo, err := doThing(bar); err != nil { // handle error } But you can't actually do this because when using type inference, both return values have to not be declared beforehand. So you have to pull err out into a declared var with a type, and remove the type inference altogether like this var foo FooType var err Error if foo, err = doThing(bar); err != nil { // handle error } And from that point on, if you're using this pattern again anywhere else below in that function and you want to continue using that slick error handling shorthand, there's barely any point because err already exists in your scope, and you'd just be redeclaring it. Perhaps there's some tricks I don't know about, but I tend to run into situations like this a lot, and I spend so much time trying to appease weird edge-cases of the compiler's strict rules that is really throws a wrench in my workflow.

6y ago

jimmyed 6y ago

Does Go have tail recursion? I'm guessing not since Go isn't big on the "optimization" part.

fredrikholm 6y ago
> Go isn't big on the "optimization" part. Care to elaborate?
- jerf 6y ago
  It's true. Go prioritizes compile speed over a ton of optimization. It does fast ones, but it doesn't do the expensive ones. I don't know whether the Go compiler never does tail-call optimization, but I do know it is never something you can count on. (There's two kinds of tail call optimization... there's the one where the compiler may choose to do it as an optimization step, but you can't ever count on it because at any time for any reason it may stop, so you have to assume it didn't happen. Then there's the kind you can absolutely count on, and program tail-call-based algorithms secure in the knowledge that they won't blow out the stack. I'm pretty sure Go doesn't have the latter.)
  - fredrikholm 6y ago
    Thank you for clarifying. Does this apply to procedural code as well? Go not implementing TCO makes sense as the language is _very_ Wirthian.
thomascgalvin 6y ago
Yes: https://blog.usejournal.com/tail-recursion-in-go-fb5cf69a0f26 https://blog.usejournal.com/tail-recursion-in-go-fb5cf69a0f2...
- jerf 6y ago
  FWIW, I read "tail calls" as referring to the optimization that allows you to rely on the tail-recursive calls not generating stack frames, on the grounds that I'm not aware of any language that specifically forbids tail recursion.

kaladin_1 6y ago

Nice article... Over here I've invested a lot in Java, to be used where static typing is necessary, JavaScript (Node.Js), Elixir and PHP on other occasions. But it's beginning to look like Go will displace Java. So, might be high time we learned Go :/

panzerboy 6y ago
Umm ... what exactly makes you say that?
- kaladin_1 6y ago
  Very soon whoishiring will start a thread for April. I bet you are going to see more Go opportunities than Java.
thomascgalvin 6y ago
The only production Go code I ever see is in a kubernetes operator. The backend services I see deployed are probably 75% JVM, 25% Node, and less than 1% something else. Go is popular at Google, but we're kind of past the point where something being popular at Google makes it popular everywhere.
- Philip-J-Fry 6y ago
  Twitch.tv uses mostly Go AFAIK. Where I work we use Go in all our services. There's plenty of uses of Go. You just won't ever hear about them, because why would you? You see Java and Node because that's all you've ever worked with. I see Erlang, .NET and Go, because that's all I've ever worked with.
  - RSHEPP 6y ago
    Work at a large telecom co., who used to be Java only, I only write Go. Hn threads like this is when you realize it's core user base.
- kyrra 6y ago

preommr 6y ago

Go is not a simple language. Please learn from my mistakes, and ignore arbitrary metrics like how go has fewer keywords. The complexity doesn't go away, it's hidden away somewhere. If anybody wants to learn go, ignore everything about how easy it is to learn. Because it's extremely deceptive. Take time to actually read through a lot of the important underlying concepts like how slices work. Ignore comments about how go is simple to write. There's a fair amount of bad go code and people break rules all the time. From official sdks to standard libs. Go can be extremely difficult to both write and read. It's implicit interfaces and judicious abuse of interface{} can make tracing how a library is supposed to work a PITA. Writing go can be difficult because of a lack of some language constructs that leave you unsure how to proceed. If you can, use goland. I use vscode and it's... not pretty. Almost every single thread I've seen on reddit recommends goland. My experience with vscode has been very unpleasant, particularly with go plus. OTOH, things like criticisms about it's error handling are overblown. At best it's a mild nuisance, and more often than not, a good thing that makes error handling explicit and clear. There are many things about go that have made me appreciate it's existence. There are also many things that have left me absolutely baffled at how bad it is.

randomdata 6y ago
> Ignore comments about how go is simple to write. Do people say that? I've never heard anyone claim that Go is simple to write. Pike, I believe (may have been someone else), claimed something to the effect that new grads with limited exposure to real-world codebases were able to understand existing projects written in Go more quickly than in other languages at Google. I have seen that message distilled down into "Go is simple to read." Go was built on the premise that people spend more time reading code than writing code and Go attempts to make tradeoffs towards reading optimization rather than writing optimization. Whether or not it is successful in that is another topic for another day.
- Thaxll 6y ago
  Go is very simple to read and to write, I'm not sure how one can argue against that. Without prior knowledge you can jump into any code base and won't be suprised by something you never seen before or does not understand what it does. The language is simple to grasp because it has just a few concepts and keywords.

jonathanstrange 6y ago

I like Go and have no major complaints about it. I especially like the highly performant garbage collector and the fact that there are a lot of libraries for it. With the libraries you have to be careful, though, quality of 3rd-party libraries differs a lot on Github. There is also one point of critique, I believe that Go got its concurrency primitives wrong. I fear people will hate me for saying this, but I say it because almost every library I've tested that uses lots of goroutines fails or produces some serious concurrency errors at one point or another. Not only are there many race conditions in Go code, there are also many libraries that silently fail. For example, scan Github for parallel directory walkers or check out uses of sync.atomic. I personally believe that both transactional memory and the actor model are easier to use although it might be harder to implement and make them efficient. I also think that thread local storage and Goroutine identities would have been useful, despite what the language purists say. Generally speaking, I think Go's choices of concurrency primitives are too low level. (I'm not saying there is anything wrong with them per se, just too low-level for most of Go's users, and I'm not excluding myself in this assessment.)

dilap 6y ago
Yeah, bounded channels ended up being more effective as a hype mechanism than a great concurrency primitive, I would say. Coming from Go and kicking the tires a bit on Rust, I was impressed w/ how much nicer it was to write parallel code using Rust + the crossbeam library than Go. At the end of the day Go's concurrency story is just traditional threads and mutexes, with custom syntax for one particular datastructure. But, you do get a great runtime race detector & the M:N scheduler, so you can use lots of goroutines w/o blowing out memory, avoiding async hassles.
coder543 6y ago
I agree with a lot of this. I'm especially looking forward how generics should make it easier to build a library of high level concurrency patterns that people can use in Go, instead of everyone trying to build their own. Promises (which would allow you to start a number of parallel tasks, then wait on the results), "parallel for" with controlled amounts of concurrency, etc. The M:N scheduler is great, and the ability to easily spin off Goroutines is really nice, but I think most people shouldn't need to manually launch goroutines most of the time. Goroutines should just be an implementation detail.

isaiahg 6y ago

I really like go. Its simple in that you can learn the language pretty quick. I might get burned in another comment below but it's the language that feels the closest to C to me. Both are really simple languages that can get relatively complicated pretty fast. Inheritance through embedding for one feels a lot like using -fms-extensions in C. However I think the coolest part of the language is the part no one talks about. The inclusion of comments as a major part of a program. // +linux for managing files for specific platforms is just wonderful. //go:embed for embedding files and directories into your program // #include <stdlib.h> import "C" is probably the coolest and easiest ways to use C libraries I've seen. You can write C code directly into your go files and even set complier and linker flags. //go:generate can allow you to automate your build process from within your codebase.

JeremyBanks 6y ago
Go: we have so few keywords! Simple language! Also Go: because we shoved them all into comments instead! This seems like an extremely weird choice.
- vram22 6y ago
  Yes, I agree. Also (with the big caveat that I am not even a little bit of a language designer / implementer / lawyer, just a guy interested in these PL topics from early in my career), the use of comments, which are meant to be ignored by the compiler, to make certain actions happen, seems non-orthogonal and not a good choice. Like shoehorning something into something else it was not meant to be or support.
  - isaiahg 6y ago
    As someone who uses the language. I think it's one of its most overlooked features. By convention comments are ignored, but the truth is they're not by the programmer. Comments are extremely important to keep track of what you're doing and reading other people's code. So I think this is a case where the convention doesn't meet the reality. Also using these features within comments makes it so every use of these extra features is documented and shows up in completions, so you the programmer always know what you're doing. I'm a fan haha

irokita94 6y ago

I see that the technology world got in love with GoLang lately. In the Software House I work we get tons of questions, can we build an app in Go (yes, we can). Is this the Google authority that gets people so eager, to use this specific programming language? And I'm talking about entrepreneurs who know ZERO about app development - yet, they insist to develop their app in Go. Even though most of the time, it would be easier for us to do it in Ruby on Rails we agree to do it in GO. Is this the trust matter of why GO has got such a great PR lately? Nevertheless, dear developers: learn it, because from the business side I see its potential may only rising as it did with other backed by huge corporations languages (Flutter, React Native). PS. Interested in GO benefits written from the business perspective? Check them here: https://blog.railwaymen.org/why-use-golang-to-build-your-business-app https://blog.railwaymen.org/why-use-golang-to-build-your-bus...

synergy20 6y ago

Python is also said to be beginner friendly and easy to learn but in fact there are a lot tricks hidden somewhere and if you want to be a professional python programmer, there are lots to learn and they're very deep. Go is indeed great for web-oriented applications, its built-in network stack is really handy, and you don't need run a nginx, another application server, etc, everything can be one single executable, it's like a docker itself.

diarrhea 6y ago
Disclaimer: I don't know anything. > Python is also said to be beginner friendly and easy to learn but in fact there are a lot tricks hidden somewhere and if you want to be a professional python programmer, there are lots to learn and they're very deep. Yeah. I'd add that to become proficient, you are also going to have to learn a bit of C and know your way around Python's bytecode. You'll have to learn the language and the interpreter. I've never used a compiled language (shame on me), but I'm not aware of people learning the Go compiler aside from a couple of its options maybe. The static binary thing is amazing, I love it. By now, a large part of my selfhosted stuff is written in Go and all of it is great so far (no causality, "just" correlation).

lawrenceyan 6y ago

Ken Thompson states that, initially, Go was purely an experimental project. Referring to himself along with the other original authors of Go, he states: > When the three of us [Thompson, Rob Pike, and Robert Griesemer] got started, it was pure research. The three of us got together and decided that we hated C++. [laughter] ... [Returning to Go,] we started off with the idea that all three of us had to be talked into every feature in the language, so there was no extraneous garbage put into the language for any reason.

sdevonoes 6y ago

I find Go the "perfect" programming language except for two things: - the one to one mapping between directories and packages. It feels so inflexible compared to what other programming languages have (e.g., namespaces) - that I have to hardcode "github.com" (or another website) in my source files. Sure I can do "find and replace" if needed, but this kind of stuff shouldn't really be within the `.go` source files. Just add a `dependencies.txt` that maps names (used in code) to urls. Easy Having said that, I enjoy writing Go code.

mrmister00 6y ago

Is it me or did Go fail its original mission to replace systems languages (c/c++), but then somehow achieved victory by loads of Python devs embracing it as a far more performant runtime for their code? Whichever way it is, as a lisper I just find the language tedious and ceremonial, and its csp implementation lacking.

whimsicalism 6y ago
I feel like Go is more similar to another Java or C# in the role that it fills in enterprises.

toolz 6y ago

I was writing code in go for maybe a week before I noticed "make" was an overloaded function and subsequently noticing go doesn't allow you to overload your own functions. Things as simple as this seem mundane, but it's painfully obvious discrepancies like this that make me avoid go when I can - if I'm going to utilize a new language, I'd prefer it to have interesting and consistent paradigms that lead developers to a similar understanding of how to use the language. Inconsistency in the core language like this doesn't give me a lot of hope for the longevity of go projects remaining easy to reason about.

DangitBobby 6y ago
To me, the fact that there are concepts such as generic containers (slices, maps) but that you aren't allowed to design your own is a concession that generics are useful, necessary, and not too complicated for the language. It confuses me that people then defend the decision to exclude other forms of generics. I was very interested in learning and applying the language at one point, but the inability to make very basic abstractions and the horrific proliferation of either manual or generated boilerplate code made me decide to shelve it permanently, or at least until go 2.0 comes out with generics.

CobrastanJorji 6y ago

This is a great article, but it felt needlessly defensive on the "lack of assertions" thing. Admitting that something is missing makes the rest of the article feel more believable. No need to say stuff like "maybe the lack of asserts makes the test code build faster so it's actually a good thing." Just say "unfortunately, no asserts."