Хотел в качестве примера привести один из своих сервисов с Protobuf и кучей рефлексии на бэкенде, и полным ее отсутствием на фронтенде. Но потом осознал, что я использовал TypeScript на фронтенде. Просто TypeScript, с его утиной типизацией и объединением типов, оказался значительно более гибким, чем C#
Мне неочевидно, что потребность в рефлексии прямо следует из статической типизации.
Разумеется, область применения рефлексии значительно шире, чем просто динамическая работа с неизвестными типами данных в рантайме. Тем не менее, на моем опыте это встречается не так уж и редко.
Решение может быть в формировании дополнительного модуля...
И вместо единого, умещающегося на один экран, скрипта получим целую кучу разных модулей и конфигов, которые так же нужно будет поддерживать и отлаживать.
А все для того что бы решить такую простую задачу, как например, запустить сервис с некоторыми аргументами. Где сервис и так сам проверяет входящие параметры и выдает ошибку в случае не корректного аргумента.
Вот как проверить опечатку, например, в переменной окружения? Не перекомпилировать же все имеющиеся в системе скрипты каждый раз.
Кстати, еще один пример, где динамическая типизация может оказаться полезнее статической. Это рефлексия, а точнее отсутствие необходимости в ее явном использовании. Читать код активно использующий рефлексию на порядки труднее, чем аналогичный код на динамических языках.
Под словом "простой" стоит понимать не количество кода, а низкую запутанность (или по англ. low complexity) кода.
Возьмем, к пример, скрипты на bash. В них могут быть сотни строчек кода, но все они, как правило, прямолинейные и простые. Соответственно добавлять в bash статическую типизацию было бы не очень разумно, это не дало бы реальной пользы как-раз в силу простоты таких скриптов.
Почему просто не использовать язык со статической типизацией?
Ответ на этот вопрос предельно прост: потому что популярные браузеры не поддерживают никаких других языков кроме JavaScript.
Конечно же, вы можете сказать: а как же WASM и бесчисленное множество транспайлеров из других языков? WASM, за редким исключением, пока что не готов для использования в боевых проектах, а транспайлеры все так же на выходе выдают JavaScript. Только в отличии от TypeScript, все остальные популярные транспайлеры не имеют такой богатой базы описаний типов других библиотек и прямой совместимости с JS. Да еще и часто тащат с собой тяжелый рантайм.
По этому и получается, что самый простой и эффективный способ для фронтэнда, это прикручивать статическую типизацию уже поверх существующего JavaScript.
С теплотой вспоминаю время, когда nginx был еще очень далек от версии 1.0 и когда основным источником информации, за исключением документации, были только email конференци.
Невозможно переоценить как много часов, нервов, денег, циклов CPU и мегабайт памяти помог сэкономить этот замечательный продукт. Очень надеюсь, что данный конфликт в итоге разрешиться в полную и безоговорочную победу Игоря Сысоева и его команды.
Возможно это сказывается багаж опыта, но даже я, человек написавший за всю жизнь на C++ не больше тысячи строк, отчётливо вижу разницу между size и capacity.
Кроме того, если я не ошибаюсь, IDE от Jetbrains угадывают его только для некоторых встроенных типов, а не для любых произвольных типов.
Хороший маленький монолит лучше, чем плохая распределённая сеть из микросервисов. Не так ли ?
Я рассуждал именно в разрезе микросервисов. Иначе нужно было бы ставить вопрос не VPS vs Docker, а именно Монолит vs Микросервисы.
Да, я согласен, что бывают ситуации, когда монолит лучше, микросервисов. Но бывают задачи, когда именно микросервисы лучше решают проблему. И именно в этом контексте я и рассуждал.
И по AMIшкам я ответил — можно их готовить HashiCorp Packer. Не нравится? Ну, давайте попробуем подобрать другой тулинг.
Т.е. вы имеете ввиду, что можно взять нейкий тулкит и при помощи него делать более менее схожие многослойные (ромбические?) образы для того же AWS EC2? Видимо, я не сразу понял о чем речь.
Это интересная мысль, но остается проблема с репозиторием. В случае кастомных тулкитов придется размещать этот репозиторий где-то отдельно, ведь вряд-ли они предоставляют такой же сервис как и Docker Hub?
Во-вторых, VPS вызывает неверные (или Вы специально в это русло утаскивает?) ассоциации с маленькими провайдерами типа ТаймВеб, Beget, hetzner
Да, именно такое впечатление у меня и осталось от комментария bgnx.
Как бы есть небольшая разница между непонятной vps у непонятного провайдера и EC2/Compute Engine в облаке с нормальным API?
Именно так. Хорошо, если вопрос стоит как "Почему не использовать AWS/Azure/Google Cloud вместо Docker", то это немного меняет дело. Но у меня, как разработчика, все еще остаются некоторые вопросы:
Например как запустить AMI контейнер у себя локально? Когда я работал с EC2, то не находил подобной возможности. Можно ли это сделать сейчас?
Все та же проблема с взаимодействием контейнеров, в случае если я все же пишу микросервисы, а не монолит.
Еще одна проблема в том, что AMI поднимаются безумно медленно. Это будет особенно мешать, если надо обновлять контейнеры часто.
И опять же, что делать, если амазон завтра скажет, например, что больше не работает с Россией и нужно срочно переносить все другому хостеру. Как же тут быть? В случае с докером такой проблемы нету.
Если говорить за разработчика — он хочет Хероку. Вы ведь наверняка его видели? Как локальный вариант — есть dokku. Но это абстракция более высокого уровня, чем докер...
Тут именно проблема в абстракции более высокого уровня. Например, мои текущие задачи никак не вписываются в возможности Heroku
Хотел в качестве примера привести один из своих сервисов с Protobuf и кучей рефлексии на бэкенде, и полным ее отсутствием на фронтенде. Но потом осознал, что я использовал TypeScript на фронтенде. Просто TypeScript, с его утиной типизацией и объединением типов, оказался значительно более гибким, чем C#
Разумеется, область применения рефлексии значительно шире, чем просто динамическая работа с неизвестными типами данных в рантайме. Тем не менее, на моем опыте это встречается не так уж и редко.
И вместо единого, умещающегося на один экран, скрипта получим целую кучу разных модулей и конфигов, которые так же нужно будет поддерживать и отлаживать.
А все для того что бы решить такую простую задачу, как например, запустить сервис с некоторыми аргументами. Где сервис и так сам проверяет входящие параметры и выдает ошибку в случае не корректного аргумента.
Вот как проверить опечатку, например, в переменной окружения? Не перекомпилировать же все имеющиеся в системе скрипты каждый раз.
Кстати, еще один пример, где динамическая типизация может оказаться полезнее статической. Это рефлексия, а точнее отсутствие необходимости в ее явном использовании. Читать код активно использующий рефлексию на порядки труднее, чем аналогичный код на динамических языках.
Под словом "простой" стоит понимать не количество кода, а низкую запутанность (или по англ. low complexity) кода.
Возьмем, к пример, скрипты на bash. В них могут быть сотни строчек кода, но все они, как правило, прямолинейные и простые. Соответственно добавлять в bash статическую типизацию было бы не очень разумно, это не дало бы реальной пользы как-раз в силу простоты таких скриптов.
Ответ на этот вопрос предельно прост: потому что популярные браузеры не поддерживают никаких других языков кроме JavaScript.
Конечно же, вы можете сказать: а как же WASM и бесчисленное множество транспайлеров из других языков? WASM, за редким исключением, пока что не готов для использования в боевых проектах, а транспайлеры все так же на выходе выдают JavaScript. Только в отличии от TypeScript, все остальные популярные транспайлеры не имеют такой богатой базы описаний типов других библиотек и прямой совместимости с JS. Да еще и часто тащат с собой тяжелый рантайм.
По этому и получается, что самый простой и эффективный способ для фронтэнда, это прикручивать статическую типизацию уже поверх существующего JavaScript.
+Илья Пирогов, РазработчикС теплотой вспоминаю время, когда nginx был еще очень далек от версии 1.0 и когда основным источником информации, за исключением документации, были только email конференци.
Невозможно переоценить как много часов, нервов, денег, циклов CPU и мегабайт памяти помог сэкономить этот замечательный продукт. Очень надеюсь, что данный конфликт в итоге разрешиться в полную и безоговорочную победу Игоря Сысоева и его команды.
Да, это серьезная проблема!
Возможно это сказывается багаж опыта, но даже я, человек написавший за всю жизнь на C++ не больше тысячи строк, отчётливо вижу разницу между size и capacity.
Кроме того, если я не ошибаюсь, IDE от Jetbrains угадывают его только для некоторых встроенных типов, а не для любых произвольных типов.
Видимо, только если вы большая компания.
А нельзя было добавить хотя бы краткие описания приложений/игр или то, чем они так примечательны?
Это же просто превосходно! Спасибо за информацию, обязательно попробую использовать его на домашних проектах.
Это совершенно нормально. Я даже про ствой собственный код так говорю.
Скорее всего нейросеть обучается прямо в браузере. А весь код написан на JavaScript, либо выполняется через Webassembly.
Контейнеры собранные таким образом падают со странными ошибками. Если интересно, то могу попробовать поискать какие образы у меня ломались.
Если работать только с существующими контейнерами, то да, все замечательно работает. А вот сборка образов в такой конфигурации работает крайне криво.
Самому. Но в случае WSL 2 с этим нет никаких проблем, по скольку это полноценный Linux.
Насколько я помню, он будет работать так как будто проект расположен локально, но при сохранении файла закачивать его.
PhpStorm тоже умеет работать с проектами на удаленных машинах. Например, в данном случае можно попробовать открыть проект через ssh.
Я рассуждал именно в разрезе микросервисов. Иначе нужно было бы ставить вопрос не VPS vs Docker, а именно Монолит vs Микросервисы.
Да, я согласен, что бывают ситуации, когда монолит лучше, микросервисов. Но бывают задачи, когда именно микросервисы лучше решают проблему. И именно в этом контексте я и рассуждал.
Т.е. вы имеете ввиду, что можно взять нейкий тулкит и при помощи него делать более менее схожие многослойные (ромбические?) образы для того же AWS EC2? Видимо, я не сразу понял о чем речь.
Это интересная мысль, но остается проблема с репозиторием. В случае кастомных тулкитов придется размещать этот репозиторий где-то отдельно, ведь вряд-ли они предоставляют такой же сервис как и Docker Hub?
Да, именно такое впечатление у меня и осталось от комментария bgnx.
Именно так. Хорошо, если вопрос стоит как "Почему не использовать AWS/Azure/Google Cloud вместо Docker", то это немного меняет дело. Но у меня, как разработчика, все еще остаются некоторые вопросы:
Тут именно проблема в абстракции более высокого уровня. Например, мои текущие задачи никак не вписываются в возможности Heroku