Another "fun" thing people miss out on is that you spend less time making choices, and more time writing what you need.
When there is generally one library/function/struct that does what you want to do, so you don't need to overthink about what tool to use to do what you are trying to accomplish. This is from the simplistic set of APIs in the libraries. You want a "list", you use a slice. You don't need to decide if it should be a linked list, array, doubly linked list, etc. Want a map? You don't need to decide if it is a hashmap, treemap, etc. It is just a "map". The less decisions you are needed to make to do something simple, the more fun it is. When you need to do something complex, then you can dig for a library that implements the specifics you need. When the Go team also takes their time to implement a new feature/library/etc, I generally can trust that it does what it should do, and does it well. It took until Go 1.7 to get context to be part of the core library, and I use it for almost every method now. io.Reader was weird to think about first, and now I expose a lot of functionality through those interfaces and get features I would have never thought of before, for free. Uncovering these well thought out designs leads to fun new moments that are hard to describe. On Sunday, April 10, 2022 at 5:00:46 PM UTC-7 ben...@gmail.com wrote: > Reading the spec probably isn't the best way to experience the "fun" in > any case. (Though the spec is worth a read once you've use the language a > bit -- as far as specs go, it's concise and readable.) > > "Fun" is quite a personal thing, but similar people often have similar > experiences, so I'll take a stab at answering from my perspective: > > Go is fun because the language is: > > * Easy to learn: I learned it coming from years of Python and some C. You > can be productive in Go in a couple of weeks. My first medium-sized project > in Go was porting a web backend from Python to Go, and I found it a lot of > fun (https://benhoyt.com/writings/learning-go/). > * Builds fast: even large programs compile and build in seconds (not > minutes or hours). Go caches builds of packages that haven't changed, > meaning the time from editing code to running it is very short, sometimes > close to instantaneous. > * Runs fast: Go compiles to reasonably fast native code. Coming from an > interpreted language like Python, this is great when you need to do > something like loop over the characters in a string. > * Solid stdlib: enough quality stuff in the standard library to get a lot > done quickly. > * Concrete focus: good Go code (like the stdlib) tends toward concrete > types and simple patterns rather than abstract interfaces, factories, and > deep nesting. > * Excellent tooling: "go build" builds your project with no ceremony. "go > test ./..." runs all your tests. "go run" builds and runs a program in one > step. The caches for the above just work. > > The above is why Go is fun for me. That leaves out Go's other unique > features (though arguably these are more "useful" than "fun"): > > * Unique take on types and interfaces that doesn't result in an > inheritance mess. > * Statically typed. For medium-sized to large projects, this really helps > reassure you when refactoring (compared to Python, JavaScript, and so on). > * Generic slices and maps: right from Go 1 (that is, pre-Go > 1.18-generics), Go always had type-safe growable arrays and hash tables, > two of the most useful data structures. > * (Some) control over memory allocation. You don't usually have to worry > about it, but when you need to reduce allocations, you can: make(), reuse > buffers, and so on. > * Goroutines and channels. Concurrency is never easy, but at least with Go > the primitives are built into the language and relatively straight-forward > to learn. > * The above means functions aren't colored -- all libraries are sync, use > "go" to make them async. See: > https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ > * io.Reader and io.Writer. These are simple but amazing tools for > composing I/O (I'm comparing to things like the vague mess that is Python's > "file-like objects"). > * Go modules. Relatively new in the scheme of things, but it's a really > good system. (It's also well built, for example: > https://go.dev/blog/supply-chain) > * The Go community's focus on few dependencies. So much better than the > pain and fragility of a node_modules directory with 1500 entries. > * Easily-deployable binaries. Instead of having to ship around a big > runtime and stdlib, to deploy a Go program, you just copy the binary to the > target machine. (And Go 1.16's "embed" means you can even include your > static files, templates, and so on.) > * Incredible cross-compilation. Just set two environment variables (GOOS > and GOARCH) and type "go build", and have a macOS or Windows binary a few > seconds later. > > I'm sure others have their own lists... > > -Ben > > > On Monday, April 11, 2022 at 8:53:55 AM UTC+12 kziem...@gmail.com wrote: > >> Hello, >> >> I lack a motivation to read Go spec (long story) and I seek few stories >> along the line "Go is fun", which it is, to motivate myself. Google didn't >> give me any results, maybe you can tell me few reasons, why Go is fun? >> >> I feel that it is fun, but can't tell why. >> >> Best, >> Kamil Ziemian >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/07288963-1ba7-410e-8e48-b270c41ec6f0n%40googlegroups.com.
