as for the clear, not my style, as i like being able to refer back to older tweets, while also keep track of when something new comes in. But to clear the tray icon star right now, i have to mark all existing tweets as read, especially tiresome when there are maybe 100+ loaded after a boot.

I didn’t thought about “mark all as read”. I was using the clear for that (since Mitter don’t have any copies.) I may add, don’t look so much more complicated.

Old style retweet will not come back. I really don’t like the old style ’cause a lot of people think it is “Reply That” and mess with the original message (or worst, use the RT to *reply* to a message with full body.) Sadly, Brent Spinner seems to be the biggest abuser of this feature.

Also, supporting both styles would make the code a mess. It would have to be one or the other, but not both.

i guess the ability to minimize to tray will come soon.

also, two features i would love is a button to mark all read, and also a variant on the repost that work like old retweet :)

Channels are sort of like “typed inter-thread sockets”. They allow for really clean inter-thread communication code, and also double as synchronization points. It’s a very elegant design; worth a look.

I can’t explain precisely why, but Python’s “multiple returns using a tuple” never felt too right for me. I recall bumping into some issues because of that, but I can’t remember which.

And credit where credit’s due: Objective-C’s message and object system is basically Smalltalk’s. :)

Coroutines are underrated, but they keep showing up hidden under various names (Windows Fibers, etc.) lately. In the end, they can scale way more than threads, but you have to change your way of thinking a little to work with them (personally, I’m still very much thread-minded, but I appreciate the theory behind the whole thing.)

On pointers: I found them cleaner than C simply because they removed pointer arithmetic. Unless you’re writing a memory manager, doing pointer arithmetics means you’re not using a proper data structure. :)

On the brand, yeah, it’s a Google product, of course. But that doesn’t matter much for programming languages… it’s not like we care that Python was a “CWI product”, or Pascal was a “ETH product”. I think the people behind it matter more than the company. :)

Related, pointing that you’re more productive because things compile faster is highly irrelevant if you have to compile things a thousand times ’cause the language don’t let you express the requirements properly and you have to keep the cycle of “write, compile, test” about 5 times. If you can write it twice and make it work properly but your compiler takes 15secs more to compile, you still are more productive. That’s why I really don’t think compiler speeds matter at all. If your syntax don’t allow explaining properly what *you want*, then yes, compiler speed is important, but you’re not going for the root of the problem: Your language doesn’t allow the level of “explicity” you need to explain to the computer what you want.

Agreed on “needs proper OOP, FFS!” point. Thing is, OOP in C is as awkward as they are pointing it in Go. But C never had “hooks” for OOP-like programming while Go have… in a very ugly looking way. Either do it properly or don’t do it at all.

I didn’t mention the channel system ’cause, honestly, I didn’t read the whole tutorial. As I heard, it resembles the Objective-C message passing method to call functions (and Objective-C predates Limbo by about 10 years) — and, by God, may I be right in what you’re talking about ;)

Multiple return values is not novelty. Python does that since 1991 (ok, maybe a bit later), although it does that using one of the internal types. Also, Python also supports coroutines but, in all honesty, I don’t see it being much more interesting for (and that’s when you can flame me to hell and back and to hell again) “consumer scale applications.” “yield” does a good job in a coroutine-like manner already.

Pointers… honestly, they are not cleaner than C. I even though they were more confusing in Go than in C. They may be cleaner than C++, which is a mess with pointers, references, implicity-references and de-referencing. To me, the cleaner implementation EVER of pointers goes to Objective-C. But, again, personal, biased opinion.

Finally, Ken Thompson currently works for Google since 2000; Rob Pike currently works for Google; Robert Griesemer also works for Google and started the Go language in 2007. So, calling Unix a “Bell Labs product” may very much apply to Go as “Google product.”

Calling a language “faster” is pointless — both regarding the runtime speed of the code and compiler speed, as both are implementation details, not really tied to language design (though some package systems may make things easier or harder). Look at the latest results in LuaJIT 2 to see how implementation can affect the perception of a language’s “speed”. Still, compile cycles (for those of us still using compiled languages — and we’re here to stay) do matter. Pascal’s design favors much faster compile cycles than C (remember Turbo’s speed, back in 286′s?) and switching from FreePascal to gcc was indeed a pain in that regard.

Syntax is important, true, but semantics in the end count the most. Go’s syntax is a lighter version of C. Having used Limbo a little bit, I noticed a number of similarities, and all of those are things I missed in other C-related languages. These are welcome additions.

Variable declaration in particular is the same as Limbo’s derivation of the Pascal/Modula/Oberon tradition into C-land and having used it, I can say it’s very comfortable. You either use “var” to declare a variable, or use the declare-and-assign operator :=. So in the end you just have to say p := “”; which is shorter and cleaner than C’s char* p = “”; so no worries there.

I’m pretty sure the interface system does not come from JavaScript, but rather from the Modula module system. There is no object system per se — the point is that they provide abstractions that are more general than objects. I understand their reasoning behind this, but I confess I rather like having dedicated OOP constructs in a language. I’m yet to see if using Go for writing OOP code ends up feeling like OOP-by-hand in C or if the abstractions are good enough.

Other great features you didn’t mention are the channel system (straight from Limbo), multiple return values and coroutines (looks like they’ve been paying attention to Lua) and cleaner pointer manipulation (much welcome).

And finally, Go was created not “by Google”, but by Robert Griesemer, Rob Pike and Ken Thompson — yes, the Bell Labs guys.

In short, Go feels _very much_ like what I would like to see in a programming language, except for the OOP part…