I came to Go from mainly C++, Java, and Python background, and I feel like it's the best of all 3 (to me). It's compiled and really fast (like C++), it has a great set of libraries and community interaction/support (like Java), and it has simple syntax that is clear and quick to understand (like Python).
It's not a perfect language (nothing can ever be), but it's become my favorite to use for back-end web services and even taken over some of my scripting workflow.
I can see it being painful if you're trying to render websites server-side though. That's a bit outside of what it's made for
Use https://github.com/kisielk/errcheck for that.
Or prefer https://staticcheck.io/ for a larger set of checks.
fmt.Println("foo")
I don't see errcheck complaining therehow about (taken from here: (https://www.reddit.com/r/programming/comments/ak305l/goodbye...):
r1, err := fn1()
r2, err = fn2()
if err != nil {
return err
}
err check doesn't complain eitherVSCode is also really good for Go, I was surprised. There are plugins that massively help with testing, syntax checking, error handling, etc. I think it actually catches more issues than GoLand!
I wish we could use more than channels - for me, I often feel like I'm shoehorning them in because there's no support for protected objects (native queues, conditional variables etc).
Perhaps I'm just using them wrong. Sometimes I have to use locks, and I don't think we should be forced to use locks in 2019. We've had better solutions since the 80s.
Absolutely not. Locks/spinlocks are found in pretty much every significantly parallel software project. It is pretty arrogant to criticize almost all software architectures on earth.
Almost all software is programmed with modern languages, which all (imo) have extremely lackluster support for concurrency. It's not a symptom of the programmers, but the tools they work with. Who uses Ada these days?
Locks should only be used when other protection mechanisms are too slow.
Semantically, the critical region protected by a lock is not connected to the lock in any way. This can make debugging races super difficult, and you have to rely on everyone to lock everything at the right point.
Juggling multiple locks in complex concurrent processes is difficult, and prone to bugs.
I struggle to think of where a lock is required, barring the extremely hyperoptimised hot paths within operating systems, or similar applications.
Writing code-generators for everything wasn't fun.
I'd flip what you said and say that most of the people arguing against generics in Go don't have much or any experience with them. Which makes sense because a large number of users came from dynamically typed languages.
Go is actually simpler than PHP as a language, once one understands "explicit" pointers (though PHP does expose pointers for a few things, arrays for instance since they are copied by default).
As for PHP, it's useful IN SPITE of itself, and that's the issue, the language works against the developer and only the tooling, frameworks and rigorous security practices can mitigate its flaws.