Как стать автором
Обновить
0
0

Пользователь

Отправить сообщение

Ребята, автору англоязычной статьи скорее всего занесли :). Никому не советую эти библиотеки в рабочем проекте. Обе эти поделки не дорастают до уровня miniconda.


пользовался pyenv, полёт нормальный, но я не пишу целые проекты на питоне, а только небольшие вспомогательные тулы. Можете пошарить ваш опыт - что не так с pyenv или poetry?

мне кажется что чисто программистов (в вакууме) немного - всё-таки часто люди имеют и другие сопутствующие способности, да и цена специалистов на рынке (как говорят) тоже увеличивается от сопутствующих навыков. По-моему тут важно не забыться и не возомнить себя профи, и когда надо - идти советоваться к специалистам в другой области.

нигде не смог увидеть автора книги. Что здесь на хабре, что на сайте издательства автор не указан, а на изображении книги плохо видно

В любой непонятной ситуации предпочту угрюмого хмыря

угрюмый хмырь по кличке Голый? )) (простите не удержался)

 что такие хмыри не умеют работать в команде, то я вам скажу, что вы не умеете ставить им задачи.

это нечасто что кто-то работает в изоляции и полностью автономно, обычно что-то приходится узнавать у других и спрашивать. Сложно что-то выяснить у других если ты угрюмый хмырь. Хард скиллы важнее, но минимальные социальные навыки нужны, как то умение поговорить с кем-то так чтоб он голову не воротил. Особенно это актуально сейчас, когда многие сидят на удалёнке. Общение стало асинхронным, и нужно чтоб люди отвечали, ну не бегать же каждый раз к начальнику и продавливать каждый раз чтоб начальник ходил их пинал

пишет как-то рекрутеру ответственный, с критическим мышлением, самостоятельный и работающий на команду парень, а рекрутер ему: "извините, но нам нужен человек с минимум 5 лет опыта, 2 это мало" )

 Почему эволюция не сделала процесс обучения без боли. Это же было бы гениально.


обучение это долгосрочная перспектива, т.е. профит особь получает только через время, возможно длительное. Наверное краткосрочные результаты были актуальны гораздо более длительный период, чем долгосрочные (ну там убежать от саблезубого тигра). Но я не специалист, просто предположил))

ну Uber тоже поморочился чтобы управлять сложностью микросервисов. Не понял суть вашего месседжа. Вы говорите что "это не настоящие микросервисы", но сами признаете что настоящих нигде нет. Тогда выходит что и у Убера вышла какая-то фигня раз они стали заморачиваться как управлять зоопарком?

в этом подходе не очень нравится то что теперь существует оба варианта обработки ошибок параллельно. В теории все выглядит хорошо, но я видел проекты в которых писали с таким подходом и выходила мешанина. Поскольку Either это надстройка, а сам язык работает с исключениями, то в итоге приходится иметь дело и с исключениями, и с Either. Я видел такое и по итогу выходило что параллельно существовали одни и те же ошибки в виде исключений и объектов, и код который в try обрабатывал ошибки в ФП стиле, но и catch все равно ставил, т.к. исключения по прежнему возможны. Either выглядит как workaround, потому что нет проверяемых исключений. Плюс это возврат к старому С-стилю кодов возврата, только с небольшим синтаксическим сахарком. Насколько я понял, каких-то дополнительных статических гарантий Either не дает, и вполне можно пропустить ветку обработки ошибок точно так же как и проигнорировать исключения, или нет?

Citation needed. Получается несколько голословно.

По моему опыту разница существенная.

у меня сейчас нет под рукой хороших ссылок, в основном по бэнчмаркам видел что разница небольшая. Мне кажется это логично т.к. в вебсервисах (и особенно микросервисах) чаще io-bound задачи, т.е. вебсервис это не числодробилка.
Если у вас есть какой-то опыт или статейки - пошарьте, расскажите, будет интересно услышать
со своей стороны, вот, может будет интересно
https://go.dev/blog/ismmkeynote

 Но во-первых защищает так же от data race, т.е. накосячить с многопотоком в расте действительно сложно.

видимо вы имеете в виду что из-за передачи владения не выйдет поменять. В принципе может и так, но если говорить о гонках вообще - то думаю вряд ли Раст от них защитит (data races - это подмножество race condition).
Кстати, у Go тоже есть анализатор гонок данных, только запускается он отдельно, но ничто не мешает его встроить в какие-то части билд пайплайна на CI/CD
Насчет репортов Гугла и 70% ошибок из-за памяти - этот пласт ошибок актуален больше для языков без GC. В Go тоже можно кое-где накосячить с escape analysis, а в java сделать утечку памяти тоже реально, но в целом ситуация проще. Если сравнивать с языками с GC, тогда нет смысла говорить о защите от ошибок памяти - будем считать что и те и другие решают эту проблему, просто по своему. Расту записываем очко за перформанс, но надо понять какой он именно для веб-сервисов. Выносим за скобки защиту от гонок данных и ошибок памяти, считая что они у Го и Раст примерно те же. Итого, что остается у Раст как преимущество в плане именно защитного программирования? Наверное вы скажете что мощная система типов.

А если ещё и пользоваться возможностями систем типов по полной — то тут и бизнесовые баги можно вылавливать.

простой код проще анализировать и видеть в нём ошибки бизнес-логики, и ошибки бизнес-логики проще отлавливать в коде который не засоряет глаза обилием подробностей и неизбежных накладных расходов мозга (интеллектуальных, визуальных - при восприятии) при анализе кода из-за того что код содержит высокое число защитных техник, которые решают лов-левел ошибки (вроде памяти). Т.е. вам кажется что статический анализ может защитить от багов бизнес-логики, а мне кажется что не так уж и сильно и простой для чтения и восприятия код - тоже довольно мощная защита от ошибок бизнес-логики, и как тут проверить кто прав? И то и другое всего лишь умозрительные рассуждения.
Скажем мы в java на нескольких проектах очень активно пользовались даже несколькими стат. анализ тулами, и в конечном итоге отключили их т.к. они приносят очень мало пользы.
Многие советы по написанию кода связаны со снижением давления на восприятие - длина методов, длина файлов, длина строки - всё это направлено на снижение давление и перегруз мозга деталями. Сложный синтаксис и обилие защитных техник - это из той же области. Например простыню простого и дубового кода, в котором вещи делаются просто и прямолинейно, я могу отрефакторить и просто разбить на несколько методов, а вот воспринимать код в котором на каждую строку идет большая интеллектуальная нагрузка мне сложнее. Конечно это дело вкуса, не спорю. Может средние программист на Rust умнее и у него буфер памяти в голове больше, но тогда этот язык будет сложно сделать массовым)

Для вебсерверов раст более чем полезен. Я лично год назад переписывал с шарпа на раст одну штуку. 10 тысяч строк были переписаны за неделю, небольшой сервисок. Снизили нагрузку на порядок, потребление памяти в пару раз. Вполне неплохой результат кмк. Не говорю что на каком-нибудь го было бы хуже, но и не лучше.

Интересно, спасибо.
А использовали при этом асинхронный ввод-вывод?

Вы явно недооцениваете сколько инженеров можно добавлять на оптимизацию кода, пока это не станет невыгодным. Понятно, что не все гугл, но даже компании в пару десятков человек сталкиваются с миллиоными счетами на инфраструктуру. Попробуйте узнать, сколько ваша компания тратит на это, возможно это будет сюрпризом.

я вполне верю, т.к. видел траты крупных компаний на инфраструктуру. Т.е. сама идея уменьшения биллинга на ресурсы конечно разумная. Просто у Гугла допустим тоже огромные системы, и они вполне неплохо обкатали Го для этого. Тоже как никак опыт.
Кстати насчет трат, мой опыт говорит что прожорливые технологии на серверах бэкэнда это не единственная проблема. Часто сам AWS подсаживает на такие технологии которые дорогие. DynamoDB например очень дорогая.
вот статейка занятная, если лень читать всю, то можете просто вбить "DynamoDB hot shards"
https://segment.com/blog/the-million-dollar-eng-problem/

Ничего не мешает нанять двух разработчиков, правда?

та понятно что можно, но нужно учитывать и стоимость поддержки. Более сложная технология (а Раст - такая) - больше стоимость поддержки (а это не 1 месяц, а годы). Я анализирую в основном по тому что прямо сейчас происходит на рынке. Даже крупные компании типа AWS используют Rust только в критических частях инфраструктуры. Если вдруг они начнут переписывать и перепишут всё остальное - тогда это будет повод задуматься.

многовато вышло текста, надеюсь не утомил)

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

Rust начали использовать в AWS точно, но я не помню используют ли они его именно для веб сервисов. По-моему больше используют какраз как системный язык. Google же вполне адаптировал Go. Я думаю что потребление памяти, пропускная способность и задержка у Go незначительно хуже чем у Rust, а вот отсутствие GC усложняет кодирование. Rust же защищает в большинстве случаев от ошибок памяти. От дэдлоков или гонок уже не защищает, верно? Итого выходит что сколько там той безопасности по итогу. Ошибки при кодировании связаны не только с памятью, и нет такой системы типов которая бы защищала от ошибок бизнес-логики. Я бы назвал это когнитивный биасом "переоценка типизации для предотвращения ошибок" (я вижу что некоторые считают что стоит сделать супермощную систему типов, и это будет панацея) Во-всяком случае я не видел исследований которые бы говорили какой процент ошибок памяти в программах на java. Можно конечно утверждать что остальные ошибки в java коде связаны со слабой (по мнению раст-сообщества) системой типов, но думаю это уже было бы ничем не подкрепленным заявлением. При этом Go имеет встроенный тулинг для профайлинга, быстро билдится, а значит ускоряет цикл фидбэка программисту.
Короче я не вижу реально сколько-нибудь несубъективных моментов. Вижу только что Google почему-то вполне адаптировал Go для части вебсервисов, но я не слышал ничего подобного о Rust (может просто не слышал?). Нельзя же полагать что они там в Google все дураки?

лично я со своей колокольни вижу что Rust может быть применен для написания вебсерверов, но для вебсервисов - в 95% это оверкил. Если же говорить чисто о субъективных предпочтениях, то понятно что нормальный архитектор по возможности пытается избегать личной предвзятости в выборе инструментов

Если же речь про какую-нибудь онлайн игрушку желательно с тридэ, то у раста уже есть шансы

ну зато интересная мысль, чо )

уже за миллион рублёв в месяц, а разраб который мог бы срезать их количество в разы стоит всего пару сотен.

что-то мне подсказывает что не все так просто) Если такие счета, то вряд ли это мелкая система которую перепишут за 1 человеко-месяц. А если взяли более сложный инструмент - получите более высокую стоимость поддержки этого кода (всегда). Сколько будет стоить уже такой разклад? Наверняка выгода-то будет, но спустя время, и надо садиться и считать. А за то время пока кто-то переписывает продукт чтоб сократить биллинг ресурсов - кто-то другой делает новые фичи и имеет потенциал откусить часть рынка

я понял, вам очень нравится Rust )
я думал как бы мнение-анализ получить, по факту вышел просто обмен предпочтениями.
Из абзаца про Go я смог вычленить пару пунктов
1) cтатическая типизация
2) наличие готовых решений
3) наличие/отсутствие GC

из этих пунктов 2й и 3й могут в общем-то повлиять на выбор, если есть какие-то ультра серьезные требования вроде как в случае Discord. В целом я интересовался юзкейсами наподобие этого, можете ли вы назвать еще какие-нибудь

Почему нет?
https://yew.rs
https://rustwasm.github.io/wasm-bindgen/web-sys

ну самого наличия и существования этих библиотек недостаточно же ))

сейчас идет тенденция на скорость разработки, никто не пытается делать "на века". Играет роль выход на рынок. В лучшем случае после успешного выхода на рынок, некоторые части начинают переписывать. Потому делают на тех инструментах на которых быстрее. Судя по тому что происходит, эта тенденция только усиливается. И в вебе (фронтэнде) лабать нужно очень быстро. Потому даже если на Rust писать и можно, вряд ли это станут делать в большом количестве
я допускаю мысль (в порядке фантазий) что все вдруг озаботятся счетами на AWS и будут смотреть как их обгоняют конкуренты, модернизируя свои системы быстрее, но ставочку я сделаю все же на то что Rust не только не заменит JS на фронтэнде, а скорее JS заменит большую часть кода и на сервере )

реально на всю? И вместо Javascript?
Касательно серверной ниши, на хабре были статейки (прямо на этом хабе, посвященном Rust) что с асинхронностью в Rust непросто https://habr.com/ru/company/macloud/blog/564812/

Некоторая ниша уже успешно занята Go. При этом Go - специализированный нишевый язык, хорошо заточенный под нишу микросервисов, переболбашивания данных, серверлесс, низкую лейтенси, и может что-то ещё. Чтобы выбить Go из этой ниши, какие факторы должны сыграть? Давайте пока оставим за скобками анализ чисто языковых конструкций, т.к. выбор инструмента это гораздо больше чем наличие системы типов и тд (есть много багов которые никакая система типов не порешает). Rust же - язык общего назначения (хотя скорее системный). Я могу представить какие-то узкие кейсы где Rust может быть лучше, но это будет низкий процент.

Ниша большого интерпрайза занята С# и java. Там где не нужны low latency и то остальное что для Go - это их ниша. У них есть огромное число готовых решений. Иногда джаву выбирают даже тупо потому что клиенты Кафки на других языках не поддерживают нужный спектр фич. Банально? Да, но вот так.

Тут дело в том, что недостаточно просто каких-то прикольных фич в языке. Недостаточно бежать быстро, нужно бежать быстрее чем конкуренты.

Так что я немного уточню вопрос:
1) где, по-вашему, стоит взять Rust вместо Go? Каковы кейсы, критерии
2) тоже самое по сравнению с java/c#
3) тоже самое по сравнению с JS

на какую нишу в вебе претендует Rust?

Rust по-моему посложнее и Go и Python. Может его адаптируют для системных задач вполне, только пройдут годы для миграции с С++, мне кажется лет 10

@nsinreal
cпасибо большое за книжечку и ответ

а где-то описан этот принцип что вы говорите? Может есть ссылка или книга ?

Какая связь между java + Spring и Kubernetes?

речь не о Spring+java, а о стэке Netflix для микросервисов, который (так уж совпало) базируется в основном на Spring.

Я читал вот тут, https://en.wikipedia.org/wiki/Microservices (см раздел A comparison of platforms) в связи с чем и возник вопрос

вопрос к знатокам, может кто в теме: вроде как классическим стэком для микросервисов длительное время был стэк Netflix (по большей части это java и Spring). Но в последние годы всё больше двигаются в сторону Kubernetes. Как считаете, лучше ли Kubernetes? Что насчет service mesh?

Голову на место мне вставила книжечка по DDD+микросервисам - показала, где именно есть место микросервисам


присоединяюсь к просьбе, что за книжечка?

Вот смотрите. Есть такое правило. Надо писать код без goto. Нарушается? Нарушается! Раньше — больше. Сейчас — куда меньше, но все равно goto есть и нужен. Разве правило дурацкое? Да ни в коем случае, замечательное правило.

Так что я не думаю, что моя идея расходится с реальностью.

Netflix является и типичным, и атипичным примером. Типичным — потому что именно для таких компаний как netflix микросервисы дают огроменную выгоду. Атипичным — потому что в большинстве систем будет 10-100 микросервисов

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

(цитирую разные участки чтоб собрать в кучу цепочку мыслей)

идея понятна - надо стараться делать как лучше, несмотря на плохие примеры в отрасли. Т.е. вы считаете что обычно у компаний 10-100 микросервисов, и такие ситуации когда обрабатывают запрос 5 микросервисов по цепочке - скорее всего в 99% случаев результата плохого проектирования, верно?

просто вы сами отметили, что спроектировать правильно почти никому не удаётся, потому-то и интересно - не становятся ли бест-практики для микросервисов своего рода недостижимым идеалом. У вас не было в личной практике случаев перепроектирования и скажем упрощения архитектуры с урезанием числа микросервисов?

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

почему? Как вы это определили, не видя систему?

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность