81–90 of 94 posts
The most obvious advantage here is that the code at the left is much more concise. This is good because then more code will fit in the same screen. Not sure this is what Go needs though.
How is more code on the same screen a good thing?
On the other hand many young developers these days seem to think, that scrolling is good and insert lots of blank lines everywhere.
Why is significant-whitespace vs. braces a significant issue for people? I've coded in both and while I suppose I would have to say that I'm "most" comfortable with braces, I don't find SW that different. The semantics of the code haven't changed at all. It's not like we're going from C to O'Caml here. This doesn't enable a different way of thinking about the code. I guess I just feel that, if I could run a set of ve…
Personally, it's not a significant issue, but it is a preference. Do you indent code when coding with braces? How anal are you about keeping your code formatted consistently (i.e. spaces after operators)?
In addition most editors have plugins for automatic gofmt on save.
One of the best parts of Go is that the grammar is (almost) entirely context-free - it is one of only two languages I know of in this regard - Lisp is the other[0]. This comes in handy because it is very easy to parse Go and make syntactic transformations while preserving semantic meaning. The "go fix" tool (which was used to port pre-1.0 code to Go 1.0) meant that Go never had a "py3k" moment[1]. This is not like py…
Such tools, positioned such that they are defacto standards can cause qualitative changes in how programming happens in a language.
Earlier quoted context omitted.
I believe his point is that iGo is just a way of editing .go files. It's not as though you would be saving .igo files to disk or anything. So, it's totally unrelated to any kind of version control or file management, much less to Github.
No, it's not. Because if you're used to reading igo code and then you're browsing normal Go code in GitHub or watching a talk or reading a tutorial, you're going to have to mentally translate that code to igo. It's needless mental acrobatics.
IGo as-is could've been just an alternate colored-syntax mode with color of curly characters set to background color. Much less work with same result.
I don't think that's a fair statement. You would still have to keep track of and type curly braces, only now they'd be invisible.
Useless
I appreciate the inline if-else statements. I'm so tired of having: if err != nil { return err } Take up 70% of all lines in a function.
the cost in making the code harder to parse (both for compilers and, IMO, humans) isn't worth it. Using short assignment mixed with if makes the Go error handling branch code not so bad, eg instead of: err = doSomething if err != nil { return err } do: if err = doSomething(); err != nil { return err } Also if your function only returns err, I'd use a named return to save even more typing. I know they are seen as a bi…
if buf, err := json.Marshal(make(chan int)); err != nil { fmt.Println("Ehh..", err) return }
In this case, buf will not be available outside of the if statement. Go fmt can already leave your insignificant whitespace as is, I just wish it could also leave the if error != nil statement say in one line instead of formatting it to take three.
Why sacrifice consistency for some minor syntax changes? We have gofmt so that everyone's code looks the same, and now this? I don't see the benefit.
It seems like a real "because we can" thing. Coffee script is smelly in the same way.