Комментарии 26
Несмотря на то, что Java чрезвычайно популярна среди разработчиков ПО, она менее дружелюбна к пользователю, чем, скажем, Python.
Это как не дружелюбна? Что за пользователи у бэкенда? Чем Пайтон дружелюбнее, улыбается чаще?
Visual Basic для бэкенда?! Месье знает толк в извращениях! :)
В статье какой-то невероятный микс в секции .NET.
Можно подумать, что только в секции .Net. Ну вот возьмите хоть это:
Бэкенд-технологии Java могут использоваться для решения большого количества задач, включая:
Разработка мобильных приложений под Android.
НЛО прилетело и опубликовало эту надпись здесь
Мне больше понравилась эта претензия:
Из этого вообще выходит что VS с проектом на VB.NET требует сильно больше памяти чем таже студия с проектом на C#/F#. Не пожалел времени(ноут рабочий у меня древний) на проверку:
Порядок — запуск студии, ожидание когда устаканится расход CPU/Mem, создание/открытие проекта(пустой проект, после открытия только полистал код). Закрытие студии, открытие в студии ранее созданного проекта, ожидание когда устаканится расход CPU/Mem. Сколько занимает на винте «поддержка» того или иного языка проверять не буду — потратить весь день на установку/снос разных версий студии в разной комплектации я не готов.
VS 2019 Community, v 16.18.3
до создания/открытия проекта — 326,3-329.1
VB.NET console app(new/reopen) — 713.2-713.8/689.5-691.4=>~-7%
C# console app(new/reopen) — 738.3-743.8/743.8-742.6
VS 2017 Community, v 15.9.29(не самая последняя, но обновления не ставил пока)
до создания/открытия проекта — 274.6-275
VB.NET console app(new/reopen) — 369.6-370.2/368.5-369.4=>~+7%
C# console app(new/reopen) — 327.1-327.5/345.3-345.7
VS 2015 Community, v 14.0.25431.01 Update 3
до создания/открытия проекта — 161.8-162.3
VB.NET console app(new/reopen) — 205.8-208.1/185.0-187.5=>~+42%
C# console app(new/reopen) — 155.5-157.1/130.7-131.4
VS2010 на ноуте уже не держу, за неё сказать не смогу :).
Получается что для VS2015 заявление верно(почти в 1.5 раза больше памяти для запуска — OMG на целых 50+Мб!!!), но MS это поправила :), и на VS2019 претензию нужно адресовать уже C#. Но вообще конечно бредовый абзац — даже в момент выхода VS2015 разница в 50Мб была ни о чём, одна вкладка браузера отъедала больше. С тем же успехом автор оригинала мог бы поставить в вину C# что в нём слишком много скобок :).
P.S. Если абстрагироваться от VS(как «инструмента разработки»), то в редакторе Midnight Commander при редактировании одинакового объёма кода(NET.Core) VB.NET/C# разницы в потреблении оперативки я не заметил :).
Недостаток VB — большой объем памяти, который необходим для установки и запуска инструментов разработки.
Из этого вообще выходит что VS с проектом на VB.NET требует сильно больше памяти чем таже студия с проектом на C#/F#. Не пожалел времени(ноут рабочий у меня древний) на проверку:
Порядок — запуск студии, ожидание когда устаканится расход CPU/Mem, создание/открытие проекта(пустой проект, после открытия только полистал код). Закрытие студии, открытие в студии ранее созданного проекта, ожидание когда устаканится расход CPU/Mem. Сколько занимает на винте «поддержка» того или иного языка проверять не буду — потратить весь день на установку/снос разных версий студии в разной комплектации я не готов.
VS 2019 Community, v 16.18.3
до создания/открытия проекта — 326,3-329.1
VB.NET console app(new/reopen) — 713.2-713.8/689.5-691.4=>~-7%
C# console app(new/reopen) — 738.3-743.8/743.8-742.6
VS 2017 Community, v 15.9.29(не самая последняя, но обновления не ставил пока)
до создания/открытия проекта — 274.6-275
VB.NET console app(new/reopen) — 369.6-370.2/368.5-369.4=>~+7%
C# console app(new/reopen) — 327.1-327.5/345.3-345.7
VS 2015 Community, v 14.0.25431.01 Update 3
до создания/открытия проекта — 161.8-162.3
VB.NET console app(new/reopen) — 205.8-208.1/185.0-187.5=>~+42%
C# console app(new/reopen) — 155.5-157.1/130.7-131.4
VS2010 на ноуте уже не держу, за неё сказать не смогу :).
Получается что для VS2015 заявление верно(почти в 1.5 раза больше памяти для запуска — OMG на целых 50+Мб!!!), но MS это поправила :), и на VS2019 претензию нужно адресовать уже C#. Но вообще конечно бредовый абзац — даже в момент выхода VS2015 разница в 50Мб была ни о чём, одна вкладка браузера отъедала больше. С тем же успехом автор оригинала мог бы поставить в вину C# что в нём слишком много скобок :).
P.S. Если абстрагироваться от VS(как «инструмента разработки»), то в редакторе Midnight Commander при редактировании одинакового объёма кода(NET.Core) VB.NET/C# разницы в потреблении оперативки я не заметил :).
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Бесполезная статья на хайповую тему.
Основа языка — архитектурный шаблон >MVC (Model-View-Controller).
Что-то с переводом? Не языка, видимо, основа.
JS для начинающего программирование — на мой взгляд, хуже не придумаешь. Начинать надо с любого языка, где нет не включенных в синтаксис добавок, например, разного рода препроцессоров, или магических функций вида __mf_name__. Новичку и так приходится вникать в новую для него область знаний, а вы ему еще и нюансы функционирования конкретной среды исполнения в мозг вваливаете.
Сахарок, препроцессоры и прочее никак не влияют на пригодность языка для новичка, если их не нужно изучать сразу. Это главная причина бешеной популярности Питона для обучения программированию: он очень хорошо спроектирован в плане плавности увеличения сложности, не нужно зубрить заклинания public static void main и иже с ними. В нём много магии, но она умело спрятана под капот.
JS же имеет другой колоссальный плюс, даже два: он вездесущ, и сравнительно небольшими усилиями можно достичь ощутимого результата (знание основ HTML/CSS подразумевается, конечно, но это тоже элементарно). То, что можно сделать на связке HTML/CSS/JS в несколько страниц кода при весьма и весьма поверхностном знании, попросту недостижимо на других языках.
JS же имеет другой колоссальный плюс, даже два: он вездесущ, и сравнительно небольшими усилиями можно достичь ощутимого результата (знание основ HTML/CSS подразумевается, конечно, но это тоже элементарно). То, что можно сделать на связке HTML/CSS/JS в несколько страниц кода при весьма и весьма поверхностном знании, попросту недостижимо на других языках.
К питону меньше всего упреков.
Главное, при отборе материала, все последовательно, и очень аккуратно изложить.
Скользкие, на мой взгляд, темы:
— магические функции вида __mf_name__(). нужно аккуратно объяснить, что это инструмент взаимодействия со средой исполнения, но ни как не синтаксиса.
— декораторы. инструмент на сколько мощный, на столько и опасный для неокрепшего разума неофита (логика, реализуемая декораторами, может быть весьма раскиданной по пакетам, при всей лаконичности использования и реализации самой декорируемой функции, за декораторами может скрываться весьма нехилая работа).
— метапрограммирование. даже если вы не пишите метаклассы сами, достаточно, к примеру, подтянуть orm, чтобы сбить с толку новичка. необходимо добиваться четкого понимания, что является частью языка, а что реализовано в отдельном модуле программистом и будет исполняться в программе.
На начальном этапе эти темы следует избегать, максимально отодвигая разговор о них.
К JS как к первому языку программирования упреков больше.
Первым приходит на ум: распространенность практики на «чистом» js примерно такая же, как у ассемблера относительно высокоуровневых языков. Даже поклонники old school, как минимум, используют jquery+plugins. Да, без знания js не усвоить весь остальной арсенал, но, на мой взгляд, это hard way, если говорить о первоначальном обучении программированию, когда очень важно не отбить у неофита желание что либо изучать в принципе.
Начертание кода, его читаемость, на мой взгляд, даже если и удобна в написании, крайне не удобна в восприятии непрофессионалом. JS можно вменить тот же упрек, что, в свое время, любили относить к perl: код на этом языке сложно читать, а раз сложно читать, значит сложно и понимать.
Главное, при отборе материала, все последовательно, и очень аккуратно изложить.
Скользкие, на мой взгляд, темы:
— магические функции вида __mf_name__(). нужно аккуратно объяснить, что это инструмент взаимодействия со средой исполнения, но ни как не синтаксиса.
— декораторы. инструмент на сколько мощный, на столько и опасный для неокрепшего разума неофита (логика, реализуемая декораторами, может быть весьма раскиданной по пакетам, при всей лаконичности использования и реализации самой декорируемой функции, за декораторами может скрываться весьма нехилая работа).
— метапрограммирование. даже если вы не пишите метаклассы сами, достаточно, к примеру, подтянуть orm, чтобы сбить с толку новичка. необходимо добиваться четкого понимания, что является частью языка, а что реализовано в отдельном модуле программистом и будет исполняться в программе.
На начальном этапе эти темы следует избегать, максимально отодвигая разговор о них.
К JS как к первому языку программирования упреков больше.
Первым приходит на ум: распространенность практики на «чистом» js примерно такая же, как у ассемблера относительно высокоуровневых языков. Даже поклонники old school, как минимум, используют jquery+plugins. Да, без знания js не усвоить весь остальной арсенал, но, на мой взгляд, это hard way, если говорить о первоначальном обучении программированию, когда очень важно не отбить у неофита желание что либо изучать в принципе.
Начертание кода, его читаемость, на мой взгляд, даже если и удобна в написании, крайне не удобна в восприятии непрофессионалом. JS можно вменить тот же упрек, что, в свое время, любили относить к perl: код на этом языке сложно читать, а раз сложно читать, значит сложно и понимать.
JS ещё и отлаживать сложно. Когда вам в лог упадёт «undefined is not a function», вы можете вылавливать ошибку буквально часами. Ведь вменяемого стектрейса, как том же Python, вы не получите, потому что контекст давно потерян: управление прошло через 100500 промисовых лямбд и всяких коллбэков.
Вообще, код на нормальном ЯП должен вылядеть как синхронный и отлаживаться как синхронный, и только выполняться, если это действительно нужно, уже асинхронно. А так JS заставляет программиста вручную делать то, что по уму за него должны делать JIT-компилятор и среда выполнения.
Вообще, код на нормальном ЯП должен вылядеть как синхронный и отлаживаться как синхронный, и только выполняться, если это действительно нужно, уже асинхронно. А так JS заставляет программиста вручную делать то, что по уму за него должны делать JIT-компилятор и среда выполнения.
Кстати, удивился, что в PHP довольно высокая средняя зарплата, почему-то думал, что платят чуть ли не меньше всего.
Весной 2020 года средняя зарплата (Python) в США составляла $76526 в год. Разброс — от $58k до $107k.
Весной 2020 года в США средняя зарплата JavaScript-программистов составила $76526 в год. Разброс — от $58k до $107k.
Главный недостаток VB в том, что он всё, больше не будет развиваться.
Главный плюс PHP — из всего упомянутого он наименее ресурсоёмок. Если вы для экспериментов берёте наидешевейший (или даже вообще халявый) VPS с 512Мб памяти, то именно связка nginx+MySQL+PHP позволит вам выжать из этого железа максимум, буквально порвав всё остальное (ну, не считая всякой экзотики вроде OpenResty).
Вот например неплохое сравнение потребления серверных ресурсов различными фреймворками в зависимости от задачи/нагрузки.
Вот например неплохое сравнение потребления серверных ресурсов различными фреймворками в зависимости от задачи/нагрузки.
Ну и развернуть его на голом сервере, имея только репу/папку с исходниками почти проще всего. Go, если правильный бинарник собрать знаешь как разве что проще.
ну сборка гошных бинарников штука тривиальная))
go build --ldflags '-s -w' — самый простой способ, но бинарь будет требовать (на примере линуксов), чтобы версия libc на собираемой оси была не выше, чем на оси где все будет запускаться. Если это является проблемой можно сделать так:
go build --ldflags '-s -w -linkmode external -extldflags "-static"' -trimpath
бинарь толстоватый получится, но запустится практически где угодно без дополнительных плясок с бубном
go build --ldflags '-s -w' — самый простой способ, но бинарь будет требовать (на примере линуксов), чтобы версия libc на собираемой оси была не выше, чем на оси где все будет запускаться. Если это является проблемой можно сделать так:
go build --ldflags '-s -w -linkmode external -extldflags "-static"' -trimpath
бинарь толстоватый получится, но запустится практически где угодно без дополнительных плясок с бубном
Установить PHP гораздо проще, чем, скажем, Ruby on Rails.
Ну, во-первых PHP это язык программирования, а Ruby on Rails, это фреймворк.
Во-вторых, благодаря таким инструментам как rbenv(для python даже клон сделали — pyenv) и rvm установка и управление версиями приложения и языка, даже без использования виртуализации, куда проще чем тот-же composer, в том числе проще и легче решение проблем с зависимостями.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самые популярные языки программирования бэкенда: для чего они подходят лучше всего и какие компании их используют