Когда слишком много выбора, у некоторых руки чешутся использовать вещи не по назначению. Go полон компромиссов. Создатели постарались добиться максимальной простоты, во всём. Где-то это ограничивает программистов, но как правило оно того стоит.

Сейчас область применения Go — это утилитки и веб-серверы. Нету необходимости использовать общее окружение.

Я как раз писал статью на хабре, в которой описано, как работают горутины. В том числе и как их переключает планировщик.

Так а в чём выигрыш? Библиотеки-зависимости тоже меняются. В итоге времени всё равно больше уйдёт.

Вот из опыта Iron.io:

Go compiles into a single, static binary file so deployment is simply putting the file on a server and starting it up. No dependencies required. No runtime required (you don't need to install Go on the server). And it's small; the IronMQ binary is ~6MB.

If something goes wrong after deploying and you need to roll back, you can just stop the bad process then start the previous binary. You don't need to worry about a dependency being upgraded since the entire program is compiled into a single binary.

Кстати вопрос к знающим по поводу размеров исполняющего файла. Можно ли как-нибудь все это дело разбить? Т.е. сторонние либы отдельно, сам экзешник отдельно?

А зачем? Весь рантайм статически компилируется в один бинарник. В современных системах — это очень удобно, т.к. нету никаких зависимостей, что сказачно облегчает деплоймент.

Показательный пример, да.

Правда хранить хеши в файле — сомнительное удовольствие. (Разве что в качестве примера). Проще ведь заново их пересчитывать каждый раз.

И стоит-таки соблюдать naming conventions.

Каждой задаче — свой инструмент. Go и не предназначался для full stack веб приложений. Он прекрасно подходит для веб-сервисов или консольных утилиток. Во всяком случае такое мнение витает в сообществе.

Полнофункциональный веб сайт прекрасно пишется на Rails/Django/etc, а бэкенды к нему на всяких Erlang/Go/etc.

Тогда уж не публичными, а экспортируемыми ;)

Наиболее популярные фреймворки — это Revel и Beego. Ничего типа Django и Rails под Go нет и вряд ли будет.

Радует то, что производительность в QtQuick 2 выросла настолько, что теперь без шуток его можно использовать в продакшене. Летает даже на андроиде :)

Какая-то нездоровая ситуация, когда пользователю предлагают скачать security update мало того, что не из маркета, так ещё и по короткой ссылке, которая к тому же не на https :)

http://download.viber.com/viber.apk

Да, у Канады разрваны торговые отношения с Белоруссией, поэтому BB не разрешает нам качать их ПО. Более того, запрещён доступ в маркет с телефонов!

SDK отлично качается через TOR. На телефонах приходится сидеть через непрозрачные прокси.

Ещё добавлю: в Blackberry своя обёртка над вебкитом вместо QtWebKit, и апи у неё не такой хороший. Нету всяких ништяков типа QWebElement и т.п. Поэтому может показаться что парсить html довольно напряжно.

Но по факту это можно делать прямо в QML через javascript, и в итоге получается даже проще :)

Добавлю, что весьма активная работа ведётся над плагином для QtCreator. Уже можно делать и заливать на телефон приложения на Cascades. Но пока останавливает то, что в редакторе некорректно распознаётся их диалект QML.

И ещё очень не хватает исходников, но тут уж ничего не поделаешь.

В остальном просто сказка.

Для справки: и vk, и fb используют XMPP как протокол для общения. Другое дело, что во внешний мир они не выпускают.

Будет грустно, если гугл к ним в этом присоединится.

Кому есть дело до восточной части? ;)

Запустит, а потом закроет. Чего ещё от гугла ожидать ;)

А монетизация за счет подделывания этих данных ;)

Очевидно, что QMap быстрее если хеш вычислять долго, а сравнивать легко. Например, если использовать в качестве ключа SHA-512 строки, то я бы предпочёл именно QMap.