Здравствуйте, Dair, Вы писали:
D>Сервер надо чтобы раздавать контент пользователям. D>Контент сравнительно небольшой — ну десятки мегабайт. Пользователей тыщ 100.
D>Workflow типа "здрасьте, я тут у вас контент купил, вот чек" — "давайте посмотрим. Петровна! Ты этому молодому человеку пробивала?! Да? Вот, молодой человек, вам файлик, пожалуйста" D>Ну или "Здрасьте, вот у меня чек, нет ли у вас чего новенького?" — "Петровна, помнишь этого парня? Помнишь? Хорошо. Да, вот у нас тут новенькое случилось специально для вас"
D>Флейм приветствуется
Ну раз так, то сервер не нужен (с)
Функционал достаточно простой, чтобы сделать serverless, на azure functions или aws lambda.
Никаких забот о сервере, его администрировании, масштабировании и прочем.
Никакого бойлерплейт-кода. Просто функция, принимающая вебреквест и отдающая уникальную ссылку на скачивание с s3 или другого стораджа.
Прямо из функции файл отдавать не стоит, так как у функции лимит времени на выполнение, десятки мегабайт на мобильном инете не успеет отдать.
Саму функцию можно писать на джава, шарп, питон, го и других.
Экономическую сторону вопроса надо отдельно посчитать.
Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, Calc, Вы писали:
C>>бери PHP и не выеживайся
M>для чистого бекенда совсем не лучший выбор
что значит "чистый"?
Задачу свою выполнит. JSON перешлет. C++ знает, культура кода есть. Компилить не надо, всё проверяется runtime, в 7й версии ввели типизацию параметров (уже хоть что то)
В докере всё есть, бери, качай, запускай, linux знать не надо.
Для прототипирования и изучения чего либо нового — идеальный вариант.
Для миллиона пользователей и миллиона зеленых денег тоже подходит.
PHP не любят за популярность и комьюнити. Для многих это первый язык, вот и выдают полный треш. В том же С++ с дуру можно херни понавертеть, но как инструмент штука хорошая. Также и с PHP.
C>Задачу свою выполнит. JSON перешлет. C++ знает, культура кода есть. Компилить не надо, всё проверяется runtime, в 7й версии ввели типизацию параметров (уже хоть что то) C>В докере всё есть, бери, качай, запускай, linux знать не надо.
C>Для прототипирования и изучения чего либо нового — идеальный вариант. C>Для миллиона пользователей и миллиона зеленых денег тоже подходит.
* многие вещи делаются ну очень через жопу( например шоком было что простой print для отладки посылает это сразу на клиента )
За последний год угораздило в 2 проекта проекта вляпаться где был PHP
я работал много с чем, сравнить могу, хуже у меня был опыт только с Clojure
* тот же JSON не родной, и ( по крайней мере в двух проектах где я был за этот год ) часто сериализация JSON вылезает в ньюансы
* Комьюнити очень слабое, гугление на некоторые вопросы переводит на стековерфлоу и ответы "экспертов" заставляют шевелится все волосы на теле
* фреймворков достаточно много, придется потратить время на изучения что выбрать ( или без фреймворка работать )
Здравствуйте, mogadanez, Вы писали:
M>Здравствуйте, Calc, Вы писали:
C>>Задачу свою выполнит. JSON перешлет. C++ знает, культура кода есть. Компилить не надо, всё проверяется runtime, в 7й версии ввели типизацию параметров (уже хоть что то) C>>В докере всё есть, бери, качай, запускай, linux знать не надо.
C>>Для прототипирования и изучения чего либо нового — идеальный вариант. C>>Для миллиона пользователей и миллиона зеленых денег тоже подходит.
M>* многие вещи делаются ну очень через жопу( например шоком было что простой print для отладки посылает это сразу на клиента )
ну так это и есть самый чистый бэкэнд
stdout клиенту,stderr в лог
M>За последний год угораздило в 2 проекта проекта вляпаться где был PHP M>я работал много с чем, сравнить могу, хуже у меня был опыт только с Clojure
PHP по времени выдачи кода быстрее всяких других языков.
M>* тот же JSON не родной, и ( по крайней мере в двух проектах где я был за этот год ) часто сериализация JSON вылезает в ньюансы
json_serialize(data)
json_deserealize(data)
всё.
M>* Комьюнити очень слабое, гугление на некоторые вопросы переводит на стековерфлоу и ответы "экспертов" заставляют шевелится все волосы на теле
ну я бы не сказал что на вопросы отвечают эксперты. Просто левые люди, которые как то решали проблему.
M>* фреймворков достаточно много, придется потратить время на изучения что выбрать ( или без фреймворка работать )
для прокидывания пары жсонов обычного ООП за глаза.
Второй вариант ktor + kotlin, но PHP по скорости написания кода и деплоя всё равно будет выигрывать. (опыт есть, 40 мобильных проектов в команде за 3 года)
Здравствуйте, IID, Вы писали:
F>>а на жс можно переходить только с голодухи. хотя он процентов на 20 быстрее питона. IID>всего на 20% ? IID>Что-то сомневаюсь... Учитывая насколько тормозной питон, и сколько сил (и денег) вбухивается в JIT для JS движков.
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, neFormal, Вы писали:
F>>а на жс можно переходить только с голодухи. хотя он процентов на 20 быстрее питона.
IID>всего на 20% ? IID>Что-то сомневаюсь... Учитывая насколько тормозной питон, и сколько сил (и денег) вбухивается в JIT для JS движков.
В питоне намного более развитые библиотеки для сервера (БД, разработка API, логи, авторизация, JSON и многое-многое другое). В js нормальные библиотеки в основном для веб-клиента.
И скорость бэкенда, написанного на любом языке из предложенного списка, будет практически одинаковая, т.к. все упрется в скорость БД, диска, сети и т.п, а не в скорость языка.
Здравствуйте, Ватакуси, Вы писали:
D>>Python/Django — за часа три курения мануала по Django я не понял, как там сделать просто. Как сделать сложно — понял. В>Поддерживаю людей посоветовавших фласк с питоном. В твоём случае это делается за 30-60 минут с нуля, включая юнит-тесты.
Ага, и потом придётся это быстро написанную субстанцию поддерживать. Когда оно всё будет трещать по швам.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ватакуси, Вы писали:
D>>>Python/Django — за часа три курения мануала по Django я не понял, как там сделать просто. Как сделать сложно — понял. В>>Поддерживаю людей посоветовавших фласк с питоном. В твоём случае это делается за 30-60 минут с нуля, включая юнит-тесты. C>Ага, и потом придётся это быстро написанную субстанцию поддерживать. Когда оно всё будет трещать по швам.
Почему оно будет трещать по швам, если будут тесты?
И почему будет иначе на других языках?
Здравствуйте, Буравчик, Вы писали:
C>>Ага, и потом придётся это быстро написанную субстанцию поддерживать. Когда оно всё будет трещать по швам. Б>Почему оно будет трещать по швам, если будут тесты?
Потому, что Питон.
Б>И почему будет иначе на других языках?
Потому, что другие языки. Если, конечно, это не Ruby.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Буравчик, Вы писали:
C>>>Ага, и потом придётся это быстро написанную субстанцию поддерживать. Когда оно всё будет трещать по швам. Б>>Почему оно будет трещать по швам, если будут тесты? C>Потому, что Питон.
Откуда такая неприязнь? Расскажи, пожалуйста, про фейлы питона, с которыми ты сталкивался (лучше, если лично сталкивался).
Здравствуйте, Dair, Вы писали:
D>Хотел было в веб-программирование, но там трут за фронтенд, решил сюда.
D>Я в основном умею в C++, но пишу ещё на Swift и Kotlin.
Здравствуйте, Буравчик, Вы писали:
Б>>>Почему оно будет трещать по швам, если будут тесты? C>>Потому, что Питон. Б>Откуда такая неприязнь? Расскажи, пожалуйста, про фейлы питона, с которыми ты сталкивался (лучше, если лично сталкивался).
Проблемы Питона в:
1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно.
2) Однопоточности. Это реально проблема — сервер придётся запускать в виде нескольких процессов, что делает невозможным вещи типа разделяемого кэша.
3) Интерпретируемости. Если нужно делать высокоскоростные сервисы, то можно забыть про высокоуровневые библиотеки типа SQLAlchemy. Теоретически на подходе есть PyPy, но он всё ещё не дорос.
4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/
При этом начинать проект легко, да. Сначала код пишется как будет сам. Но вот потом всё становится очень уныло. Я и сам попадал в эту ловушку, и в других проектах тоже встречал.
Так что пожалуйста, не надо использовать Питон для чего-то сложнее скрипта в сотню строк.
Да, всё то же относится к Ruby и немного меньшей степени к NodeJS (он хотя бы быстрый).
Здравствуйте, Calc, Вы писали:
D>>Нет, как-то миновала меня чаша сия. C>бери PHP и не выеживайся
За новый софт на PHP надо расстреливать без разговоров.
Здравствуйте, Cyberax, Вы писали:
C>Проблемы Питона в: C>1) Динамичности. Любая реальная большая кодовая база становится крайне лохматой, даже если писать в стиле Питон-с-классами и избегать магии в виде декораторов и прочих страшностей. Тестов обычно бывает недостаточно.
это если с дизайном кода плохо
в статике ровно то же самое будет
C>4) Уродский инструментарий. Питон до сих пор нормально ниасилил пакетные менеджеры, так что распространение и установка программ на нём часто весьма нетривиальна. XKCD в тему: https://xkcd.com/1987/
вообще, все давно проекты держат в локальных окружениях для конкретного проекта
поэтому и таким сложностей не испытывают
