Александр Воробьев

Александр Воробьев
Рейтинг
63
Регистрация
03.02.2020
MrPi #:
Нужен один язык нейронок, которые она сама интерпертирует и компилирует. Что бы уровень разработки определялся качественным запросом, четко структурированным, описываемым. Т.е. четкое ТЗ от разработчика. 
Да потом будет добавлена некоторая строгость или "типизация" в язык описания ТЗ для нейронок.... и пойдем на следующий круг. Просто наши хотелки будем описывать не на пхп/плюсах/питоне/итп и скармливать их интерпертатору/компилятору, а какой то новый "язык" и скармливать его нейронкам... в общем по сути: просто новый виток и новый уровень абстракций :)
Sly32 #:
Ты удивляешься, но на самом деле это уже давно обсуждено в понимающих кругах. В чем удивление? ИИ за тебя не думает. Ты предложил идею - он бросился ее реализовывать. Он не будет за тебя проверять. Ты взял общую идею. А у меня в рамках проекта я забыл что уже делал это, попросил реализовать и он радостно написал мне аналогичный код, вообще не парясь что похожее уже есть. Поэтому теперь в промпте зашито железное правило - перед реализацией проверь существующую имплементацию, найди, если нет тогда....

Тут не про удивление. Тут про забавную ситуацию, и что такое поведение надо иметь ввиду если брать ИИ в качестве помощника в обучении. 

Кроме того, это не про вайбкодинг, он мне ее не реализовывал. (я по прежнему в своем фреймворке делаю все сам - цель в этом, тот эксперимент с одним модулем - просто один эксперимент и не более). Т.е. я именно обсуждал идею, спрашивал есть ли реализации. И он именно обосновывал что моя идея классная и полезная... но то было вначале "обсуждения"... :)

Sly32 #:
Просто если не хочется - зачем тогда вообще было заводить спор? Ты сначала что-то мне доказываешь, потом тебе не хочется. Суть ведь была разобраться в технике, а не как экономист - фигня, докидаем памяти и ядер...

Уже выше пояснял. Спор изначально слишком неопределенный. в котором смешаны несколько холиваров X vs Y плюс отсутствие внятного определения "серьезного проекта", плюс тема (если бы ее обсуждать технически) скорее для другого форума.  А в качестве холиваров - меня всегда такие темы тегают :)

Но если "не как экономист" я тогда тут вообще надо на сторону ArbNet вставать - пишем все с ноля и на голом - в топку все лишнее. Под каждый проект свое узкоспецифичное решения без всякой гибкости - это будет быстрее работать  :D 

Sly32 #:
Это - главная моя пртензия к ВП  - Он при старте грузит в память все ядро и все плагины, неважно, что нужно на конкретной странице. Поэтому и такое ограничение по RPS.

Прям все? Или те что авторы указали что их надо грузить?

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

Sly32 #:
Давай даже уйдем от Пайтона и сравним ВП с Симфону

Бессмысленное сравнение. Не удивлюсь если мой фреймворк сейчас выдаст больший RPS чем симфони. Говорит ли это о том что мой фреймворе неимоверно круче?

Как минимум надо: сначла реализовать тот же самый функционал что стартует при старте ВП. Ну опять же на примере битрикс. При старте "из коробки" там запускается проактивная защита - штука полезная, при старте симфони нет... На RPS это повлияет?

Sly32 #:
Ну например, когда затраты на хостинг такие:

Ясно ок. т.е. речь о перевозке 140 тонн....  Я газелист.

Sly32 #:
Ну ты же понимаешь, что я 5 лет пишу на фастапи исключительно. Любой инфосайт в стиле вордпресса я сделаю примерно с такой же скоростью что и на ВП - каркас готов, время написания шаблона - одинаковое. Создать БД и менеджер под нее - полчаса.  Развернуть на проде - 5 минут.

Не скажу за ВП. На битрикс подниму полноценный интернет магазин минут за 15. (там будет все включая каталог, гибкие инструменты для СЕО, проактивная защита, если необходимо аналитика, CRM и еще овердохрена функционала нужного бизнеса. И сделаю это так (за это же время) даже если только сейчас увидел битрикс. Судя по обсуждениям в подобных темах и по позиции Wp+eCommers в мире - очень сильно сомневаюсь что там все сильно хуже.

Sly32 #:
Проверь. Ты же в состоянии сам посчитать?

Создать реальный проект, наполнить данными, поднять нагрузочный стенд....  Не, я считаю, что все же разработчики оп всему миру не такие дебилы что предпочитают wp+ecomers, а не битрикс (который я знаю) при таком очевидном минусе (если б он был). Хотя опять же с оговоркой: всем ли нужен большой RPS, всем ли сложно  в случае необходимости малыми средствами его поднять....

И да, важно: если смотреть на RPS, то нужно понимать, что ты сравниваешь асинхронный инструмент  с синхронным. Это разные весовые категории по архитектуре.
Но вопрос в том, всем ли нужна эта асинхронность?
  1. Headless-режим уже помогает нивелировать разницу для пользователя. Мы перестаем генерировать тяжелый HTML на лету, а отдаем "сырые" данные через API. Это позволяет разнести нагрузку: бэкенд (WP) может думать сколько угодно, пока быстрый фронтенд (или кэш) отдает контент.
  2. Современные рантаймы. Даже классический WP сейчас можно запустить в режиме постоянного процесса через FrankenPHP или RoadRunner. Это убирает те самые накладные расходы на инициализацию, о которых ты пишешь. Да, это требует настройки...
Короче, всё упирается в баланс ресурсов: Либо мы тратим время разработчиков на написание большого объема кода с нуля (FastAPI), получая полный контроль и асинхронность. Либо мы берем готовое решение (WP), экономя сотни часов на разработке админки, SEO и базовой логики, а затем точечно "лечим" узкие горлышки (кэшем, CDN или тем же FrankenPHP).
Для бизнеса часто второй путь оказывается выгоднее, даже если он технически менее "красивый".
Sly32 #:
Могу привести расчеты, если не веришь. Надо ли что-то пояснять?

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

То что ВП грамотно настроенный тащит всего лишь 100 RPS не верю. В потолок порядка 1000 RPS поверю еще более менее. (т.к. в этом году на Битрикс проекте выдержали 1500RPS и есть что еще крутить. (но да не совсем все только "штатные механизмы")

Составь теперь таблицу скорость подъема проекта на WP и на FastApi и стоимость.

В общем правильным будет сначала определиться: что считаем серьезным проектом.

Сайты на ВП у которых я сомневаюсь что маленький трафик

https://news.microsoft.com/ru-ru/

Вот у этих ребят не хватило средств чтоб сделать себе сайт по красоте и им пришлось создавать вот такие дико тормозящие сайты?

Sly32 #:
На серьезном магазине с кучей вариаций - начнет дико тормозить.
А куча это сколько?
Всего: 945