What would you call the middle ground between the two of them? I feel like I spend a lot of time reading, but I just can't bring myself to blog. I've had one for years that has maybe 5 posts. It's a combination of being tired at the end of the day, feeling like I have nothing useful to say (that hasn't already been said), and generally not thinking about it.
It's also a similar story with Stack Overflow. When I think to try and answer questions, they've already been answered by people more knowledgeable than me.
>If Servo (written in Rust) isn't faster than Gecko (written in C++), then Mozilla won't continue funding Rust. Rust needs to be fast in a very existential way.
Ouch, I didn't know the project had a deadline. By when does it need to be faster?
Ok, that makes me feel better. I've been watching and waiting for Windows support to get better, and I'd hate to have it fizzle before I really got to play with it.
You might want to do some moderation on tags. Looking up "Android" brings up "Android", "Android Development", and "Android App Development". Looking up "Golang" returns "golang" and "Golang".
I wonder how much people are going to miss out on connections if they pick one of three terms for what's probably the same idea.
It's not much better in the US. I live in Atlanta and I feel like I'm missing out on most of the fun. If you're not in SF or NYC, there's a lot you don't get.
Go might be young but the underlying compiler suite is derived from Ken Thompson's c compiler written for plan9 ~25 years ago. Also taking into consideration that the people developing Go have an impressive history of innovation; its not an uncommon by the time somebody actually finishes developing that critical software, for the compilers and runtime to receive vast improvements via new useful diagnostic tools and optimizations.
Google have some pretty critical software running on Go already (and have for a couple of years now). For example, their MySQL scaling proxy[1] is in Go.
But it is very different to use something server-side in your own environment where you can deploy updates easily, vs. client side on devices where the wrong kind of bugs can wreak havoc for millions of uses and make updates to fix them extremely much more complicated.
Yeah, they probably want to wait until Go 2.0 or something, before they commit Android to supporting Go (and support only 64-bit apps while they're at it, since from what I hear Go handles 64-bit much better than 32-bit anyway). So maybe in 2-3 years.
But I do think they should do it eventually, and move away completely from Java, because I think Java is a pain to learn, especially for new programmers who want to make Android apps. Being able to write Go apps for Android could make Android that much more attractive to developers.
In the meantime, this transition to ART apps, will be a huge benefit for users, as their apps will run better, especially on lower-end devices, which KitKat also addresses.
