Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 310 posts

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

#71

Post by pydry »

thiht wrote: post #68
piinbinary wrote: post #23

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

Because web servers look simple from the outset but are, underneath it all, very complicated. And it's not a web server.

If you want something basic, gunicorn can run flask with one line.

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

#72

Post by lima »

jen20 wrote: post #62
djstein wrote: post #42

Earlier quoted context omitted.

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 Wind…

Plus, it does so non-reproducibly and downloads random binaries from the internet.

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

#73

Post by mook »

anonymoushn wrote: post #19

Non-exported struct fields are a way of preventing your library from being composable. Checking if a value implements an interface is a way of writing surprising bugs. The standard library uses both of these features extensively, to give users bugs and prevent itself from being composable. Checking that the user uses all values bound to variables but letting them discard errors by not binding them to a variable is a…

Related complaint, the standard library taking structs as input is kind of annoying. I'm specifically thinking of net.Dialer having a net.Resolver, where that's a struct and not an interface, so it's difficult to sub in custom logic there (but still possible, at least, with some contortions).

Single-binary deployment and (these days) good dependency tracking (downloading multiple versions of a library) is great; I don't worry about trying to get somebody else's source code built I do the way when I get python packages. The python side is largely because setting up a venv is error-prone (at least, for me, somehow) and leaky. I still think having the version baked into the import path is kind of dumb, but I suspect that's really just because the documentation failed to explain the reasoning and good workflows (I understand just changing the path in go.mod may be enough).

I wish they had things like generics, but I fear that an incompatible version break would cause too much strife, much in the same way of python 3 / perl 6. Given how the vendoring tools story went, I'm not yet confident the core team can manage the community very well.

On the positive side, the error handling has been decent for me so far; an error interface is easy to understand, compared to rust (where I think you can use Box but they don't actually say that in the basic documentation). I also like the decently sized standard library, again in comparison to rust where things are too minimal. I think ruby has a decent compromise, where the standard library is (mostly) also available as downloadable packages if you need a newer version. Somehow I've had worse experience with ruby gems compared to go modules, though; I think that's because the bundler documentation is rather bad — it feels more like an essay rather than a reference.

Not having a central repository of packages is a definite plus in my book for go; it leads to less of a problem with people taking the good package names (since most names are bad anyway). Less worries about cutely named libraries like devise (ruby, for auth) or hyper (rust, HTTP). IMHO, libraries should be plainly named, apps can have weird names if they want.

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

#74

Post by edfletcher_t137 »

stperrin wrote: post #55

Go is a welcomed simplicity to the stack in a world where everyone is over complicating software engineering by jumping to Kubernetes and micro-services. Simplicity really is where Go stands out against languages like Java. Yes, you may write more boilerplate and break DRY, but your code will be readable and won’t contain any hidden magic. We spend most of our work day reading and trying to understanding code. What y…

All of this, 1000%.

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

#75

Post by edfletcher_t137 »

darkest_ruby wrote: post #34

So many comments, not a single mention of Rust...kinda sad.

"What are your thoughts on the Go programming language?"

"Well, let me tell you about this other language called Rust..."

Classic Rustacean: sees zero daylight to inject oneself, does so anyway.

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

#76

Post by Glavnokoman »

Being backed by Google contributes a big deal to its (relative) success. I think it is the most limited and ugliest of all the "modern" languages (Rust, D, Zig (never tried Swift)). And at the same time it seems to have the most significant output of all these (docker, kubernetes, gitea...).

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

#77

Post by vram22 »

Mr_T_ wrote: post #57
sabellito wrote: post #9

Speaking strictly about the language, and not the platform, I'm skeptical about the lack of more modern core library and language features like immutability, pattern matching, and records. They spent almost 10 years saying "we don't need generics", but now are implementing it Also, the dependency management.

> They spent almost 10 years saying "we don't need generics", but now are implementing it You're making things up. Not a single member of the Go team ever said "we don't need generics". In fact, the FAQ stated from day one that they "continue to think about it", and that "Generics may well be added at some point".

Yes. IIRC, Rob Pike or someone else on the Go team even said something like "it's hard, so we are taking our time about it, may implement it later". Edit: see [1] below.

Also googled and found this:

http://lambda-the-ultimate.org/node/4554

which includes this section:

Go might have generics in future

with this text:

The Go FAQ recognizes the issue and says that generics may be added at some point... http://golang.org/doc/go_faq.html#generics

Considering how Java generics turned out I am fine with the Go team taking the time to think about a proper design for generics in Go :-)

By ted stockwell at Tue, 2012-06-26 15:03

[1] The golang.org link above about generics also says this:

We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it.

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

#78

Post by anonymoushn »

closeparen wrote: post #24
anonymoushn wrote: post #19

Non-exported struct fields are a way of preventing your library from being composable. Checking if a value implements an interface is a way of writing surprising bugs. The standard library uses both of these features extensively, to give users bugs and prevent itself from being composable. Checking that the user uses all values bound to variables but letting them discard errors by not binding them to a variable is a…

Can you elaborate on private struct fields? The same criticism would apply for any OO language with access control / visibility of fields right?

The particular combination of things is, some library includes some method signatures that accept and return a specific struct (not a specific interface). Then, also, there is no exported way to make one of that struct, or to set its fields. Now you cannot write a library that wraps the original library and exposes the same API (unless you use unsafe and reflection).

In the OO languages I have encountered there seems to be a stronger convention toward using interfaces instead of struct or class types in this sort of situation, but people are certainly free in Java to use a final class type as the type of their parameters and return values if they want to make their library less composable.

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

#79

Post by staticassertion »

pjmlp wrote: post #54

It was a large mistake to ignore the lessons of Java and now the language is full of quirks as well, including the upcoming generics design. Regardless of the whole systems programming language polemic from the anti-GC crowd, several projects deployed into production like gVisor and TamaGo prove otherwise. Finally thanks to killer applications like Docker, Kubernetes and everything around them, Go has become unavoida…

> several projects deployed into production like gVisor and TamaGo prove otherwise

Do they? AFAIK gVisor absolutely had to fight with Go, and it has a huge performance impact, and lots of larger projects have done some semi-absurd work such as implementing their own generics impl via preprocessors.

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

#80

Post by closeparen »

anonymoushn wrote: post #78
closeparen wrote: post #24

Earlier quoted context omitted.

Can you elaborate on private struct fields? The same criticism would apply for any OO language with access control / visibility of fields right?

The particular combination of things is, some library includes some method signatures that accept and return a specific struct (not a specific interface). Then, also, there is no exported way to make one of that struct, or to set its fields. Now you cannot write a library that wraps the original library and exposes the same API (unless you use unsafe and reflection). In the OO languages I have encountered there seems…

Is this a different problem from private constructors / setters in OO world?
Post reply on HN