Ну странно наличие вариантов рассматривать как минус. Так же можно было вместо Го использовать Rust, node.js или много еще чего.
Я подозревал, что на go потребуется меньше. Я убедился, что да, меньше. Раза в два.
Верю с трудом, особенно в долгосрочной перспективе, и тем более если есть опыт подобных проектов на Java.
Может быть вы и правы. И даже если выбор эмоциональный, то всегда хорошо, когда программирование приносит удовольствие. Особенно если проект небольшой и делается в основном на энтузиазме.
Судя по приведенным аргументам, все-таки остается впечатление, что выбор сделали скорее эмоциональный, нежели рациональный. Новый язык всегда изучать весело.
Если требуется поддерживать несколько тысяч клиентов одновременно, особенно при высокой частоте запросов как в онлайн игре, понятно что скорее всего придется использовать асинхронный ввод-вывод вместо традиционной модели «один поток на соединение». Тут, как говорится, и к гадалке (профайлеру) не ходи. Да, в Го это работает из коробки путем использования «горутин», ну а в Java можно использовать Netty.
Проблема с запуском профилировщика удаленно в Java совершенно надумана. Достигается добавлением пары опций в JVM.
Проблема с запуском нескольких тысяч клиентов тоже надумана. Зачем запускать настоящие клиенты, если можно с помощью того же Netty/NIO написать относительно несложную программу для нагрузочного тестирования, которая буквально с одного компьютера создаст достаточную нагрузку?
И в конце концов, в Го вы все равно можете упереться в сборщик мусора или, скажем, странное поведение планировщика горутин. И что тогда, снова все бросить и переписать на C++?
По-моему, шило на мыло. Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.
Автопилот в Тесле назван неудачно (ну или наоборот удачно, с точки зрения маркетинга). По задумке это просто продвинутый круиз-контроль, по-прежнему обязующий водителя держать руки на руле и сохранять бдительность (понятно, что на практике это далеко не всегда соблюдается). Поэтому не очень понятен разговор про Теслу в контексте автономных автомобилей. Лучше смотреть на гугловские машины, которые уже ездят по улице. Убер тоже активно ведет разработку в этой области, даже выманили кучу профессоров из Карнеги Меллон (CMU) с этой целью. Если верить интернету, они уже тестируют свои технологии в Питтсбурге: http://qz.com/688003/ubers-self-driving-cars-are-on-the-road/
Что значит не будет? По Маунтин Вью и Пало Алто каждый день рассекают самоуправляемые гугловские автомобили. Делают повороты, перестраиваются из полосы в полосу. В них даже руля нет, только джойстик на случай, если придется вручную управлять.
Получается, что какой-нибудь FFT на Rust писать скорее всего не имеет смысла (хотя кто знает, вдруг возможно тот же FFT эффективно написать, используя хитрые итераторы вместо доступа по индексу).
Интересно, а как в Rust решается задача проверки индексов массивов? Понятно, что при простой итерации эту проблему решают конструкции типа for each, которые гарантируют корректность. Но ведь иногда реально нужен доступ по произвольному индексу. Если каждый раз делать проверку, то может выйти дорого, особенно в задачах типа декодирования. А если не делать, то тогда ведь нет никакой безопасности памяти?
Кстати, про foreach: а можно ли в Rust устроить грабли с изменением размера вектора в то время, пока по нему идет итерация?
Согласен, что умение себя «пиарить» ни к чему, но умение доступно объяснить, например, чем ты занимался, важно. На мой взгляд, тут вполне имеет смысл какой-то минимальный фильтр на уровне HR. Не нужно ни перед кем распинаться, нужно (хотя бы временно) засунуть своё эго подальше и рассказать о себе в доступных для простого люда терминах.
Проблема в подходе «пусть команда решит» в том, что тратится очень много времени команды (и, как следствие, денег компании). Если HR будет пропускать к вам всех кандидатов, чтобы вы сами все решили, то вы быстро завоете, потому что у вас не останется времени на собственно работу. Мне вот недавно пришлось в течение пары месяцев проводить по шесть телефонных собеседований в неделю, времени на написание кода реально оставалось ощутимо меньше.
Еще одна проблема в том, что состав команды будет меняться. Беря на работу человека, который обладает хоть какими-то социальными навыками, вы снижаете риск того, что он будет конфликтовать с новыми коллегами в будущем.
Коммуникативные навыки тоже важны. Разработка ведется командой, а не одним человеком в вакууме. Иногда приходится работать с разными личностями, из которых нужную информацию клещами не вытащишь. Да, они могут хорошо писать код, но работать с ними реально неприятно. Да и объяснить им задачу порой сложно. Так что они могут быстро решать задачи, но порой совсем не те задачи, которые требуется решить.
Запретный плод сладок :) Раньше сквозь шум глушилок слушали «Голос Америки», теперь будем вопреки фаерволам через медленный VPN качать ролики с запрещенного ютюба, а вместо самиздата будут «подпольные» блоггеры, рапространяющие свои посты через западные сайты.
GC не решает проблему управления ресурсами в общем случае, а только управление памятью. В той же Java слежение за открытыми файлами или, например, соединениями с БД создает огромную нагрузку на мозг, потому что нет никаких инструментов для гарантированного автоматического освобождения кроме finally.
Да и "утечку памяти" в языке с GC устроить не так сложно, например в стандартной библиотеке Java для этого есть замечательная функция File.deleteOnExit :)
А еще «there/their/they are», да. Но этого немного разного порядка ошибки. Впрочем, неважно. Слово «школьники» было употреблено в переносном смысле. Посыл был в том, что если человек делает такую ошибку, я бы предпочел не доверять ему писать код, от которого может зависеть моя безопасность. Криптографию программировать должны грамотные люди, а не студенты-второкурсники, которым море по колено :)
Не обижайтесь уж так на них, пацаны просто пошутили немного («closely» действительно звучит как будто вы хотите «сблизиться» с ним). Хотя грамматическая ошибка в последней строке («would of» вместо «would've»/«would have») намекает на что, что там сидят школьники. Я бы предпочел, если бы криптографией занимались люди более образованые (с ученой степенью в идеале).
В статье идет речь об одномерных автоматах, то есть в каждый момент времени состояние — это одна строка черно-белых пикселей. Если по вертикальной оси отложить время, то как раз получается двумерная картинка. Динамика в статике, так сказать :)
А я заметил, что разноцветные буквы и цифры в коде меня отвлекают/раздражают. В итоге, я пришел к компромиссу: использование различных начертаний вместо цветов для выделения слов (жирный для ключевых слов, подчеркнутый — для полей класса и т. д.). Цвета используются в основном для строк.
Перевод некачественный, пришлось читать оригинал. Например, в самом начале статьи:
В первом случае поиск занимает A?nAn времени, во втором — An.
В оригинале:
Time to match a?nan against an
то есть, «Время на поиск выражения a?nan в строке an». То есть, оба графика показывают результаты одного и того же эксперимента, проведенного для двух разных алгоритмов. По-моему, переводчик вообще не понял, о чем речь :)
Насколько я слышал, разработчики ядра Linux видят компилятор языка C скорее как макроассемблер, который всегда выдает предсказуемый результат. Поэтому для них не очень-то важны эти тонкости стандарта, ведь они знают, что этот код скомпилируется в простое арифметическое сложение адреса и смещения. И именно поэтому для сборки ядра всегда используется один и тот же компилятор (GCC).
Главный контраругмент говорящих здесь про финансовую сторону вопроса в том, что у вас, возможно, нерепрезентативная выборка в силу непривлекательности вашей вакансии, и потому делать какие-то удручающие выводы и паниковать беспочвенно. Да, ни для кого не секрет, что система образования переживает сейчас не лучшие времена, и можно увидеть краснодипломников, не знающих ровном счетом ничего. Но я не верю, что ваш негативный опыт является основанием полагать, что масштаб трагедии огромен.
Верю с трудом, особенно в долгосрочной перспективе, и тем более если есть опыт подобных проектов на Java.
Может быть вы и правы. И даже если выбор эмоциональный, то всегда хорошо, когда программирование приносит удовольствие. Особенно если проект небольшой и делается в основном на энтузиазме.
Если требуется поддерживать несколько тысяч клиентов одновременно, особенно при высокой частоте запросов как в онлайн игре, понятно что скорее всего придется использовать асинхронный ввод-вывод вместо традиционной модели «один поток на соединение». Тут, как говорится, и к гадалке (профайлеру) не ходи. Да, в Го это работает из коробки путем использования «горутин», ну а в Java можно использовать Netty.
Проблема с запуском профилировщика удаленно в Java совершенно надумана. Достигается добавлением пары опций в JVM.
Проблема с запуском нескольких тысяч клиентов тоже надумана. Зачем запускать настоящие клиенты, если можно с помощью того же Netty/NIO написать относительно несложную программу для нагрузочного тестирования, которая буквально с одного компьютера создаст достаточную нагрузку?
И в конце концов, в Го вы все равно можете упереться в сборщик мусора или, скажем, странное поведение планировщика горутин. И что тогда, снова все бросить и переписать на C++?
По-моему, шило на мыло. Выбросили существующий код и проверенную временем JVM ради «модного» языка из-за каких-то странных доводов.
Получается, что какой-нибудь FFT на Rust писать скорее всего не имеет смысла (хотя кто знает, вдруг возможно тот же FFT эффективно написать, используя хитрые итераторы вместо доступа по индексу).
Кстати, про foreach: а можно ли в Rust устроить грабли с изменением размера вектора в то время, пока по нему идет итерация?
Проблема в подходе «пусть команда решит» в том, что тратится очень много времени команды (и, как следствие, денег компании). Если HR будет пропускать к вам всех кандидатов, чтобы вы сами все решили, то вы быстро завоете, потому что у вас не останется времени на собственно работу. Мне вот недавно пришлось в течение пары месяцев проводить по шесть телефонных собеседований в неделю, времени на написание кода реально оставалось ощутимо меньше.
Еще одна проблема в том, что состав команды будет меняться. Беря на работу человека, который обладает хоть какими-то социальными навыками, вы снижаете риск того, что он будет конфликтовать с новыми коллегами в будущем.
Да и "утечку памяти" в языке с GC устроить не так сложно, например в стандартной библиотеке Java для этого есть замечательная функция File.deleteOnExit :)
В оригинале:
то есть, «Время на поиск выражения a?nan в строке an». То есть, оба графика показывают результаты одного и того же эксперимента, проведенного для двух разных алгоритмов. По-моему, переводчик вообще не понял, о чем речь :)
см. en.wikipedia.org/wiki/United_States_Intelligence_Community