Why I’m Frustrated with Go
1–10 of 233 posts
Re: Why I’m Frustrated with Go
#2Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it provides the tools to add as much convenience as needed on a case-by-case basis. I recently ported a 7kloc Go codebase to C++ and wrote down some of my impressions here: https://github.com/andreas-gone-wild/blog/blob/master/rewrit...
Re: Why I’m Frustrated with Go
#3Worth reading the comments where someone points out a much simpler and more elegant solution, although it's still not an ideal situation.
As noted in the post, generics could solve this, so I'm looking forward to Go 2 if indeed generics is included. There's a few QOL issues I'd like to see addressed in 2 which would make Go a lot nicer to work with, and I say that as someone who spends most of their time working on Go codebases.
Re: Why I’m Frustrated with Go
#4What is the perfect language?
Re: Why I’m Frustrated with Go
#5Go contains many good ideas that may be carried over to more pragmatic languages. Using it for anything beyond simple, self-contained command-line tools and network servers never really worked out for me. And that makes sense, since it was explicitly designed to scale over groups of inexperienced developers at any cost; the opposite of my needs. Modern C++ runs circles around Go for more complex software, and it prov…
Your blog entry you're referring to contains surprisingly little information to support the arguments mentioned in your posts. Maybe if you provided some specific example of why a given fragment of code works better in C++ rather than Go, we could have some interesting discussion.
Re: Why I’m Frustrated with Go
#6So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go.
Ended up with this. [0]
Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib.
I still appreciate many go tools and the cross platform single binaries that work great on Solaris/Illumos. But in many cases the strong opinions of Go authors really stand in the way of getting work done.
Re: Why I’m Frustrated with Go
#7I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages.
However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.
Re: Why I’m Frustrated with Go
#8I personally tend to choose Go for newer projects as I'm looking for the efficiency of C and safety/elegance of more "modern" languages. However, I always keep an eye on D and Nim. It seems these are the only two languages that can compete with Go in both above aspects.
Go is not in the league of C for efficiency though? Very different kinds of languages...
Re: Why I’m Frustrated with Go
#9OT: I recently learned that the newer ETH client Parity is written in Rust and much faster than the older Go-based Geth ETH client.
Guess it is due to a different architecture and design which makes the client faster (e.g. chaindata is smaller) but does anyone know why they chose Rust instead of Go for the Parity client?
Re: Why I’m Frustrated with Go
#10What is the perfect language?
Let's just say it can't have a type-system limited to not understanding generics.