15 ms·

Eleven Years of Go

354 points by mfrw 6y ago

mfrw 6y ago
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."
- Rochus 6y ago
  By the end of the year 2021!
  - mfrw 6y ago
    Yes... Updated my comment. It was misleading :(
- qz2 6y ago
  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.
- dgb23 6y ago
  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.
  - philosopher1234 6y ago
    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.
- alquemist 6y ago
  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 https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling https://github.com/golang/go/labels/error-handling
  - jhoechtl 6y ago
    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.
    - alquemist 6y ago
      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/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf....
      - mseepgood 6y ago
        > 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-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-...
        Groxx 6y ago
        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.
- valyala 6y ago
  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. [1] https://github.com/valyala/ https://github.com/valyala/ [2] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/
  - throw_m239339 6y ago
    > 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.
    - valyala 6y ago
      It would be great if you could provide practical examples where generics could significantly improve Go code.
      - throw_m239339 6y ago
        > 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.
dalu 6y ago
I had different opinion than guy who joined the Go team in 2019 (Ian Lance Taylor). I was banned from their github repo, my AdSense sites were removed from Google's index, my AdSense CPC dropped by 2/3. My github account was "flagged" aka disabled from being seen in public. I was on github for 7 years. I received nonsensical "not in accordance to policies" messages from AdSense all of a sudden when that happened aka the whole sites were being flagged as not following policies. And all that because I wanted a font that you can easier read than the stupid roboto font. Go may be open source, but you're not part of it. It belongs to Google and anyone disagreeing with them they will actively attack you. I still use Go and every time I use it I'm reminded of their bullying and power tripping. My sites are still off Google's index btw and any new sites receive the "no content" response and are rejected, despite there being content. You made an enemy that day. You always meet twice in life. I'll pay that back to you.
- rezeroed 6y ago
  I've not had a good experience with them either. I was contributed a bug fix to the std lib which would've been a decent feather in my cap. Not even a thanks; some maintainer copied, pasted, made a few changes, merged "his" fix. 2014 iirc; extinguished my interest.
  - burgerquizz 6y ago
    Any commits we can refer to, so we can expose this situation for potential contributors?
    - rezeroed 6y ago
      Archaeology. (~2014, couldn't be bothered.)
      - rezeroed 6y ago
        Downvoting the way I prioritise my time? Good lord.
andreygrehov 6y ago
If anyone is interested in playing with generics in Go, here you go: https://go2goplay.golang.org/ https://go2goplay.golang.org/ https://go2goplay.golang.org/p/mUWfsZPHs5h https://go2goplay.golang.org/p/mUWfsZPHs5h
- avinassh 6y ago
  Is it possible to compile my local Go code with generics?
  - avery42 6y ago
    Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md https://github.com/golang/go/blob/dev.go2go/README.go2go.md
- hajile 6y ago
  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 }
ku-man 6y ago
11 years it's a long time. Back then I was hoping Go would overtake Python's position as the default earth-science and engineering programing language. It didn't. And if it didn't in 10 years, it won't ever.
skrtskrt 6y ago
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.
- ngrilly 6y ago
  Agreed about the template hierarchy being a bit weird, but the HTML template escaping is amazing. Much smarter and more secure than Jinja, etc.
- jeffbee 6y ago
  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.
  - nicoburns 6y ago
    Have you tried langauges other than C++ and Go? Almost anything makes you pull your hair out in C++!
  - skrtskrt 6y ago
    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.
Sean-Der 6y ago
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/dtls * https://github.com/pion/webrtc https://github.com/pion/webrtc * https://github.com/pion/turn 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?
- jhoechtl 6y ago
  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.
  - thefounder 6y ago
    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 )
    - jhoechtl 6y ago
      Soemthing to show the world, github / -lab repo, the like?
  - thegeekpirate 6y ago
intricatedetail 6y ago
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.
- philosopher1234 6y ago
  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.
- dilap 6y ago
  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)
lsllc 6y ago
Looks like GOPATH is finally going away and a go.mod will be required. Time to update those old projects I guess ...
- thefounder 6y ago
  But I have tools built with GOPATH assumptions...
dvt 6y ago
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.
- throwaway894345 6y ago
  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.
aprdm 6y ago
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!
asim 6y ago
Micro was on the frontpage earlier today (https://news.ycombinator.com/item?id=25044604 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.
- irishcule 6y ago
  >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 :) )
  - asim 6y ago
    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.
    - irishcule 6y ago
      Ah ok, I misunderstood your comment. Glad to hear Go has had such a big impact for you.
GordonS 6y ago
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?
- throwaway894345 6y ago
  I got started with the Go tour: https://tour.golang.org 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 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.
  - throwaway894345 6y ago
    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.
    - lanstin 6y ago
      Plus an awesome multi-core solution.
x87678r 6y ago
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.
- networkimprov 6y ago
  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.
- brundolf 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - x87678r 6y ago
    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%20City https://www.dice.com/jobs?q=golang&location=New%20York%20Cit..., NY,%20USA
    - jmg_ 6y ago
      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
    - 6y ago
preommr 6y ago
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.
- ra7 6y ago
  > 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.
- DangitBobby 6y ago
  I have also found tooling, especially surrounding modules, to be a gigantic hassle. Using Goland has helped.
- tensor 6y ago
  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.
domano 6y ago
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!
- alienspaces 6y ago
  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!
- yyyuutt 6y ago
  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.
  - emilp89 6y ago
    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.
premek 6y ago
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)
- blandflakes 6y ago
  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.
  - premek 6y ago
    thanks for a great comment, I feel similar about most of the stuff
  - avinassh 6y ago
MichaelMoser123 6y ago
> 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.
wirrbel 6y ago
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.
- valenterry 6y ago
  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.
  - st1ck 6y ago
    misread as > But if you come from doing shell scripting in C Sure I'd switch to Go in no time!
  - wirrbel 6y ago
    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 ...
    - valenterry 6y ago
      That's what I expect, too. In the end, the biggest problem is always to understand and change complex foreign code.
activatedgeek 6y ago
Eleven Years A-Go?
valyala 6y ago
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/ https://github.com/VictoriaMetrics/VictoriaMetrics/ [2] https://github.com/valyala/ https://github.com/valyala/
- shiba_developer 6y ago
  You're absolutely right. Generics especially in form of contracts would be a mess.
- kinjba11 6y ago
  > 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 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/ https://golang.org/pkg/sync/) with interface{} all over? Not so great. Generics solves a real problem.

354 points by mfrw 6y ago

mfrw 6y ago

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

Rochus 6y ago
By the end of the year 2021!
- mfrw 6y ago
  Yes... Updated my comment. It was misleading :(
qz2 6y ago
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.
dgb23 6y ago
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.
- philosopher1234 6y ago
  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.
alquemist 6y ago
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 https://github.com/golang/go/issues/32437#issuecomment-512035919 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling https://github.com/golang/go/labels/error-handling
- jhoechtl 6y ago
  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.
  - alquemist 6y ago
    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/go2draft-error-handling-overview.md https://go.googlesource.com/proposal/+/master/design/go2draf....
    - mseepgood 6y ago
      > 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-try-builtin.md https://github.com/golang/proposal/blob/master/design/32437-...
      - Groxx 6y ago
        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.
valyala 6y ago
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. [1] https://github.com/valyala/ https://github.com/valyala/ [2] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/
- throw_m239339 6y ago
  > 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.
  - valyala 6y ago
    It would be great if you could provide practical examples where generics could significantly improve Go code.
    - throw_m239339 6y ago
      > 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.

dalu 6y ago

I had different opinion than guy who joined the Go team in 2019 (Ian Lance Taylor). I was banned from their github repo, my AdSense sites were removed from Google's index, my AdSense CPC dropped by 2/3. My github account was "flagged" aka disabled from being seen in public. I was on github for 7 years. I received nonsensical "not in accordance to policies" messages from AdSense all of a sudden when that happened aka the whole sites were being flagged as not following policies. And all that because I wanted a font that you can easier read than the stupid roboto font. Go may be open source, but you're not part of it. It belongs to Google and anyone disagreeing with them they will actively attack you. I still use Go and every time I use it I'm reminded of their bullying and power tripping. My sites are still off Google's index btw and any new sites receive the "no content" response and are rejected, despite there being content. You made an enemy that day. You always meet twice in life. I'll pay that back to you.

rezeroed 6y ago
I've not had a good experience with them either. I was contributed a bug fix to the std lib which would've been a decent feather in my cap. Not even a thanks; some maintainer copied, pasted, made a few changes, merged "his" fix. 2014 iirc; extinguished my interest.
- burgerquizz 6y ago
  Any commits we can refer to, so we can expose this situation for potential contributors?
  - rezeroed 6y ago
    Archaeology. (~2014, couldn't be bothered.)
    - rezeroed 6y ago
      Downvoting the way I prioritise my time? Good lord.

andreygrehov 6y ago

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

avinassh 6y ago
Is it possible to compile my local Go code with generics?
- avery42 6y ago
  Yes, by building the dev.go2go branch: https://github.com/golang/go/blob/dev.go2go/README.go2go.md https://github.com/golang/go/blob/dev.go2go/README.go2go.md
hajile 6y ago
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 }

ku-man 6y ago

11 years it's a long time. Back then I was hoping Go would overtake Python's position as the default earth-science and engineering programing language. It didn't. And if it didn't in 10 years, it won't ever.

skrtskrt 6y ago

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.

ngrilly 6y ago
Agreed about the template hierarchy being a bit weird, but the HTML template escaping is amazing. Much smarter and more secure than Jinja, etc.
jeffbee 6y ago
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.
- nicoburns 6y ago
  Have you tried langauges other than C++ and Go? Almost anything makes you pull your hair out in C++!
- skrtskrt 6y ago
  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.

Sean-Der 6y ago

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/dtls * https://github.com/pion/webrtc https://github.com/pion/webrtc * https://github.com/pion/turn 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?

jhoechtl 6y ago
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.
- thefounder 6y ago
  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 )
  - jhoechtl 6y ago
    Soemthing to show the world, github / -lab repo, the like?
- thegeekpirate 6y ago

intricatedetail 6y ago

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.

philosopher1234 6y ago
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.
dilap 6y ago
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)

lsllc 6y ago

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

thefounder 6y ago
But I have tools built with GOPATH assumptions...

dvt 6y ago

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.

throwaway894345 6y ago
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.

aprdm 6y ago

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!

asim 6y ago

Micro was on the frontpage earlier today (https://news.ycombinator.com/item?id=25044604 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.

irishcule 6y ago
>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 :) )
- asim 6y ago
  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.
  - irishcule 6y ago
    Ah ok, I misunderstood your comment. Glad to hear Go has had such a big impact for you.

GordonS 6y ago

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?

throwaway894345 6y ago
I got started with the Go tour: https://tour.golang.org 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 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.
- throwaway894345 6y ago
  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.
  - lanstin 6y ago
    Plus an awesome multi-core solution.

x87678r 6y ago

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.

networkimprov 6y ago
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.
brundolf 6y ago
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.
- deleted 6y ago
  [deleted]
- x87678r 6y ago
  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%20City https://www.dice.com/jobs?q=golang&location=New%20York%20Cit..., NY,%20USA
  - jmg_ 6y ago
    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
  - 6y ago

preommr 6y ago

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.

ra7 6y ago
> 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.
DangitBobby 6y ago
I have also found tooling, especially surrounding modules, to be a gigantic hassle. Using Goland has helped.
tensor 6y ago
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.

domano 6y ago

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!

alienspaces 6y ago
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!
yyyuutt 6y ago
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.
- emilp89 6y ago
  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.

premek 6y ago

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)

blandflakes 6y ago
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.
- premek 6y ago
  thanks for a great comment, I feel similar about most of the stuff
- avinassh 6y ago

MichaelMoser123 6y ago

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

wirrbel 6y ago

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.

valenterry 6y ago
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.
- st1ck 6y ago
  misread as > But if you come from doing shell scripting in C Sure I'd switch to Go in no time!
- wirrbel 6y ago
  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 ...
  - valenterry 6y ago
    That's what I expect, too. In the end, the biggest problem is always to understand and change complex foreign code.

activatedgeek 6y ago

Eleven Years A-Go?

valyala 6y ago

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/ https://github.com/VictoriaMetrics/VictoriaMetrics/ [2] https://github.com/valyala/ https://github.com/valyala/

shiba_developer 6y ago
You're absolutely right. Generics especially in form of contracts would be a mess.
kinjba11 6y ago
> 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 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/ https://golang.org/pkg/sync/) with interface{} all over? Not so great. Generics solves a real problem.