ЧАСТО это относительно: до и после удаленнки. Наверное слово ЧАЩЕ было бы уместнее. Конечно это ЧАСТО у каждого разное. Кому-то с семьей, пет-проектом и пара интервью в месяц уже много энергии отнимает. А так у всех свое мнение) Говорю только за свой личный опыт и опыт знакомых.
Я специально указал слово 'часто' в утверждении: "резко отбивает желание ЧАСТО ходить на собедования". Конечно ходили. Но факт собеседования не означает 100% оффер. Имхо чаще проходить интервью было лень)
Еще до всяких удаленок часто можно было видеть джуна, приходящего в офис в 8-9, а синьора в 12. Свободный график был нормой в ит еще до ковида, пускай и негласной. А одно интервью вполне может уложиться в обеденное время. Больше часа скорее редкость.
Ходить искать переговорную каждый раз или объяснять руководителю, чем не доволен на текущем месте. У нас в области и так максимальная концентрация интровертов) А в bigtech твой менеджер, узнав о твоих интервью, может заблаговременно отправить тебя на PIP и сразу начать искать замену. Все равно так же часто ходить на интервью будет сложно.
Да даже если второй работы нет, просто собеситься на новые позиции из офиса уже будет нельзя, если не отпрашиваться. Ведь собесы всё равно всегда в рабочее время все проводят. Остаётся в таком случае уповать только на редкие weekend-офферы.
ИМХО Считаю что это первая причина для отмены удаленок. Рынок труда, как и фондовый рынок не может адекватно оценить актив без ликвидности. Когда процесс продажи актива (своего времени) и поиска покупателя затруднен. Когда для тебя поход на собес, это путешествие из своего уютного офиса / дома в чужой, резко отбивает желание часто ходить на собедования, даже если не доволен своим текущим местом. Работая удаленно я мог устравать 2-3 собеседования в день в активном поиске, или 2-3 интервью в месяц пассивно проверяя рынок и сравнивая предлагаемую зп с текущей. Даже если устраивает текущее место, всегда можно поторговаться "оффером". Что я думаю, как и я, делали многие. А компании конежно же это раздувает ФОТ.
Кстати можете добавить, что Option<T> и Result<T, E> по сути являются итераторами, которые при итерации возвращают один элемент если что-то есть внутри или ничего в противном случае
Если вам действительно интересно и вы не хотите просто потролить.
То есть к примеру классификация Amazon где они делят все существующие решения на monolithic, SOA (сервисы) и microservices(микросервисы) и описывают где проходит грань с примерами. Естествено я допускаю что классификаций много и мнения есть другие. По этому это вечный вопрос)
В плане веба большой монолит чаще (но не всегда) считается плохой практикой. Но вот самый большой проект на rust в одном репозитории (не веб), что я знаю это сам компилятор языка. Там по сути много маленьких crates, которые прилинкованы к корневому workspace. Кажется что лепить что-то большое можно, хоть я и не пробовал лично)
В плане "железа" для rust проектов экономить не приходится. Ведь если с нуля, то компилируются все все зависимости.
Если зарплату не увеличат, то работник пойдет к тому кто осободившиеся деньги в ФОТ потратит на повышение зп. А тк находят новую работу чаще работники получше, то потеря хороших кадров будет очень вредна для экономящих и полезна для справедливо платящих. Рыночек) (это конечно в ситуации если услуги работников не переоценены рынком на текущий момент)
Если зарплату не увеличат, то работник пойдет к тому кто осободившиеся деньги в ФОТ потратит на повышение зп. А тк находят новую работу чаще работники получше, то потеря хороших кадров будет очень вредна для экономящих и полезна для справедливо платящих. Рыночек) (это конечно в ситуации если услуги работников не переоценены рынком на текущий момент)
У вас больше вопрос к разработке и опыту с ide, которые подерживают rust все лучше с каждым годом, но все еще не очень по сравнению с Java/Kotlin/C#. JetBrains уже отдельную ide для rust выкатили RustRover но еще в альфа релизе. А rust компилятор выводит довольно хорошие подсказки для новичков. Тем не менее после полугода работы с языком понимаешь сам без помощи компилятора, когда код собирется и как писать нужно т.е становишься продуктивнее и в плане чтения кода тоже. Библиотеки конечно бывают разные, ваша правда) Но потенциал развития довольно большой. Все частоиспользуемые либы вроде сериализаций(serde), веб фреймворков уже довольно хороши. Касательно больших проектов. Большая часть бэкенд сервисов одной крупной криптобиржи написано на rust https://blog.kraken.com/product/engineering/oxidizing-kraken-improving-kraken-infrastructure-using-rust и воочию выглядели неплохо.
Кстати нет. Не так давно видел вакансии на Rust в Сбере, МТС и Тиньке помимо мелких компаний и стартапов. Ну и зарубежных удаленных еще больше. И поскольку язык молодой требований из серии 5-10+ лет опыта на нем нет.
Стоимость ошибок вызваных переводом ИИ будет высокой тогда. Так как не зная другого языка даже понять, что есть ошибка трудно. А функции/переменные в коде тогда тоже на своем языке называть а потом отдавать ИИ на перевод?)
Для воторого случая, как раз подсчет среднего веса пассажира вместе со среднем весом ручной клади будет актуальнее для эксплуатации самолета, чем вес отдельно взятого пассажира
Ну можно взять последнию стоимость компании, когда она торговалась и ее прибыль тогда и сравнить с текущими оценками прибыли. Как говориться ballpark оценка (с футбольный стадион). Те с погрешностью но все же
ЧАСТО это относительно: до и после удаленнки. Наверное слово ЧАЩЕ было бы уместнее. Конечно это ЧАСТО у каждого разное. Кому-то с семьей, пет-проектом и пара интервью в месяц уже много энергии отнимает. А так у всех свое мнение) Говорю только за свой личный опыт и опыт знакомых.
Я специально указал слово 'часто' в утверждении: "резко отбивает желание ЧАСТО ходить на собедования". Конечно ходили. Но факт собеседования не означает 100% оффер. Имхо чаще проходить интервью было лень)
Еще до всяких удаленок часто можно было видеть джуна, приходящего в офис в 8-9, а синьора в 12. Свободный график был нормой в ит еще до ковида, пускай и негласной.
А одно интервью вполне может уложиться в обеденное время. Больше часа скорее редкость.
На обед тоже надо отпрашиваться? Или подразумевается, что кушать нужно за монитором??
Ходить искать переговорную каждый раз или объяснять руководителю, чем не доволен на текущем месте. У нас в области и так максимальная концентрация интровертов)
А в bigtech твой менеджер, узнав о твоих интервью, может заблаговременно отправить тебя на PIP и сразу начать искать замену.
Все равно так же часто ходить на интервью будет сложно.
ИМХО Считаю что это первая причина для отмены удаленок. Рынок труда, как и фондовый рынок не может адекватно оценить актив без ликвидности. Когда процесс продажи актива (своего времени) и поиска покупателя затруднен. Когда для тебя поход на собес, это путешествие из своего уютного офиса / дома в чужой, резко отбивает желание часто ходить на собедования, даже если не доволен своим текущим местом. Работая удаленно я мог устравать 2-3 собеседования в день в активном поиске, или 2-3 интервью в месяц пассивно проверяя рынок и сравнивая предлагаемую зп с текущей. Даже если устраивает текущее место, всегда можно поторговаться "оффером". Что я думаю, как и я, делали многие. А компании конежно же это раздувает ФОТ.
Как минимум странно упомянуть сихронный diesel и асинхронный warp рядом. Их точно имеет смысл использовать вместе?
Кстати можете добавить, что Option<T> и Result<T, E> по сути являются итераторами, которые при итерации возвращают один элемент если что-то есть внутри или ничего в противном случае
Если вам действительно интересно и вы не хотите просто потролить.
То есть к примеру классификация Amazon где они делят все существующие решения на monolithic, SOA (сервисы) и microservices(микросервисы) и описывают где проходит грань с примерами. Естествено я допускаю что классификаций много и мнения есть другие. По этому это вечный вопрос)
Согласен, согласен. Тут общего мнения нет. It depends.
Что бы холивары не разводить, поэтому так и выразился) "Маленький/средний монолит" точно считаю нормой.
А это вечный вопрос)
В плане веба большой монолит чаще (но не всегда) считается плохой практикой. Но вот самый большой проект на rust в одном репозитории (не веб), что я знаю это сам компилятор языка. Там по сути много маленьких crates, которые прилинкованы к корневому workspace. Кажется что лепить что-то большое можно, хоть я и не пробовал лично)
В плане "железа" для rust проектов экономить не приходится. Ведь если с нуля, то компилируются все все зависимости.
Если зарплату не увеличат, то работник пойдет к тому кто осободившиеся
деньги в ФОТ потратит на повышение зп. А тк находят новую работу чаще
работники получше, то потеря хороших кадров будет очень вредна для
экономящих и полезна для справедливо платящих. Рыночек) (это конечно в
ситуации если услуги работников не переоценены рынком на текущий момент)
Если зарплату не увеличат, то работник пойдет к тому кто осободившиеся деньги в ФОТ потратит на повышение зп. А тк находят новую работу чаще работники получше, то потеря хороших кадров будет очень вредна для экономящих и полезна для справедливо платящих. Рыночек) (это конечно в ситуации если услуги работников не переоценены рынком на текущий момент)
У вас больше вопрос к разработке и опыту с ide, которые подерживают rust все лучше с каждым годом, но все еще не очень по сравнению с Java/Kotlin/C#. JetBrains уже отдельную ide для rust выкатили RustRover но еще в альфа релизе. А rust компилятор выводит довольно хорошие подсказки для новичков. Тем не менее после полугода работы с языком понимаешь сам без помощи компилятора, когда код собирется и как писать нужно т.е становишься продуктивнее и в плане чтения кода тоже. Библиотеки конечно бывают разные, ваша правда) Но потенциал развития довольно большой. Все частоиспользуемые либы вроде сериализаций(serde), веб фреймворков уже довольно хороши. Касательно больших проектов. Большая часть бэкенд сервисов одной крупной криптобиржи написано на rust https://blog.kraken.com/product/engineering/oxidizing-kraken-improving-kraken-infrastructure-using-rust и воочию выглядели неплохо.
Кстати нет. Не так давно видел вакансии на Rust в Сбере, МТС и Тиньке помимо мелких компаний и стартапов. Ну и зарубежных удаленных еще больше. И поскольку язык молодой требований из серии 5-10+ лет опыта на нем нет.
Стоимость ошибок вызваных переводом ИИ будет высокой тогда. Так как не зная другого языка даже понять, что есть ошибка трудно. А функции/переменные в коде тогда тоже на своем языке называть а потом отдавать ИИ на перевод?)
Для воторого случая, как раз подсчет среднего веса пассажира вместе со среднем весом ручной клади будет актуальнее для эксплуатации самолета, чем вес отдельно взятого пассажира
Это же демо. Они уже знают, что пули мягче корпуса и сомнуться/расколятся. 9 миллеметровая болванка не отлетит в глаз) Так тест честнее и зрелищнее
Цена исправления последствий риска: 5 уколов в мягкое место. Если у вас нет детской травмы, то звучит не так страшно)
Ну можно взять последнию стоимость компании, когда она торговалась и ее прибыль тогда и сравнить с текущими оценками прибыли. Как говориться ballpark оценка (с футбольный стадион). Те с погрешностью но все же