Live data from Hacker News

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

news.ycombinator.com

101–110 of 111 posts

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

#101

I migrated my scrapers from Python + BeautifulSoup to Go + Colly and it was a pleasure: the new programs are impressive fast (1/3 of the time) and managing the concurrency and parallelism is a lot easier in Go that messing up with asyncio. Even the dependency management is a pleasure, no need for virtualenv or other tools. If there is something that I don't like it's the serialize/deserialize of JSON objects: you nee…

> you need to know the structure of JSON in advance and define in your struct

You can unmarshal to map[string]any if it’s of any help. You have to cast a lot but it’s sometimes useful.

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

#102
Aside: has anyone read “100 Go Mistakes and How To Avoid Them” [1] and would care to share their takeaways?

After getting back to it after quite some years I’m still conflicted about the language and its tooling. It’s a frustratingly (and seemingly) primitive/simple language but also a very productive one. I personally don’t love golang but it’s a great tool “for the common programmer / worker”.

The unix philosophy is baked in without the excitement (to me). That’s OK.

Also the stdlib has similarly great / lacking characteristics. It’s strong but then often missing basic functionality that you just don’t want to maintain yourself any more (e.g. try to do a unix like sort / unique on a slice of strings - afaik only lexicographical sorting in there).

I would say that the main driver for my rekindled interest in the language stems from its current Lingua-Franca aspects for “higher level systems programming”. I’m thinking Kubernetes and Terraform here for example.

In many ways but especially in this one it’s similar to Python actually - which I also don’t love at all - but which FWIW found its niche as the current go-to scientific computing and machine learning language / ecosystem.

[1] https://www.manning.com/books/100-go-mistakes-and-how-to-avo...

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

#103
post #101

I migrated my scrapers from Python + BeautifulSoup to Go + Colly and it was a pleasure: the new programs are impressive fast (1/3 of the time) and managing the concurrency and parallelism is a lot easier in Go that messing up with asyncio. Even the dependency management is a pleasure, no need for virtualenv or other tools. If there is something that I don't like it's the serialize/deserialize of JSON objects: you nee…

> you need to know the structure of JSON in advance and define in your struct You can unmarshal to map[string]any if it’s of any help. You have to cast a lot but it’s sometimes useful.

Thank you for the suggestion, but yes, I need to cast a lot.

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

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

[deleted]

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

#105
post #23

Like: - Ecosystem - Static linking - goroutines - small and light runtime - fast compilation speed Dislike: - missing shorthand lambda functions, making functional programming very painful - typed nils - billion dollar mistake (lack of non-nullable types) - implicit/automatic copying on value types. Value types as a whole need to be re-thought. - too much error handling boilerplate - unused variables are compiler err…

I forgot about starting with nil and ending up with an interface where every method will immediately panic, yet doesn’t equal nil because it’s carrying a type around. Reminds me of the HHGG box containing “no tea: just like the tea professional hitchhikers don’t carry!”

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

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

I don't even like the concept of visibility--at least as implemented in C++, go, Rust, and a host of others. The whole notion of "getters and setters" just seems like so much pointless boilerplate. Explicitly requiring mutability, as Rust does, is much better for data encapsulation and protection.

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

#107
post #62

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

> If we could make generic types What do you mean by this? Methods?

Generics as currently implemented in go are so limited that you may as well stick with interfaces for anything but trivial boilerplate or textbook data structure/algorithm implementations.

For example, it's currently impossible to define type constraints with user-defined interfaces embedded:

  ```
  // this is legal
  type MyConstraint interface {
    int64 | float
  }

  type SomeAPI interface {
    AMethod() error
  }

  // Nope
  type CantHaveThisConstraint interface {
    int64 | float | SomeAPI
  }

  // NOPE
  func SomeGeneric[T CantHaveThisConstraint](...) {
  }
  ```

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

#108
post #107

Earlier quoted context omitted.

> If we could make generic types What do you mean by this? Methods?

Generics as currently implemented in go are so limited that you may as well stick with interfaces for anything but trivial boilerplate or textbook data structure/algorithm implementations. For example, it's currently impossible to define type constraints with user-defined interfaces embedded: ``` // this is legal type MyConstraint interface { int64 | float } type SomeAPI interface { AMethod() error } // Nope type Can…

It's true that doesn't work because you can't mix types with methods and types with no methods. But that's a far cry from "Go doesn't have generic types" or "may as well stick with interfaces for anything but trivial boilerplate".

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

#109
post #87

Earlier quoted context omitted.

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.

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

I'm not a fan of Go, at all, but credit where due: they did make this slightly better with error wrapping (https://pkg.go.dev/errors#Is). Of course, this doesn't work unless errors are wrapped, instead of blindly concatenated, forcing you to do string matching more often than not. :)

Post reply on HN