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

Ask HN: What do you like/dislike about Golang?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Ask HN: What do you like/dislike about Golang?

#61

Post by yjftsjthsd-h »

morelisp wrote: post #26
yjftsjthsd-h wrote: post #14

It's a very practical language, and I like its affinity for static binaries. A downside is Google's approach to handling modules: https://drewdevault.com/2021/08/06/goproxy-breaks-go.html

This seems to only be a complaint about a particular (granted, default) proxy for downloading modules, and no criticism of the actual module system (which does not depend on a proxy) nor the idea of a proxy (which is pretty easy to run, especially when compared to most other languages' package repositories). As to the criticism, if a public module isn't playing well with the default proxy, it's a good sign I don't wa…

> about a particular (granted, default) proxy

Yeah, but defaults matter. That's one of Go's big selling points, usually.

> As to the criticism, if a public module isn't playing well with the default proxy, it's a good sign I don't want to use it to begin with.

The concern raised here is more that things only work because the proxy masks problems. Also alluded to is that said default proxy is kind of awful to its upstreams, unnecessarily pulling things and burning bandwidth.

Re: Ask HN: What do you like/dislike about Golang?

#62

Post by AntiMS »

Like:

- `go generate` for embedding resources into the executable. So intuitive and beautiful.

- Strict curating. It's the kind of language that things don't get into unless they're the right solution.

- Performance! Python was my favorite language before Go got sufficiently mature. It was refreshing to have that much efficiency coming from Python.

- `if err != nil {`, dammit!

- Imports referring to the location where the code can be got. `import "github.com/fogleman/gg"` for instance.

- `go fmt`. Nuff said.

- Tabs as the standard indentation character.

- `fallthrough`

- `init()`

Dislike:

- nil. I wish nil had a smller role in the language. It's an agreed best practice in Go that a zero value should be a ready to use thing. I feel like that would be easier to do (and more true of the core language) if the zero value of a slice/map was an empty slice/map, the zero value of a pointer was a pointer to a zero value of the type it points to, etc. Maybe this can't be done for all types (function and interface types, for instance), and maybe there are good reasons for the way it is that I'm not smart enough to realize, but if it could be done for some types, it would be nice.

Things I Pretty Much Eschew:

- Generics are limited. Maybe I'm missing something, but I doubt I'll be using generics as they are very extensively at all. If we could make generic types that would be something I could see myself using more.

- Embedding. It's rare I find a use for that.

- `defer`, honestly.

Re: Ask HN: What do you like/dislike about Golang?

#63

Post by dijit »

cratermoon wrote: post #56
dijit wrote: post #46

I'm a sysadmin type, so take this with a grain of salt. Like: - Compiled and can be run as a scripting language. - Easy to learn, quite simple to use (even concurrency!) - Cross compilation is an environment variable setting. - Fast compilation, though apparently this gets worse with reflection and generics (and it's not that important to me honestly) Dislike: - The opinionated build/dependency system, which sort of…

I love case-based visibility. I don't have to look at any declaration beyond the name to know if I can use the identifier outside of the package it's declared in. In most other languages case is just convention and visibility is determined by another keyword. Yes, I know programmers who came from a Java or C# background who continue to use naming conventions from those languages, to their detriment. I don't blame Go…

To each their own, it doesn’t sit well with me and I got used to `grep -rE ‘^pub’ ` to lazily get an idea of what is available to me.

Glad it works for you though, it’s not likely to change with my little whinge. :)

Re: Ask HN: What do you like/dislike about Golang?

#64

Post by jolmg »

cratermoon wrote: post #59
jolmg wrote: post #30

Earlier quoted context omitted.

> For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint. What do you mean? C, C++, D, Rust, Haskell, and Common Lisp seem to be capable of static linking. (Admittedly Common Lisp seems to require a fork of SBCL that was written about last year, but still)

> that can fetch from a HTTPS endpoint. Seems like a lot of replies are glossing over that clause. How many of those other languages can do that in a fully static binary that runs on (almost) any system that can read and launch that executable?

It's glossed over because it's trivial, isn't it? Just statically link libcurl through a binding. And at least Haskell also has Haskell-implemented HTTP and TLS libraries. There's even options.

Re: Ask HN: What do you like/dislike about Golang?

#65

Post by cratermoon »

abdusco wrote: post #28
ta3411 wrote: post #4

Love: - Ecosystem - Clean code - Single executable file Dislike: - Pointers -- maybe I am still getting the hang of it. But I feel like pointers throw off a lot of beginner programmers. Would love some practical advice here

> pointers Stick with pass-by-value and non-pointer receivers. Use pointers only if you have to.

I worked with one team who deliberately chose pointer receivers for everything. Their reasoning? The compiler can't know if the receiver for the call you are making will be nil at run time, so it doesn't complain.

Yes, they literally chose to subject themselves to runtime panics to silence the compiler.

Re: Ask HN: What do you like/dislike about Golang?

#66

Post by closeparen »

brian_rak wrote: post #35

Like: The package and build system is amazing and just works. Simple, yet intuitive and powerful with the introduction of modules. It's hard to quantify the number of hours I've saved over other tools hunting down build/linker/dependency management issues. Dislike: Error handling feels extremely verbose. I like the design choice to return errors explicitly, but it feels like there needs to be a return-if-error syntac…

Having worked with Go from the days of vendoring, to Glide, to Dep, it is really amazing to see Go turn its greatest weakness into one of its greatest strengths and most-loved features. It was worth the wait. Here’s hoping the rest of my gripes follow a similar arc.

Re: Ask HN: What do you like/dislike about Golang?

#67

Post by jolmg »

joshuak wrote: post #60
jolmg wrote: post #51

Earlier quoted context omitted.

You're not replying to the same person. In a separate comment, I asked for a clarification on that specific part of their comment. The other pros, they're not part of what I asked about. In the comment I replied to you, I'm just stating that you're bringing up something that's not in discussion.

Sorry for the misattribution, my mistake. Nevertheless, the fact remains that https is a part of the standard library and one of the elements that the op finds unique about Go. It is unambiguously part of the conversation, and the ostensibly negative comment that focuses on static linking is missing the point. But I didn't even make the assumption that I was right on that understanding. I simply asked for more detail…

> https is a part of the standard library and one of the elements that the op finds unique about Go.

Where do they say that it being part of the standard library is unique? I don't even see the words "standard library" mentioned.

EDIT: Look, this back and forth seems kind of pointless. This started with a statement about Go being unique for being able to be statically linked and talk HTTPS. If a language can be linked to compiled libraries, static or not, it's surely able to at least use libcurl, so I and the other commenter you replied to took it as Go is unique for being able to link statically. I assumed they meant, ignoring C/C++, static linking is rare, which I found interesting. I found other languages and asked for clarification. That's all.

Re: Ask HN: What do you like/dislike about Golang?

#68

Post by bheadmaster »

liampulles wrote: post #53
Winsaucerer wrote: post #34

Earlier quoted context omitted.

Good list. Regarding (4) Implicit interfaces -- to me, it's implicit interfaces that feel wrong :) Something having a method with a particular signature doesn't seem to me to be any kind of promise that it's intended to be used for the interface that expects that method. 'implements X', is a clear statement that yes, this method is made just for that specific interface. But this is just academic. I've never actually…

Here's what I do: ``` type Doer interface { Do() error } type CanDoer struct{} var _ Doer = &CanDoer{} // This ``` If CanDoer does not implement Doer, it will fail to compile, and you can quickly see what you need to do to fix.

I think the question is more in lines of "How do I know that CanDoer does what I expect of Doer to do, semantically?". In which case, it's impossible to know for sure.

For example, I could create a type with a `Read([]byte) (int, error)` method that doesn't conform to the `io.Reader` expected behavior (e.g. reads from the byte array and returns an int if byte array contains a numeric string), yet I'd be able to pass it as an argument to a function that accepts `io.Reader` - the type system won't stop me, but the behavior will be broken.

However, in practice, writing erroneous implementations of common interfaces is uncommon. Naming conventions are really important in Go, so the only way to abuse type system in this way is to abuse the naming conventions, which is already considered bad practice in any sane programming language.

Re: Ask HN: What do you like/dislike about Golang?

#69

Post by joshuak »

jolmg wrote: post #64
cratermoon wrote: post #59

Earlier quoted context omitted.

> that can fetch from a HTTPS endpoint. Seems like a lot of replies are glossing over that clause. How many of those other languages can do that in a fully static binary that runs on (almost) any system that can read and launch that executable?

It's glossed over because it's trivial, isn't it? Just statically link libcurl through a binding. And at least Haskell also has Haskell-implemented HTTP and TLS libraries. There's even options.

Then why not assume it is the static linking that is trivial? Isolated each item is trivial in some context, its the exclusive set that is non-trivial, or at least uncommon.

The fact https is included in the standard library means that you can give a new user a hello world tutorial that includes producing a web server. It's a huge boon to productivity in a programming language to have a default path for such libraries.

I also work in C++, and it is infuriating the amount of time that must be spent sorting out the correct libraries for all the various aspects of an application one is not inclined to write themselves. People who don't fully grok the Go ecosystem overlook this cost when they claim that you can do the same thing in some other language. What they are missing in the subtext is the fundamental quality of life improvement.

Re: Ask HN: What do you like/dislike about Golang?

#70

Post by joshuak »

jolmg wrote: post #67
joshuak wrote: post #60

Earlier quoted context omitted.

Sorry for the misattribution, my mistake. Nevertheless, the fact remains that https is a part of the standard library and one of the elements that the op finds unique about Go. It is unambiguously part of the conversation, and the ostensibly negative comment that focuses on static linking is missing the point. But I didn't even make the assumption that I was right on that understanding. I simply asked for more detail…

> https is a part of the standard library and one of the elements that the op finds unique about Go. Where do they say that it being part of the standard library is unique? I don't even see the words "standard library" mentioned. EDIT: Look, this back and forth seems kind of pointless. This started with a statement about Go being unique for being able to be statically linked and talk HTTPS. If a language can be linke…

I just addressed this question more directly on your other comment.

I do not agree that it is incumbent upon a speaker to anticipate the listeners knowledge, so I do not think it is a reasonable expectation that every qualifier be included. It's simply not practical. But I do think this is an interesting conversation you bring up.

Post reply on HN