Главные темы:
- Какие знания нужны начинающему программисту, чтобы заниматься
веб-разработкой? - Чего ждут работодатели от разработчиков?
- Что делать, чтобы найти работу без опыта?
- Как может развиваться Python-разработчик?
Python Junior Podcast — подкаст о программировании для тех, кто хочет лучше разбираться в Python. Эфиры ведут евангелисты сообщества MoscowPython и преподаватели курсов Learn Python.
В разговоре участвовали:
- Валентин Домбровский,сооснователь MoscowPython
- Злата Обуховская, тимлид NVIDIA
- Григорий Петров, евангелист MoscowPython
- Алексей Штырняев, разработчик в FinEx, преподаватель курсов Learn
Python
Почему Python хорош для веб-разработки
Валентин Домбровский: Почему именно Python подходит для веб-разработки? Почему не PHP или JavaScript, например?
Григорий Петров: Так ведь выбора особо нет. Несмотря на то что в современном Вебе можно фактически без бэкенда — чисто на фронтенд-технологиях, на JavaScript — собрать себе single page application или progressive web application, все равно это слишком сложно, плохо индексируется и требует крутых разработчиков.
Если мы хотим сделать сайт или сервис, мы используем комбинированный подход: у нас какой-то бэкенд осуществляет логику и создает веб-страницы и какой-то фронтенд рисует эти веб-страницы в браузере. И когда нам надо быстро это все на чем-то собрать, то выбора особо нет.
Давайте рассмотрим возможные варианты.
- C#. Microsoft действительно молодцы, они сделали .NET Core и всячески ее продвигают. Но, во-первых, это новая кроссплатформенная технология, и там еще не все гладко. Во-вторых, это действительно дорого, разработчиков C# мало — просто потому, что она непопулярна.
- Java. Это сложно. Сделать нормальный сайт на Java — это не 10 строчек кода, как на Python. Это много кода, это фреймворки, и нужно знать специфику настройки Java-серверов. В общем, сплошные боль и страдания.
- PHP. В последних версиях он замечательный. Я даже так скажу: PHP 7.2 не хуже Python. Но нельзя просто так взять и использовать PHP 7.2. Если обычный, не топовый разработчик делает сайт на PHP, он не будет писать только на 7.2: все равно придется читать какие-то учебники, туториалы, везде куча legacy-кода, и это не очень хорошо.
- JavaScript и Node.js. Это замечательно и очень современно, когда один язык и на фронтенде, и на бэкенде. Только не очень стабильно. Node.js — хорошая штука, но проблематично развернуть ее в продакшене так, чтобы она не падала и работала устойчиво. Плюс, если мы хотим писать качественный код на JavaScript, нам нужен не JavaScript, а TypeScript. А вот TypeScript неожиданно сложный, при виде него у рядового разработчика вскипают мозги.
Давайте опустим Ruby, Haskell, Erlang и другие нишевые штуки, и у нас остается… Python. Язык с консистентным синтаксисом, единообразной стандартной библиотекой, лучшей документацией, популярными легкими фреймворками, мегапопулярным комбайном Django.Получается, что, несмотря на широчайший выбор, если у нас обычные, не топовые разработчики, мы обычный бизнес, который хочет делать обычные сайты, у нас нет отдела разработки на 50 человек, то мы берем Python.
Какие знания нужны для входа в профессию
Злата Обуховская: Я считаю, что один фреймворк нужно знать хорошо — и знать, какие еще бывают и когда они используются. Где Tornado, где Django, где Flask, где aiohttp и так далее.
Пригодится знать, что есть такая штука, как протоколы. В частности, знание протокола http — центральное для построения веб-приложений.
Еще нужно хотя бы приблизительно представлять себе, как в веб-проектах устроен фронтенд: что есть HTML, CSS, JS.
Алексей Штырняев: И знать, где лежит документация. Это самое главное.
Григорий Петров: Тут мы ступаем на очень зыбкую почву. Если нам не повезло и мы начали как-то серьезно изучать современный фронтенд, то он будет примерно раз в 10 сложнее, чем бэкенд на Python. Начинающему разработчику нужно ограничить свой фокус так, чтобы начать изучать HTML, но чтобы не провалиться во все эти div, span, float, как там все выравнивается и выстраивается.
Алексей Штырняев: Нужен базовый курс по Bootstrap. И основы HTML.
В первый год не стоит углубляться в JS-фреймворки (если вы фокусируетесь на бэкенде). В базовом курсе по Bootstrap уже есть готовые модули: хочешь слайдер — делай слайдер, хочешь плавающее меню — сделай плавающее меню.Злата Обуховская: Думаю, что за изучением фронтенда можно погрузиться, в частности, в то, как вообще статика отдается веб-приложениям. Так разработчик плавно переходит к тому, чтобы начать узнавать, как в принципе устроена архитектура веб-приложений и как они живут на продакшене.
Григорий Петров: Да, порекомендую сразу на тот случай, если вы выбрали Python в качестве языка бэкенд разработки и, например, Django в качестве фреймворка: у Django есть документация в Django Book, она реально клевая, в ней все то, о чем сказала Злата, она и правда хороша для начинающего.
Алексей Штырняев: Еще для быстрого старта подойдет какой-нибудь Django Girls, если цель — изучить именно Django. Это такой туториал, где за один день можно пройти по верхам, понять основы и то, на что способен фреймворк.
Валентин Домбровский: Готовясь к записи подкаста, мы составили список того, что нужно программисту на Python для веб-разработки, чем и резюмируем ранее сказанное.
Что входит в базис для веб-разработки на Python
- Веб-фреймворки Django, Flask, aiohttp, Tornado и т. д. (и знать о существовании остальных).
- Протоколы и API: в первую очередь http, JSON-RPC, Protocol Buffers, gRPC.
- ORM и миграции, реляционные базы данных, SQLAlchemy, SQL, PostgreSQL, MySQL.
- Основы HTML, CSS, Bootstrap, а также JS-фреймворки и JQuery.
- Принципы работы приложений на продакшене, тестирование, юнит-тесты, автотесты, системы контроля версий, git.
Нужны ли джуниору алгоритмы
Злата Обуховская: Поначалу не нужно знать алгоритмы, они сами постепенно появятся в голове, если заниматься разработкой достаточно долго. Я знаю кучу хороших инженеров, у которых не было хорошего формального курса алгоритмов.
Григорий Петров: Я хочу подлить масла в огонь. Вот откуда вообще берется наша тяга к алгоритмам?
У нас сейчас нет фундаментального образования по алгоритмам, у нас не умеют обучать программистов, нет технической базы.
Это пытаются делать, но тут у нас история Хогвартса: мы не можем сделать школу волшебников, пока у нас нет ни одного волшебника. Поэтому что делать университету, в который приходят и просят: «Начните обучать программистов», а программистов у них нет, потому что все работают в Mail.ru, Rambler и «Яндексе», им там хорошо?
В университете смотрят и говорят:
— О’кей, программирование. Давайте найдем какую-то смежную область знаний и пригласим специалистов оттуда. Давайте пригласим журналистов, которые умеют писать текст, инженеров-электриков, которые умеют делать электрические схемы, и математиков, которые умеют в алгоритмы.
В итоге получается, что это настолько же целесообразно, как обучать строителя физике элементарных частиц лишь потому, что кирпич и цемент состоят из элементарных частиц.
При этом про сам цемент и кирпич не рассказывают, потому что физик, который пытается обучить строителя, дома строить не умеет. В итоге получаем строителя, который в состоянии прекрасно расписать, как «работает цемент», но ни разу его не видел и делать из него ничего не умеет.
Алгоритмы и структуры данных — это очень хорошо, но это очень маленькая прикладная область. Они остро нужны, например, если ты пишешь игровой движок, компилятор, сетевой протокол.
Большинство программистов решают бизнес-задачи, где не нужны алгоритмы и структуры данных.
Там самая сложная математика — это два раза сложить, а потом разделить. Там нужны совсем другие знания. Для решения бизнес-задач требуются в основном прикладные, а не фундаментальные знания.
Начинающему разработчику лучше иметь представление о бизнесе и о том, как правильно и быстро собирать из готовых блоков нужные конструкции, как их отлаживать, как делать так, чтобы они не разваливались, знать, почему они разваливаются, что происходит, когда меняются требования и программа начинает «оседать на фундаменте», как дом после дождя.
Вот эти прикладные штуки и понимание того, как писать софт. Ему надо знать, что кроме отладчика у него есть набор инструментов, который покажет, где именно программа тормозит.
Валентин Домбровский: Мне такое сравнение пришло на ум: это перевод с языка бизнеса на язык, на котором можно общаться с компьютером. То есть программист — эдакий специфический лингвист.
Григорий Петров: Бизнесу нужен писатель, а не лингвист. Писателю не нужно знать, почему тысячу лет назад это слово трансформировалось вот в то. Ему надо уметь применять эти слова.
Что нужно, чтобы найти первую работу разработчиком
Алексей Штырняев: Наверное, нет универсального рецепта, по которому нужно готовить джуниора.
Если вы приходите в какую-то компанию, вас возьмут не за то, что вы знаете Django, JSON и немного алгоритмов. Вас, скорее всего, возьмут за те скиллы, которые здесь и сейчас нужны этой компании.Компаний много, и у всех разные требования. Нет такого универсального объема знаний, которые нужно получить, чтобы дальше подготовить резюме и идти трудоустраиваться.
Григорий Петров: Когда мы в VoxImplant искали нескольких джунов, наш технический директор сформулировал базовое требование так: человек должен уметь решать задачи. Понятно, что джун это будет делать не всегда эффективно, не лучшим способом и не всегда правильно, но в идеале ты ставишь человеку задачу, он напрягается и решает ее. Это тот скилл, который в первую очередь ищут работодатели.
Злата Обуховская: Люди, которые ищут работу, переходя из других областей, имеют с точки зрения бизнеса некоторое преимущество, потому что уже прошли какой-то путь и умеют решать задачи быстро. Это soft skills, я бы это назвала даже трудовой культурой. Зачастую у выпускников вузов эта трудовая культура еще не наработана.
Но мне бы хотелось все-таки попытаться дать какой-то рецепт начинающим.
Первые шаги для начинающего разработчика
Злата Обуховская: Первое — это все-таки какой-то свой проект, потому что в резюме нужно что-то написать, показать минимальное портфолио. Круче, когда эти проекты сделаны не для себя, а на фрилансе — для кого-то.
После первых проектов уже можно делать резюме и рассылать его во все компании, где есть джуновские позиции. Собеседования дадут понимание того, что нужно компаниям. Рано или поздно вас кто-нибудь возьмет, хотя бы в маленькую компанию. Впоследствии этот опыт работы даст вам возможность попасть в компанию побольше и поинтереснее.
Валентин Домбровский: Кстати, мы на курсах готовим учеников к тому, чтобы у них появился свой проект за 10 недель обучения. Плюс тренируем навык командной разработки. Это как раз те soft skills, о которых говорила Злата.
Алексей Штырняев: По опыту скажу, что первую работу можно искать очень долго. Когда вы ищете месяц-два — это нормально. Если вы подаете резюме во все компании, ходите на собеседования, на третий месяц вы обязательно что-то найдете.
Валентин Домбровский: Можно пилить свои проекты или брать простые проекты на фрилансе и параллельно заниматься рассылкой резюме.
Какие перспективы есть у Python-разработчика
Злата Обуховская: Python-разработчик может пойти куда угодно. Можно пойти в тестирование, продолжить развиваться до senior-архитектора. Или даже в менеджмент. Технические менеджеры бывают разные, и можно дорасти до топ-менеджмента. Можно развиваться в data science, DevOps, пойти в автотесты или machine learning.
Валентин Домбровский: В общем вариантов масса, возможностей тоже, в том числе наши курсы. Знаний на входе нужно не так много, но желательно потом охватить более широкий спектр, потому что чем больше вы сможете, тем лучше для вас.
***
Это лишь часть выпуска Python Junior. Полную версию эпизода можно послушать.
Или даже посмотреть:
RSS подкаста
Спасибо, что прочитали, послушали или посмотрели.
Комментарии (39)
Corpsee
04.04.2019 15:44+6Ответ на вопрос «Почему именно Python подходит для веб-разработки?» — какой-то бред от начала и до конца. В вебе нет альтернатив Python-у, а Ruby — нишевый, как Haskell… Ну и по остальному списку языков какой-то адский треш.
peresada
05.04.2019 07:23В частности позабавило про ПХП, мол он замечательный и не уступает питону, но не стоит его использовать, потому что языку уже ХХ лет и везде куча легаси
fso
04.04.2019 16:21+5Питон довольно сильно застрял в своей парадигме и это мешает ему развиваться в нужном для веб направлении. Отсутствие констант, модификаторов доступа, длинные простыни кода в одиночных файлах, мутная история с тайпхинтингом/типизацией и многое другое. Питон хорош для научной работы, математики, расчетов, числодробилок наконец. В вебе он как-то держится, но тот же PHP 7-ых версий именно в вебе, будет наголову выше. И по производительности и по «заточенности».
LighteR
04.04.2019 18:39-1Отсутствие констант
Не особо нужно, но оно есть в виде тайпхинта: mypy.readthedocs.io/en/latest/final_attrs.html
модификаторов доступа
Все прекрасно обходятся без них
длинные простыни кода в одиночных файлах
Какое это имеет отношение к ЯП. В других языках нельзя что ли простыню сделать?
мутная история с тайпхинтингом/типизацией
В чем ее мутность? В Python нормальная система типов, в отличии от велосипеда с квадратными колесами в PHP7
И по производительности и по «заточенности»
В чем заточенность? В том что у php даже event loop'а из коробки нет?fso
04.04.2019 19:08+1Не особо нужно
Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.
В других языках нельзя что ли простыню сделать?
Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.
В чем ее мутность?
В необходимости писать тип в виде строки вместо непосредственно литерала, если импортировать тип нельзя из-за проблемы циклического импорта. И в том, что при запуске и в рантайме, питон не пикнет даже если будут несоответствие типов (частая проблема при использовании сторонних пакетов, где pypy не поможет ввиду отсутствия тайпхинтинга в этих самых сторонних пакетах ).
В чем заточенность?
PHP изначально проектировался для обработки http запросов, цикл обработки запроса заточен именно под это. Как пример — встроенный механизм сессий. работа с сессиями — это функции самого языка.
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк. И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.mamokino
04.04.2019 19:14Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк
Вы это пишете в то время, когда полным-полно для Python'а качественных фреймворков и/или библиотек для веба. И когда существует удобное управление пакетами для установки/обновления этих фреймворков/библиотек.
Сейчас уже наличие/отсутствие функционала «под веб» непосредственно в стандартной библиотеке Python'а проблемой не является.
Про PHP можно сказать ровно тоже самое. Без PHP-расширений (тех, что бинарные, написанные обычно на С) — сделать полнофункциональный сколько-нибудь сложный сайт невозможно.fso
04.04.2019 19:20Соглашусь с вами, не утверждал что это большая проблема, просто обратил внимание, что php проектировался именно под веб, когда как для питона web — не родная среда.
mamokino
04.04.2019 19:27-2что php проектировался именно под веб
Только шаблонизатор у PHP самая сильная сторона в его «заточенности на веб».
А вот остальное — вполне себе имеет хорошие решения и в других языках.
worldmind
04.04.2019 20:22Речь про то, что питон диктует так делать (проблема циклического импорта)
попобробнее, какую проблему имеете ввиду и как она что-то диктует
LighteR
05.04.2019 03:12Да, обойтись можно без чего угодно. Однако практика показывает, что во всех зрелых языках они есть, ибо есть задачи которые константы решают. Если нет констант — нет для этих задач предназначенного инструмента.
Большинство этих зрелых языков, в которых есть константы являются статически типизированными и проверка на переопределение констант происходит на этапе компиляции, что значительно лучше чем проверка в рантайме. Вот Final, который я кидал выше способ сделать константу проверяемую на этапе статического анализа. Ну и получается что Lua и Ruby недостаточно зрелые?
И в том, что при запуске и в рантайме, питон не пикнет даже если будут несоответствие типов (частая проблема при использовании сторонних пакетов, где pypy не поможет ввиду отсутствия тайпхинтинга в этих самых сторонних пакетах ).
Да, пока далеко не во всех библиотеках есть тайпхинты. Но это же не проблема системы типов питона. Со временем тайпхинты будут появляться все в большем кол-ве библиотек. В любом случае ставить тайпхинты в минус питону, когда в php все гораздо примитивнее и вообще не позволяет делать хоть какой-то вразумительный статический анализ, довольно странно.
Речь про то, что питон диктует так делать (проблема циклического импорта) и устоявшаяся практика. Посмотрите на models.py в django любого сложного проекта.
Мне кажется, вы преувеличиваете проблему циклических импортов. Почти во всех проектах на django, которые я видел models был разбит на packages/modules
В необходимости писать тип в виде строки вместо непосредственно литерала, если импортировать тип нельзя из-за проблемы циклического импорта.
Опять же, проблема, мне кажется немного преувеличенной, но тем не менее начиная с Python 3.7 это уже не проблема: www.python.org/dev/peps/pep-0563
Большинство вещей, которые делаются в PHP на базовом уровне, в питоне делает фреймворк.
Для каких-то вещей это даже хорошо. Как правило release cycle языка сильно длиннее чем у библиотеки/фреймворка, что позволяет добавлять новые фичи/фиксить баги гораздо оперативнее не дожидаясь релиза новой версии языка.
И оно понятно, обработка http — это не целевая задача питона и делается сравнительно «сторонними» от ядра, средствами.
И что в этом плохого? Как это мешает разработчику?
007913
05.04.2019 06:33Я бы не согласился насчет «Простыни кода» и что все вынуждают пихать в один файл. В том то и сила питона — в его «гибкости», ты можешь многое регулировать в том как интерпретатор будет работать с твоими скриптами, да быть может это порой порушит читаемость (местами) но далеко не всегда, причем профит от структурированности перевешивает небольшую потерю понятности. Я у себя в некоторых частях программы сделал хранение определений классов моделек в чтоли java-подобном стиле (Основной тематический класс в одноименном классу файле) а так как «питон гибок» всего-то поправил __init__ пакета чтобы конструкции импорта которые уже юзали сохранили обратную совместимость при различных конструкциях импорта.
Циклический импорт, да неудобство, но кажется в последних версиях питона с ним разобрались «из коробки», кроме того ранее частично можно было с ним бороться стратегией типа «каталогов», «регистрированием модулей» через какую-то общую переменную в другом модуле.
А насчет констант как сущности — согласен это было бы полезно, еще бы круто если бы они были типа «в общем пуле сессии интерпретатора» и не зависели от импорта в конкретном модуле, кстати этот момент тоже в современных питонах кажется разрулили или разруливают :)
worldmind
04.04.2019 20:15Отсутствие констант
Константы нужны только для неизменяемых конфигурационных данных, а это реализуется кучей способов, от юзания стандартных namedtuple, до юзания frozen box.
модификаторов доступа
если вы про всякие public/private, то в питоне всё это есть, пусть и немного по иному реализованное, хотя по факту ценность этих вещей преувеличена
длинные простыни кода в одиночных файлах
это какой-то бред не связанный с питоном
мутная история с тайпхинтингом/типизацией
если не пытаться разобраться, то всё будет мутно, а по факту всё более чем хорошо и юзаетсчя в продакшене
и многое другое
видимо такого же уровняfso
04.04.2019 20:38Веду сейчас крупный федеральный проект на питоне, с большой распределенной командой разработчиков. Проблемы на самом деле существуют.
Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Невозможность приватных методов приводит к тому, что один разработчик начинает использовать публично метод, который для этого не предназначался и при дальнейшей разработке будет меняться несовместимо. Понятно что все это культура программистов, но предпосылки этих проблем — отсутствие модификаторов доступа.
Большая простыня models.py приводит к конфликтам слияния, попытка разбить на модули — к проблеме циклического импорта. И так далее.worldmind
04.04.2019 20:54Ну те кто используют 2 питон жаловаться права не имеют, так можно и на дористорический пхп жаловаться, да вообще на все старые версии языков.
Про константы я сказал, решения есть в том числе в стандартной библиотеке, кому нужно, тот использует.
Невозможность приватных методов
Вы ведёте проект и не владеете языком? Или что-то другое имеете ввиду?
В питоне есть достаточно приватные методы, погуглите чтоль про python private method да про property.
попытка разбить на модули — к проблеме циклического импорта.
Я пока не понимаю о чём вы, погуглитеpython avoid cyclic importfso
04.04.2019 23:18Или что-то другое имеете ввиду?
Да, чуть ошибся, я имел ввиду контекстprotected. То есть при наследовании доступен, но недоступен при вызове снаружи. И не сокрытие видимости с помощью__(кстати, тоже не выглядит элегантным), а именно ограничение доступа.worldmind
05.04.2019 09:05Дело в то, что за этим стоит базовые концепции языка, философия его создателей, вы её можете не разделять, но понимать стоит, об этом много написано, например тут, суть в том, что авторы питона считают (и я с ними согласен), что если программист дурак или вредитель, то никакими техническими ухищрениями вы не сделаете его умным и не защититись от его попыток навредить.
А нормальный человек если видит_some_methodпонимает, что это protected или__some_method— private и знает что на них полагаться нельзя.
Более того, на самом деле никто не знает как и почему, кому-то может понабодиться использовать ваш protected метод, пусть человек, под свою ответственность принимает решение в конкретном случае, ведь мы же считаем, что он понимает что делает.
Но если у вас нет нормальных программистов, то можно поискать решение, в питоне можно сделать практически всё, вот например попалось или вот, но не тестил.fso
05.04.2019 10:37А зачем, если можно взять язык, в котором это все просто-напросто есть?
worldmind
05.04.2019 10:41Каждый выбирает тот инструмент, который считает лучшим по сумме показателей, к счастью тут есть свобода выбора, если вам ближе идеология условно джавы, то не пишите на питоне.
fso
05.04.2019 10:44Трудно не согласиться с этим) Но мы как-то уклонилсь от изначального посыла в обсуждении «заточенности» питона под веб, перейдя к его недостаткам. Конечно, нет серебряной пули, у всего есть свои плюсы и минусы. Но, ИМХО, питон мог бы стать много лучше, причем малой кровью.
worldmind
05.04.2019 10:52Во-первых, не все решения так просты, попробуйте предложить куда-нибудь в python-ideas и скорее всего выяснится, что не так уж просто.
Во-вторых, он и становится лучше, с каждой версией, медленно, но верно. Оснований для спешки нет, те кто делают быстрее обычно делают плохо и на длинной дистации отваливаются.fso
05.04.2019 10:563-ей версии питона уже 11 лет… и первый мой комментарий как раз и был про то, что «не все так просто» и это во многом мешает питону развиваться, по крайней мере в сторону веба.
LighteR
05.04.2019 00:39Отсутствие констант очень сильно мешает, особенно в легаси 2.7 версии. Доходит до того, что простая опечатка в сравнении приводит к изменению значения того, что меняться в принципе не должно.
Можете привести пример такого кода в вашем проекте?fso
05.04.2019 00:49Примерно такое было (django с его настройками в settings.py в виде «констант»):
SETTINGS_CONSTANT = 1 condition = SETTINGS_CONSTANT = 2 # Must be == 2 if condition: print("Now SETTINGS_CONSTANT=%s" % SETTINGS_CONSTANT)
fso
04.04.2019 20:49+1а это реализуется кучей способов
Фактически, я и хотел сказать, что не надо «кучу способов», нужны просто константы. Зачем эти обходные пути, костыли-велосипеды, когда, повторюсь, во всех зрелых языках просто есть константы. И просто есть модификаторы доступа. И да, без них можно обойтись, но они придуманы не просто так и решают вполне насущные проблемы.worldmind
04.04.2019 20:55Да не надо обходится, берёте namedtuple и получаете иммутабельную структуру данных с красивым синтаксисом доступа (dot notation).
fso
04.04.2019 22:21+1Вы не хотите меня понять) Я не говорю что в питоне нельзя сделать неизменяемую структуру. я говорю, что это делается не как в других языках, специальным для этого инструментом — константой, а обходными путями, namedtuple в частности, занулением сеттеров и прочими костылями.
worldmind
05.04.2019 08:43Ну да, у каждого языка есть какие-то особенности, но если возможность есть, то на значимый недостаток это не тянет, хотя согласен что это минус.
mamokino
04.04.2019 18:46+2Давайте рассмотрим возможные варианты.
- C#
- Java
- PHP
- JavaScript и Node.js
JavaScript сейчас имеет смысл рассматривать сразу с TypeScript, а не опционально.
Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.
Ruby. Никакой он не нишевой как написано в статье, а вполне себе с кучей инструментария именно что и под web. Тоже вполне можно отнести к основным веб-языкам.
Под спойлером те, что нельзя причислить к основным веб-языкам, но, все же используемые в вебеСледующие мало где пока используются в вебе, но все же уже не экзотика для веба:
Elixir
Kotlin
Dart
Еще экзотика для веба, но все же используемая иногда:
Clojure
Erlang
Rust
У Юли пообъективнее про выбор языка в 2019 году
Imagine you have to select a programming language in 2019mkshma
04.04.2019 19:18-1Go забыли. А он имеет в вебе довольно сильные позиции. Да и разрабатывался с учетом веб-применения.
Go — это Ruby 2016-2018х годов. Поигрались и потихоньку бросают в пользу более полноценных языков.mamokino
04.04.2019 19:22-1Поигрались и потихоньку бросают в пользу более полноценных языков.
Кто именно бросает?
Для высоконагруженных решений альтернатив мало.
Какие именно, «более полноценные» для высоконагруженных решений?worldmind
04.04.2019 20:18Не тестил, но не раз слышал, что нормальные питонные фреймворки с uvloop под капотом дают такую же производительность как го и нода, вот например.
mamokino
05.04.2019 21:26такую же производительность как го и нода
Говоря про производительность вы напрасно поставили рядом Go и Node.JS.
Впрочем, не спорю, что на каких-то определенных, как сейчас принято говорить, «кэйсах использования» можно получить близкую производительность.
По поводу «особо быстрого Python», если уж применяются спец-решения с Python, как CPython в вашей ссылке, то, полагаю, будет справедливо рассматривать и спец-решения для Go, например, fasthttp, который существенно быстрее встроенного в Go пакета http github.com/smallnest/go-web-framework-benchmark
И все это, замечу, без каких-либо ухищрений как с CPython, а штатным компилятором.
VIkrom
05.04.2019 05:09и нужно знать специфику настройки Java-серверов.
В смысле уметь -Xmx указывать?
dididididi
05.04.2019 11:38Сооснователь, евангелист и преподаватель))
А программистов-питонщиков про питон нельзя было спросить, обязательно людей с какими то странными регалиями?
Надо себе тоже чонить придумать, типа «Джаваокий ангел Дмитрий».
Terras
08.04.2019 01:17Если честно реальность такова, что питон хорош по-большей части в проектах, где требуется какой-то расчет, математические модели и прочие штуки, связанные с работой с данными. Это объясняется наличием крутых математических и машин-лернинг библиотек.
Для всего остального — выбор питона это откровенная вкусовщина, которая ничем не объясняется, кроме как «Мы выбрали питон, так как нам нравился питон».
Django — убер удобный фреймворк для целого набора вещей. Тут вопросов нет.
Flask/Tornado/Twisted/aiohtp — уже неудобней и запутанней. И уже появляется вопрос, а нужно ли нам это все, и не взять ли что-то более «стандартное» для этого.
neochapay
Глядя на КДПВ сразу подумалось…
