I am super happy that I invested in Go. I ended up working on TURN, WebRTC and DTLS and feel I made the right choice. The impact vs time spent was worth it. I don't think there is any other language I would have had a better experience. Either it is too niche, or it is so popular that the community is anemic.
Go is really great as a 'teaching language'. I have seen lots of software pop up that was inspired by reading the Pion code. I think that is great, it is much harder to read and learn from other languages. Also really great for contributions. I get so many people making their first Open Source commit. The languages simplicitly really makes it easy.
The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side?
> The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side?
As someone who's been writing Go full-time for over eight years, and has also done some Rust as well, I'll say that the business/corporate focus that you're noticing is a fairly recent development. My impression is that it's mostly a function of the size and the market demand for the language - ie, as the language has grown and is being used for more mission-critical stuff, a wider range of businesses have a vested interest in it.
Rust is a bit younger than Go. If we're judging by the first stable release, it's about half the age (5 years vs. 8). It's not as far along the adoption curve in many ways yet, although it's growing fast. Rust is being used for more things today than it was, say, three years ago, but it's still a narrower range (and number) of companies that are interested in Rust. Given Rust's trajectory, I think that's just a matter of time, so what you see today in Go will probably be more visible in Rust in a year or two. It's already drawing a wider range of corporate interest than it was even one year ago, and if it continues to be successful, that's inevitable.
I don't think that's a bad thing, though. The communities get wider, but that doesn't mean that the stuff you're looking for isn't there; you just have to look a little harder for it. That's definitely true for Go, and I would bet it will be true for Rust as well.
I also think that Rust and Go are not really comparable, and it's a shame that they often come up together so often in discussions, because they're compared more often than is really warranted IMO. But that's a separate matter.
At the risk of being controversial, my guess is that this is because Go makes it very difficult to build abstractions at a level that are appealing or satisfying to most developers. This is the main reason I choose Rust or Python or literally anything else over Go for personal projects. Because I may or may not be more productive in Go if I keep working at it, and go has so many benefits over many other choices, but I mainly write software because I enjoy it. I typically do not enjoy writing Go (and I have seen this sentiment echoed widely). And I think that because enjoyment is much less important in a corporate environment, corporate representatives make up the lion's share of the enthusiasm.
I think you hit on something that so many miss and it's the tooling for the job, as it were. Go and Rust are fundamentally different tools designed for fundamentally different tasks. While it's possible to use them for the same tasks, it's much more difficult. I would HATE writing a full and secure operating system in Go, while writing back end systems in Rust is doable, but at an unnecessarily slower pace than Go.
I very much agree with this. Rust is to C++ what Go is to Java. I think the fact that Go compiles to native binaries and can be linked statically are the primary reasons it is often compared to system languages like Rust or C++. But really, it's not the same type of language.
WASM is their weaker part. On the flip-side the WASM takeup is also rather modest so the net loss is not that big.
Eventually they might come up with a solution to get their huge WASM files down to bearable size. Sure its because they have to ship the bigger part of their VM with it.
I'm developing an entire desktop app in WASM(with electron). Once you build the right abstraction it's just Go...simple and fun! To me the main issue I have with Go is the incomplete reflect package(i.e StructOf )
I ran into Pion when looking for a good example implemention of a TURN server. Your code is a great read, especially for something with so little documentation relative to its use.
Happy birthday Go! I'm currently working on a little side-project and I wanted to write (part of) it in Go. As a side-note, the last time I wrote Go was all the way back when I made a few small contributions to the http standard library, circa 2009. As soon as I set up my environment, my gears were already turning (coming from Python, TypeScript, Java, etc.): how should I structure things? Where should this live? What should be calling what, and where should things be passed from and into?
And, like a breath of fresh air, I started remembering how Go works: it's a very simple, stupid language -- in the best possible way -- and it just works. You start writing code, and then you write more code. You write a function. And then you write another one. Slowly, your program gets bigger. Sometimes you need to split up functions.
And that's it. No fiddling with project structure, with taxonomies, and with hierarchies. I forgot what it felt like to just sit down and write some code. I've gotten used to battling tooling, fighting with opinionated frameworks, and having a zillion ways of doing something -- stuck in an eternal analysis paralysis.
To add to the list of things other languages make you think about: setting up a CI job for building your code packages and uploading them to the appropriate repository, setting up a CI job for building your documentation packages and a website to host them, deciding on a test framework, drafting a style document (and policing contributions accordingly), configuring a web server (e.g., tomcat, uwsgi, etc) if your project is a service, figuring out how to distribute your code to your target platform (while making sure all of the right runtime dependencies are installed), etc. This is all stuff you don't really have to learn or think about with Go because it's all solved for you out of the box.
I use Go quite a bit, and I have the exact opposite experience from a lot of these testimonials.
Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I resolved it, but I still had to fight with the tooling. Then there was the whole go mod situation.
Go code is a language that has succeeded in a niche market (It's magical to just spin up a web server that works out of the box with great performance. ) while also handicapping itself so that complex code is too difficult to write. So it doesn't get associated with the problems some other languages have. Java is a good language that people ruined with horrible enterprise culture.
I don't even really think that go is that painless to learn. The small size of average projects has led to some dire fault lines. The biggest one for me is that it's structural typing for interfaces isn't explicit. Often times I'll read some code that uses an interface, and I'll have a real hard time mentally mapping what uses that interface and how to write code. 90% of the time this isn't an issue because the projects are small enough that I can just keep the whole thing in my head, and I can make educated guesses, or I only need to remember a handful of common cases. This doesn't scale well. Yea, I know there's plugins for these things - and I use them, but I am not a fan of tying development to non-standalone tools.
Anyways, rant aside, looking forward to another 11 years of go.
The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand.
Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms and data structures, not the language you are using.
I suggest you try and implement some complex but well-defined algorithm, e.g. sha256, in some very, very simple language, say, brainfuck (which is very close to the original Turing machine language). Or, more realistically, in PDP11 assembly, which is beautifully transparent and uniform.
You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.
Rich Hickey[] has a nice talk "Simple made easy", where he differentiates between exes, the simple-complex axis and the easy-hard axis. By his definitions, you can kind of strive for easiness but get complexity, and if you aim for simplicity it may be hard. His point is, that you'd much prefer simple-hard over something 'easy' that leads to incidental complexity.
I feel like Go isn't so much aiming for simlicity but actually for easiness in that line of thought, and thus its only a matter of time until complexity is encoded within the Go code.
Now, aiming for simplicity is not easy, at times definitely hard but it can lead to actual simplicity.
[
] obligatory note that while I like this talk I don't agree with all of his utterances.
Code that requires codegen or some verbose structure to express some constraint or idea that could be expressed in a sentence or two or a simple oneliner with the right abstraction can actually be harder to read because of the miles of boilerplate you have dive through.
Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.
I have really been enjoying Go, except for the built-in templating library. It's a wart on the standard library IMO.
The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc.
It has very very poor documentation. Some docstrings are not a replacement for actual documentation when your approach is that unorthodox.
And it doesn't produce any error messages or warnings when you do something wrong - just renders a completely blank template.
EDIT: to be clear, my beef is with the template hierarchy, poor docs, and lack of errors/warnings, not with the general capabilities of the library, which are quite complete.
Interesting! I would say that the template library is one of the main reasons I reach for Go. If you want to have a microservice with a useful human-readable status page that tells the operator all about the application's internals, it is a snap in Go, while in C++ you'll be pulling your hair out.
True, and it is nice to have the capabilities in the stdlib. I just don't like the hierarchy setup, poor docs, and lack of errors/warnings when you get it wrong.
I guess I am just used to Python where there are 1-2 all-star 3rd party packages for each use case that the community tends to coalesce around. Rust appears to be heading in a similar direction.
Since Go has so much web/http stuff baked in, it is more likely that must people just stick with the stdlib approach, even if it's a bit of a PITA.
I also had hard times with built-in templating library for Go. That's why I created quicktemplate [1]. Usually it is much easier and natural to write templates in quicktemplate comparing to built-in templating library. As an additional benefit, quicktemplate templates work much faster (10x and more) than standard Go templates. The only downside that quicktemplate templates must be pre-compiled to Go code before building the app.
Not specifically Go related, but I am consistently annoyed that Helm's templating is a _very_ thin abstraction over Go's templating which has many drawbacks in that context.
Micro was on the frontpage earlier today (https://news.ycombinator.com/item?id=25044604). It's written entirely in Go, and so was its predecessor and everything I've done since 2012. Go is a phenomenal language and I'm not really sure where I'd be without it, my company basically wouldn't exist, I wouldn't be solving the problems I am. Its a phenomenal language and I owe a great deal of gratitude to the Go team for that.
The future is bright for Go, it is for sure the language that defines Cloud development for backend services and APIs. It has spawned an ecosystem of docker, kubernetes and beyond and countless companies have come to rely on it for their software. It is amazing achievement to see something go from nothing to this. It is unclear whether it would have had the same success had it not been for being within Google, but that's just part of it.
>Go is a phenomenal language and I'm not really sure where I'd be without it, my company basically wouldn't exist, I wouldn't be solving the problems I am.
I don't want this to come across as negative but I really don't get this. Can you expand upon this if you don't mind?
What is it about Go specifically that you make claims like that? Realistically couldn't you have done everything you did in Go, in say Java or something else? (I make this as a general comment, I am not aware of the things you have actually written in Go :) )
No. Without the existence of Go, I would not have gotten my last job, we would not have built the platform we did, I would not have seen the opportunity and ability to build such a business. It's all a chain of events that occur because a technology exists that enables it. If Go didn't exist my path would be very different.
I implemented a few services in Go like 5 years ago and they still work. I think some have uptime of 2 years or more. I love that once you get good test coverage, Go programs are extremely stable. I still prefer to do things in Python, but if I need extra stability I go with Go.
I wrote some toy interactive services for my personal website 4 years ago. Put them all on a GCP vm behind screen, and they're still running today. I haven't touched them once. I haven't even logged into GCP in 2+ years.
Just for fun, I went back to the very first thing I implemented in Go, about 8 years ago†. Compiled and ran flawlessly.
It is SO nice to not have stuff just break out from underneath you.
(Modules wrecked this a little bit; I think it was a mistake to go 1.0 before they worked out a packaging/distribution solution. But what they finally came up w/ looks really nice.)
For all these years, I fail to understand the appeal of Go. I think I have grown to be quite understanding to why one would favour one or the other programming language over time, can see why some favour Haskell, some Java, some C, some TCL, some Python.
For Go I guess I can comprehend the statements of praise by Go-users, but I have a hard time with really understanding it. I fail to see the appeal.
This comment is not meant as an offense to Go-lovers out there, to the contrary, pick the languages and stacks you like. Its more about myself; me wondering at my own lack of understanding.
I think it is easier to understand from a relative perspective. If you come from Haskell, you will probably not like Go at all.
But if you come from doing shell scripting or C, then Go will be much nicer.
And then it also has some actual nice things and removes some obstacles that exist in other languages.
I think with more experience, people will start dislike Go more and more and switch to other languages. But for beginners it is easier to learn and you are less distracted by nuances like formatting or a difficult typesystem.
A bit of an update to my point above, it does feel a bit like Pascal to me, but kind of missing some of Pascal's nice stuff...
My pet theory to the popularity is that it feels satisfying to just churn out many lines of code and in Go it seems you do that instead of using abstractions or "magic" as in many other languages. So Yeah, I expect popularity to drop as more "legacy" code bases need to be picked up by devs ...
The appeal to me, when Go first appeared, it seemed that it would be what .NET 1.0 or Java 1.0 should have been all along, regarding AOT compilation support (.NET had it via NGEN but MS was never serious about evolving it), while at the same time having a modern language.
Sadly I was proven wrong about the second part, and it has followed the path of doubling down on Java 1.0, including the grow warts that Java has gotten in 25 years. Here Go has learned nothing from its predecessors.
With the success of the container ecosystem based on Go written tooling, means that at some point using it in some fashion becomes unavoidable, even if your main tools happen to be something else.
Generics Update:
"We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas."
Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :)
My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I prefer it to the try/catch paradigm where the error is maybe handled somewhere up the call stack
No, error handling is not the best. The lake of generics seems to get addressed with lots of pondering which is a good thing.
But error handling is just awkward. I do not mean the retval, err := funccall(a,b) syntax but rather the absence of a standardized way to get stack traces.
This carefulness and emphasis on stability and simplicity is one of the reasons I'm attracted to the language. Currently I personally don't really see a use-case that isn't covered by my tool-belt otherwise but every time I peek into a Go repository or read about Go I get a bit jealous.
I don't think Go does anything other languages cant do, it just does things better. It makes things simple. In some ways its like the Mac OS of programming languages. In certain ways its restricting, but 99% of the time its going to make your life much easier.
This is what I want to see: taking time to make large engineering decisions conservatively. A lot of vendors, the first thing you hear is it being dumped on you instantly followed by the realisation that it was designed by a closed team in isolation with no user feedback involved and subsequently it turned out to be crap or a complete impedance mismatch for the real world.
I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers.
I wrote a ton of various code in Go [1] over the last 10 years and had never experienced the need in generics. The last my project in Go is VictoriaMetrics [2] - fast and cost-effective open source time series database and monitoring solution.
Before Go I was writing some code in C++ and was constantly struggling with C++ templates in stl and boost libraries. This was absolute nightmare from debugging PoV.
> I'll be happy if generics will be never included in Go. They will definitely reduce code readability, will increase binary sizes and will increase compile times because of generics' abusers.
Well you don't have to use them and you won't have to use any of the libraries that use them. Just like C++ templates, some C++ shops forbid their use. But that's your problem, don't make everybody else suffer from what is considered a burden and a flaw in that language.
People want compile time type safety, not having to resort to runtime reflection, which Go std lib itself does . There is nothing unfathomable about that thought process. Go has a poor type system at compile time while being way too permissive at runtime.
Readit News
* https://github.com/pion/dtls
* https://github.com/pion/webrtc
* https://github.com/pion/turn
Go is really great as a 'teaching language'. I have seen lots of software pop up that was inspired by reading the Pion code. I think that is great, it is much harder to read and learn from other languages. Also really great for contributions. I get so many people making their first Open Source commit. The languages simplicitly really makes it easy.
The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side?
As someone who's been writing Go full-time for over eight years, and has also done some Rust as well, I'll say that the business/corporate focus that you're noticing is a fairly recent development. My impression is that it's mostly a function of the size and the market demand for the language - ie, as the language has grown and is being used for more mission-critical stuff, a wider range of businesses have a vested interest in it.
Rust is a bit younger than Go. If we're judging by the first stable release, it's about half the age (5 years vs. 8). It's not as far along the adoption curve in many ways yet, although it's growing fast. Rust is being used for more things today than it was, say, three years ago, but it's still a narrower range (and number) of companies that are interested in Rust. Given Rust's trajectory, I think that's just a matter of time, so what you see today in Go will probably be more visible in Rust in a year or two. It's already drawing a wider range of corporate interest than it was even one year ago, and if it continues to be successful, that's inevitable.
I don't think that's a bad thing, though. The communities get wider, but that doesn't mean that the stuff you're looking for isn't there; you just have to look a little harder for it. That's definitely true for Go, and I would bet it will be true for Rust as well.
I also think that Rust and Go are not really comparable, and it's a shame that they often come up together so often in discussions, because they're compared more often than is really warranted IMO. But that's a separate matter.
Eventually they might come up with a solution to get their huge WASM files down to bearable size. Sure its because they have to ship the bigger part of their VM with it.
A "Hello World!" using 1.15.4 on linux/amd64 takes up 1.2MiB of space (731KiB after UPX).
Using https://github.com/tinygo-org/tinygo, it drops to 21KiB (unable to be compressed further using UPX), making WASM size a non-issue.
And, like a breath of fresh air, I started remembering how Go works: it's a very simple, stupid language -- in the best possible way -- and it just works. You start writing code, and then you write more code. You write a function. And then you write another one. Slowly, your program gets bigger. Sometimes you need to split up functions.
And that's it. No fiddling with project structure, with taxonomies, and with hierarchies. I forgot what it felt like to just sit down and write some code. I've gotten used to battling tooling, fighting with opinionated frameworks, and having a zillion ways of doing something -- stuck in an eternal analysis paralysis.
I missed Go.
Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I resolved it, but I still had to fight with the tooling. Then there was the whole go mod situation.
Go code is a language that has succeeded in a niche market (It's magical to just spin up a web server that works out of the box with great performance. ) while also handicapping itself so that complex code is too difficult to write. So it doesn't get associated with the problems some other languages have. Java is a good language that people ruined with horrible enterprise culture.
I don't even really think that go is that painless to learn. The small size of average projects has led to some dire fault lines. The biggest one for me is that it's structural typing for interfaces isn't explicit. Often times I'll read some code that uses an interface, and I'll have a real hard time mentally mapping what uses that interface and how to write code. 90% of the time this isn't an issue because the projects are small enough that I can just keep the whole thing in my head, and I can make educated guesses, or I only need to remember a handful of common cases. This doesn't scale well. Yea, I know there's plugins for these things - and I use them, but I am not a fan of tying development to non-standalone tools.
Anyways, rant aside, looking forward to another 11 years of go.
This is not the language or tooling's fault, but likely your IDE's doing. You can set it up not to run gofmt/goimports on save.
Doesn’t apply to most that I’ve used. Java, JavaScript, Ruby, python, PHP.
Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms and data structures, not the language you are using.
You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.
I feel like Go isn't so much aiming for simlicity but actually for easiness in that line of thought, and thus its only a matter of time until complexity is encoded within the Go code.
Now, aiming for simplicity is not easy, at times definitely hard but it can lead to actual simplicity.
[
] obligatory note that while I like this talk I don't agree with all of his utterances.Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.
The template declaration and invocation hierarchy seems unnecessarily complex and is almost 100% undocumented. It just hurts my brain and doesn't make any sense to me in comparison to jinja, whatever jekyll uses, etc.
It has very very poor documentation. Some docstrings are not a replacement for actual documentation when your approach is that unorthodox.
And it doesn't produce any error messages or warnings when you do something wrong - just renders a completely blank template.
EDIT: to be clear, my beef is with the template hierarchy, poor docs, and lack of errors/warnings, not with the general capabilities of the library, which are quite complete.
I guess I am just used to Python where there are 1-2 all-star 3rd party packages for each use case that the community tends to coalesce around. Rust appears to be heading in a similar direction.
Since Go has so much web/http stuff baked in, it is more likely that must people just stick with the stdlib approach, even if it's a bit of a PITA.
[1] https://github.com/valyala/quicktemplate
Deleted Comment
The future is bright for Go, it is for sure the language that defines Cloud development for backend services and APIs. It has spawned an ecosystem of docker, kubernetes and beyond and countless companies have come to rely on it for their software. It is amazing achievement to see something go from nothing to this. It is unclear whether it would have had the same success had it not been for being within Google, but that's just part of it.
I don't want this to come across as negative but I really don't get this. Can you expand upon this if you don't mind?
What is it about Go specifically that you make claims like that? Realistically couldn't you have done everything you did in Go, in say Java or something else? (I make this as a general comment, I am not aware of the things you have actually written in Go :) )
It is SO nice to not have stuff just break out from underneath you.
(Modules wrecked this a little bit; I think it was a mistake to go 1.0 before they worked out a packaging/distribution solution. But what they finally came up w/ looks really nice.)
(†my std "kick the tires problem" -- boggle solver + high-score board finder)
For Go I guess I can comprehend the statements of praise by Go-users, but I have a hard time with really understanding it. I fail to see the appeal.
This comment is not meant as an offense to Go-lovers out there, to the contrary, pick the languages and stacks you like. Its more about myself; me wondering at my own lack of understanding.
But if you come from doing shell scripting or C, then Go will be much nicer. And then it also has some actual nice things and removes some obstacles that exist in other languages.
I think with more experience, people will start dislike Go more and more and switch to other languages. But for beginners it is easier to learn and you are less distracted by nuances like formatting or a difficult typesystem.
My pet theory to the popularity is that it feels satisfying to just churn out many lines of code and in Go it seems you do that instead of using abstractions or "magic" as in many other languages. So Yeah, I expect popularity to drop as more "legacy" code bases need to be picked up by devs ...
> But if you come from doing shell scripting in C
Sure I'd switch to Go in no time!
Sadly I was proven wrong about the second part, and it has followed the path of doubling down on Java 1.0, including the grow warts that Java has gotten in 25 years. Here Go has learned nothing from its predecessors.
With the success of the container ecosystem based on Go written tooling, means that at some point using it in some fashion becomes unavoidable, even if your main tools happen to be something else.
https://github.com/golang/go/issues/32437
https://github.com/golang/go/issues/32437#issuecomment-51203...
https://github.com/golang/go/labels/error-handling
But error handling is just awkward. I do not mean the retval, err := funccall(a,b) syntax but rather the absence of a standardized way to get stack traces.
I wrote a ton of various code in Go [1] over the last 10 years and had never experienced the need in generics. The last my project in Go is VictoriaMetrics [2] - fast and cost-effective open source time series database and monitoring solution.
Before Go I was writing some code in C++ and was constantly struggling with C++ templates in stl and boost libraries. This was absolute nightmare from debugging PoV.
[1] https://github.com/valyala/
[2] https://github.com/VictoriaMetrics/VictoriaMetrics/
Well you don't have to use them and you won't have to use any of the libraries that use them. Just like C++ templates, some C++ shops forbid their use. But that's your problem, don't make everybody else suffer from what is considered a burden and a flaw in that language.
People want compile time type safety, not having to resort to runtime reflection, which Go std lib itself does . There is nothing unfathomable about that thought process. Go has a poor type system at compile time while being way too permissive at runtime.