Может показаться, что чем больше язык дает возможностей, тем он лучше, но это не так, на самом деле чем меньше в языке возможностей, тем лучше. Как правила, ограничения делают нас сильнее, например запреты на убийство и употребление наркотиков сделало все человечество сильнее.
А запреты на продажу алкоголя породило всплеск роста организованной преступности которые заработали на этом целые состояния. Жил бы язык Java который по идее должен был быть простым языком поэтому был топорным и без излишеств. Но программистом это не пришлось по душе и они обмазали все плагинами с когенерацией и куче рефлексией, что сделало работу с Java на некоторых проектах сходной с работой на JS по предсказуемости.
Время программистов стоит денег(видимо это знали всегда, поэтому begin/end из Паскаля совершенно не прижились, а С получил сильный буст из-за своей синтаксической простоты).
Ну да. Программисты это - это стенографисты, они только непрерывно печатают код и написание лишнего символа стоит денег заказчику. C победил паскаль за счет того что продал свою производительность а не за счет какой-то синтаксической простоты.
Пожалуй, максимально это понимали при дизайне Go, поэтому имеем
А где пример вида?
data, err:= fu()
if err!= nil {
log.Fatal(err)
}
/*вместо*/
var data = fu()
По другую сторону баррикад Go lang, для создателей которого важнее были простота и скорость компиляции(что для бизнеса зачастую куда важнее).
Если бы бизнесу была важна простота и скорость компиляции то он бы везде использовал Python. А вот Go как раз взлетел как раз из-за того что бизнесу внезапно понадобилась еще и производительность.
Давайте, забавы ради, используя арифметику и здравый смысл порассуждаем. Ему 17 лет а это значит что он либо еще учиться в школе, либо вот вот закончил. По моему личному разумению, зверь именуемый в народе сеньор - это минимум 5 лет коммерческого опыта. Почему так? Потому что чисто статистически, за это время, скорее всего, разработчик столкнётся с большинством классических проблем своей области, пробежит дистанцию с препятствиями в виде куче возможных граблей, победит их, успеет это отрефлексировать, переосмыслить и закрепить в уме. Я молчу про то что нужно время чтобы осознавать новое, нужны передышки и переосмысления. Нужно общение с разными людьми. И если кто-то скажет что он гений и ему нужно меньше времени, я скажу что даже если так то на работе никому не будут составлять и подкидывать разноплановые задачи для его обучения, а будет то что будет. Разнообразие задач и людей приходит на дистанции. Окей. Условимся так. Наш герой устроился на работу в 14 лет(3 года опыта). Ну да ладно. Далее. Нормальный рабочий день 8 часов, но для ребенка который только в 15.00 приходит домой и по закону давайте округлим до 4 часов. Т.е. мы получаем 3 года опыта, которые можно поделить пополам. Я рискну предположить что в школе даже что-то задают, нужно готовиться и учить уроки. Нужно поесть, отдохнуть и выделить достаточно времени чтобы прокачиваться в программировании. Т.е. в день нужно: посетить школу, отработать на работе, выучить уроки, прокачаться в разработке, поесть, пообщаться с родителями, возможно выполнить какую то часть домашней работы. А что насчет погулять с друзьями, позаниматься чем-то еще? Нет? Ну нет так нет. В сухом остатке моделируем ситуацию: ребенок который последние 3 года впахивал с утра до вечера не особо общаясь с друзьями и особо больше ничем не занимавшийся кроме школы и работы, потому что нет времени, с относительно не таким уже и большим опытом. Во что нам предлагают поверить? Что он работал на 4 работал, что человек который судя по описанию даже друзей не имел и кроме школы и работы ничего не видел учит сеньоров и тимлидов управлению людьми, который по хорошему по опыту на сеньора не тянет но внезапно бывший архитектор и СТО? Можно сколько угодно рассуждать на тему гениальной гениальности но лучше задаться вопросом как наколдовать себя столько свободного времени на все это?
Вы про то, что надо знать детали реализации slice, чтобы им пользоваться? В остальном вроде всё терпимо.
Ну да к примеру неочевидность slices. Далее, на вскидку, неочевидность работы с памятью. К примеру повергает в недоумение, когда при возврате из функции указателя на структуру происходит неявный боксинг, что по моему мнению контринтуитивно. То что при всей претенциозности обработки ошибок в Go - их можно просто не обработать или сделать это неправильно малозаметным способом. Работа со строками которые под капотом вроде бы должны быть UTF-8 но нет, там может быть все что угодно. len от строки выдаст количество байт а не символов. Дикие вещи вроде возврата из функции по имени. nil указатель, который рассыпает ворох граблей тут и там. Ну и т.д.
concurrency сразу спроектировали простым
Не простым а минималистичным. Нельзя сделать сложную задачу простой. Мы либо усложняем язык и делаем более сложные но более безопасные решения(привет Rust) либо заметаем сложность под ковер как в Go а потом наступаем. Сложность будет либо в изучении языка либо в решении проблемы. К тому же минимализм, при всей его привлекательности приносит также много проблем. К примеру в Java большая хорошая библиотека для многопоточки, где почти на все случаи жизни что-то имеется, да больше да сложнее и разнообразнее, но под конкретную проблемы мы просто возьмем подходящий проверенный инструмент. В случае Go это приведет либо к костылям либо к чужим либам. Это как предложить хирургу, в арсенале которого сотня инструментов, пользоваться одним типом скальпеля для любой операции. В плане обучения, единообразия, поставок инструментов вроде ок, но в плане результата - такое себе.
В ООП как в панацею мало кто верит
Хороший пример Rust. Язык имеющий определенный сходства с Go - отказ от ООП, наследования типов, отказ от исключений и т.д. Но сразу нашлись умники которые пошли писать библиотеки добавляющие исключения, наследование и прочее в язык в котором идиоматически этого быть не должно. Более того, нашлись гении которые пошли писать для него сборщик мусора. Так что к сожалению пока это все базируется на идеологии, а потом придет модный спикер и расскажет чего в Go не хватает.
Мой посыл наверное в том что яп не панацея, должна быть команда которая друг друга понимает, должна быть IT культура которая продвигает правильный подход.
В целом со статьей согласен и со всей этой болью. Но
С Kotlin, например, возможностей меньше, а значит, и саботаж устраивать сложнее, но ситуация не идеальная.
Java кажется более предпочтительным вариантом, так как менее экспрессивна
Поэтому в большой команде, где будут джуны, мидлы и техно-анархисты, я бы хотел писать на Go.
К сожалению не все так просто. Это скорей самообман сознания желающего найти простоту радикальным образом. Нельзя просто так взять и повыкидывать все из ЯП.
Возьмем тот же Kotlin, который излишне экспрессивный и Java, философия которой изначально строилась в стиле Go - повыкидывать все из языка, все ограничить и запретить. Что мы имеем в Java? Отсутствие перегрузки операторов приводит к огромной лапше в коде в местах где это бы пригодилось бы. Отсутствие именованных параметров - к повсеместному паттену builder. А главное, отсутствие выразительности языка привело к обилию паттернов и самое ужасное куче костылей от Lombok до взлета популярности проклятого AOP, который превратил Java из, в теории простого и читабельного языка в какое то неявное адище, в проектах с AOP. Если в языке не хватает выразительности чтобы решить проблему лаконично то часто это будет приводить либо к огромным портянках кода для простых вещей, либо разработчики быстро придумаю как прикрутить туда какую-нибудь вундервафлю и может стать еще хуже.
Есть очень тонкая грань, между выразительностью и простотой и в нее очень сложно попасть.
Go не панацея. Во-первых, да из языка много чего повыкидывали, проблема что забыли выкинуть грабли на которые тут и там можно наступить. Во-вторых, я думаю к сожалению все пойдет по тому же пути развития - будет расти комьюнити, будут расти проекты и будут чаще находиться люди которые будут писать библиотеки закрывающие по их мнению дыры языка, понапридумывают что-то в стиле AOP и Spring. Язык не забанит их за это.
А все потому что проблема в людях а не инструментах. Никакой ЯП даже самый минималистичны не запретит людям страдать фигней.
Т.е. вместо того чтобы воспользоваться здравым смыслом и позвать толкового разработчика, вместе пройтись по кодовой базе и описать ее, Вы предлагаете пойти купить курс по программированию? Вместо того чтобы потратить время и деньги на то чтобы прокачать себя как аналитика или куда-то еще?
Ну купили вы курс по Python, прошли основы, даже изучили что такое ООП, пришли на проект где к примеру C#/Java/C++/PHP а еще неожиданно оказалось что то что пишут в книгах и то что Вы увидите - разные вещи. Ваши действия?
По моему у вас просто подспудное желание разработкой заниматься и Вы зачем то себе придумали историю "зачем что аналитику это нужно".
Алгоритмическая секция есть нравится оно вам или нет. Кажется что в таком случае лучше ее любить, чем не любить)
А архитектурная секция встречается на собеседовании для фронтов довольно часто. Лично я ничего не приделывал) Она просто есть и к нему надо быть готовым. Насчет полезности и объективности каждого из этапов можно спорить долго, сейчас такой цели нет
Т.е. Вы просто делаете модно, хайпово, как все делают, даже не понимая и не задумываясь зачем, в стиле: ну у всех же так и у нас так, нужно просто смириться.
Но при этом пишите статью:
Техническое собеседование фронтенд-разработчика: советы от тимлида
Кажется, для многих это самая нелюбимая секция, что лично для меня крайне удивительно.
Действительно удивительно. Почему разработчик не любит секцию, когда ему нужно тратить время на подготовку к задаче которая с 99% вероятности никогда не встретиться ему на работе, при этом даже если бы встретилась то ему бы не пришлось ее решать за строго ограниченное время под пристальным присмотром другого человека с необходимостью комментировать каждый свой шаг. И главное зачем все это? Только потому что кому-то показалось это модным.
Если это нужно по работе то люди пишут это на работе. Если чтобы подготовиться нужно заниматься синтетической деятельностью вроде Leetcode - значит вы фигней маетесь.
Эта секция не про фронтенд. Если вы хотите пройти её успешно, вам необходимо разбираться, как устроена инфраструктура на сервере. Какие есть базы данных и чем они отличаются. Как организовать надёжное взаимодействие, и многое другое.
Не очень понятно, Вы приделали архитектурную секцию к собесу по фронтенду? Потому что модно и потому что у бэкендеров это есть а у вас нет, а оно при этом сейчас модное? Ну или какое разумное объяснение этому?
В моём коде я описываю логику отправки события, которое каждое является уникальным и точно не подходит под описание "один экземпляр на всё приложение". Будь у моего класса хотя бы один параметр в primary конструкторе, то такого предупреждения от IDE с "полезным" советом я не получил.
Проблема не в IDE а в том что Вы нигде и никак кроме как в словей голове не обозначили что экземпляры данного класса должны быть уникальными и надеетесь на identityhashcode вместо того чтобы явно выделить это свойство класса. IDE в данном случае вполне права - либо делайте синглтоном либо явно прописывайте те свойство что сделают объекты этого класса уникальными.
Я в целом согласен но есть одно большущее НО. Работать по уму - замечательный совет. Думать то что вы делаете - замечательный совет. Это все применимо либо когда работаешь один или небольшой группой, ну либо очень повезло с людьми. А теперь вернемся в реальность. Допустим у Вас хорошая команда, высока вероятность что все просто переругаются, потому что все индивидуалисты и уникальные снежинки. От того что пишет один будет воротить другого. Проект будет выглядеть как попало, потому что каждый сам себе буратин и творческая личность. Либо более реальная ситуация. К сожалению, особенно сейчас, не так много разработчиков которые умеют писать просто, которые умеют применять подход и инструменты к месту и к еще большему сожалению еще меньше тех кто вообще хочет думать. Для огромного количество разрабов это все от звонка до звонка и просто нужно сделать задачу. Если пускать людей в свободное плавание то как показывает такая практика проект просто превращается в ад.
С Вами в целом соглашусь что каждый подход хорош к месту но мой опыт показывает что уже лучше все будут плюс минус единообразно фанатеть по solid и для всех будут сходные стандарты и догмы, но зато в среднем по больнице это дает лучшие плоды чем надеяться что каждый примет правильное решение и проект не будет похож на творческий зоопарк.
Писать просто - сложно. Для этого нужно много опыта, которого на рынке нет. Намного проще чтобы все писали единообразно, пусть где-то с овер-инженерингом. Пусть лучше все будет через интерфейсы чем то так то сяк. Пусть лучше разделяют интерфейсы и пишут больше классов, которые по итогу можно заменять и легко тестировать, чем пускаются во все тяжкие и верить что условный разраб, которому возможно вообще это ваше программирование не интересно, он тут чисто за деньги, будет обдуманно каждое решение выкатывать. Проверяли, еще хуже все.
Я пытался рассуждать об идеологии, но комментаторы почему-то сваливаются в реализации.
Потому что программы пишуться на реализации конкретных решений а не на идеологии. Большого смысла рассуждать как было бы хорошо если бы... нет.
Если говорить о конкретных языках, то большинство из них обладает одним и тем же недостатком - статические сигнатуры методов для обработки сообщений.
Наверное потому что методы это не обработчики сообщений а методы.
А идея в том и состоит, чтобы сообщения были максимально произвольные. Некоторые утверждают, что бывают кейсы, в которых структура сообщения вообще неизвестна.
А что в этом такого сакрального и зачем вам это именно в ЯП? Хотите построить архитектуру где обработчики будут получать сообщения и произвольно обрабатывать их, напишите. Вот есть акторные модели есть архитектурное модели такого построения.
Вот у меня сейчас на проекте именно такая - микросервис получает сообщение через кафку и обрабатывает только те которые знает, остальные игнорирует. Что это такого даст если это внедрить на уровень ЯП?
Мое мнение что главная проблема современного ООП что никто толком даже не понимает что это вообще такое. Все есть объект? Если взять столпы ООП в виде C++ и Java, там все есть объект? Нет. Инкапсуляция, наследование, полиморфизм? Прекрасно существуют и в не ООП языках и не делают их ООП языками. По моему личному мнению, современное ООП это не целостная самодостаточная концепция с четкой теоретической базой, целями, задачами и путями их решения. Современное ООП - это просто одно из направлений развития старого доброго структурного программирования к которому добавили идею еще одного уровня модульности (на уровне структуры) и прикрутили несколько свистоперделок в виде наследования типов и динамической диспетчеризации а также назвали это модным по тем годам словом. Именно по этому, за несколько десятилетий так и не научились как на нем правильно писать а эволюция написания ООП программы пришла к простому процедурному стилю, где нужно иметь тупые объекты только с данными и сервисы без состояния.
Самое интересное не описали - с какой болью приходиться сталкиваться при написании программ на Go и почему для компании преимущества перевешивают эту боль. Без этого статья смотриться исключительно как реклама языка Go.
Вам говорят: на язык X можно создать cli приложение в прямом смысле слова в пару команд, пользуясь официальной документацией, используя встроенную библиотеку и средства разработчика и собрать это в том виде в котором нужно для конкретной цели. Не нужно ничего особо дополнительно устанавливать, не нужно лазить по интернету в поисках решений и библиотек для простейшей задачи. Не нужно дополнительные виртуальные машины ставить. Происто идем по оф. мануалу и вызваем несколько команд. Хотите кроссплатформенный вариант который будет работать на любой машине где установлена среда выполнения(C#), хотите - исполняемый файл, который будет работать без установленной виртуальной машины(C#/Go). Без проблем. Все из коробки.
Вы говорите: на Java все делается просто: если так -то вот так, а если вот так - то по другому, а если нужно чуток посложнее то вот это идем идем гуглим читаем доки. Для выполнения простейшей операции нет встроенной в язык функции? Да и не нужно, массив приходит и ладно. Нужно будет поискать еще библиотеки не проблема. Нужно исполняемый файл? Нужно ставить отдельную виртуальную машину в систему? Ну и ладно.
Можно ли все это сделать на Java, да можно, никто не спорит. Но когда после вышеописанного, что проще для простой программы: вызвать пару команд или копаться ковыряться в изучении плагинов для элементарных вещей, искать по интернету инструменты чтобы элементарно нормально можно было свое простое решение использовать, вы как ни в чем не бывало пишите:
В первый раз будет трудно, если похожего готового мануала не найду, а потом легко.
...
...но как по мне минимальный порог входа для того, чтобы сделать что-то относительно простое из всего о чем шла речь именно у java.
Это называется фанатизм своим языком программирования вопреки здравому смыслу. Тут спорить бесполезно.
Статью читали? Сейчас вам ничего не надо собирать, чтобы выполнить программу состоящую из одного файла. Просто java MyProgram.java
Если нужны зависимости для запуска этого файла без компиляции - используйте jbang
Сборка артефактов? Ну тогда вам нужно делать по-нормальному с maven/gradle. Но и тут я не вижу проблемы, это 3 клика в ide на все про все.
Есть такая элементарная и очень базовая задача - написать приложение для командной строки. Могу я схожу создать такое приложение имея только Java? Ну если hello word может быть. Если что-то чуток серьезнее где не один файл или нужна либа то нет. Нам уже нужно установить сборщик Ну ок. Далее мне чтобы получать в удобном виде аргументы командной строки, выводить help сообщения и т.д, нужно искать отдельную либу. Далее мы сможем собрать наше приложение в единый файл? Нет. Нам нужно ставить плагин чтобы хотя бы иметь возможность собрать все в Jar. Окей, будут ли в этом Jar файлы зависимости нашей либы? Нет. Нам нужен еще один плагин чтобы собирать полный Jar. Можем ли мы удобно это запускать как исполняемый файл не заставляя пользователя помнить что нужно прописывать java -jar? Нет не можем, нам опять нужен еще один из плагинов которые будет запускать скрипт когда мы пытаемся запустить Jar. И наконец, можем ли мы сделать полноценный исполняемый файл чтобы бы мы могли его запустить? Да, но нам нужно установить в систему и настроить отдельную JVM. И только после этого всего мы сможем сделать простейшую задачу - написать cli утилиту. Как итог, можем мы сделать это на Java? Да можем. Удобно ли это делать на Java? Да нефига.
Я просто не пойму с чем вы сравниваете
Да просто на вскидку. Возьмем Go, накидываем программу, используем встроенные средства для основных задач вроде парсинга аргументов, компилируем и получаем исполняемый файл без всяких танцев с бубном. Ну ок Go компилируемый. Берем самого очевидного и похожего конкурента C#. Просто через командную строку .net создаем сразу проект cli программы, накидываем что нужно и собираем в том виде в котором нам интересно: либо в единый исполняемый файл требующий виртуальной машины на ОС или в единый запускаемый файл в который уже все встроено. По итогу получаем исполняемый файл который не требует установки ничего и выполняем то что нам нужно. Нам не нужно ставить пакетные менеджеры, не нужно ставить и настраивать 10 плагинов и библиотек, и даже не нужно ставить сторонние виртуальные машины. У нас для элементарной задачи есть элементарное и удобное решение из коробки. Это называется - удобный языки для написания маленьких программ.
При подходящем инструментарии Java оказывается на удивление эффективным выбором для написания маленьких программ.
При всем уважении, Java - это один из самых неэффективных и неудобных языков для написания именно маленьких программ. Это тот редкий случай когда из коробки решение представляет из себя буквально ничего. Ни пакетного менеджера, ни сборщика артефактов, ни парсера аргументов командной строки. То что в других языках делаеться с лету встроенным функционалом, в Java нужно обмазываться кучей инструментов, библиотек и плагинов для написания простейшей cli программы.
Лояльность: проявление верности, преданности и честности в отношениях с коллегами и руководством компании, защита и поддержка их интересов.
Организую встречу с руководителем проекта и техлидом аналитиков, где мы в формате свободного общения смотрим задания и макеты, которые пришли от заказчика.
Умение создать и поддержать настоящую, а не номинальную культуру открытости, доверия, инноваций и саморазвития в команде. Умение поддержать профессиональное развитие коллег, включая организацию обучающих мероприятий и внутренних тренингов. Возможность выслушать и помочь не только в профессиональных, но и личных проблемах сотрудников.
У нас лояльность теперь это навык а главный аналитик - это техлид аналитики. Абсолютно рафинированный текст очевидно написанный нейросетью. Но зачем это на Хабре?
У виртуального потока есть свой стек, за счет этого как раз и имеем нормальный тред дамп
Согласен тут видимо меня немного занесло.
oracle делают что-то новое, когда в этом есть реальная необходимость и без этого никак, там ничего не хотят добавлять просто по приколу, например в лепешку разобьются, чтобы не добавить новое ключевое слово.
11->17 теперь в языке два switch с разной семантикой, + yield + record + sealed + permits + сломанная семантика get/set в records, + сам синтаксис records сломал весь стандартный привычный синтаксис. Все что вы пишите было актуально до 11 версии. Сейчас уже никто в лепешку не разбиваеться.
Сильно java упала в популярности из-за того, что в ней небыло асинхронщины на уровне языка?
Java популярна по причине того что исторически заняла финансовый сектор и успешно держит а не по причине качества, быстродействия или каких то фич языка. Там все обкатано и большой пул разработчиков а это главное.
в принципе по части самой vm java сильно лучше .net
Сильное заявление. А аргументы будут?
теперь вот оракл еще ее и сделан заново (graalvm)
Молодцы конечно, в .net с 2019 года AOT есть из коробки. Без установок дополнительных VM и прочего.
можно с другой стороны зайти: если вы делаете не прокси сервер, то сильно ли вы потеряете, если вместе с диском и базой зависнет еще и машина с приложением? ;) все равно есть какой-то пул потоков, типичный бекенд это oltp, нет никакого смысла пускать 5 тысяч клиентов на одну базу чтобы они все вместе ее грузили по чуть-чуть, эффективнее дать доступ только 50-и в один момент.
Да действительно, используются 200 потоков когда можно 8, обрабатываются запросы параллельно или пусть постоят в очереди. какая разница. Прилетело 1000 запросов и мы вывозим по кэшам базам и интеграциям обрабатывать их параллельно, не беда, пусть постоят в очереди для их же блага.
все что не содержит в себе synchronized работает хорошо, как-то особо катать там нечего.
Это конечно очень здорово что Вы сказали что все работает хорошо и тестить там нечего но я предпочту старый добрый метод опытной эксплуатации на больших проектах как показатель качества работы и ее зрелости.
лично я из своего опыта редко видел какие-то асинхронные подзадачи в коде
Все эти корутины и виртуальные потоки это история не столько про асинхронность сколько про эффективную утилизацию ресурсов давая возможность не блокировать потоки. Любой backend это практически одни IO операции.
сделали полноценные виртуальные потоки, как в го (с некоторыми минусами, но близко)
Что там общего с Go? В Go потоки не деляться на платформенные и виртуальные, там вся работа на уровне языка идет с горутинами. Горутины сделаны по stackful схеме, в Java виртуальные потоки по stackless. Горутины порождаются явно, и не нужно думать в любой точке кода в каком контексте мы работаем, потому что все работает на горутинах. На Java мы будем работать в неявном контексте. Ну разве что общее что и там и там поддержка со стороны рантайма.
Как бы по этому в C# и добавили сахар с async/await в 2012, потому что работы не очень много на него надо
И как итог, в C# 12 лет как пишут по новому а в Java все эти годы давились реактивщиной, или просто забивали на нужды разработчиков. В принципе можно было и другие проблемы также решать: нужен новый сборщик мусора? Подождите лет 20, зато мы выкатим самый модный.
вам сделали конфетку, а вы тянетесь по привычке к сухарику
Вот когда это все добро обкатают, внедрят поддержку на всех необходимых библиотеках, ни у кого ничего не отвалится или отвалиться и все починят, и когда это обкатается на больших проектах, вот тогда да, можно будет похвалить. Потому что на деле может оказаться, как часто бывает шило на мыло.
Трудно сказать насколько сильно нужна эта асинхронищина на беке, в том смысле что если у вас пару мест асинхронного вызова, то можно использовать апи, которое еще с java 8 было, не самое красивое, с нюансами, но работает.
Если это шутка то не очень понятная.
По этому может и с большим запозданием, но в java это сделано так как должно
Есть такое хорошее выражение "лучшее - враг хорошего". Может быть async/await это не идеальное решение, но это решение которое работало, работает и будет работать. В то время как другие ЯП (JS, TS, Swift, Kotlin, Python, Rust) скопировали не идеальное но рабочее решение и многие годы используют их в боевых проектах, в Java семь лет пытались сделать "лучшее" решение, которое еще не факт что себя оправдает. Хотя нет же, в Java все это время закрывали проблему реактивными библиотеками, там прям страх и ненависть в комплекте и стакан молока за вредность, но зато не async/await.
в java это сделано так как должно
только время покажет должное ли оно
вам не надо знать ни про какие async/await
Как показывает практика знать придется еще больше, но про другое
Смотря что мы решаем. Если наша задача оптимизировать большое количество IO операций с минимальными вычислениями на CPU то разница между одним и несколькими потоками уже не будет такой драматичной - большую часть времени задачи будет находиться в состоянии ожидания. Так как горутины в основном для этого и создавались (так как с вычислительными CPU операциями хорошо справляются и обычные потоки) то справедливо заметить что в данном контексте как раз горутины и async это решениям одной и той же проблемы, немного отличающимися но все равно довольно близкими методами. Если мы возьмем не питон а C# или Kotlin где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.
А запреты на продажу алкоголя породило всплеск роста организованной преступности которые заработали на этом целые состояния. Жил бы язык Java который по идее должен был быть простым языком поэтому был топорным и без излишеств. Но программистом это не пришлось по душе и они обмазали все плагинами с когенерацией и куче рефлексией, что сделало работу с Java на некоторых проектах сходной с работой на JS по предсказуемости.
Ну да. Программисты это - это стенографисты, они только непрерывно печатают код и написание лишнего символа стоит денег заказчику. C победил паскаль за счет того что продал свою производительность а не за счет какой-то синтаксической простоты.
А где пример вида?
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go-gpp.html
Если бы бизнесу была важна простота и скорость компиляции то он бы везде использовал Python. А вот Go как раз взлетел как раз из-за того что бизнесу внезапно понадобилась еще и производительность.
Давайте, забавы ради, используя арифметику и здравый смысл порассуждаем.
Ему 17 лет а это значит что он либо еще учиться в школе, либо вот вот закончил.
По моему личному разумению, зверь именуемый в народе сеньор - это минимум 5 лет коммерческого опыта. Почему так?
Потому что чисто статистически, за это время, скорее всего, разработчик столкнётся с большинством классических проблем своей области, пробежит дистанцию с препятствиями в виде куче возможных граблей, победит их, успеет это отрефлексировать, переосмыслить и закрепить в уме. Я молчу про то что нужно время чтобы осознавать новое, нужны передышки и переосмысления. Нужно общение с разными людьми. И если кто-то скажет что он гений и ему нужно меньше времени, я скажу что даже если так то на работе никому не будут составлять и подкидывать разноплановые задачи для его обучения, а будет то что будет. Разнообразие задач и людей приходит на дистанции.
Окей. Условимся так.
Наш герой устроился на работу в 14 лет(3 года опыта). Ну да ладно.
Далее. Нормальный рабочий день 8 часов, но для ребенка который только в 15.00 приходит домой и по закону давайте округлим до 4 часов.
Т.е. мы получаем 3 года опыта, которые можно поделить пополам.
Я рискну предположить что в школе даже что-то задают, нужно готовиться и учить уроки. Нужно поесть, отдохнуть и выделить достаточно времени чтобы прокачиваться в программировании.
Т.е. в день нужно: посетить школу, отработать на работе, выучить уроки, прокачаться в разработке, поесть, пообщаться с родителями, возможно выполнить какую то часть домашней работы. А что насчет погулять с друзьями, позаниматься чем-то еще? Нет?
Ну нет так нет.
В сухом остатке моделируем ситуацию:
ребенок который последние 3 года впахивал с утра до вечера не особо общаясь с друзьями и особо больше ничем не занимавшийся кроме школы и работы, потому что нет времени, с относительно не таким уже и большим опытом.
Во что нам предлагают поверить?
Что он работал на 4 работал, что человек который судя по описанию даже друзей не имел и кроме школы и работы ничего не видел учит сеньоров и тимлидов управлению людьми, который по хорошему по опыту на сеньора не тянет но внезапно бывший архитектор и СТО?
Можно сколько угодно рассуждать на тему гениальной гениальности но лучше задаться вопросом как наколдовать себя столько свободного времени на все это?
Ну да к примеру неочевидность slices. Далее, на вскидку, неочевидность работы с памятью. К примеру повергает в недоумение, когда при возврате из функции указателя на структуру происходит неявный боксинг, что по моему мнению контринтуитивно.
То что при всей претенциозности обработки ошибок в Go - их можно просто не обработать или сделать это неправильно малозаметным способом.
Работа со строками которые под капотом вроде бы должны быть UTF-8 но нет, там может быть все что угодно. len от строки выдаст количество байт а не символов.
Дикие вещи вроде возврата из функции по имени.
nil указатель, который рассыпает ворох граблей тут и там.
Ну и т.д.
Не простым а минималистичным. Нельзя сделать сложную задачу простой. Мы либо усложняем язык и делаем более сложные но более безопасные решения(привет Rust) либо заметаем сложность под ковер как в Go а потом наступаем. Сложность будет либо в изучении языка либо в решении проблемы. К тому же минимализм, при всей его привлекательности приносит также много проблем. К примеру в Java большая хорошая библиотека для многопоточки, где почти на все случаи жизни что-то имеется, да больше да сложнее и разнообразнее, но под конкретную проблемы мы просто возьмем подходящий проверенный инструмент. В случае Go это приведет либо к костылям либо к чужим либам. Это как предложить хирургу, в арсенале которого сотня инструментов, пользоваться одним типом скальпеля для любой операции. В плане обучения, единообразия, поставок инструментов вроде ок, но в плане результата - такое себе.
Хороший пример Rust. Язык имеющий определенный сходства с Go - отказ от ООП, наследования типов, отказ от исключений и т.д. Но сразу нашлись умники которые пошли писать библиотеки добавляющие исключения, наследование и прочее в язык в котором идиоматически этого быть не должно. Более того, нашлись гении которые пошли писать для него сборщик мусора. Так что к сожалению пока это все базируется на идеологии, а потом придет модный спикер и расскажет чего в Go не хватает.
Мой посыл наверное в том что яп не панацея, должна быть команда которая друг друга понимает, должна быть IT культура которая продвигает правильный подход.
В целом со статьей согласен и со всей этой болью. Но
К сожалению не все так просто. Это скорей самообман сознания желающего найти простоту радикальным образом.
Нельзя просто так взять и повыкидывать все из ЯП.
Возьмем тот же Kotlin, который излишне экспрессивный и Java, философия которой изначально строилась в стиле Go - повыкидывать все из языка, все ограничить и запретить.
Что мы имеем в Java?
Отсутствие перегрузки операторов приводит к огромной лапше в коде в местах где это бы пригодилось бы. Отсутствие именованных параметров - к повсеместному паттену builder.
А главное, отсутствие выразительности языка привело к обилию паттернов и самое ужасное куче костылей от Lombok до взлета популярности проклятого AOP, который превратил Java из, в теории простого и читабельного языка в какое то неявное адище, в проектах с AOP.
Если в языке не хватает выразительности чтобы решить проблему лаконично то часто это будет приводить либо к огромным портянках кода для простых вещей, либо разработчики быстро придумаю как прикрутить туда какую-нибудь вундервафлю и может стать еще хуже.
Есть очень тонкая грань, между выразительностью и простотой и в нее очень сложно попасть.
Go не панацея. Во-первых, да из языка много чего повыкидывали, проблема что забыли выкинуть грабли на которые тут и там можно наступить. Во-вторых, я думаю к сожалению все пойдет по тому же пути развития - будет расти комьюнити, будут расти проекты и будут чаще находиться люди которые будут писать библиотеки закрывающие по их мнению дыры языка, понапридумывают что-то в стиле AOP и Spring. Язык не забанит их за это.
А все потому что проблема в людях а не инструментах. Никакой ЯП даже самый минималистичны не запретит людям страдать фигней.
Т.е. вместо того чтобы воспользоваться здравым смыслом и позвать толкового разработчика, вместе пройтись по кодовой базе и описать ее, Вы предлагаете пойти купить курс по программированию? Вместо того чтобы потратить время и деньги на то чтобы прокачать себя как аналитика или куда-то еще?
Ну купили вы курс по Python, прошли основы, даже изучили что такое ООП, пришли на проект где к примеру C#/Java/C++/PHP а еще неожиданно оказалось что то что пишут в книгах и то что Вы увидите - разные вещи. Ваши действия?
По моему у вас просто подспудное желание разработкой заниматься и Вы зачем то себе придумали историю "зачем что аналитику это нужно".
Т.е. Вы просто делаете модно, хайпово, как все делают, даже не понимая и не задумываясь зачем, в стиле: ну у всех же так и у нас так, нужно просто смириться.
Но при этом пишите статью:
где начинаете какие-то советы давать?
Действительно удивительно. Почему разработчик не любит секцию, когда ему нужно тратить время на подготовку к задаче которая с 99% вероятности никогда не встретиться ему на работе, при этом даже если бы встретилась то ему бы не пришлось ее решать за строго ограниченное время под пристальным присмотром другого человека с необходимостью комментировать каждый свой шаг. И главное зачем все это? Только потому что кому-то показалось это модным.
Если это нужно по работе то люди пишут это на работе. Если чтобы подготовиться нужно заниматься синтетической деятельностью вроде Leetcode - значит вы фигней маетесь.
Не очень понятно, Вы приделали архитектурную секцию к собесу по фронтенду?
Потому что модно и потому что у бэкендеров это есть а у вас нет, а оно при этом сейчас модное? Ну или какое разумное объяснение этому?
Проблема не в IDE а в том что Вы нигде и никак кроме как в словей голове не обозначили что экземпляры данного класса должны быть уникальными и надеетесь на identityhashcode вместо того чтобы явно выделить это свойство класса. IDE в данном случае вполне права - либо делайте синглтоном либо явно прописывайте те свойство что сделают объекты этого класса уникальными.
Я в целом согласен но есть одно большущее НО.
Работать по уму - замечательный совет. Думать то что вы делаете - замечательный совет.
Это все применимо либо когда работаешь один или небольшой группой, ну либо очень повезло с людьми.
А теперь вернемся в реальность.
Допустим у Вас хорошая команда, высока вероятность что все просто переругаются, потому что все индивидуалисты и уникальные снежинки. От того что пишет один будет воротить другого. Проект будет выглядеть как попало, потому что каждый сам себе буратин и творческая личность.
Либо более реальная ситуация. К сожалению, особенно сейчас, не так много разработчиков которые умеют писать просто, которые умеют применять подход и инструменты к месту и к еще большему сожалению еще меньше тех кто вообще хочет думать. Для огромного количество разрабов это все от звонка до звонка и просто нужно сделать задачу. Если пускать людей в свободное плавание то как показывает такая практика проект просто превращается в ад.
С Вами в целом соглашусь что каждый подход хорош к месту но мой опыт показывает что уже лучше все будут плюс минус единообразно фанатеть по solid и для всех будут сходные стандарты и догмы, но зато в среднем по больнице это дает лучшие плоды чем надеяться что каждый примет правильное решение и проект не будет похож на творческий зоопарк.
Писать просто - сложно. Для этого нужно много опыта, которого на рынке нет. Намного проще чтобы все писали единообразно, пусть где-то с овер-инженерингом. Пусть лучше все будет через интерфейсы чем то так то сяк. Пусть лучше разделяют интерфейсы и пишут больше классов, которые по итогу можно заменять и легко тестировать, чем пускаются во все тяжкие и верить что условный разраб, которому возможно вообще это ваше программирование не интересно, он тут чисто за деньги, будет обдуманно каждое решение выкатывать. Проверяли, еще хуже все.
Потому что программы пишуться на реализации конкретных решений а не на идеологии. Большого смысла рассуждать как было бы хорошо если бы... нет.
Наверное потому что методы это не обработчики сообщений а методы.
А что в этом такого сакрального и зачем вам это именно в ЯП? Хотите построить архитектуру где обработчики будут получать сообщения и произвольно обрабатывать их, напишите. Вот есть акторные модели есть архитектурное модели такого построения.
Вот у меня сейчас на проекте именно такая - микросервис получает сообщение через кафку и обрабатывает только те которые знает, остальные игнорирует. Что это такого даст если это внедрить на уровень ЯП?
Мое мнение что главная проблема современного ООП что никто толком даже не понимает что это вообще такое. Все есть объект? Если взять столпы ООП в виде C++ и Java, там все есть объект? Нет. Инкапсуляция, наследование, полиморфизм? Прекрасно существуют и в не ООП языках и не делают их ООП языками.
По моему личному мнению, современное ООП это не целостная самодостаточная концепция с четкой теоретической базой, целями, задачами и путями их решения. Современное ООП - это просто одно из направлений развития старого доброго структурного программирования к которому добавили идею еще одного уровня модульности (на уровне структуры) и прикрутили несколько свистоперделок в виде наследования типов и динамической диспетчеризации а также назвали это модным по тем годам словом.
Именно по этому, за несколько десятилетий так и не научились как на нем правильно писать а эволюция написания ООП программы пришла к простому процедурному стилю, где нужно иметь тупые объекты только с данными и сервисы без состояния.
Самое интересное не описали - с какой болью приходиться сталкиваться при написании программ на Go и почему для компании преимущества перевешивают эту боль.
Без этого статья смотриться исключительно как реклама языка Go.
Вам говорят:
на язык X можно создать cli приложение в прямом смысле слова в пару команд, пользуясь официальной документацией, используя встроенную библиотеку и средства разработчика и собрать это в том виде в котором нужно для конкретной цели. Не нужно ничего особо дополнительно устанавливать, не нужно лазить по интернету в поисках решений и библиотек для простейшей задачи. Не нужно дополнительные виртуальные машины ставить. Происто идем по оф. мануалу и вызваем несколько команд.
Хотите кроссплатформенный вариант который будет работать на любой машине где установлена среда выполнения(C#), хотите - исполняемый файл, который будет работать без установленной виртуальной машины(C#/Go). Без проблем. Все из коробки.
Вы говорите:
на Java все делается просто: если так -то вот так, а если вот так - то по другому, а если нужно чуток посложнее то вот это идем идем гуглим читаем доки. Для выполнения простейшей операции нет встроенной в язык функции? Да и не нужно, массив приходит и ладно. Нужно будет поискать еще библиотеки не проблема.
Нужно исполняемый файл? Нужно ставить отдельную виртуальную машину в систему? Ну и ладно.
Можно ли все это сделать на Java, да можно, никто не спорит.
Но когда после вышеописанного, что проще для простой программы: вызвать пару команд или копаться ковыряться в изучении плагинов для элементарных вещей, искать по интернету инструменты чтобы элементарно нормально можно было свое простое решение использовать, вы как ни в чем не бывало пишите:
Это называется фанатизм своим языком программирования вопреки здравому смыслу. Тут спорить бесполезно.
Есть такая элементарная и очень базовая задача - написать приложение для командной строки. Могу я схожу создать такое приложение имея только Java?
Ну если hello word может быть. Если что-то чуток серьезнее где не один файл или нужна либа то нет. Нам уже нужно установить сборщик Ну ок. Далее мне чтобы получать в удобном виде аргументы командной строки, выводить help сообщения и т.д, нужно искать отдельную либу. Далее мы сможем собрать наше приложение в единый файл? Нет. Нам нужно ставить плагин чтобы хотя бы иметь возможность собрать все в Jar. Окей, будут ли в этом Jar файлы зависимости нашей либы? Нет. Нам нужен еще один плагин чтобы собирать полный Jar. Можем ли мы удобно это запускать как исполняемый файл не заставляя пользователя помнить что нужно прописывать java -jar? Нет не можем, нам опять нужен еще один из плагинов которые будет запускать скрипт когда мы пытаемся запустить Jar. И наконец, можем ли мы сделать полноценный исполняемый файл чтобы бы мы могли его запустить? Да, но нам нужно установить в систему и настроить отдельную JVM. И только после этого всего мы сможем сделать простейшую задачу - написать cli утилиту.
Как итог, можем мы сделать это на Java? Да можем.
Удобно ли это делать на Java? Да нефига.
Да просто на вскидку. Возьмем Go, накидываем программу, используем встроенные средства для основных задач вроде парсинга аргументов, компилируем и получаем исполняемый файл без всяких танцев с бубном. Ну ок Go компилируемый.
Берем самого очевидного и похожего конкурента C#. Просто через командную строку .net создаем сразу проект cli программы, накидываем что нужно и собираем в том виде в котором нам интересно: либо в единый исполняемый файл требующий виртуальной машины на ОС или в единый запускаемый файл в который уже все встроено. По итогу получаем исполняемый файл который не требует установки ничего и выполняем то что нам нужно. Нам не нужно ставить пакетные менеджеры, не нужно ставить и настраивать 10 плагинов и библиотек, и даже не нужно ставить сторонние виртуальные машины. У нас для элементарной задачи есть элементарное и удобное решение из коробки.
Это называется - удобный языки для написания маленьких программ.
При всем уважении, Java - это один из самых неэффективных и неудобных языков для написания именно маленьких программ. Это тот редкий случай когда из коробки решение представляет из себя буквально ничего. Ни пакетного менеджера, ни сборщика артефактов, ни парсера аргументов командной строки. То что в других языках делаеться с лету встроенным функционалом, в Java нужно обмазываться кучей инструментов, библиотек и плагинов для написания простейшей cli программы.
У нас лояльность теперь это навык а главный аналитик - это техлид аналитики. Абсолютно рафинированный текст очевидно написанный нейросетью. Но зачем это на Хабре?
Согласен тут видимо меня немного занесло.
11->17
теперь в языке два switch с разной семантикой, + yield + record + sealed + permits + сломанная семантика get/set в records, + сам синтаксис records сломал весь стандартный привычный синтаксис.
Все что вы пишите было актуально до 11 версии. Сейчас уже никто в лепешку не разбиваеться.
Java популярна по причине того что исторически заняла финансовый сектор и успешно держит а не по причине качества, быстродействия или каких то фич языка. Там все обкатано и большой пул разработчиков а это главное.
Сильное заявление. А аргументы будут?
Молодцы конечно, в .net с 2019 года AOT есть из коробки. Без установок дополнительных VM и прочего.
Да действительно, используются 200 потоков когда можно 8, обрабатываются запросы параллельно или пусть постоят в очереди. какая разница. Прилетело 1000 запросов и мы вывозим по кэшам базам и интеграциям обрабатывать их параллельно, не беда, пусть постоят в очереди для их же блага.
Это конечно очень здорово что Вы сказали что все работает хорошо и тестить там нечего но я предпочту старый добрый метод опытной эксплуатации на больших проектах как показатель качества работы и ее зрелости.
Все эти корутины и виртуальные потоки это история не столько про асинхронность сколько про эффективную утилизацию ресурсов давая возможность не блокировать потоки. Любой backend это практически одни IO операции.
Что там общего с Go? В Go потоки не деляться на платформенные и виртуальные, там вся работа на уровне языка идет с горутинами. Горутины сделаны по stackful схеме, в Java виртуальные потоки по stackless. Горутины порождаются явно, и не нужно думать в любой точке кода в каком контексте мы работаем, потому что все работает на горутинах. На Java мы будем работать в неявном контексте. Ну разве что общее что и там и там поддержка со стороны рантайма.
И как итог, в C# 12 лет как пишут по новому а в Java все эти годы давились реактивщиной, или просто забивали на нужды разработчиков. В принципе можно было и другие проблемы также решать: нужен новый сборщик мусора? Подождите лет 20, зато мы выкатим самый модный.
Вот когда это все добро обкатают, внедрят поддержку на всех необходимых библиотеках, ни у кого ничего не отвалится или отвалиться и все починят, и когда это обкатается на больших проектах, вот тогда да, можно будет похвалить. Потому что на деле может оказаться, как часто бывает шило на мыло.
Если это шутка то не очень понятная.
Есть такое хорошее выражение "лучшее - враг хорошего". Может быть async/await это не идеальное решение, но это решение которое работало, работает и будет работать. В то время как другие ЯП (JS, TS, Swift, Kotlin, Python, Rust) скопировали не идеальное но рабочее решение и многие годы используют их в боевых проектах, в Java семь лет пытались сделать "лучшее" решение, которое еще не факт что себя оправдает. Хотя нет же, в Java все это время закрывали проблему реактивными библиотеками, там прям страх и ненависть в комплекте и стакан молока за вредность, но зато не async/await.
только время покажет должное ли оно
Как показывает практика знать придется еще больше, но про другое
Смотря что мы решаем. Если наша задача оптимизировать большое количество IO операций с минимальными вычислениями на CPU то разница между одним и несколькими потоками уже не будет такой драматичной - большую часть времени задачи будет находиться в состоянии ожидания. Так как горутины в основном для этого и создавались (так как с вычислительными CPU операциями хорошо справляются и обычные потоки) то справедливо заметить что в данном контексте как раз горутины и async это решениям одной и той же проблемы, немного отличающимися но все равно довольно близкими методами. Если мы возьмем не питон а C# или Kotlin где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.