I can write code in iGo and save it as .go. You'll never know if the code was written using Go syntax or iGo syntax, whether the person used tabs of width 4, 8, or 2 (it'll be a '\t' character in the file), or if they used Sublime Text or vim or emacs.
Oh really? So the igo code won't be checked into your repo? The comments you've made will be preserved and in the right place in the resulting code? And you'll be writing go code that other go programmers will find idiomatic and easy to read?
Also, if you use igo won't you have to adjust to read other peoples non-igo code? Or will you use a converter tool whenever you read any go code?
Yes, that's the idea. The current implementation may not be finished/perfect.
> Also, if you use igo won't you have to adjust to read other peoples non-igo code? Or will you use a converter tool whenever you read any go code?
"Converter tool" makes it sound like you find it unreasonable. Do people use "converter tools" to view .html files in a rendered format? No, they use a browser. Or to display '\t' characters with different widths? Use a text editor: http://img534.imageshack.us/img534/1627/zo3w.png
If you're gonna write Go code using iGo syntax, you're probably going to be using a code editor that supports iGo (I don't think one exists yet, this is just a prototype).
You're not gonna be converting from .go to .igo manually, that'd be like running gofmt manually. I don't run gofmt manually, it happens on save (and in fact, I use goimports instead of gofmt).
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.
Most presentations don't use pure go-fmt'd code, they usually do some vertical space compression to get the code to fit on the slides better. So technically you already have to do this anyways.
Um no. Apart from being pretty coffee-script makes you stick with good object definition conventions, hides away unsafe comparisons (== vs ===), and is generally much more easily understood. This is one of coffeescript's main focus points : hide away the not so nice features of js, and highlight the good parts.
Yeah, but the language is what it is. It's out there, it's in all the browsers, it's not going away.
Rather than just learn to idiomatically write code that uses the nice features of js while avoiding the bad parts; we have two totally different notations to learn. That only causes further fragmentation.
We have gofmt so that everyone's code looks the same, and now this? I don't see the benefit.