$1500-$2500

а на джуна сколько примерно? (через полгодика)

ээээй! я первый в очередь на джуна)

я не в очереди :) просто интересно

а)

повторюсь: кстати, а кто расскажет, какие требования при приёме на работу для джуна\миддла? большая пропасть между ними?

а на джуна сколько примерно? (через полгодика)

1000

повторюсь: кстати, а кто расскажет, какие требования при приёме на работу для джуна\миддла? большая пропасть между ними?

миддл - это вообще никчемное существо

никогда миддлов не видел

джуна берешь, смотришь - вырастет ли в сеньера

если не вырастет - увольняешь

ну так джун-миддл-сеньёр же, не?

или сразу джун-сеньёр?

это так

но

как такового — миддла в явном виде нет

на самом деле, существуют сеньеры и ебаные обезьяны

сениор это перец с 35 см

джуниор это джуниор

и джуны, которые личинки тех или других

занимательная математика)

ну она такая

странная )

а по требованиям к джунам?

мидлами зовут тех, кто гуглит меньше, но еще еблан

?

(рискнул получить люлей в чате)

в первую очередь смотрят на твою адекватность, в любом случае

как сказал Ден, если ты хорош, то денег больше выбьют )

мидлами зовут тех, кто гуглит меньше, но еще еблан

мидлы вообще не гуглят. убедились, что им не помогает. дебилы

фух, я гуглю, значит я не миддл)

про требоания - позже, ок?

мне тут код попался. голанг апи для мобайл чатов. открыл код и вижу чистый stack overflow

насколько нагружено/масштабируется в планах?

про требоания - позже, ок?

ок, пасиба

сейчас пользователей мало

текущая архитектура тестируется на 10М пользователей

мидлы вообще не гуглят. убедились, что им не помогает. дебилы

тот момент, когда почувствовал себя сеньором на пустом месте ?

как сказал Ден, если ты хорош, то денег больше выбьют )

ну я скорее план повышения зп выстрою

типа 2000 сейчас, 3000 через полгода. ну или как договоримся

резко получается )

на иглу посадишь :D

мне того и надо

да я про то, что потом будут ждать повышение до 3.5 )

через полгода-год

какой-то внезапный замес посреди дня -)

резюме отправляй

кеш собирай ))

GO быстрее Node.JS?

Нет, но мне никто не поверит в этом чатике. У Go большие накладные расходы на реализацию interface. Я видел мнение, что не используйте интерфейсов и будет вам производительность. Но тогда это не совсем Go way.

Дело спасает что Node - однопоточная. Вроде бы собирались там делать какие то менеджеры процессов, но ... нет. Сейчас даже на плате ARM за 30 баксов есть 4 ядра и Go нативно утилизирует эту многопроцессорность, поэтому оставания от JavaScript я никак не сичтаю проблемой

Дело спасает что Node - однопоточная. Вроде бы собирались там делать какие то менеджеры процессов, но ... нет. Сейчас даже на плате ARM за 30 баксов есть 4 ядра и Go нативно утилизирует эту многопроцессорность, поэтому оставания от JavaScript я никак не сичтаю проблемой

А на сколько он медленней? Есть цифры какие-то конкретные?

нода масштабируемая

"язык программирования" быстрее чем "другой язык программирования"? рили? в 2016 году такие вопросы? :)

можно запускать несколько инстансов

и менеджерить

есть специальные либы и утилиты

в 2016 проблема возникает уже не в скорости выполнения, а кто быстрее с памятью работает

ну например https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node

на мой взгляд странный бенчмарк

там нода только одно ядро использует, а го все

не честно

можно ограничить кол-во горутин

тогда будет честно

да так не честно, потому что одноногий бегун не должен соревноватся с двуногим

у ноды из коробки есть модуль clusters https://nodejs.org/api/cluster.html , которые позволяет равномерно распределить нагрузку на все ядра

да это же обычный форк

А на сколько он медленней? Есть цифры какие-то конкретные?

У меня только впечатление от одной из серверной задач. На ноде была использована оптимизация с использованием типа компилированных шаблонных функций ( за точность названия не ручаюсь), а на GO билблиотека была полностью на интерфейсах. Разница на обработке одинакового потока UDP данных - в два раза в пользу Node.js

по моему вообще простыми hello world'ами сравнивать что угодно, с чем угодно не правильно

ERROR: S client not available

пока-что для себя используем такую схему: API на nodejs, ходит в микросервисы с помощью grpc которые написаны на go

по моему вообще простыми hello world'ами сравнивать что угодно, с чем угодно не правильно

+1. часто слышал мнение, что нода хороша только в головом виде, когда чистый http из либы, и он показывает хорошие результаты. но стоит взять что-то более прикладное и популярное, как начинается слив, аналогичным решениям из других экосистем

Простыми хеловордами Го в два раза хуже чем оптимизированных код C++

Например Go стандартный http vs nginx

в том и дело, человек может сравнивать две вещи, где одну знает как оптимизировать и вообще у него в ней опыта больше, а о другой знает только необходимое чтобы написать хелло ворлд, пишет перформанс тесты на основе своих знаний и получает, что одно быстрее другого, хотя на самом деле сравнение не корректно изначально

Например Go стандартный http vs nginx

да кстати, парень из mail.ru рассказывал как они сравнивали скорость разных языков, и была у него такая фраза что они сделали сервер на go и узким местом оказался nginx стоящий перед сервером, слова не мои но прошедшие через призму моего восприятия

да кстати, парень из mail.ru рассказывал как они сравнивали скорость разных языков, и была у него такая фраза что они сделали сервер на go и узким местом оказался nginx стоящий перед сервером, слова не мои но прошедшие через призму моего восприятия

Может, он в нжинкс не умеет просто? У меня обычно по трафику сервер c nginx упирается раньше, чем по CPU

Мое субъективное мнение что Go теряет производительность на росте уровней абстракции. Например берем библиотечные операции, вставляем в свои функции, добавляем интерфейсы, засовываем в модуль, на модуль пишем обертку для основного процесса.

ну так Nginx то в этом случае работает намного больше. Серверу где он стоит надо из пакетов составлять соединения, надо хендшейки делать и поддерживать кучу открытых соединений.

ну так Nginx то в этом случае работает намного больше. Серверу где он стоит надо из пакетов составлять соединения, надо хендшейки делать и поддерживать кучу открытых соединений.

ну да, у меня тоже в режиме прокси тот нжинкс.

а бакенду любому запросы достаются по кипалив соединению от нгинкс

а бакенду любому запросы достаются по кипалив соединению от нгинкс

Тем более, если бэкенд по keep-alive, то хендшейков в разы меньше

их там просто нет считай

Мое субъективное мнение что Go теряет производительность на росте уровней абстракции. Например берем библиотечные операции, вставляем в свои функции, добавляем интерфейсы, засовываем в модуль, на модуль пишем обертку для основного процесса.

по моему все теряют на росте уровней абстракции, в EE яве, например, так люто ими обмазываются, что вообще уже никакой производетльности не остается уже, только куча из всяких abstratProxyFactoryBean вместо этого

потом выстраивание соединений из пакетов в линуксах сделан на хештаблицах которые по умолчанию компилятся маленькими, и не растут динамически, только compile time

если ты работаешь с 1М открытых соединений это очень плохо становится

по моему все теряют на росте уровней абстракции, в EE яве, например, так люто ими обмазываются, что вообще уже никакой производетльности не остается уже, только куча из всяких abstratProxyFactoryBean вместо этого

Кроме C. Чем более плоский код тем ближе к C. Возможно это все связанно с работой с памятью, сборщика мусора. Разумная плата за комфорт разработки.

если ты работаешь с 1М открытых соединений это очень плохо становится

То есть, нжинксу плохо, а Go справляется?

думаю если go голой попой выставить ловить 1М соединений вместо nginx, то все видно будет кто справляется

я не пробовал

Кстати, в блоге Интела читал, что главное ускорение PHP7 происходит от уменьшения структур памяти. Тупо меньше гоняют раздутых массивов и все работает быстрее. В этом смысле Go значально в очень хорошей позиции :)

ну чем меньше ты гоняешь памяти тем быстрее конечно, не только для пхп

думаю если go голой попой выставить ловить 1М соединений вместо nginx, то все видно будет кто справляется

тут ещё вопрос в том что го стандартная библиотека для http далека от идеальной в плане производительности

думаю если go голой попой выставить ловить 1М соединений вместо nginx, то все видно будет кто справляется

я пробовал. полет нормалный. более того, nginx перед go превращает 1M в 3M, и вот тут уже наступает жопа

fasthttp?

все равно 3М

а ты не настраивал чтобы апстримов коннекшенов было меньше?

нет - у меня websocket

и потом, как ты умудрился 3М соединений создать?

понастраивал ядро, че

соединение это четверка srcip:srcport:dstip:dstport, т.к. здесь три параметра фактически зафиксированы, соединений больше 65К быть не может

если еще учесть TIME_WAIT, то подавно