I'm now starting to look at the Go language seriously, whereas before I just thought it was an "Indy" language. In the past month, I've had the chance to work with a team that uses Go, which led me to read up on it. I stumbled upon one of its core ideas: Go doesn't have "async" programming (it has green threads—logical threads that handle concurrency via software through context switching). But Go is actually an asynchronous language by default! (It's comparable to every single function in Go using async/await.) The interesting part is that Go makes all the code look synchronous (but it handles the async parts where needed automatically). Personally, I really like this code style, but people who haven't read the specs might misunderstand and think Go is a single-threaded application, much like JS or Python.
If anyone has tried Haskell's IO monad, you'll find it's the same concept: you wrap a function (whether sync or async) with an IO type, and it ultimately makes the code look synchronous even though it can be both sync and async. In the past, I tried to apply this concept to several languages (C#, F#, TypeScript) but gave up because it involved a lot of boilerplate, and the resulting syntax was very "alien" (for anyone who wants to try the IO monad with JS/TS, check out https://effect.website/). So I never used it seriously. But Go embeds this idea through Go routines, whether by coincidence or not.
Another thing that made me uninterested in Go before: over ten years ago, I read about the language's origin, wondering why it was designed to be so "indy." I remember one interview quote from a designer: "Go is a language designed for junior developers to help them catch up with a codebase quickly." This idea led Go to cut out many abstract concepts (even generic types!). I had tried Go 2-3 times before but got annoyed because the lack of abstract ideas, especially generics, resulted in a lot of code duplication.
But recently, I had the chance to manage a team of Chula graduates (honors, new grads). The team uses C++, but they were using it at a very basic level, and some didn't understand core concepts like RAII. (Oh, and this made me go back and read the C++11 specs and discover that C++ has had the 'move' concept for over a decade! At first, I thought Rust introduced this idea.)
So I set up a 3-hour course to teach them about C++ memory pitfalls and RAII and found that... 3 hours was not nearly enough. And honestly, to use this stuff correctly, it takes months of practice and understanding, especially since C++ has so many nuances if you want to write truly idiomatic code.
It was only this past month that I finally had an "aha" moment about the Go designer's words. Go wants devs to get up to speed quickly while still remaining low-level enough to write system programming—even though it has mostly become an application language now.
Top comments (0)