Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Could you share which things those were? I mean error handling is a common issue people first raise an eyebrow at, but other than that I've found it a really straightforward language to use (coming from Java and JS myself, a bit of obj-c/swift, some scala in between).



Error handling is a big one for me. It just seems illogical that it's so easily skipped.

There's a lot of magic in the APIs. This blog post covered it but I hit quite a few of them. I get why they're appealing but I mentally feel the API is wrong which causes friction when I use them. https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

I find I don't agree with the package and versioning story either. Publicness based on casing, the way dependencies are declared in the source code.

It's lots of little things that, while I can see the appeal, they create friction with how I like to work.

My background is somewhat similar, Python, C++, ObjC, Swift, Java/Kotlin, JS, C#,GLSL etc...

In particular, I've used some APIs in the past that were very similar to Go and been bitten by it. E.g defining dependencies in the source quickly became an exercise in frustration when dealing with multiple packages needing updates for a shared runtime. It's not an issue people would hit when writing microservices or CLI tools, but it hit hard for working on graphics tools where everything runs in the same runtime. I know go has ways around it though but still not a fan.


I wonder if the poipnt you're making about dependency conflicts is the diamond dependency problem. rsc wrote a very detailed post about the rationale here, and how go versioning solves diamond dependencies, which you might find interesting: https://research.swtch.com/vgo-principles


Thanks, I'll give that a read.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: