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.

* 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?

> 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.

To each his own. There is an equally wide group of developers who choose Go for personal projects as it’s in line with their taste. The joy of programming is in the eye of the beholder.

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 would HATE writing a full and secure operating system in Go

For the record, it _can_ be done.[0]

[0] https://dspace.mit.edu/handle/1721.1/122734

Agreed. Comparing them does a disservice to both languages—they're tools with separate niches. It's fair to compare their package management strategies or communities, but the languages themselves are too different.

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.

Rust fundamentally improves C++ with memory safety and allegedly provably correct concurrency. It is a vastly different set of assumptions, design, and opinions than C++.

What does Go do to fundamentally deviate from Java? IMO it is basically the same space with a few different opinions. It has GC, is C-style, a more modern stdlib than C/C++.

Go improves on Java in several ways, perhaps most importantly, it is much nicer to deploy - no JVM. It's also a lot less verbose, compiles way faster and uses composition instead of inheritance. Having said that, I really hate Java, and only mildly dislike Go.

Java has had support for AOT compilation to native code since 2000, just not as free beer.

Single threaded concurrency: goroutines. It's better for writing servers

F-Secure thinks otherwise, https://labs.f-secure.com/blog/tamago/

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.

There's no VM in Go—you're probably thinking of the runtime.

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.

Forgot to mention I was using TinyGo v0.15.0.

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 )

Soemthing to show the world, github / -lab repo, the like?

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.

I missed Go.

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.

> 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.

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.

I have also found tooling, especially surrounding modules, to be a gigantic hassle. Using Goland has helped.

“that they worked on a go program that works five years later (which language does this not apply to). ??? ”

Doesn’t apply to most that I’ve used. Java, JavaScript, Ruby, python, PHP.

It’s still possible to run Java programs that were compiled for 1.2 on modern day JVMs without change.

Yeah, Java is better than most languages at this too. It’s still too early to say for sure, but Go feels better at this point. it has more to do with the libraries, dependencies, and ecosystem relative to Java.

I don’t even remember what I was using for Java 1.2. Maybe ant and struts? I doubt there’s a good path to update such things without a giant rewrite or refactor.

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.

SHA256 is a fixed circuit. It's a particularly weird thing to implement. Other than it being a bit long, it's not complex to implement, even on a calculator.

If you want an example of something moderately complex but well defined, go implement a min-heap or some other basic algorithm.

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.

Cool - let's write everthing in Assembly or Brainfuck! It is great for "complex code", right?

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.

Have you tried langauges other than C++ and Go? Almost anything makes you pull your hair out in C++!

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.

Agreed about the template hierarchy being a bit weird, but the HTML template escaping is amazing. Much smarter and more secure than Jinja, etc.

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.

[1] https://github.com/valyala/quicktemplate

Love using the template library for writing codegen utils for Go and Java

Looked for codegen utils on Github a while back -- but found nothing useful. Any public utils you'd recommend?

I love using text/template directly for codegen. Its really easy in my experience to create sophisticated tools using it + some go functionality. The trick is learning what gen problems are best solved in text templates and whats best solved in go functions. A big advantage of using text/template for codegen is you can just write the code you want to generate and it looks like real go code. Really easy to maintain compared to AST-style codegen.

Sounds similar to my use case. Two snags to work around when generating Go source:

1. The {{}} pairs confuse editor syntax coloring (in emacs, anyway).

2. Expansions that introduce or drop line breaks will cause the runtime/dlv to report line numbers that disagree with the pre-gen source you need to correct.

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.

Ah ok, I misunderstood your comment. Glad to hear Go has had such a big impact for you.

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.)

(†my std "kick the tires problem" -- boggle solver + high-score board finder)

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 ...

That's what I expect, too. In the end, the biggest problem is always to understand and change complex foreign code.

misread as

> But if you come from doing shell scripting in C

Sure I'd switch to Go in no time!

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 :)

https://github.com/golang/go/issues/32437

https://github.com/golang/go/issues/32437#issuecomment-51203...

https://github.com/golang/go/labels/error-handling

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

Well, the point is not that "handle errors immediately" is bad. It's that "tuples are a poor way to do it". A Result type makes you handle errors immediately, but also precisely models what you need (i.e. you don't even get the choice to use an invalid returned value).

Granted, explicit error handling is a good idea. At some level, it depends on the personal style. Perhaps I'm missing something, but I like to write a ton of assertions to validate code invariants. On assertion failure, which obviously never happens as I write perfect code that never violates invariants, all I want to happen is 'write the error in the logs and return 50x'. I suppose panic/recover is the way to go, but I have the impression they are shunned by the community and not recommended by Golang official docs.

https://golang.org/doc/faq#assertions

> Why does Go not have assertions?

> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.

> We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.

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.

It's really a joke :)

Fundamentally, the Go team made the correct choice between explicit and implicit error handling. Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch.

For a good overview of the issue: https://go.googlesource.com/proposal/+/master/design/go2draf....

> Yet one would hope for a bit terser syntax and language supported stack traces, 11 years after launch.

The Go team tried, but the community shot it down.

Your link was the first proposal, and this was the second proposal: https://github.com/golang/proposal/blob/master/design/32437-...

As one who didn't like either proposal: I'm thrilled that they were shot down. Both worked fine (great, even) in simple cases, but fell apart when needing to add context / wrapping to multiple possible errors.

Simple cases are already simple. It's the harder spots that need help.

Can you please share some examples of the harder spots?

Both have at least one shared issue which makes 2+ error wrapping noisy or nasty:

    func whatev() (err error) {
        defer helper(&err, "mightFail context to help debugging", some, vars)
        try(mightFail())
    
        defer helper(&err, "alsoMightFail context to help debugging", some, vars)
        try(alsoMightFail())
    }

if the second call fails, your error has now been wrapped twice.

There are of course ways to deal with this. You can add a "already wrapped" sentinel of some kind (say, a * bool that they check and modify), or use a `helper := once(helperfn)` to do that same kind of thing internally... but that's more verbose. And can't be done generically without reflection (though `func(*error, string, ...interface{})` would be quite common, which might be good enough). Inline handlers shown in many examples are even worse since they can't be composed as easily, so you'd probably end up maintaining a bool var between all handlers. By hand.

They both also require naming your `error` return value, which requires naming all returned values, which has been a depressingly large source of shadowing and not-initialized-value mistakes in my experience. Improperly-initialized values especially, as those tend to cause problems a fair distance from the cause, and sometimes go unnoticed for quite a while.

tl;dr it adds more easily-forgotten boilerplate to non-trivial error handling, and makes it and related code more mistake-prone. I'd rather have `return fmt.Errorf(err, ...)`, it fairly naturally resists growing more complex as your func grows more complex.

Thanks, appreciated. Your example rhymes with u/jhoechtl remark that there is no standardized way to manage stack traces, aka stacked error contexts. Perhaps the Golang elves will come up with an elegant solution. By 2025 :)

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.

By the end of the year 2021!

Yes... Updated my comment. It was misleading :(

> 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.

It would be great if you could provide practical examples where generics could significantly improve Go code.

> It would be great if you could provide practical examples where generics could significantly improve Go code.

It would be great if you stopped patronizing people who just provided you an explanation you just don't want to hear.

Go has been a career kickstarter for me and gambling on it for a multi year ecommerce project was a hit, for me at least. I switched from so-so Java dev to Senior Dev, Go Trainer and Systems Architect and Go played a very big part.

It has its' shortcomings, but what i have learned due to just writing stuff instead of using enterprise frameworks was eye opening and i would be a comoletely different lerson today.

Thank you dear Go team & community!

I can second this. From being proficient in multiple languages to then picking up Go for primarily API service's I'm not looking back. It has taken a little while to level up to expert but the effort in learning how to build from the ground up by not using a framework is well worth it!

Yeah there is a lot of freedom that comes from a smaller set of choices. Java is so vast and so many libraries it is overwhelming and solutions are usually over engineered. With Go its nice to just write some code.

I am a C# developer. I don't like that the number of features and frameworks is increasing with every new release. It's overwhelming.

I tried Go, but I couldn't get into it. I don't know why. I guess it's like leaving prison. You can't go anywhere. Then suddenly you can go anywhere you like, but you feel paralyzed. The freedom itself is also overwhelming.

If anyone is interested in playing with generics in Go, here you go: https://go2goplay.golang.org/

https://go2goplay.golang.org/p/mUWfsZPHs5h

I'd kill for them adding support for structurally typed, non-nullable immutable tuples and records, destructuring, and pattern matching. This would make sharing data across channels much safer and seems like it could be implemented with minimal syntactic changes. I envision something like the following.

    //full-blown tuple support
    var person (string, string) = ("John", "Doe")

    //records are just tuples with named fields, but can use existing struct access syntax.
    var point #{x: int, y: int, z: int} = #{x: 1, y: 2, z: 3}

    //due to structural typing, we can just use a type alias
    type Person = (string, string)
    type Point = #{x: int, y: int, z: int}

    var person Person = ("John", "Doe")
    var point Point = #{x: 1, y: 2, z: 3}

    //or just infer
    person := ("John", "Doe")
    point := #{x: 1, y: 2, z: 3}

    //destructure
    fname, lname := person
    
    //destructure record/tuple
    {x, y, z} := point

    //destructure array or slice (c is always slice)
    [a, b, ...c] := myArray

    //pattern matching on tuple
    switch person {
        case ("John", "Doe"): //do exact match
        case ("John", _): //only match first name
        case (fname, lname): //use new variables
        default: //this is the same as `case _:`
    }

    //pattern matching on record or struct
    switch point {
        case {x, y, 0}: //do stuff with variable match
        case {1, 1, 1}: //do stuff with exact match
        default: //do stuff
    }

    
    //same style of error handling with more flexibility
    switch getPointWithPossibleError(point1, point2) {
        case (_, {type: "error1", msg}): //handle error 1
        case (_, {type: "errorN", msg}): //handle error N
        case ({x, 0, 0}, _): //handle exceptional case
        case ({x, y, z}, _): //handle default case
    }

The Go team is extremely friendly, so I encourage anyone thinking they could improve the language to open a feature request on GitHub: https://github.com/golang/go/issues

I love go but im annoyed they didn't choose angle brackets for the syntax. It's illogical to be annoyed at this, i know, but it feels like being different just for the sake of being different.

> Angle brackets require unbounded parser look-ahead or type information in certain situations

https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8

The argument seems to be that a,b=c<d,e>g could be misplaced based on whether this is a generic type or a pair of comparisons.

They then go on to say that they needed to revisit the design in the square brackets case to insert the keyword “type” whenever generics were used, which means this example would presumably become c<type d, type e> which resolves the ambiguity.

It seems more likely it was an issue discovered atbut not revisited when the issue was fixed, and now inertia is keeping it as is.

Is it possible to compile my local Go code with generics?

Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md

I'd like to hear some Java devs opinions on Go.

On one hand I'd like to try and learn something new,

on the other hand, everything I could do in go I would probably do better in java (as in I know how to do it already)

The vast majority of my work has been on the JVM - and most of that in Java. I tried Go for a while, and came away pretty unhappy.

First, similarities: Go seems like a really good language for building software for teams. It's straightforward and simple, and generally what you see is what you get. That's great.

Where it wins:

- having a standard formatter is amazing

- having a compiler that is fast, and an executable that starts fast and runs quickly is great

- the built-in http stuff seems better than what was available in Java's stlib for years

- channels are nice

- lower resource usage, especially memory

- by breaking with the JVM, you get to abandon a lot of bad patterns because they simply aren't available

Where it loses:

- I simply don't need pointers for the places I want to use Go

- the GC, though different, still needs tuning/consideration for high-load, and if I have to mess with GCs I want the options available to me on the JVM

- the dependency management story was rough for a while, though that seems to have settled into something more mature

- the error handling is unacceptably anemic

- the type system is unacceptably anemic. I'm not even talking about generics (maybe I am) - it just seems moronic to have to subvert it with "interface{}" all the time, which also renders the documentation pretty opaque to me.

Overall Go is a solid tool, and I see why it's so successful, especially for network stuff and command-line tools. It's hard to overstate how great an experience it is to have a fast-compile loop and I really envy that (I feel this way any time I use most languages not on the JVM).

And for learning something new, there's nothing novel that I've seen in Go. If you want to use it because it is pragmatic and efficient, that's a great reason.

How was experience using Go routines? And how would you compare it with Java? I am sure Java would have something similar

They (Go routines) mostly get out of the way and provide some abstraction over what I've typically used things like Future for in Scala.

As pjmlp mentioned, The concurrency package is pretty nice to know, and offers functionality to chain work or fire off an async task or enqueue stuff to be done as messages, but it's not as trivial as marking a function async. Clojure and Scala have more direct paths to this sort of convenience. Loom will be interesting!

It had green threads in the early day, than concurrency packages, finally project Loom with virtual threads.

thanks for a great comment, I feel similar about most of the stuff

Having used it some, and watched others use it more, I'm struck by the commonality that the most steadfast adherents of the language confuse typing with productivity; "The code flies from my fingers!"

Well, sure, but the code I don't need to write in the first place because of well used and vetted libraries, or higher level abstractions, is pretty cool too. It just isn't as keyboard clackyclacky.

This is how I feel. I need to deploy applications not rewrite Django/Rails/Spring/etc (and all the associating tooling) for the hundredth time.

The performance boost argument is a joke when we have horizontal scaling and and multithreading.

But not everything is a monolithic REST web app. Sometimes you have many different components -- from CLI apps to serverless functions -- and having a lean but powerful stdlib is amazing, especially with builin type safety, consistent lining, and cross-platform native binaries easily under 10MB.

I am mainly Java developer but used Go for some tools. I can't use Go for official applications because Go's XML library is little funky and my work is quite a bit XML dependent. It also lacks pure Go drivers for major commercial databases. If these 2 things were there I would have written lot more Go.

Just curious, what kind of drivers are missing?

Go's standard library is spectacular. Java could be as easy as Go to write quick micro-services, utilities etc if all the HTTP client and server stuff were part of the standard library. If Java had offered a Java -> native option right out of the box (instead of installing and setting up GraalVM), Go would have had difficulty in achieving the adoption it had today.

Go lang also made some fundamental re-useable interfaces that are leveraged across all its packages making the stdlib consistent to learn.

I still prefer Java though - because Intellij rocks and I am personally faster with development. But for newbies, golang is easier.

Go kills abstraction, which is in my opinion its greatest feature. There is far too many little functions, classes, and abstractions in the Java codebases I interact with day to day. Go is just a lot simpler than Java.

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

There's a big gap in trends between new-wave "tech companies" and "enterprise companies". It's hard to cleanly define these categories aside from culture, but Go is plenty popular in the former (along with lots of other languages), and Java remains prevalent in the latter. Sounds like maybe Python spans both.

If I look for golang jobs in NYC I see just one job in the whole city. Sure a few more in the surrounding area and a bunch remote, but just one job.

https://www.dice.com/jobs?q=golang&location=New%20York%20Cit..., NY,%20USA

1) Due to covid its highly likely that many of the companies in NY are listing as remote rather than NY-based.

2) Just an opinion, but I would guess the majority of companies on Dice would trend towards older tech stacks. My employer has 4 open Go positions but is not found on Dice.

- Angel.co shows 10 Go-related jobs in NYC

- Linkedin shows 293 Go-related jobs in NYC

Echoing others' points. The company I work for (fairly large tech company) uses Go, and is hiring in NYC, but has no roles listed on Dice. I know of at least two more definitely-not-small tech companies hiring in NYC that use Go, and their job listings say Go, but they have no job listings on Dice either.

Seems there may be a "cultural divide" on where job listings for different types of companies/languages show up.

This is reflective of the adoption of dice, not the adoption of Go... there are lots companies in NYC that hire engineers to develop in Go (Google and Uber immediately come to mind).

In the business world we have Java with powerful application frameworks and libraries like Spring, which delivers everything that the business needs, and in the other end is Typescript/NodeJS which is extremely cost effective, has reasonable performance and crazy number of open source libraries. Everything in between have smaller share because these two are easily eating most of the market.

Marketing & branding -- esp to enterprise IT -- is really not in the Go team's wheelhouse.

A third party could take it on, but that would require a different governance structure for the project. Outside entities have little influence now.

He is talking about market share. I don't think he meant big companies aren't using it.

Looks like GOPATH is finally going away and a go.mod will be required. Time to update those old projects I guess ...

But I have tools built with GOPATH assumptions...

I'm primarily a C# dev, but I find Go quite interesting. Any recommendations for how I can get started and reap some benefits, given my background?

I got started with the Go tour: https://tour.golang.org

You'll get a feel for the language constructs. Once you're ready to graduate to tinkering with your own stuff, then go install Go: https://golang.org/doc/install

Some noted differences from C# (my C# knowledge is 5-10 years out of date, mind you):

* Go is a much simpler language; it lacks classes, inheritance, generics, exceptions, etc--you can be productive in a weekend, conservatively * Go has a formatter that everyone uses, so everyone's code has the same style * Go lacks generics, so everyone generally writes in the same imperative way (few personal, creative flourishes)--it's very boring in this regard (which is a feature for many people) * Go has value types (like C#) but they are much more idiomatic--it also has pointers and other reference types * Go's interfaces are implicitly satisfied, which is like statically-typed duck typing if you're familiar with any dynamic languages (no need to write `extends IFoo` or whatever, unlike C#) * Go statically compiles everything by default (the "VM" is compiled into every individual program) so you can just pass around a single compiled artifact * Go has lightweight threads ("goroutines") * For web service things, you don't need a Netty or any other web-server in front of your service; the web server is just a library (part of the standard library, in fact) and it is production-grade

Go and C# occupy the same ballpark in terms of performance.

Oof, sorry for the formatting. Missed the edit window. One last characterization: Go is like C with a GC, package management(and other sane tooling), and many other rough edges removed.

Plus an awesome multi-core solution.

Pretty sure .Net does fine with multicore, or at least to the extent that it doesn't, it's down to excessive sharing/mutation resulting from OO design patterns (modulo "that's not True OO!" arguments, anyway).

I'm a full-stack .NET dev that did a brief stint at iStreamPlanet - a streaming media company - where I got my first exposure to Go. I was actually surprised when they hired me with absolutely zero knowledge in Go. That said, I was able to hit the ground running with minimal assistance using the language itself and I found Go to be enjoyable. Don't let the unfamiliar territory intimidate you. "A Tour of Go" was a perfect starting point: https://tour.golang.org/welcome/1

You raised an interesting point in your question though: how do you reap benefits? I did not find a good answer to this. I've yet to see any convincing real-world reason to switch from .NET Core to Go. I thought perhaps it had an edge in the streaming media industry, but I didn't find that argument to hold significant weight either. If you go searching online, you might find some articles that show Go to be more performant using large numbers of threads or doing exclusively mathematical operations, so that might be where you could reap some benefits?

EDIT: I hope what I said about reaping benefits doesn't come off as any sort of fanboy-ism towards a specific language. This is just my personal experience as C# dev. Use the language that's right for you and right for the task.

Appreciate the input from someone who has gone .NET -> Go!

I wasn't sure if there were any obvious benefits, but from looking at various Go codebases recently, they usually seem so succinct by comparison to the typical C# codebase I see - I love C#, but that has piqued my interest. Also, I don't try new languages often, so might be interesting just to have a go (yes, pun intended :)

> Over the next year, we will continue to work on developing support for Go modules and integrating them well into the entire Go ecosystem. Go 1.16 will include our smoothest Go modules experience yet.

I never thought of seeing "smooth" and "go modules" in the same sentence; but I hope he is right.

Go is my primary programming language during the last 10 year. I absolutely love Go because of the following features:

* Great code readability. I can open any project in Go and instantly start reading and understanding the code. This is because of simple syntax, which doesn't provide ability to write implicitly executed code, and `go fmt` tool, which formats everybody's code to a single code style.

* Go discourages unnecessary abstractions and encourages writing essential boring code without various "smart" tricks. The end result is much shorter code base, which is easy to read and refactor.

* Fast compile times. For instance, my latest project - VictoriaMetrics [1] - contains almost 600K lines of Go code excluding "_test.go" files. Go builds the final `victoria-metrics` executable in less than a second during development. This means that I can quickly iterate on code modifications and testing without the need to wait for minutes and hours for build process to finish (hello, Rust and C++ :) ).

* Single statically linked output binary with relatively small size. For example, VictoriaMetrics is built into 19MB statically linked binary with Go 1.15.4. And this binary contains all the debug symbols. Binary size shrinks to 12MB when stripping debug symbols. Such a binary can run on any host without the need to manage external dependencies - just upload the binary and run it.

* Ability to build executable for any supported target platform by specifying GOOS and GOARCH environment variables. For example, I can build binary for FreeBSD on ARM from my x86 laptop running Ubuntu.

* Great and easy-to-use tooling for race detection and CPU/memory/locks profiling. There tools significantly simplify code optimization and allow to catch data races at much lower mental cost comparing to race-free Rust :)

P.S. I hope Go will never adopt generics. I didn't need generics during the last 10 years of active development in Go [2]. Before Go I was working with C++ and was experiencing constant pain with reading and debugging C++ templates in stl and boost libraries. I don't want to experience the same feelings with Go.

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/

[2] https://github.com/valyala/

> constant pain with reading and debugging C++ templates

C++ templates are a nightmare agreed. What C++ does is just one way, a poor way, to implement generics. Please do not conflate generics with C++. If you've ever worked with C#, Java, TypeScript, or others you'll know that "generics" come in many different flavors. Some are quite nice. Generics are coming to Go ([https://www.gophercon.com/agenda/session/233094]).

Slices, chans, maps, arrays are all generic in Go - and they are great! Stuff like the sync package (https://golang.org/pkg/sync/) with interface{} all over? Not so great. Generics solves a real problem.

It would be great if generics could be used by a small team of professional Go developers who clearly understand strong and weak sides of generics. Unfortunately this is impossible in real world :( I predict that generics in Go will lead to much more poorly written hard to read and debug packages and apps.

Are you using an IDE?

Coming from dotnet I'm kind of spoiled here, with both Visual Studio and Rider being excellent choices. They also bring things like a great debugging dev UX, and the possibility to change variable values and code during an active debugging session - is there anything like that for Go?

You're absolutely right. Generics especially in form of contracts would be a mess.

Great post to highlight what has happened in the last year in GoLang and what is up for the next year! Very concise and to the point.

Even without having used much GoLang this last year it gave me a very clear view of what to be looking for!

Eleven Years A-Go?