While It's rarely hard to read a particular piece of code, the combination of duck typing, only structs as receivers, and interfaces can make it as hard to understand as any dynamic language.
There are quite a few traps for the unwary, like that a unitialized pointer to a concrete type will not test as null/nil if it was passed as any of its interface types, that channels ( for concurrenct ) isn't easy except in a few special cases, an that a closed listening socket isn't necessarily closed immediately, and all sorts of shenanigans. You could expect all those from a relatively new language, but not one that is ostensibly very simple.
If you, however, refrain from using any concurrency, interfaces, slices, and maps ( maps and slices are really reference types made to look superficially like they are passed by value ), and accept that the first element in an iteration over a string should give a different result than indexing the first element in that string.
Well, then it's as easy as it looks, for anything where you don't need to actually handle errors, or where you can always handle them where they occur. Also please do remember that log.Fatal() is actually going to kill your process, because calling os.Exit() is obviously the task of the loggin framework!
But yes, Go could have been that easy to read, but there are quite a few really odd decisions that make a lot of the apparent simplicity be rather superficial unless you happen to use a specific subset of the language.
I'm also a Go noob. I tried writing a basic web server in Go yesterday to handle Twilio SMS callbacks. Trying to inspect the requests I was receiving was such a pain, I gave up and wrote the server with Sinatra. Am I missing something that's making this more difficult than it should be?
In my experience, Golang was designed to be safely written and understood by people of just about any skill level, assuming basic programming competency. There's basically only one or two neat hacks in the language that are somewhat unintuitive at first, but that stuff is almost entirely relegated to library development.
you don't need to learn it. :-D you already know it, you just need to write it. There are a few things to understand defer, goroutines,channels, interfaces, structs etc.
We also have to give credit to the author. Good programmers have programs that are easy to read and understand.
However like all languages that are easy to read, it can be deceptive. Once you dive into any big/complex project. Context and design decisions matter more than anything else.
mickronome|7 years ago
There are quite a few traps for the unwary, like that a unitialized pointer to a concrete type will not test as null/nil if it was passed as any of its interface types, that channels ( for concurrenct ) isn't easy except in a few special cases, an that a closed listening socket isn't necessarily closed immediately, and all sorts of shenanigans. You could expect all those from a relatively new language, but not one that is ostensibly very simple.
If you, however, refrain from using any concurrency, interfaces, slices, and maps ( maps and slices are really reference types made to look superficially like they are passed by value ), and accept that the first element in an iteration over a string should give a different result than indexing the first element in that string.
Well, then it's as easy as it looks, for anything where you don't need to actually handle errors, or where you can always handle them where they occur. Also please do remember that log.Fatal() is actually going to kill your process, because calling os.Exit() is obviously the task of the loggin framework!
But yes, Go could have been that easy to read, but there are quite a few really odd decisions that make a lot of the apparent simplicity be rather superficial unless you happen to use a specific subset of the language.
danielvf|7 years ago
dagss|7 years ago
unknown|7 years ago
[deleted]
brink|7 years ago
kaslai|7 years ago
segmondy|7 years ago
We also have to give credit to the author. Good programmers have programs that are easy to read and understand.
However like all languages that are easy to read, it can be deceptive. Once you dive into any big/complex project. Context and design decisions matter more than anything else.
tajen|7 years ago
justbaker|7 years ago
artursapek|7 years ago
Fukkaudeku|7 years ago