Golang to me is a great runtime and very poor language. I could maybe get used to the C pointer-like syntax and to half of my code checking if err != nil, but the lack of classes is a step too far. The Golang idiomatic approach is to have a sprawling set of microservices talking to each other over the network, to manage complexity instead of having classes. This makes sense for things like systems agents (eg K8) but doesn't make sense for most applications because it complicates the development experience unnecessarily and monoliths are also easier to debug.
I would not use Golang for a big codebase with lots of business logic. Golang has not made a dent in Java usage at big companies, no large company is going to try replacing their Java codebases with Golang because there's no benefit, Java is almost as fast as Golang and has classes and actually has a richer set of concurrency primitives.
The solution to bad abstractions it not to make it very difficult to create abstractions at all. For systems code I think it's fine but for application code you probably want some abstractions or else it's very hard to scale a codebase.
It’s really not though. Plenty of systems are built in Go, Erlang etc that do not have the architectual monstrosities which commonly show up in object-oriented code, especially when a Java or C# expert beginner has been let loose.
Microservices are entirely unrelated to classes and in no way endemic to go.
Go’s lack of inheritance is one of its bolder decisions and I think has been proven entirely correct in use.
Instead of the incidental complexity encouraged by pointless inheritance hierarchies we go back to structure which bundle data and behaviour and can compose them instead.
Favouring composition over inheritance is not a new idea nor did it come from the authors of Go.
Also the author of Java (Gosling) disagrees with you.
Microservices in Golang are definitely related to classes due to the ergonomic aspects of a language. It takes a lot of discipline in Golang not to end up with huge flat functions. Golang services are easier to reason about when they are small due to the lack of abstractions, also Golang is very quick to compile, so its natural to just add services to extend functionality. Code re-use is just a lot of work in Golang. Golang is not monolith friendly IMO.
There are only two political systems at the end of the day: authoritarianism (everyone knows who is in charge) and oligarchy. Populism, in a liberal democracy, is basically authoritarianism-lite representing the interests of a particular faction of oligarchs. There's no "populism" in China, that's an American & European invention. Populism is ugly but it's a useful tool that can get things done in an oligarchy.
What kind of codebases do you work on if you don't mind me asking?
I've found a huge boost from using AI to deal with APIs (databases, k8s, aws, ...) but less so on large codebases that needed conceptual improvements. But at worst, i'm getting more than 10% benefit, just cause the AI's can read files so quickly and answer questions and propose reasonable ideas.
Disclaimer: I'm the founder. Reducto does cool stuff on post processing (and other input formats), but some people have told me Mathpix is better at just getting data out of PDFs accurately.
I tend to agree with this. These days I usually use LLMs to learn about something new or to help me generate client code for common APIs (especially boto3 these days). I tried Windsurf to help me make basic changes to my docker compose files, but when it couldn't even do that correctly, I lost a little enthusiasm. I'm sure it can build a working prototype of a small web app but that's not enough for me.
For me LLMs are a game changer for devops (API knowledge is way less important now that it's even been) but I'm still doing copy pasting from ChatGPT, however primitive it may seem.
Fundamentally I don't think it's a good idea to outsource your thinking to a bot unless it's truly better than you at long term decision making. If you're still the decision maker, then you probably want to make the final call as to what the interfaces should look like. I've definitely had good experiences carefully defining object oriented interfaces (eg for interfacing with AWS) and having LLMs fill in the implementation details but I'm not sure that's "vibe coding" per se.
I had a similar experience as the author. I've found found that cursor / copilot are FANTASTIC at "smart autocomplete", or "write a (small function that does this)" and quick viral prototypes.
But after I got a week into my LLM-led code base, it became clear it was all spaghetti code and progress ground to a halt.
This article is a perfect snapshot of the state of the art. It might improve in the future, but this is where it is in May 2025.
Mathpix is ace. That’s the best results I got so far for scientific papers and reports. It understands the layout of complex documents very well, it’s quite impressive. Equations are perfect, figures extraction works well.
There are a few annoying issues, but overall I am very happy with it.
I had a billing issue at the beginning. It was resolved very nicely but I try to be careful and I monitor the bill a bit more than I would like.
Actually my main remaining technical issue is conversion to standard Markdown for use in a data processing pipeline that has issues with the Mathpix dialect. Ideally I’d do it on a computer that is airgaped for security reasons. But I haven’t found a very good way of doing it because the Python library wanted to check my API key.
A problem I have and that is not really Mathpix’s fault is that I don’t really know how to store the figures pictures to keep them with the text in a convenient way. I haven’t found a very satisfying strategy.
Check out mathpix.com we have a hybrid approach towards OCR that features accurate layout understanding (with accurate bounding boxes) plus accurate OCR outputs.
I would not use Golang for a big codebase with lots of business logic. Golang has not made a dent in Java usage at big companies, no large company is going to try replacing their Java codebases with Golang because there's no benefit, Java is almost as fast as Golang and has classes and actually has a richer set of concurrency primitives.