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…
Ask HN: What do you like/dislike about Golang?
81–90 of 111 posts
Re: Ask HN: What do you like/dislike about Golang?
#82For 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)
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?
#83The answer to both is "it's boring".
Re: Ask HN: What do you like/dislike about Golang?
#84Go’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?
#85Below 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…
Re: Ask HN: What do you like/dislike about Golang?
#86Earlier 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…
Re: Ask HN: What do you like/dislike about Golang?
#87What 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 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?
#88Earlier 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?
Typical debugging problem in dynamic languages.
Re: Ask HN: What do you like/dislike about Golang?
#89I'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?
#90- 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.