В Мэйле (ныне часть ВК) и Яндексе ещё много Perl. Но от него активно пытаются избавиться (в основном, переходя на Go), т.к. нанять нового разработчика или стажёра стало невероятно трудно.
Говорят, Booking.Com весь на перле. Не знаю, как сейчас, но лет пять назад мне писал их хантер со словами «неважно, если вы вдруг не знаете Perl, мы вас научим. Вы только приходите, пожалуйста». И это он не меня так высоко оценивал, а явно шаблон рассылал всем подряд.
Я успел пописать на IcedCoffeeScript. Его await+defer немного отличался от того, что потом стали понимать async+await, т.к. он был реализован ещё на колбэках, без промисов.
Он позволил мне быстро накидать логику, и в целом способствовал моему совершенствованию в конкурентном программировании. Но в процессе рефакторинга, большую часть сахара я переделал обратно на колбэки. Осталось одно или два места с await+defer.
Вы не правы во всём. В каждом описанном вами случае это была не лень, а выбор между различными компромиссами. И то, что выбор разработчиков Го не совпал с вашими предпочтениями, не говорит о их лени. Просто у них были другие предпочтения.
А если Вы заговорили о лени, то где же написанный Вами язык, реализующий все Ваши предпочтения? Лень писать?
Я работал в кодовой базе на Го, написанной бывшими джавистами. И сперва не понимал, зачем они делают так сложно. Со временем стал осознавать, что это не «сложно», а на самом деле «необходимо». (Ок, я чуть привираю: до конца я так и не осознал, но стал понимать мотивы и некоторые сперва неочевидные плюсы).
Простые вещи действительно хотелось бы делать простыми вещами и способами. Но когда проект растёт, простые способы перестают работать.
Энтерпрайзные фреймворки изначально сделаны для сложных вещей, и пока ты до таких вещей не дорос, фреймворки кажутся избыточными. Но для сложных вещей фреймворки сложность превращают в рутину: есть стандартные решения стандартных задач, и 95% твоих задач - стандартны.
А так блок в блок бы вкладывал. Разница чисто синтаксическая, механизм был бы тем же, скорее всего.
Мне не нравятся Го-шные defer не из-за синтаксиса, а из-за привязки к времени жизни функции. Привязка к блоку, как в большинстве языков (RAII, или finally, или defer, где он тоже есть) выглядит намного органичнее.
Я понимаю, почему было привязано к функции: 1. так проще реализовать (просто список колбэков без сложностей со стороны компилятора), 2. изредка удобнее (если инициализация ресурса и, соответственно, defer на его «отпускание» зависят от условия).
Графики и таблица как-то странно друг с другом не совпадают. Графики подписаны практически одинаково, а результаты на них разные. Вообще не понятно, чему верить?
Вы давали кому-нибудь прочитать без предварительного показа графиков и рассказа, что на них? Кажется, все проверяющие знали, что на графиках, и потому не стали вчитываться.
А вот мне совершенно не понятно, как цифра в различных представлениях в статье друг с другом соотносятся.
В том виде, как написано, Head Of Line Blocking вредит и HTTP2, т.к. это общая проблема для TCP.
Но у пайплайнинга HTTP1.1 есть и свой Head Of Line Blocking: если обработка полученного запроса очень долгая, ответы на следующие запросы (а чаще всего, и их обработка) вынуждены будут ждать.
А с HTTP2 этой проблемы нет: сервер может получить, обработать и послать ответ на следующие запросы, не дожидаясь, пока закончится обработка (или даже получение) предыдущего.
Вот только не понятно, зачем остальные усложнения HTTP2. Сквозной HPACK, push потоки (которые в итоге отмерли) - вот ерунда, экономия на спичках. Давно уже был FastCGI, который, как протокол, решил проблему отправки конкурентных запросов. Жалко, правда, что реализаций полноценных его мало :-( (в Nginx реализация не полноценная).
Забавно: я - «опытный разработчик», но ещё не дорос до Rust.
При этом не далее как на новогоднем корпоративе имел беседу с девопс-ом, который признался, что в последнее время предпочитает писать «скрипты» на Rust вместо Bash, Perl или Python, т.к. получается «понятнее, компактнее и производительнее».
В коде очереди ошибка: value нужно получать не из oldHead->data, а из oldHead->next.load()->data . И в цикле перед этим нужно ждать, чтобы oldHead->next.load() кто-нибудь заполнил. А сейчас у вас очередь просто порвётся, если продюсер не успеет новую ноду подсунуть.
Ещё в Дюне описывался мир после войны с ИИ. Правда там люди победили, что в реальности мало вероятно.
Вы правы, но и моё утверждение тоже: портал mail.ru, мой мир и прочие сервисы сейчас «часть VK». А уж каким образом оно так получилось, я не уточнял.
1С нас с вами переживёт. Он и до импортозамещения себя неплохо чувствовал, а теперь и большие конторы его вынужденно внедряют вместо «ушедшего софта».
В Мэйле (ныне часть ВК) и Яндексе ещё много Perl. Но от него активно пытаются избавиться (в основном, переходя на Go), т.к. нанять нового разработчика или стажёра стало невероятно трудно.
Говорят, Booking.Com весь на перле. Не знаю, как сейчас, но лет пять назад мне писал их хантер со словами «неважно, если вы вдруг не знаете Perl, мы вас научим. Вы только приходите, пожалуйста». И это он не меня так высоко оценивал, а явно шаблон рассылал всем подряд.
Я успел пописать на IcedCoffeeScript. Его await+defer немного отличался от того, что потом стали понимать async+await, т.к. он был реализован ещё на колбэках, без промисов.
Он позволил мне быстро накидать логику, и в целом способствовал моему совершенствованию в конкурентном программировании. Но в процессе рефакторинга, большую часть сахара я переделал обратно на колбэки. Осталось одно или два места с await+defer.
Не только PHP. Современный Python, Ruby и (могу ошибаться) JavaScript тоже гарантируют итерацию в порядке добавления.
Рад, что у вас был другой опыт…
Вы не правы во всём. В каждом описанном вами случае это была не лень, а выбор между различными компромиссами. И то, что выбор разработчиков Го не совпал с вашими предпочтениями, не говорит о их лени. Просто у них были другие предпочтения.
А если Вы заговорили о лени, то где же написанный Вами язык, реализующий все Ваши предпочтения? Лень писать?
А вы не путайте количество строк и сложность кода.
Я не зря сказал, что все эти проверки мозг со временем игнорирует, и видит только основную логику кода.
Да, сложнее её осознавать, т.к. она не помещается «в один взгляд». Но это отнюдь не кратное усложнение.
Плюсую. Го - это и вторая пыха, и вторая жаба.
Я работал в кодовой базе на Го, написанной бывшими джавистами. И сперва не понимал, зачем они делают так сложно. Со временем стал осознавать, что это не «сложно», а на самом деле «необходимо». (Ок, я чуть привираю: до конца я так и не осознал, но стал понимать мотивы и некоторые сперва неочевидные плюсы).
Простые вещи действительно хотелось бы делать простыми вещами и способами. Но когда проект растёт, простые способы перестают работать.
Энтерпрайзные фреймворки изначально сделаны для сложных вещей, и пока ты до таких вещей не дорос, фреймворки кажутся избыточными. Но для сложных вещей фреймворки сложность превращают в рутину: есть стандартные решения стандартных задач, и 95% твоих задач - стандартны.
Дисклеймер: я люблю Го в его простоте.
А так блок в блок бы вкладывал. Разница чисто синтаксическая, механизм был бы тем же, скорее всего.
Мне не нравятся Го-шные defer не из-за синтаксиса, а из-за привязки к времени жизни функции. Привязка к блоку, как в большинстве языков (RAII, или finally, или defer, где он тоже есть) выглядит намного органичнее.
Я понимаю, почему было привязано к функции: 1. так проще реализовать (просто список колбэков без сложностей со стороны компилятора), 2. изредка удобнее (если инициализация ресурса и, соответственно, defer на его «отпускание» зависят от условия).
Но всё же привязку к блоку хочется чаще.
да, выводят за пределы экрана.
нет, усложнение не «втрое»
Я поймал себя на том, что, читая код, пропустил все if err != nil.
Да, читать менее удобно, и в один glimpse код не помещается. Но разница не в три, и даже не в два раза. Максимум полтора, а то и процентов 10-15%.
Вы упомянули Koka. Вы его уже для чего-нибудь применяли? Есть впечатления от практического использования?
Хмм… нужно попробовать…
Я нормально читаю логарифмические шкалы, у меня с этим проблем нет.
Графики и таблица как-то странно друг с другом не совпадают. Графики подписаны практически одинаково, а результаты на них разные. Вообще не понятно, чему верить?
Вы давали кому-нибудь прочитать без предварительного показа графиков и рассказа, что на них? Кажется, все проверяющие знали, что на графиках, и потому не стали вчитываться.
А вот мне совершенно не понятно, как цифра в различных представлениях в статье друг с другом соотносятся.
Увы, от любого сидения так. Вы вставали каждые 10-15 минут с него, чтобы кровь «там» разошлась? Пили ли достаточно жидкости?
У самого геморрой от вечного сидения за компом. От велотренажера проблем не было. Но я ни когда больше 15 минут подряд не занимался.
В том виде, как написано, Head Of Line Blocking вредит и HTTP2, т.к. это общая проблема для TCP.
Но у пайплайнинга HTTP1.1 есть и свой Head Of Line Blocking: если обработка полученного запроса очень долгая, ответы на следующие запросы (а чаще всего, и их обработка) вынуждены будут ждать.
А с HTTP2 этой проблемы нет: сервер может получить, обработать и послать ответ на следующие запросы, не дожидаясь, пока закончится обработка (или даже получение) предыдущего.
Вот только не понятно, зачем остальные усложнения HTTP2. Сквозной HPACK, push потоки (которые в итоге отмерли) - вот ерунда, экономия на спичках. Давно уже был FastCGI, который, как протокол, решил проблему отправки конкурентных запросов. Жалко, правда, что реализаций полноценных его мало :-( (в Nginx реализация не полноценная).
Забавно: я - «опытный разработчик», но ещё не дорос до Rust.
При этом не далее как на новогоднем корпоративе имел беседу с девопс-ом, который признался, что в последнее время предпочитает писать «скрипты» на Rust вместо Bash, Perl или Python, т.к. получается «понятнее, компактнее и производительнее».
Получается, «разруха в головах, а не в сортирах».
В коде очереди ошибка: value нужно получать не из oldHead->data, а из oldHead->next.load()->data . И в цикле перед этим нужно ждать, чтобы oldHead->next.load() кто-нибудь заполнил. А сейчас у вас очередь просто порвётся, если продюсер не успеет новую ноду подсунуть.