Доброго времени суток Только пробую для себя язык В данный момент пишу

java + Spring
Подскажите, есть ли востребованные (популярные) веб фреймворки для Rust?

Может не нада

Из востребованного и популярного actix

Вопрос зачем? Spring нормальный фреймворк для разработки. Какие качества нужны, что востребован переход на низкоуровневый язык

+

С каких пор толсто намазанный DI поверх фабрик стало нормальным?

Ява не сильно высокоуровней раста, это не питон/руби/жс

actix-web и все

Всегда?

Как будто питон/руби/жс сильно высокоуровневей явы. Но у них у всех есть GC и потому замыкания без головной боли, так что они слегка высокоуровневей раста.

Актикс легаси

Сильно. Суть в jvm.

На этом моменте давайте в оффтопик)

А потом память течёт, потому что сохранили замыкание, которое захватывает слишком много

В спринге всегда.

Забавно, что я-то указал хоть какие-то аргументы для своего заявления. Видимо, аргументированные высказывания — это оффтоп. 😁

В любом среднем веб проекте без диая с фабриками будет макаронная каша в определении зависимостей)

Пора в системное программирование затащить Яву, ага... *sarcasm*

Всегда вопрос для каких задач. Споры в этих вещах всегда упираются в контекст, без контекста спорить не о чем

Как раз таки DI и вызывает макароны Тонский это хорошо описал

Что значит "течёт"? Чем это отличается от ручного Box::leak?

Вообще-то, давно затащили...

Мой ответ был в контексте веб разработки, а не в целом

Кстати, где? Любопытно почитать его мнение по этому поводу. 😊

Ссылок на тонского мы давать не будем?

Куда?))

а есть линк?

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

https://t.me/nikitonsky_pub/141

А что Вы считаете системным программированием? Распределённые системы? ✅ Сетевые службы? ✅ Файловые системы? ✅ ОС? ✅ Управление роботами? ✅

Т.е. от Box::leak отличается тем, что про ссылку знает GC. 👌😊

>dependency injection, он же ioc. Почему названия два? Наверное два лидера было. Вы всерьез считаете авторитетным такой источник? 😂

Лол ) он же конечно (нет)

можно еще вспомнить что в означенных языках у захватываемых переменных indefinite extent, да

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

Могу дать другую ссылку: https://blog.ploeh.dk/2017/01/27/from-dependency-injection-to-dependency-rejection/ Не то, чтобы я был строго против DI и считал, что он превращает код в лапшу, но, с другой стороны, кажется, при нормальной hexagonal architecture DI действительно особо не нужен, ни в ООП, ни в ФП. Ни в Rust. 😊

будто раст в системном программировании используют!

Он описывает DI 15 лет назад. Вы всерьез считаете что за 15 лет ничего не поменялось?) Из увиденных мною фреймворков наиболее правильным считаю C# Dependency Injection Framework. На нем и основан к слову https://github.com/p0lunin/teloc

Ну DI это буквально опухоль, как и паттерны

IoC это паттерн, а они с годами не меняются

Linux, хоть и экспериментально

С каких пор показатель много статей говорит о каждая статья правильная и авторитетная

Дефайн авторитет

Так вы гляньте мой пример из ридми - все что вам необходимо в моем случае, это добавить макрос #[inject] и создать контейнер, куда занести типы необходимых зависимостей) Никакой каши не надо, у нас тут Раст а не джава)

В джаве тоже каши нету, там вообще компайл тайм инъекторы есть. Кашу можно сделать везде

Окей, а потом ты нагородишь десятки контейнеров и сотни зависимостей. Как будешь интроспекцию делать? У меня интерес грепать слова по коду пропал во времена Spring 4.2 Извини, IoC это дичь

А в случае C# Dependency Injection Framework, вам и вовсе необходимо лишь добавить .add_lifetime метод, даже макрос создавать не надо, рефлексия сама разберётся как конструировать ваш объект😉 Так что по джаве ровняться уж точно не стоит)

Не надо путать inversion of control и иньекции

Когда у тебя сотни зависимостей - вы будете каждую зависимость создавать через new() и все будет читабельно и удобно?

Go to definition тоже удобно :)

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

Там же самое интересное начинается, когда создаваемые объекты нужно по-разному конфигурировать для разных деплоев. Хорошо, если через конфиг-файл при старте. А то бывает, прямо в рантайме из Зукипера надо тащить! 😃

Если вам конфигурацию объектов нужно тащить в рантайме из Zookeeper, то у вас что-то не в порядке с архитектурой

Oh really?! Распределённый деплоймент, постепенное выкатывание новых фич, тестирование под нагрузкой, разная конфигурация под разных клиентов? Не, это всё неправильная архитектура! 😂

Да. Пусть отдельное приложение вынимает инфу и прокидывает конечному через флаги. В самом приложении этого быть не должно

Да хоть через переменные среды! Главное — руками прокидывать до каждого new — вот это правильная архитектура! И перезапускать всю ноду при изменении конфига — иначе зачем нам k8s, правда же? 😃

Я не видел примера, где использование DI даёт хоть что-то положительное

Хотите сказать, Вы посмотрели вообще на все приложения в мире? Или это утверждение говорит только об ограниченности Вашего личного опыта? 😉

Как говорится "посчитайте сколько у вас интерфейсов, а потом посчитайте сколько интерфейсов имеют более одной реализации"

Это не есть требование DI/IoC, лишь опциональная возможность, и на примере teloc/C# Dependency Injection Framework это показано.

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

зачем_кот.жпэг

ну да, ведь все нужно с нуля переизопретать. Втопку https://rust-unofficial.github.io/patterns/ заодно

паттерн это DI, а IoC это либы которые офк меняютс и становятся лучше

наоборот

Наоборот. DI это один из способов реализовать IoC

Так и что? Это другие паттерны буквально

ну я вот считаю что паттерны полезные, их знать не повредит

я кашу видел в dagger, правда это не совсем жаба, а котлин

Токсичное знание

А что в этом интересного? Вместо IService приходится передавать IServiceProvider и на месте инстанцировать, все классически решается

ну да, меньше знаешь - крепче спишь, так ведь. Джун идеальный разраб

В смысле "классически"? Там выше утверждалось, что ни DI, ни фабрики не нужны — достаточно просто везде создавать объекты по месту оператором new. Ваше предложение в схему с new не укладывается.

а, сори, тогда пропустил