Honestly Golang is not hard to learn, compared to other typed languages like Rust.

I think it depends on personal mental models. I found rust easier to get to grips with because it was more straightforward for the way I thought, whereas with Go I struggled with a lot of things that felt funky to me.

I fully agree that Go is a simpler language up front though at the syntax level.

I found C++ template meta-programming easier to learn than Rust. The only thing new to learn in Go was Go-routines. Followed by a scan of Effective Go, a single page of "gotchas" and one can immediately churn out software. Never found a language/stdlib so easy to start coding in.

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.

I think you probably didn’t spend enough time with Go, it is objectively much easier to learn because there is no borrow checker, no generics, no macros, etc.

I've already addressed that the language is simpler, but that doesn't always translate to easier to learn.

If the level of "learned a language" is just being able to write code then Go is easy. But writing an app and dealing with all of Go's oddities made it much more cumbersome for me.

Took me maybe two days to feel comfortable rewriting one of my bigger projects from Python to Go. Absolutely wonderful language.

Why compare a low level language to a high level one? Of course one will be more complex, because the GC takes many of the details out of the picture, reducing the essential complexity of the problem domain.