←back to thread

634 points david927 | 1 comments | | HN request time: 0.24s | source

What are you working on? Any new ideas that you're thinking about?
1. steve_adams_86 ◴[] No.41349253[source]
I’m writing a series on how to understand golang if you’re an experienced TypeScript developer.

I’ve worked with several teams now who wanted to adopt Go for the backend, but the team’s only extensive type system experience is in TypeScript. They tended to hit very similar pitfalls and want to coerce the type system to behave like what they’re familiar with, and inevitably they wound up with inflexible and error-prone architecture.

They also failed to accomplish any kind of holistic, 30,000ft view architecture because implementations were too often sent off the rails by not understanding the language deeply enough. That was often in part due to type system confusion inherent to how Go implements certain data structures (particularly slices), which leads to the sprawling repetitive Go code people dislike so much.

I did all of this too, so I feel like my insight and experience would be valuable to share. I actually wrote 90% of it last year and felt like a goof, like, ahhh what am I doing obviously everyone else figured out Go faster than I did and this writing is just telling people how incompetent I am. Haha. But then I worked on another project and the situation was exactly the same. I actually used my draft content to help the team understand how I see the problem, and how to get past the mental traps that they were in.

Fundamentally it comes down to “learn the type system/language properly”, but it’s not quite so blatant or unhelpful. One of the problems with TypeScript methodologies is that they’re so ridiculously flexible, but go is not at all in the same ways, yet they have just enough superficially in common to trick you into thinking otherwise.

So, my series essentially elucidates the similarities, differences, and what’s totally absent in Go from the bottom to the top. It’s interesting because they really are remarkably similar in some ways, which is precisely why it can trip newcomers up. Knowing why that’s a trap makes you a far, far better Go developer. Along the way it also reveals details about TypeScript that some people might not be fully aware of (at least several in the team I shared the drafts with said so), which could be helpful.

I mostly need to muster the courage to hit publish now. My confidence has taken a beating in the last year or so!