3 ms·

In my experience, Go is as simple as you make it and it is easy to learn. You can cover the whole language in a few hours. With anything that simplifies interac

In my experience, Go is as simple as you make it and it is easy to learn. You can cover the whole language in a few hours. With anything that simplifies interacting with the underlying hardware there will be complexity hidden away from you. That's inevitable. Go is no different to any other language in that regard. The hardest part of Go is learning how to effectively use things like goroutines and channels. Slices might catch some noobs out, but at the end of the day it's as simple as saying "a slice is a view on a block of memory", so 2 slices can point at the same data, and changing data with 1 slice can be reflected in the other. Once you realise that a slice doesn't hold values there's no issues. That's simple, I just explained slices in 5 seconds. I think implicit interfaces are amazing. Yes it can be hard to figure out what implements it, but an IDE is used for that. Like you say, Goland is really good. Abuse of interface{} is bad, it's the worse decision that was ever made for the language in my opinion. But I don't think it's that big of a deal in the grand scheme of things. Generics will remove a lot of it's current uses anyway. I write microservices and the only time I have to touch interface{} is when using contexts. It's not for everyone, but people saying "Go isn't simple" are just as bad. You've got to understand people from all sorts of backgrounds have learned Go. For me, I really think it's easy to learn and simple to use. Others might think it's the hardest thing they've ever done.

shp0ngle 6y ago
Ahhh Context. For me, using context and stuffing and retrieving things from it is the most painful part of go. If anything from go should die in a fire, it’s Context - well, the key value storage anyway. The canceling part is fine.
- Philip-J-Fry 6y ago
  Context is really good so long as what you're storing deserves to be there. For example, any UUIDs you generate for request tracing or anything like that. Once you start storing actual request data like users, or session data, etc. then it's a problem. I'm of the opinion that (if you're writing web services) anything related to the request should just be passed to the function using it. Shouldn't be stored on context and passed along 20 middleware handlers. If you need to share state this way then it's a failure of your design. Putting the meat of your business logic in multiple handlers is not the way. A handler is how you get the data into your application, then you can forget about them. But some people don't really understand that and start having authentication middleware, session middleware, user middleware etc. Just pointless complexity.
- henvic 6y ago
  For you the problem is the very fact you're able to pass values through context transparently or that some people abuse it passing all sort of data that should be passed in better ways?
  - shp0ngle 6y ago
    If something is so frequently abused to become normal, it means the design is somehow wrong. Design of context and the key/value storage there is wrong.
gher-shyu3i 6y ago
> Yes it can be hard to figure out what implements it, but an IDE is used for that. Which is ironic given that the golang designers and users tend to shun IDEs and mock that languages like Java rely on them. When in fact, to do anything useful in golang you also need an IDE.

shp0ngle 6y ago

Ahhh Context. For me, using context and stuffing and retrieving things from it is the most painful part of go. If anything from go should die in a fire, it’s Context - well, the key value storage anyway. The canceling part is fine.

Philip-J-Fry 6y ago
Context is really good so long as what you're storing deserves to be there. For example, any UUIDs you generate for request tracing or anything like that. Once you start storing actual request data like users, or session data, etc. then it's a problem. I'm of the opinion that (if you're writing web services) anything related to the request should just be passed to the function using it. Shouldn't be stored on context and passed along 20 middleware handlers. If you need to share state this way then it's a failure of your design. Putting the meat of your business logic in multiple handlers is not the way. A handler is how you get the data into your application, then you can forget about them. But some people don't really understand that and start having authentication middleware, session middleware, user middleware etc. Just pointless complexity.
henvic 6y ago
For you the problem is the very fact you're able to pass values through context transparently or that some people abuse it passing all sort of data that should be passed in better ways?
- shp0ngle 6y ago
  If something is so frequently abused to become normal, it means the design is somehow wrong. Design of context and the key/value storage there is wrong.

gher-shyu3i 6y ago

> Yes it can be hard to figure out what implements it, but an IDE is used for that. Which is ironic given that the golang designers and users tend to shun IDEs and mock that languages like Java rely on them. When in fact, to do anything useful in golang you also need an IDE.