> Readability. I always found the Go code I encountered quite easy to read and understand, both our code and external code. Some of the C++ I encountered, in contrast, took hours to fully comprehend. Go also forced me to write readable code: the language makes it impossible to think something like “hey, the >8=3 operator in this obscure paper on ouroboromorphic sapphotriplets could save me 10 lines of code, I’d better include it. My coworkers won’t have trouble understanding it as the meaning is clearly expressed in the type signature: (PrimMonad W, PoshFunctor Y, ReichsLens S) => W Y S ((I -> W) -> Y) -> G -> Bool”.<p>This sentence is gold J
Coming from JVM languages, it drives me nuts that I can't .map/.filter/.foreach/.reduce etc. my collections, especially with something like streams/sequences. That's where you really notice the lack of generics if you're used to this sort of programming.
I personally love Rust and think Rust is the future for C and C++, and use it professionally. But Go is simple, fun, fast, and easy to read and frankly more approachable by the people many companies can afford to hire.<p>I view language choice as a line. If I need to build big, or build niche, or build fast, I use Rust. But if it’s general purpose I use Go. I can write Go faster than I can write Python because the type system gives me a fast feedback loop and the language is simple and builds in the common case building blocks. I can get better performance and understand my app better than with the JVM because it’s compiled ahead of time and I already know the ins and outs of Linux. There is no black box JVM that consumes resources while idling.<p>Go has advanced the state of formatting, documentation, and revitalized the Unix philosophy of building small, focused pieces without getting caught in the clouds over abstracting.<p>If you are currently using a Python, Java, C#, or JavaScript, Go is better. Just don’t post angrily to your blog until you’ve written Go while also embracing its philisophy and taking the time to understand the authors intentions.
Switched from Python to Go about 2 years ago. If you need to build performant APIs with a small team there is nothing that comes close. You get the productivity of something like Python with the performance of C++. Or at least very close to it in both cases. (<a href="https://getstream.io/blog/switched-python-go/" rel="nofollow">https://getstream.io/blog/switched-python-go/</a>)<p>The lack of generics hasn't bothered me so far. You just find different solutions to the problem. Composition, interfaces, or if all else fails an empty interface{}. It's rare to really not be able to work around it. It does make it near impossible to build reusable and performant data structures in Go though. (say that you want to build your own heap or list, hashtable etc.) So that's annoying, but something that you rarely run into.<p>Bigger issue is that GO modules are still not ready for production since the ecosystem didn't catch up: <a href="https://github.com/golang/go/issues/24661" rel="nofollow">https://github.com/golang/go/issues/24661</a>
This HN item links to the blog's front page. The actual article is at <a href="https://togototo.wordpress.com/2015/03/07/fulfilling-a-pikedream-the-ups-of-downs-of-porting-50k-lines-of-c-to-go/" rel="nofollow">https://togototo.wordpress.com/2015/03/07/fulfilling-a-piked...</a>
For anyone bothered by Go's simplistic error handling, a menu of <i>Requirements to Consider for Go 2 Error Handling</i>:<p><a href="https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a" rel="nofollow">https://gist.github.com/networkimprov/961c9caa2631ad3b95413f...</a><p>See also the Go 2 Draft Design feedback wiki:<p><a href="https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback" rel="nofollow">https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback</a>
After switching to ML languages for most development tasks, I don’t think I could face using a language with so few features.<p>Is most of the hype from a dev ops perspective? Go looks tiresome to program in.
Discussed at the time: <a href="https://news.ycombinator.com/item?id=9161366" rel="nofollow">https://news.ycombinator.com/item?id=9161366</a>
> he expected the language to be adopted by C++ programmers, a prediction that hasn’t been realised<p>I respect go (and its runtime) a lot, but one little thing keeps me from using it: the reverse "argument type" ordering (backwards from C++) makes me avoid it. If this were the only language I used, it would be easy, but when switching back and forth, does anyone else find it hard to do?
Link to the article instead of the blog: <a href="https://togototo.wordpress.com/2015/03/07/fulfilling-a-pikedream-the-ups-of-downs-of-porting-50k-lines-of-c-to-go/" rel="nofollow">https://togototo.wordpress.com/2015/03/07/fulfilling-a-piked...</a>
"one of my reasons for getting into programming was the opportunity to get paid to use Emacs".<p>Not a reason for getting into programming that many have, I expect!
Wow, I'm surprised to see the typical "Well, why didn't you just use Rust" comment hasn't been posted.<p>At the end of the day, it sounds like they just had some clunky C++ code that was due for a rewrite anyways (and the author admits as much). If you don't need it to be ultra low latency, some nice abstraction and modularity can already do wonders.<p>I've found Go to be an excellent Java replacement when all is said and done. Great for the vast majority of services you might write. But if you need to do anything lower level or that involves complex type logic you always end up with a clunky solution (and I'm not going to sing any praises for C++ having an elegant solution either).<p>That said, modern C++ (especially 17) can be made to look decently clean and without weird behavior in most cases. Yes, there's always the person that shows up and points out weird edge cases that you can run into but the situation is far, far better than it was years ago. With some good engineering practices in encapsulating low level optimized code you can largely limit the "danger surface" of your codebase.
>> The worse the abstraction that you and your colleagues are likely to use, the better a language is Go<p>I feel the same way about most statically typed languages. They're designed for developers who aren't good at coming up with abstractions. Basically, they're great for junior developers. For senior developers, they just give you more work and slow down progress.<p>On my last project (statically typed language), we had to do a refactoring of a decent portion of the code just because it allowed us to use one interface/type instead of two related interfaces/types (one inheriting from the other). It didn't fix any bugs, make it more maintainable or even change the external behaviour at all.