Wataru, охотно верю. А реально эта производительность помогает? Если аналогичный алгоритм на какойнибудь жаве или шарпе сделать, то там по времени/памяти не уложится?
historydev, сейчас для теста выключил whole line completion, сортировку при помощи machine learning, Jetbrains AI, тултипы с документацией, сигнатурами, и типами параметров.
Tooltip Delay = 1ms
Проект - bevyengine.
Предварительно даже не смог собрать проект из-за "Файл подкачки слишком мал для завершения операции." + IDE вылетает периодически.
Но при вводе bevy:: почти мгновенно получаю тултип с предложениями.
У тебя же проект не в wsl лежит?
historydev, сейчас в сильно большом проекте посмотрел, даже выставил tooltip delay=1мс. Тоже где-то меньше секунды жду появления тултипа (ну 100-200мс на глаз я бы сказал)
Кажется, придётся смириться с этим.
evomed, наверное стоило в теги ларавел добавить, раз речь не о фасадах как патерне, а о фасадах из ларавела).
Впрочем даже по документации, которую вы скинули - не выглядит так, что они под ваш кейс подходят.
Кстати, а ты уверен, что ты не Tooltip delay утыкаешься? (параметр такой в настройках, чтобы при наборе первой же буквы тебе не высвечивалось окно с предложениями)
historydev, а как измерить задержку? Вообще как ниже уже написали - на задержку больше влияет размер проекта, количество зависимостей, а не количество строк в одном файле.
Максимум на что может влиять количество строк в файле - дополнение при помощи JB AI, так что я бы для проверки выключил бы всё что связано с машинным обучением и ai.
А ну и ещё автокомплиту могут мешать ошибки компиляции - в таком случае зря выключил cargo check.
evomed, Всё ещё сужу исключительно по словам (и тому как я себе в голове картину нарисовал), тк не увидел ни диаграммы, ни кода.
Фасад служит только доступом к реализации через контейнер
Звучит ещё хуже, если честно)
Чем не устроил нормальный dependency injection?
Какую тогда вообще пользу даёт фасад? Почему мы потребителю напрямую к этому контейнеру не обратиться?
Вопрос можно ли вызывать фасад из логики (которую он вызывает/запускает) или нет.
Нет, тк в текущей реализации сразу несколько проблем
1. Циклическая зависимость (которая потенциально может к рекурсии привести и когда-нибудь приведёт)
2. Гвоздями прибиваешь свой домен к инфраструктуре
Чем не устроила "тупая" архитектура?
Контроллер (обработчик http-запросов) -> сервис (доменный, который отвечает за бизнес-правила) -> базовая инфраструктура (запросы к сторонним сервисам, очереди, базы данных)
И связать их все при помощи dependency injection.
Рамазан Камилов, ну если схожесть синтаксиса мерять по количеству совпадающих ключевых слов, то да, в остальном - общего с жс у него только то что он императивный.
На серьёзе (имхо) тут пока только JS(deno), Rust, C#, Java(graalvm), Delphi рекомендовали
Я бы не стал его советовать человеку "с бэкграундом php и nodejs", особенно если хочется "простой порог входа".
1. Полностью ручное управление памятью (даже без борроу чекера)
2. Тут должен был быть пункт про систему типов, но потом я понял, как в zig сделаны женерики. Одновременно впечатлён и напуган.
3. Идеоматичный код абсолютно не похож на упомянутые выше языки (вы хотябы в документацию заглядывали?)
4. Нет пакетного менеджера из коробки.
Опять же работа со строками в зиге очень похожа на оную в C/Cpp за исключением того что строки юникодные (но корректность не гарантируется), а автор отдельно отмечает, что ему не подходит работа со строками, как в c/cpp (что бы за этими словами не скрывалось)
