Обычно не использование фреймворка заканчивается изобретением своего собственного фреймворка, если проект разрастается. С которым в конце-концов так же приходится бороться.
Если учесть то, что стандарты веба никто толком не знает - получаются очень часто очень топорные решения. К примеру, видел тысячи проектов на Го, которые отдают в браузер и не удосужились сделать HEAD и OPTIONS роуты. Необходимость вручную думать про CSRF, XSS, правильные роуты в соответствии с REST (которые тоже никто не знает)... А во фреймворке это из коробки, он за тебя позаботился.
Из-за кажущейся свободы начинается полный зоопарк с http codes и error handling в API, структуры папок в которых надо вникать 2 недели после смены проекта, зоопарк решений для конфигурации.
То же самое относится к SQL - тысячи проектов с конкатенацией строк для запросов SQL, каша из функций, raw sql без какого-либо порядка в миграциях и дата-миграциях.
Дикий запад PHP в его худшие годы.
И ради чего? Чтобы "гипотетически" не сражаться с фреймворком, причем на том этапе где все и так начинают переписывать, рефакторить, разбивать на микросервисы?
Не надо денормализовывать для GQL и натравливать дедубликатор - сервер то твой целиком, зачем делать лишние шаги - тебя никто не заставляет. Если у тебя отдельный черный ящик, который не знает о том, что ты используешь такой подход - тогда эти шаги нужны.
Денормализует клиент и в случае с REST. Тут никакой разницы нету. Чтобы в UI отобразить. То есть "клиенту денормализация не уперлась" - я не могу себе представить такого кейса. Наоброт, в конце-концов клиенту нужна денормализцаия для отрисовки UI.
Стартапы в опыте работы настораживают эйчаров. Стартапы — часто про хайп. И при этом они быстро закрываются. В итоге у вас в списке прошлых мест работы могут быть поинты на хайповые темы по полгода-год работы. Это настораживает эйчаров — кажется, что вас легко могут переманить в другую компанию.
Как бы сказать помягче... Лично меня настораживают люди которые 5 лет сидят в энтерпрайзе на одной позиции.
Будем честны: эта статья - просто маркетинговый булшит.
Из 6 «инструментов» 3 - это просто «а вот у нас в каждом облаке есть что-то для МЛ», а ещё 3 - проприетарщина или сама по себе, и гвоздями прибитая к конкретным облакам, то есть вендор-лок.
Кроме того, из статьи не очень понятно даже какие именно функции в структуре ML Ops выполняют перечисленные инструменты.
Первая статья этого автора довольно общая, но хотябы имеет смысл в контексте минимального описания и ознакомления с темой.
Не холивара ради, а только в качестве интереса: не могли бы вы привести несколько примеров таких «фишек», которые есть в PHP а не только в языке X, и заодно сам язык X
Фишка Wasm в том, что в него компилируется все. Зачем учить ещё один язык, который к тому же компилируется только в Wasm, если можно писать на Go, Rust, Js, C?
И как этот язык может быть чьим-то конкурентом, если у него нету экосистемы?
Безусловной новинкой является язык Go. Включивший в свой синтаксис средства коммуникации между потоками/процессами
% Create a process and invoke the function web:start_server(Port, MaxConnections)
ServerProcess = spawn(web, start_server, [Port, MaxConnections]),
% Create a remote process and invoke the function
% web:start_server(Port, MaxConnections) on machine RemoteNode
RemoteProcess = spawn(RemoteNode, web, start_server, [Port, MaxConnections]),
% Send a message to ServerProcess (asynchronously). The message consists of a tuple
% with the atom "pause" and the number "10".
ServerProcess ! {pause, 10},
% Receive messages sent to this process
receive
a_message -> do_something;
{data, DataContent} -> handle(DataContent);
{hello, Text} -> io:format("Got hello message: ~s", [Text]);
{goodbye, Text} -> io:format("Got goodbye message: ~s", [Text])
end.
Пример из Википедии синтакса Эрланга, появившегося в 1986 году. Обратите внимание на восклицательный знак и управляющую конструкцию receive.
Согласен. Python — это язык с самой ярковыраженной stackoverflow driven development необходимостью. На это есть несколько причин, основные:
Довольно дурацкая дока (особенно в библиотеках), постоянное отсутствие примеров
Постоянные **kwargs, в которых даже читая source code библиотек не всегда понятно что происходит
Каждый пишет как хочет, нет общих паттернов. Код DataScience и код Web Service и сопутствующие библиотеки отличаются по парадигмам и подходам, кроме того есть огромное количество разных покалений (вроде "как тут делать async до того как завезли async"), и все библиотеки на разных покалениях сидят.
В результате, единственный быстрый способ писать на Python — гуглить вопрос как есть и копипсатить со stackoverflow. Качество кода — соответствующее
Обычно не использование фреймворка заканчивается изобретением своего собственного фреймворка, если проект разрастается. С которым в конце-концов так же приходится бороться.
Если учесть то, что стандарты веба никто толком не знает - получаются очень часто очень топорные решения. К примеру, видел тысячи проектов на Го, которые отдают в браузер и не удосужились сделать HEAD и OPTIONS роуты. Необходимость вручную думать про CSRF, XSS, правильные роуты в соответствии с REST (которые тоже никто не знает)... А во фреймворке это из коробки, он за тебя позаботился.
Из-за кажущейся свободы начинается полный зоопарк с http codes и error handling в API, структуры папок в которых надо вникать 2 недели после смены проекта, зоопарк решений для конфигурации.
То же самое относится к SQL - тысячи проектов с конкатенацией строк для запросов SQL, каша из функций, raw sql без какого-либо порядка в миграциях и дата-миграциях.
Дикий запад PHP в его худшие годы.
И ради чего? Чтобы "гипотетически" не сражаться с фреймворком, причем на том этапе где все и так начинают переписывать, рефакторить, разбивать на микросервисы?
А чем, если не секрет?
Might & Magic
Как golang попал у вас в список интерпретируемых языков для прототипирования?
Не надо денормализовывать для GQL и натравливать дедубликатор - сервер то твой целиком, зачем делать лишние шаги - тебя никто не заставляет. Если у тебя отдельный черный ящик, который не знает о том, что ты используешь такой подход - тогда эти шаги нужны.
Денормализует клиент и в случае с REST. Тут никакой разницы нету. Чтобы в UI отобразить. То есть "клиенту денормализация не уперлась" - я не могу себе представить такого кейса. Наоброт, в конце-концов клиенту нужна денормализцаия для отрисовки UI.
Для graphql есть некоторые решения которые делают подобное, например вот здесь: https://gajus.medium.com/reducing-graphql-response-size-by-a-lot-ff5ba9dcb60
А как задача с недублированием данных о городе решалась бы в REST подходе?
Как бы сказать помягче... Лично меня настораживают люди которые 5 лет сидят в энтерпрайзе на одной позиции.
Да, именно так.
На самом деле сравнение не корректно. И все результаты фактически вытекают из этого.
Более корректно было бы сравнить горутины с async кодом, в идеале - наверное на голом tokio
Замечу, что tokio умеет запускать рутины в разных «физических» тредах, поэтому io-bound-ность не обязательно
Расскажите - куда читать про то, как это делать правильно?
Будем честны: эта статья - просто маркетинговый булшит.
Из 6 «инструментов» 3 - это просто «а вот у нас в каждом облаке есть что-то для МЛ», а ещё 3 - проприетарщина или сама по себе, и гвоздями прибитая к конкретным облакам, то есть вендор-лок.
Кроме того, из статьи не очень понятно даже какие именно функции в структуре ML Ops выполняют перечисленные инструменты.
Первая статья этого автора довольно общая, но хотябы имеет смысл в контексте минимального описания и ознакомления с темой.
Ну вот по какой-то причине Phoenix вообще не упомянут в самой статье.
Не холивара ради, а только в качестве интереса: не могли бы вы привести несколько примеров таких «фишек», которые есть в PHP а не только в языке X, и заодно сам язык X
Что значит nullable?
В proto3 спецификации все поля - optional, то есть могут либо быть либо отсутствовать. Чем это отличается от nullable?
Так всетки, есть шанс появления FlipperPay, или это слишком невозможно реализовать?
Фишка Wasm в том, что в него компилируется все. Зачем учить ещё один язык, который к тому же компилируется только в Wasm, если можно писать на Go, Rust, Js, C?
И как этот язык может быть чьим-то конкурентом, если у него нету экосистемы?
Пример из Википедии синтакса Эрланга, появившегося в 1986 году. Обратите внимание на восклицательный знак и управляющую конструкцию
receive.Согласен. Python — это язык с самой ярковыраженной stackoverflow driven development необходимостью. На это есть несколько причин, основные:
В результате, единственный быстрый способ писать на Python — гуглить вопрос как есть и копипсатить со stackoverflow. Качество кода — соответствующее
Я правильно понял, что автор этой статьи считает что необходим WASM и Rust для того, чтобы запустить child process в ноде?
Т.е. кинуть в сумку килограмовый ноут, когда едешь на дачу и знаешь что надо будет поработать — это проблема?