Вам говорят: на язык 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 программы.
Лояльность: проявление верности, преданности и честности в отношениях с коллегами и руководством компании, защита и поддержка их интересов.
Организую встречу с руководителем проекта и техлидом аналитиков, где мы в формате свободного общения смотрим задания и макеты, которые пришли от заказчика.
Умение создать и поддержать настоящую, а не номинальную культуру открытости, доверия, инноваций и саморазвития в команде. Умение поддержать профессиональное развитие коллег, включая организацию обучающих мероприятий и внутренних тренингов. Возможность выслушать и помочь не только в профессиональных, но и личных проблемах сотрудников.
У нас лояльность теперь это навык а главный аналитик - это техлид аналитики. Абсолютно рафинированный текст очевидно написанный нейросетью. Но зачем это на Хабре?
В общем. Быть миддлом - нормально. Берегите менталочку.
Плюсую. Во первых, по моему опыту, не так много разработчиков в принципе смогут, по ряду причин, дорасти до уровня сеньор. Во-вторых, крепкие опытные мидлы - это основа хорошей команды.
Иначе, когда они станут миддлами, а миддл не будет развиваться дальше, они станут на одну ступень, и здесь может победить молодость, а не опыт.
Глупо рассматривать весь опыт разработчика в 3 абсолютные ступени и считать что вчерашний джун который проработал 1.5-2 года и стал мидлом вдруг встал на одну ступень с мидлом у которого 5-6 лет опыта. То что и того и другого упрощенно принято называть словом мидл не значит их эквивалентность. Уж про то что молодость будет преимуществом промолчу.
У виртуального потока есть свой стек, за счет этого как раз и имеем нормальный тред дамп
Согласен тут видимо меня немного занесло.
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 где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.
И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
public static void sleep(long millis) throws InterruptedException {
if (millis < 0) {
throw new IllegalArgumentException("timeout value is negative");
}
long nanos = MILLISECONDS.toNanos(millis);
ThreadSleepEvent event = beforeSleep(nanos);
try {
if (currentThread() instanceof VirtualThread vthread) {
vthread.sleepNanos(nanos);
} else {
sleep0(nanos);
}
} finally {
afterSleep(event);
}
}
Наверное, дело в каких-то оптимизациях хранения объектов в куче.
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи. Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого. Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем. Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Развивайте как глубину в своей области, так и ширину знаний. Например, Java-разработчику полезно изучить DevOps или основы UI-дизайна.
Технологии развиваются стремительно. Знание популярных инструментов, таких как Docker или Kubernetes, и новых языков программирования вроде Go или Rust, выделит вас среди других специалистов.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Умение объяснять сложные технические детали, работать в команде и понимать цели бизнеса ценится не меньше, чем знание фреймворков.
Для кого? Для джуна?
"Java Concurrency in Practice" — Брайан Гетц
Вот тут можно дискутировать насчет полезности LeetCode да и в целом способности решать алгоритмические задачки, но мое индивидуальное мнение - алгоритмы полезны, так как, если ты знаешь структуры данных и можешь их использовать в решении задач, то ты можешь чувствовать себя увереннее в разработке.
Отличные советы чтобы навичок все забросил. Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий. Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто. Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Бесшовный пользовательский опыт: Хотя микрофронтенды разрабатываются отдельно, пользователь воспринимает их как одно целое.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода. Читать такие переводы уже на физическом уровне больно.
C#, в отличие от C++, подходящим для игр языком никогда не был. В играх это во многом другой язык, без LINQ и даже без foreach.
Я стесняюсь спросить, если не C++ и не C#, то какие языки вообще являются подходящими?
По моему мнению как раз C# это очень подходящий для этого язык, за счет широких возможностей в управлении хотя бы тем где будет выделена память, большому числу возможных оптимизаций и удобной интеграцией с FFI. Да, есть GC и сложно от него куда-то деться, но ведь никто не мешает создавать пулы объектов, обходить стороной виртуальные вызовы, инлайнить, выделять память in place, и применять множество других трюков, а бутылочные горлышки закрывать тем же FFI. Зато, сравнивая с C++ или Rust по разным причинам он куда проще и лучше для прототипирования фич, и в среднем безопаснее.
Отличное знание Java Core и Java Concurrency. Понимание объектно-ориентированного программирования, знание особенностей при работе с ним в Java.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.
Вам говорят:
на язык 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 программы.
У нас лояльность теперь это навык а главный аналитик - это техлид аналитики. Абсолютно рафинированный текст очевидно написанный нейросетью. Но зачем это на Хабре?
Плюсую.
Во первых, по моему опыту, не так много разработчиков в принципе смогут, по ряду причин, дорасти до уровня сеньор.
Во-вторых, крепкие опытные мидлы - это основа хорошей команды.
Глупо рассматривать весь опыт разработчика в 3 абсолютные ступени и считать что вчерашний джун который проработал 1.5-2 года и стал мидлом вдруг встал на одну ступень с мидлом у которого 5-6 лет опыта. То что и того и другого упрощенно принято называть словом мидл не значит их эквивалентность.
Уж про то что молодость будет преимуществом промолчу.
Согласен тут видимо меня немного занесло.
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 где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.
И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи.
Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого.
Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем.
Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Для кого? Для джуна?
Отличные советы чтобы навичок все забросил.
Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий.
Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто.
Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода.
Читать такие переводы уже на физическом уровне больно.
Т.е. на C# писать пулы объектов неудобно а вот на Кедре то что для проекта сначала нужно написать игровой движок - это в самый раз?
Уже есть игровые движки, причем одни из самых популярных: Unity/Godot
Огромное число разработчиков по всему миру
Обслуживается Microsoft и не протухнет когда разработчику языка надоест
Огромное количество учебных материалов
Огромное число библиотек и готовых решений
Зрелая экосистема
и прочее прочее прочее
Что из этого есть у Кедра?
Я стесняюсь спросить, если не C++ и не C#, то какие языки вообще являются подходящими?
По моему мнению как раз C# это очень подходящий для этого язык, за счет широких возможностей в управлении хотя бы тем где будет выделена память, большому числу возможных оптимизаций и удобной интеграцией с FFI.
Да, есть GC и сложно от него куда-то деться, но ведь никто не мешает создавать пулы объектов, обходить стороной виртуальные вызовы, инлайнить, выделять память in place, и применять множество других трюков, а бутылочные горлышки закрывать тем же FFI.
Зато, сравнивая с C++ или Rust по разным причинам он куда проще и лучше для прототипирования фич, и в среднем безопаснее.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.