I'd install every app if they didn't all seem to need access to my identity, wifi state, phone state, etc to display some simple information on a screen.

If I have visited your website from a browser there's a good chance that's how i want to interact with you.

Because you can is largely why I wrote the post.

That being said, i think the nature of go routines and how go handles threading could be very important for mobile. We are all walking around with handsets that have multiple weak cores. If we can spread the general work over those cores our handset could possibly get back to a lower power mode faster.

That's my take on it anyways

> We are all walking around with handsets that have multiple weak cores. If we can spread the general work over those cores our handset could possibly get back to a lower power mode faster.

Any advantages gained from this are going to be lost due to the lack of a highly optimizing compiler. Unless you have a lot of cores, my general experience is that you need sequential performance first and only then can you think about achieving speedups from going multicore. Compiler optimizations matter even more on ARM than on x86 due to shorter pipelines, smaller caches, super-expensive synchronization primitives, and so forth.

Of course, to be fair to Go, the primary alternative is Java (though the performance-critical parts of Android tend to be written in C++), which as implemented in Android doesn't do a whole lot of optimization either.

I think Go could be a great choice for application development, mind you. I just don't think that reaching for it to get multicore speedups will work at the moment compared to the alternatives.

Thanks for clearing that up.

I fell this is rather important, and kind of missing from your blog entry, as that's the first question that pops to my head as a reader (or at least a reader who's a software dev)

Thanks for the feedback, i'm pretty new to blogging and i've found the hardest part is giving the right context to my readers.

You mean like Grand Central Dispatch ? It's been available in iOS for a few years now and is very well integrated into the language.

Also battery life is largely pointless for an app developer to lose sleep over. The tiny power saving you make will always be eclipsed by screen brightness, cost of poor networks (the radio won't sleep) and apps like Facebook which happily sit in the background with their VOIP mode active.

Not to mention users will punish you far more if your UI is poor or features are missing rather than if it chews up battery (which they largely will never be able to measure). I don't know many ordinary users who check their battery usage deep down within the many Settings submenus.

I didn't know about Grand Central Dispatch, my experience with iOS is fairly limited.

I agree that UI is super important, but personally if i find an app is chewing up my battery it's getting removed regardless of its utility. I've also helped a handful of ordinary users diagnose why their battery life is poor. The result is commonly a poorly optimized/buggy app which they uninstall. A dead phone is a useless phone. My experience is primarily android so your mileage may vary on other platforms.

Not to mention that shitty devs can hide behind the Play Services... Google really need to add a way to shame devs that eat half your battery with play requests.

Not the original person, but in any organization with a non trivial amount of code needs someone that is really on top of managing how the applications build and how dependencies mesh together. There's many tools to learn and leverage (in java you have ant/ivy, maven, gradle) and can easily take up a fairly large amount of time to organize. If done properly it can also prevent certain project failure.

It's definitely true. But does it lead to money? We developers think it's logical that it should lead to money, but does it?

I used locust to supplement testing that third party was doing (they used some ibm product that I didn't have a license too).

I liked locust because it was easy to start using, but you write a decent amount of code if you have a complex application. I suggest using pyquery (https://pypi.python.org/pypi/pyquery) with it if you need to inspect any html, it was quite useful

It's largely accepted that while you can use gdb, it's not really good at debugging go code. from your own link.. "GDB does not understand Go programs well"

https://github.com/derekparker/delve delve as mentioned other places is more of a true go debugger

I agree largely with what you say but advice point 2 is an obvious smell in today's working world. I'm taking that advice as "don't do anything that would prevent you from moving tomorrow". That includes having a spouse that is employed, having family, having property, etc. Being mobile shouldn't be a requirement for the average person. If you are striving to be top in your field, then mobility might be a requirement.

That one is rough, agreed. A better interpretation might be,"don't get bogged down on an illiquid asset, i.e. a fixer-upper when your cash reserve is low, and would be difficult to generate rental income from". The point is to not let that be an anchor if you lose employment for an extended period of time. It's as much a defensive as offensive posture.