Live data from Hacker News

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

news.ycombinator.com

51–60 of 111 posts

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

#51
post #42
post #31

Earlier quoted context omitted.

fwsgonzo never said anything about it being in the standard library.

Well that's not on him man. You are the one calling him out for being unaware of static linking, when you don't even seem to understand the full set of pros he listed in his first sentience.

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.

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

#52
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…

nit: One can use pointer values for marking JSON fields as optional, and thus distinguish between the 0 and nil case.

I felt similar to you initially about the difference between 0 and Null/None - I have to say that once I started modelling my APIs so that these two cases could be treated equivalently, I think the quality of my APIs improved.

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

#53

1. Static linking. I'm astonished by how many languages expect the end user to install dependencies/runtime themselves, and something about it feels very impure . 2. The "go" keyword (and the whole goroutine system underneath it). Threads are clunky, somewhat unportable and generally unscalable. Goroutines just feel right. 3. Ability to use multiple major versions of a library. Diamond dependencies are an unsolved pr…

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.

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

#54
My big complaint with Golang is the way they (don't) handle nulls.

Golang treats null as a memory initialization problem, while ignoring its semantic use.

You still encounter nulls when interacting with external systems, and Golang has inconsistent ways of handling them. From memory (it's been a while):

- Nullable DB columns return a struct with the value, and a boolean for whether the value is actually the value, or a placeholder for null

- Requesting a non-existent query parameter from an inbound HTTP request returns an empty string. That's "fun" to debug.

- Decoding a JSON object with a null value omits the key+value completely. There's no way to tell the key was ever present. This is a problem when you don't control the originator of the JSON.

- I think maybe sometimes null pointers are used?

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

#55
Go lacks things I decided I must have, including Sum types and a string type which doesn't just think "string" is a fancy word for "Some bytes". So I no longer use it in anger. As a result these judgements are perhaps a year or two out of date:

I don't like the error handling, and I don't like that they basically punted the hard problem when it comes to data races.

I do like the broad range of stuff in the standard library, and I like how slim its garbage collector and runtime in general feel under use. Start-up time in particular is pretty good for a language with garbage collection.

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

#56
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 for their problems, though.

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

#57
post #31

Earlier quoted context omitted.

fwsgonzo never said anything about it being in the standard library.

The convenience of building network clients in Go is heavily implied. Strictly you can say that assembly code can make standalone binary HTTPS endpoints, but that would be a bit silly. To be sure you might write such a program in assembly, but you’d be doing it for fun or aesthetics. No engineering manager would commission such a thing. Though of course this is inviting the trading maniacs to tell stories of hyper op…

Ok, but it's not either Go or assembly. There's other languages. I listed 6 in a close-by comment. I wonder if Go's much more convenient at network clients than, say, Haskell or Common Lisp.

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

#58
post #31

Earlier quoted context omitted.

fwsgonzo never said anything about it being in the standard library.

The convenience of building network clients in Go is heavily implied. Strictly you can say that assembly code can make standalone binary HTTPS endpoints, but that would be a bit silly. To be sure you might write such a program in assembly, but you’d be doing it for fun or aesthetics. No engineering manager would commission such a thing. Though of course this is inviting the trading maniacs to tell stories of hyper op…

HTTP doesn’t need to be in stdlib. Java and Python each had one but everyone long since switched to third-party reimplementations with better APIs. And HTTP will probably be replaced over the next twenty years, like FTP and Sun RPC and CORBA before it.

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

#59
post #30
post #7

For me Go is unique in that it can produce a fully static binary that can fetch from a HTTPS endpoint. It also supports many architectures. On top of that the package system and it's just way more convenient to use than other languages. Easy to learn, easy to put somewhere in practice. Not every program has to be 100% safe and delivering 2M req/s. Sometimes you just want to build a program once and ship it. What othe…

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

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

#60
post #51
post #42

Earlier quoted context omitted.

Well that's not on him man. You are the one calling him out for being unaware of static linking, when you don't even seem to understand the full set of pros he listed in his first sentience.

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. Which was so that either I would learn something new, or the parent would.

Post reply on HN