[ekidd]

I've written several non-trivial Go programs, the most recent of which was a server that solved substitution ciphers (for use in subtitle OCR).

I tried to write nice idiomatic Go code. And I'm usually pretty good at adapting my brain to strange languages—I've positively enjoyed Haskell, constraint programming in Mozart, distributed functional programming in Elixir, and quite a few other strange things. (To be fair, I never did get comfortable in Prolog.)

And try as I might, every time I write a couple thousand lines of Go, I walk away in frustration. I love so much about the language, but my actual code keeps disappearing under the weight of error handlers, and stupid little iteration/transformation functions that I have to write over and over again thanks to the lack of generics. (Sometimes I get lucky, and an interface fits well.)

This means that every time I wander down a wrong path (and it's possible to wander down quite a few when messing with OCR algorithms), I end up having to tear up more code than I'd like. It's not fun.

Every time I say this, Go programmers say something like, give Go a shot, long enough to realize you really don't need generics as much as you think you do. But after three serious attempts, it's clear that the programs in my head were never meant to be implemented in Go. Which is too bad: It's a nice language in so many ways.

[MetaCosm]

I have OCR in production live written in pure Go. It does OCR on small specific portions of images to get keywords out to be put into a DB (1B+ page scans). We use tesseract for full page scans (when needed, when our OCR fails). But Go was so easy to write, and so fast to get live for small page partials that we wrote it in a few weeks (idea to live, just implementing well known algorithms) to avoid having to deal with tesseract overhead in the average case.

I am curious about specifically where you got bound up -- and how we managed to via ignorance or blind luck avoid these rough patches. Additionally, I am not 100% sure I understand why you refactor cycle is so brutal. That generally is one of the things I enjoy about Go, lightspeed refactor / dev / test cycles.

Good thing no one is asking you to use Go, Haskell is always around (and Elixir, I guess... I am too used to Erlang syntax, Elixir feels like an ill fitting glove) and we need lots of great languages -- and they SHOULD feel different and some shouldn't be a great fit for you.

[mwsherman]

^ This is the right way to critique a language: here’s my experience, here’s what frustrated me, and most importantly, the humility to say that the problem comes down to a mismatch between mental model and implementation tool. More like this please.