I took a brief trip this weekend into goland. Till this point, I’ve
Worked exclusively with dynamic languages for the past year
Just finished Go-Tour (completed exercises)
Seen canonical ways of structuring Go projects
Here are 2 things i like and dislike about Go so far.
+ Pointers and Simplicity
Go takes the simplest parts of C, combines it with an old-style message-passing abstraction (which I’ve yet to use extensively), and balances it with simple primitives.
I remember trying to reach for pointers in Java and Ruby / Python. As a developer reading / adding to existing code, you really want to see when someone’s passing something into a function to be modified.
+ Build System
Go is up-front about how to structure Go projects for your entire system. Because its a new language, developers haven’t had time to develop their own preferred way of setting up projects. Which is great, because everyone then follows the standard way.
- Fluency
I’ve read a lot of complaints about Go that it’s “ugly”. I’d say it’s not yet “fluent” enough, meaning that it still feels like writing lower-level code and it takes time to express higher-level logic the way you want to with Ruby and Haskell.
The language gets out of your way, but there aren’t libraries yet that allow you to do lazy-loading. Everything is done through channels. This is nice, but it would be great to have built-in libraries that allow generators. I’ve seen some on Github, so high hopes.
- Concurrency Model
Related to fluency - I have to think about channels and how to wait for goroutines every time I parallelize an operation? I like SyncWait but I feel like there should be another primitive for an actual Thread that exits when its children have finished.
This would have made the Web-Crawler example in Go Tour much simpler. Instead, we get this: (note: I decided not to use channels)