Продуктовая компания с российскими топ-менеджерами и владельцами, которая из вполне логичных соображений зарегистрирована не в России — российская или зарубежная компания?
Выигрыш по производительности от флагов компиляции самосборной системы минимален, исключая узкоспециализированные случаи типа аппаратного AES и шифрования разделов. Более того, в серьёзном продакшене тоже неудобно использовать -march=native — сервера немного разные и скомпилированный софт при переносе периодически не заводится.
На мой вкус смысл в генте появляется только тогда, когда на другом дистрибутиве приходится самостоятельно собирать значительное количество софта — use флаги и ебилды крайне удобны для этого, как для поддержки заведомо работоспособного сочетания софта, так и для обновления системы и дальнейшей кастомизации по потребностям — в прочих распространённых дистрибутивах приходится именно что руками каждый раз пересобирать софт.
На десктопе же есть арч, в котором пакеты сразу собираются на современные CPU, а настраивать систему под себя не сильно дольше, чем убунту.
Эффективное раскидывание легких потоков по процессорам есть в Go и специализированных средствах типа Erlang'а. Кооперативная многозадачность (на самом деле не совсем) позволяет сделать это достаточно эффективно.
Так и работают многослойные тёмные паттерны: главной свиньи от Новоплата вы так и не заметили. В их договоре оферты (с которым вы соглашаетесь при оплате) явно сказано, что вы не против передачи данные о ваших транзакциях. В результате после оплаты телефона вы автоматически подписываетесь на легальный смс-спам, и эти данные (включая адреса терминалов и суммы) известны всем партнёрам Новоплата.
Кстати зря смеётесь над алгоритмом Бабушкина: как ни странно он даёт вполне пристойную сортировку.
Алгоритм: строим цепную дробь для числа Бабушкина. В какой-то момент либо цепная дробь закончится (т.к. конечна), либо ошибка будет меньше последнего разряда (и поскольку отклонение приближения цепными дробями на каждом шаге меняет знак, эта либо следующая дробь подойдёт под условие «совпадает с точностью до последнего знака»). Каждый шаг цепной дроби сводится к обращению длинного числа (разделить 1 на него).
Рост знаменателя приближения цепной дробью, насколько я помню, оценивается как y^k, где k — количество шагов, y — константа. При этом отклонение от искомого числа Бабушкина не больше 1/(квадрат знаменателя).
Сложение-вычитания длинных чисел — линейны, количество шагов — логарифм. Таким образом, оценка скорости поиска пары чисел для числа Бабушкина: O(сложность деления длинных чисел * logn). Сложность деления 1 на длинное число по этой статье сводится к сложности умножения citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.7394&rep=rep1&type=pdf
т.е. O(n * logn).
Таким образом, алгоритм будет работать за O(n*log^2(n)) — что весьма неплохо.
Забавно смотреть, как автор, не разобравшись толком в Go, начинает сравнивать его с другими языками.
Для начала, флаги можно указать так:
var (
WORKERS = flag.IntVar(«w», 2, «количество потоков»)
REPORT_PERIOD = flag.Int(«r», 10, «частота отчетов (сек)»)
DUP_TO_STOP = flag.Int(«d», 500, «кол-во дубликатов для остановки»)
HASH_FILE = flag.String(«hf», «hash.bin», «файл хешей»)
QUOTES_FILE flag.String(«qf», «quotes.txt», «файл записей»)
)
это гораздо короче и удобнее того что автор понаписал как для java, так и для Go. Более того, аналога этой конструкции в java нет.
Далее, автор превратно понял логику обработки исключений в Go. Если по каким-то причинам удобнее при ошибке прерывать flow и обрабатывать в 1 месте, вы можете даже не проверять err != nil, а просто recover'ить рантайм панику при вызове метода у нулевого объекта, созданного при ошибке — не идеальное решение, но избавляет от проверки результатов работы функции.
Вообще же сама по себе логика, когда при почти любой ошибке прерывается flow и исключения «обрабатываются» где-то высоко, если явно не предусмотрено обратное — ущербна — непредусмотренная явно ошибка может привести к непредсказуемым последствиям. Особо приятно ловить в Java null pointer exception. В Go в этом смысле более явный и унифицированный подход, когда разворачивание стека вызовов наверх происходит только по делу — при паниках — а ошибки возвращаются из самой функции.
В данном случае у вас go-код, иллюстрирующий парсинг HTML, работает неидентично java-коду. Если в java-код добавить дополнительный try-catch вокруг запроса страницы, чтобы она не падала при сетевых ошибках — получится ещё уродливее, чем в go, в дополнение к неудобной проверке ошибки далеко от её места возникновения.
Прибавляя к этому абсурдность сравнения системных тред и лёгких тред, общий вывод печальный для автора: данная статья — треш, и её надо очень долго дорабатывать, чтобы она не обесценивала хабр своим присутствием.
Статья прекрасно иллюстрирует конфликт сознательного и подсознательного. Для сознания всё может быть хорошо: одобрение окружающих, высокий заработок, действительно комфортные условия итп, к чему стремятся (и нередко не достигают) многие; подсознательно же человек ощущает, что он движется не туда, что реальные цели другие. При этом подсознание умеет давать разве что эмоциональную оценку происходящего, которая в данном случае ощущается как внутренний психологический дискомфорт.
> Да, налоги + отчисления с з/п сотрудников у нас существенные. Но что-то мой опыт говорит, что в любой развитой стране с высоким уровнем жизни, они не меньше. Высокий уровень, он ведь не с потолка берется, его кто-то оплатить должен.
В США — высокий уровень жизни? А в Канаде? А в Британии? При этом налоги с з/п значительно ниже, и прогрессивная шкала нередко в другую сторону.
>в каких-то вариантах (самых массовых: для малых компаний с выручкой внутри страны) он даже будет экономичнее по налогам
В том-то и проблема, что нет. Эффективно по налогам может работать только ИП без сотрудников с неплохим регулярным доходом, а не малый бизнес.
ООО может выводить деньги под 9% только раз в квартал, с собранием учредителей и прочей бюрократией, в отличие от ЗП, которую можно платить в любой момент (премии итп).
Если вы — ИП, то _свои_ деньги вы действительно можете получить под 6-10%. Проблема в неадекватно больших налогах (те самые 50%) на заработную плату сотрудников; нередко необходимом НДС, при котором упрощёнка невозможна — а там 20% налог на прибыль и прочая печаль.
Помимо этого, ИП в 2013 стало проблематичным для тех, у кого это подработка, из-за значительно возросших обязательных взносов.
Вкалывать — вкалывают многие, проблема в том, что порог для того, чтобы начать расти — заметно выше, особенно для IT-компаний с основной статьёй расходов — на сотрудников.
Стоит заметить, что при этом вполне правильно задавать флаги прямо в var модуля (что в вашем случае будет правильнее) или в ините — они корректно достаются и отображаются при -h. Собственно, это go-way для используемых модулями флагов, и на мой взгляд волшебная фича!
На мой вкус смысл в генте появляется только тогда, когда на другом дистрибутиве приходится самостоятельно собирать значительное количество софта — use флаги и ебилды крайне удобны для этого, как для поддержки заведомо работоспособного сочетания софта, так и для обновления системы и дальнейшей кастомизации по потребностям — в прочих распространённых дистрибутивах приходится именно что руками каждый раз пересобирать софт.
На десктопе же есть арч, в котором пакеты сразу собираются на современные CPU, а настраивать систему под себя не сильно дольше, чем убунту.
www.zabbix.com/img/zabconf2013/presentations/Which_Database_is_Better_for_Zabbix.pdf
Алгоритм: строим цепную дробь для числа Бабушкина. В какой-то момент либо цепная дробь закончится (т.к. конечна), либо ошибка будет меньше последнего разряда (и поскольку отклонение приближения цепными дробями на каждом шаге меняет знак, эта либо следующая дробь подойдёт под условие «совпадает с точностью до последнего знака»). Каждый шаг цепной дроби сводится к обращению длинного числа (разделить 1 на него).
Рост знаменателя приближения цепной дробью, насколько я помню, оценивается как y^k, где k — количество шагов, y — константа. При этом отклонение от искомого числа Бабушкина не больше 1/(квадрат знаменателя).
Сложение-вычитания длинных чисел — линейны, количество шагов — логарифм. Таким образом, оценка скорости поиска пары чисел для числа Бабушкина: O(сложность деления длинных чисел * logn). Сложность деления 1 на длинное число по этой статье сводится к сложности умножения
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.7394&rep=rep1&type=pdf
т.е. O(n * logn).
Таким образом, алгоритм будет работать за O(n*log^2(n)) — что весьма неплохо.
Для начала, флаги можно указать так:
var (
WORKERS = flag.IntVar(«w», 2, «количество потоков»)
REPORT_PERIOD = flag.Int(«r», 10, «частота отчетов (сек)»)
DUP_TO_STOP = flag.Int(«d», 500, «кол-во дубликатов для остановки»)
HASH_FILE = flag.String(«hf», «hash.bin», «файл хешей»)
QUOTES_FILE flag.String(«qf», «quotes.txt», «файл записей»)
)
это гораздо короче и удобнее того что автор понаписал как для java, так и для Go. Более того, аналога этой конструкции в java нет.
Далее, автор превратно понял логику обработки исключений в Go. Если по каким-то причинам удобнее при ошибке прерывать flow и обрабатывать в 1 месте, вы можете даже не проверять err != nil, а просто recover'ить рантайм панику при вызове метода у нулевого объекта, созданного при ошибке — не идеальное решение, но избавляет от проверки результатов работы функции.
Вообще же сама по себе логика, когда при почти любой ошибке прерывается flow и исключения «обрабатываются» где-то высоко, если явно не предусмотрено обратное — ущербна — непредусмотренная явно ошибка может привести к непредсказуемым последствиям. Особо приятно ловить в Java null pointer exception. В Go в этом смысле более явный и унифицированный подход, когда разворачивание стека вызовов наверх происходит только по делу — при паниках — а ошибки возвращаются из самой функции.
В данном случае у вас go-код, иллюстрирующий парсинг HTML, работает неидентично java-коду. Если в java-код добавить дополнительный try-catch вокруг запроса страницы, чтобы она не падала при сетевых ошибках — получится ещё уродливее, чем в go, в дополнение к неудобной проверке ошибки далеко от её места возникновения.
Прибавляя к этому абсурдность сравнения системных тред и лёгких тред, общий вывод печальный для автора: данная статья — треш, и её надо очень долго дорабатывать, чтобы она не обесценивала хабр своим присутствием.
В США — высокий уровень жизни? А в Канаде? А в Британии? При этом налоги с з/п значительно ниже, и прогрессивная шкала нередко в другую сторону.
>в каких-то вариантах (самых массовых: для малых компаний с выручкой внутри страны) он даже будет экономичнее по налогам
В том-то и проблема, что нет. Эффективно по налогам может работать только ИП без сотрудников с неплохим регулярным доходом, а не малый бизнес.
Помимо этого, ИП в 2013 стало проблематичным для тех, у кого это подработка, из-за значительно возросших обязательных взносов.
Вкалывать — вкалывают многие, проблема в том, что порог для того, чтобы начать расти — заметно выше, особенно для IT-компаний с основной статьёй расходов — на сотрудников.
Например, закону Московской области №46/2013-ОЗ ( www.rg.ru/2013/06/11/mosobl-zakon46-2013-reg-dok.html ) ст.3 п.5 постоянно проживающие иностранцы могут участвовать в выборах.