Live data from Hacker News

Ask HN: Go programming language is over ten years old. What do you think of it?

news.ycombinator.com

61–70 of 310 posts

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#61
I introduced it where i work. While it has some drawback (as any language) i find myself most productive when i'm writing in go.

Just this week i wrote an entire toolchain for developing with an embed device, that now i can distribute to anyone that need to work on that project.

Before go i used nodejs/python due to the large ecosystem of library, but go nowadays has a similar ecosystem and allow me to build static executable without any dependency. That is super useful since i work with different OS (ubuntu, fedora, windows and macos). Also even sloppy/draft code is really fast and i don't need to start optimizing and profiling from the start like in python (i often process large dataset).

Lastly the language is very simple and my colleague who ,didn't even know go, learned in a week and, most importantly, is able to navigate my large codebase without much help (that for me is the biggest advantage of go)

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#62
post #42
post #18

Earlier quoted context omitted.

Go more than makes up for this in the deployment aspect, since deploying Python in 2020 (Python 2, Python 3, conda, pip, venv, system interpreter, poetry, etc.) is still a mess.

Only a mess if you use python 2, conda, etc... What’s difficult about this? /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/in... )" curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/maste... | python - brew install pyenv // update shell with pyenv pointer pyenv install 3.9.0 pyenv global 3.9.0 poetry init poetry config virtualenvs.in-project true --local poetry ins…

> What’s difficult about this?

Well, for starters, that particular multi-liner:

- installs an entire package manager, which may or may not conflict with system tools or a different package manager,

- assumes pyenv will build Python against the system libraries without additional flags (it won't if you're running Big Sur, you'll need zlib from Homebrew),

- assumes you are on macOS, and does not attempt to work on Windows or Linux, or account for the idea that someone might not want to deploy a program using Docker.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#63
Frustration over not having a proper parametric polymorphism (Also known as “static generics”) so I cannot write elegant functional style code to promote more code reuse. You wonder how do you do some kind of Map/Filter/Reduce in Golang? Check out go-funk in Github but bear in mind they use reflection to emulate it so the performance can be very dissatisfying.

This is the biggest pain point of Go throughout my journey and I have been waiting so long for Go 2! PLEASE!

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#64
I work with golang since 2011 and am still in love with this language like I am with no other. I am super impatient for the generics release in 1.17 aroung August next year as I think the current proposal is super good. Besides sometimes I miss adoption of golang in fields like ml and data science eg voice recognition.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#65

Earlier quoted context omitted.

Have you tried GoLand?

No, but I've heard really good things about it, and even tried out the demo when it initially came out a few years ago. I was hesitant to change my Vim workflow though. Thanks for mentioning it, I think I'll take another look at it now. Having a real IDE probably has more benefits once the code grows beyond tens of thousands of LOC.

FWIW IdeaVIM is the closest thing to "real" vim around, so you can at least use reasonable key bindings with Goland (and all IntelliJ-based IDEs)

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#66
post #60

I find myself reaching for it over other languages when I want to build small servers with a bit of in-memory state or a bit of heavy processing. For little search-engines, Go is perfect. While writing servers in Flask + Python is much more convenient, I still prefer Go because I don't run into the limits that Python has. The development process is fluid enough that I wish the language was suited to more usecases. Wh…

What is it that you find more convenient about Python/Flask?

Flask is better in the little mechanics of interacting with HTTP - parsing a parameter out of a URL (in Flask, it's a function argument; in Go, it's at least one extra line per arg), returning JSON (just return a dictionary in Flask), handling errors. Flask also is able to auto-reload the code when it changes (turn on development mode) which is really convenient.

Plus all the ways that Python is more convenient than Go.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#67
post #4

The structural type system is something I really wish other languages started using.

Structural types are one of those things that annoy me in both theory and practice, when I have to touch Go code.

In theory, it's annoying because it prevents you from expressing constraints (think: monad laws, or Rust's Sync/Send traits). In practice, it makes stuff like go-to-definition nearly useless, which makes it a pain to read code written by other people. Especially when combined with the almost sadistic module system.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#68

I find myself reaching for it over other languages when I want to build small servers with a bit of in-memory state or a bit of heavy processing. For little search-engines, Go is perfect. While writing servers in Flask + Python is much more convenient, I still prefer Go because I don't run into the limits that Python has. The development process is fluid enough that I wish the language was suited to more usecases. Wh…

> While writing servers in Flask + Python is much more convenient

The only time I had to use Flask, it was a nightmare to deploy. To this day I still fail to understand why I had to mess with Nginx, gunicorn, WSGI or whatever just for a basic backend. The dev experience was fine, but I don't remember it being more convenient than using Go

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#69
Wow! 10 years already. I'm the founder of HashiCorp and I'd love to share my thoughts.

Credentials: I started using Go around 9 years ago and since then I've built a company of over 1,000 employees with ~250 engineers that write Go full time. We maintain dozens of open source projects and libraries (Terraform, Vault, etc. etc.) all written in Go. We've shipped commercial products that are used by a significant percentage of the F500. Vault for example serves trillions of secrets per year for _one_ company that we know of.

I could probably write pages and pages so I'll try to highlight a few things. Go is not a perfect language or community by any means but I love it.

NOTE: Folks often read this feedback with the opinion of "but language X can also..." or some variant and I hope that doesn't come across. My feedback is not against any other language unless I'm specifically using an example. Another language might solve all these same problems for you! I'm just sharing how Go has been fantastic at these aspects for us.

== Junior and new-hire friendliness

Go is a very simple language. From the beginning of the company until now, we can hire people who have never used Go, point them at a couple resources (i.e. Tour of Go), and they can be committing to production-grade projects within a week. It is incredible.

Go makes it really hard to do anything that isn't obvious. The cost of this is often verbosity or repetition. But the benefit above is well worth it in my opinion. I know lots of people disagree with this but I personally prefer to repeat "if err != nil" 1,000 times versus introducing new control flow options that now must be educated.

I love telling new folks (junior or not): read the file top to bottom, that's how it'll execute. And for the most part, that's true.

As someone who built a rapidly growing team/company around Go, this has been indispensable.

== Flexible

Any "general purpose language" can theoretically write any software. However, I'm sure we'll all agree that its easier to write some software in certain languages, and that's a good thing.

However, I've been blown away by how flexible Go has been without feeling forced. We've written desktop CLIs, web APIs, distributed systems, security software, networking software, infrastructure software, accounting software, bots, etc. all in Go.

And most of these categories are at a scale of millions of downloads per year and successfully in production.

It's very cool to see that coming from a prior major background in Ruby where there were significant tradeoffs when doing these things. It was _possible_ of course but you had to really understand the tradeoffs you were making. In Go, there's certainly some tradeoffs but they've been minimal and Go has just worked.

As both an individual contributor and manager, this flexibility has been awesome in building a company around.

== Cross-platform Compilation and Statically-Linked Binaries

Since the first day I adopted Go 9 years ago, Go has encouraged and simplified static binary compilation and simple cross-platform compilation. Today you basically set an env var of what platform you want to target, run `go build`, and it usually works.

You still have to learn of various gotchas around platforms (API availability, filepath awkwardness, subprocess/signal behavior, etc.) but the compilation aspect alone makes it so much easier to tackle this task.

My previous experience of at-scale software I built was Vagrant in Ruby, and making that work across platforms was a constant, enormous challenge. I had to spend a few months full time just to get installers to help setup the proper runtime environment across platforms.

Looking at this also from the perspective of rising popularity with ARM systems and other less standard architectures (even Power for enterprises...), this property of Go has been very important.

== Culture

The culture surrounding the Go community is generally one that is very philosophically aligned with how I view software. I would roughly describe it as pragmatic & measured.

I think this culture is exactly why many people dislike Go (or seem to "hate" it which I think is a pretty wild emotional reaction to a language for programming computers but I digress).

The Go community doesn't chase the next hot thing or rush to implement the "state-of-the-art" without a very measured, pragmatic approach. Some view this as Go being inferior by some definition but I view it as a huge benefit. Go core in particular appears to me (I'm not part of the core team so purely an opinion) to be a measure-twice-cut-once (or maybe measure like 8 times) approach. And I love that.

== Fun

At the end of the day, the language is generally fun for me. I like writing it. And that's important, too.

== Conclusion

I'm very lucky that Go took off as a language in the industry I built my company in. It certainly wasn't that way when we started using it (it was pre-1.0, pre-Docker, pre-K8S, the majority of infra sw was still in Ruby).

I feel that the language is super productive (we built Vault 0.1 in ~6 weeks for example), it has shown to scale to the largest needs and does so stably (Vault is in the hot path of every trade in one of the major US stock exchanges and has never gone down there), and we've been able to build a large company and active OSS community around it.

Hands down a successful choice for us with zero regrets.

Re: Ask HN: Go programming language is over ten years old. What do you think of it?

#70
Great tool, two big negatives. First, checking result values is dumb. It adds 50% more code. Add exception handling.

Second, the way imports work is obviously due to some internal google kitschy-ness. Remote import paths are so dumb. People set up entire domains and CDN's just to host some code. The import path has to have a specific format, you can't have three levels. github.com/me/sub1/module won't work, so everyone creates mypersonalgithub.com/sub1/module. It feels like one L3 at google set this up on a Friday, and the industry has to live with it. Of course all this code will be broken in 3 years.

There is no easy way to point imports to a local development copy of a repo because google uses a monorepo and everyone else has to live with it.

Post reply on HN