Live data from Hacker News

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

news.ycombinator.com

81–90 of 111 posts

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

#81

Earlier quoted context omitted.

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…

Yep, this is exactly what I had in mind.

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

#82
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)

In Go that quote is literally true. If you do nothing on a new computer but download Go you can immediately build a statically linked application that can fetch from an https endpoint. There are no implied additional steps.

I don't believe this can be said of the other languages. I know that C, C++ and Rust do not include https in their standard libraries, so while they can be made to compile statically and use a library that provides https functionality, those are additional steps that must be taken by the developer, and it is the responsibility of the developer to choose the correct source and version of the https library to use. This will also include understanding and setting any additional compiler flags that the library may require, setting any optional defines or other library configuration settings and making the appropriate changes for every platform they wish to build for.

Go requires none of this.

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

#84
Go is the best.

Go’s culture of minimalism, pragmatism, and just get things done is also amazing.

What could be better:

- Even faster runtime.

- Even more efficient garbage collector.

- Sum types would have been nice to have.

- Structured logging would be great to have.

- Structured error would be nice as well.

- Cgo could be better.

- Memory arena would be great for database applications.

- Buffered channel is not as useful as I thought.

- Better channel performance would be nice.

- Closing a channel is not safe and easy to make a mistake doing it.

- Embedding could be improved.

- Standard library needs a lot more data structures.

- It needs a tuple data structure so that users can return (result, result2, error). If this exists, we can create a nice chainable libraries.

- gopls automatically generating test struct as a second implementation of an interface would be super nice to have.

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

#85

Below are my current feelings having worked with it as my primary language over the last 16 months. My previous 7 years of development focused on Java, C++, Python, and JavaScript. Like: - Standard Tooling: formatting coverage, dependencies, BIN install, versioning, vendoring all done in Go CLI - Opinionated, minimal design: often I feel like there are fewer ways to do things in Go than in other languages. - Readabil…

Lack of a set type is just bizarre to me

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

#86

Earlier quoted context omitted.

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…

How do you ensure that a language with explicit interfaces implements what the expected behavior is?

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

#87
post #18

What I like, It is a nice language had it been released in the mid-90's, following the footsteps of Oberon and Limbo. What I dislike, Being designed a decade later ignoring everything that happened in mainstream computing since Oberon and Limbo came to be, then adopting features that weren't properly backed in from the get go.

Can you elaborate more on what was ignored? For one, I think it's mind blowing that they didn't have a good system for dependency management in place from the get-go. Things are pretty good now with go modules but it's like they never even heard of languages like Python and the unholy mess that package management was (and still is to some extent) with Python.

The whole generics drama.

The const/type declaration dance to this day, to declare enumerations, even Algol could do better.

Error handling based on comparing strings, to find out the real cause.

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

#88

Earlier quoted context omitted.

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…

How do you ensure that a language with explicit interfaces implements what the expected behavior is?

It is a kind of honour system, the developer has explicitly stated, yes I want to comply to interface XYZ, instead of doing it by accident and due to copy-paste error passing the wrong one, ensuring a couple of debugging hours tracking down where the error lies in code that compiles without any issues.

Typical debugging problem in dynamic languages.

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

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

Not really: it still can't tell the difference between a null value and a missing field which is different when working with APIs as a missing field usually means "don't touch it" while null means "nullify it"

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

#90
Like:

- Simple concise syntax - Great std lib - Most of the times it's easy to do the right thing

Dislike:

- No concept of NULL values and what it means especially when dealing with JSON - Limited handling of TCP connections life-cycle

I'll add something which is not a language issue per se but I had to deal with a lot: often new devs to Go will try to force certain mental models acquired with other languages/frameworks onto Go and that makes for some terrible Go code.

Post reply on HN