Leaning go. I like it. Any thoughts?

It's a nice language to learn on the side for interest - lots of interesting features on the language level such as goroutines which are only now being considered in a lot of other, more popular languages.

Unfortunately it's not used much outside of Google however, so it's a bit of a niche one to learn if you're doing so for employment purposes.

I like that it can be statically compiled, allows me to create minimal docker images with only 1 binary

@SevenDeadlyBugs My wording probably came off a bit strong. There's a few big companies (and lots of smaller ones) that use it, but those who do so tend not to use it ubiquitously, and it's certainly not a widespread language as far as these things go (no pun intended.)

I'm sure there's plenty of people who have made a killing in industry as Go devs, but it's still a language choice I would consider as a bit limiting in most areas. (Heck, if you happen to be in an area where there's a plethora of jobs open for it, knock yourself out!)

@AlmondSauce Yeah, I like how it handles things that should normally be handled asynchronously with the scheduler. As for job opportunities I'll stick with what I do. As I'm leaning towards automation and DevOps Go seems like a nice language though.

@alexbrooklyn Is that always the case? No one off cases?

@ScriptCoded Not always, only when it's statically compiled and doesn't require any other binaries

I really hated its dependency management and the compiler messages are horrible. It also forces me to put my project in a "go" directory, and all other dependencies need to be somewhere in that tree for go to be able to find dependencies. Also its error management is only based on strings.. I don't know, I feel like this would just end up in bugfixing more than developing.

I say Go for it...

@simulate As for deps I think you can set the GOPATH

@ScriptCoded I fiddled around with it for hours, but I think all go code has to be under GO_PATH so I just left it the way it was.

@SevenDeadlyBugs Yes we switched to that now, but then there are Go Modules version 1.11 and 1.13 or something, which are different or something? The documentation is minimal and so are the error messages by go tools. It felt just extremely unnecessarily complicated and messy. If go get could give a bit more information about what the problem was except of "could not find package", I would have been done much quicker.
Every language has its details you need to worry about, but Go just seemed to be unnecessarily primitive in an unhelpful way.

I really like Go, the syntax is a bit weird but I really enjoy it.

@simulate personally one of the only big things that Irk me about Go is the “Go directory”

@Bubbles I like the language otherwise.. I think object orientation is very simple and natural, and the Syntax is also very consise, which is neat sometimes. Also Go routines are a useful standard feature.

My biggest con of Go is definitely the error handling. It seems to be encouraged to use if blocks to check if an error occurred. Also there is excessive use of nil references, which means you have to be extremely cautious all the time and if you forget one error check once, your program crashes at runtime, of course in front of the client. No thank you.

Don't read reddit opinions on go. They're idiots. That's it.

@simulate well go doesn’t use OOP it’s more like C and depends on Structs but I completely agree with the error handling criticism it should be improved

@Nanos I don't think I wrote follow along 🙈

@Bubbles Well Go does have inheritance and methods and interfaces and such. It just doesn't force you to use objects for everything like Java.

Rust.

@Root So much yes