Вы точно уверены, что яндекс не использует Java? А может они не используют еще python? Вы пишете бред полный. Откройте яндекс вакансии. У яндекса куча проектов на многих популярных языках, конечно критический код пишут на C++ или C, и у них есть отдельно люди с хорошим знанием алгоритмов для оптимизации кода, тут к гадалке не ходи. По вашим комментария сразу становится понятно, что вы никогда не имели дело с крупными проектами, и в принципе не понимаете их специфику и какие задачи они решают. Вы пишете просто тут непонятные мифы...)))
Вы пишете полную чушь. Так же товарищ выше писал про Rust. Глубоко сомневаюсь, что вы писали приличные приложения на Java и Rust. Вы сейчас тут распространяете непонятные мифы. Rust не решает проблемы GC и не заменит его! Читайте мой комментарий выше! Rust решает совсем другую проблему! Если вам нужен низкоуровневый доступ к памяти JAVA, то может использовать Unsafe, VarHandle, но вы видимо таких вещей даже не знаете.
Дело не в развитой системе типов. JAVA это в первую очередь платформа, инфраструктура и набор решений, технологий для бизнес задач, например Enterprise Java Beans, развиты фреймфорки типа spring и hibernate, есть сервера приложений. Java умеет делать Hot Swap! Есть ли что-то подобное для Rust?
1. У вас не примут коммит, если вы не придерживаетесь правил форматирования и оформления кода. На то майнтайнер, чтобы следить за всем этим. Или например вы не придерживаетесь нужной методологии в стилях, к примеру вы не придерживаетесь БЭМ.
2. Есть автоматические системы проверки репозитория на соответствие правилам оформления кода. Если у вас где-то пробелы вместо табуляции, или у вас 4 пробела вместо 2, это сразу покажет. Это же покажут линтеры при загрузке конфига с проекта, и нормальный редактор загрузит c проекта автоматически editor config, чтобы форматирование производить по правилам.
3. Есть автоматические системы сборки и тестирования, чтобы быстро отловить кривые коммиты и их отклонить.
Это вполне нормально. Когда язык обрастает конструкциями и меняет сильно облик, то его становится значительно сложнее поддерживать. К примеру в Clang еще не полностью поддерживается C++ 20, а некоторые вещи портят производительность. Поэтому многие языки не редко переписывают с нуля и переход всегда болезненный. К примеру, за 15 лет perl даже не решились выпустить perl 6, в итоге люди разделились и выпустили как отдельный язык raku. Видимо побоялись участи python.
Не улучшает чтение, к примеру можно взять sass или less, при переходе на stylus количество строк кода значительно сокращается и увеличивается его читаемость. Это одна из причин почему в крупных компаниях очень любят stylus, просто становится проще ориентироваться по коду. У меня за плечами большое количество языков, и тоже много раз приходил к тому, что упрощение синтаксиса идет только на руки читаемости крупных проектов.
Проблема такая есть, еще лет 20 назад про нее слышал. Но она имхо раздута и преувеличена. Самое главное это никак не помогает kotlin он так же медленно компилирует.
Хорошо, а зачем лишнее двоеточие? Можно было бы его выкинуть. Для токенизатора и лексера это наверное упрощает парсинг, но можно легко обойтись без :.
Меня всегда убивало, что в языках программирования ради парсинга исходников добавляли дополнительные символы, например в R дико не удобно использовать <= для присвоения значения, pascal go :=, где-то помню было +=. Зачастую подобные вещи просто убавляют читаемости.
Супер, оказывается потенциальные пользователи продуктов Jetbrains бомжи, хорошее начало… Что и писал выше, сотрудники Jetbrains смешные и не умеют реагировать на конструктивную критику… В VS Code есть OSS сборка, там нет телеметрии и проприетарных компонентов.
Ага, цена космос на metrahit ultra. Обычно все берут fluke или brymen. Ох уж эти богатые европейцы… Лично остановился на Brymen BM869s. Fluke 87 тоже дорогой, но brymen ему почти не уступает, а где-то даже превосходит.
Он изначально превосходил JAVA, они первыми завезли лямбда выражения и кучу синтаксического сахара. Майкрософт же создали изначально свою Microsoft Java Virtual Machine, даже помню, как она ставилась вместе с Visual Studio 2003, но столкнулись с судебными исками по поводу торговой марки JAVA в названии. В итоге они жестко обиделись, обида подтолкнула их создать что-то более лучшее, и они создали C#, который имел схожий синтаксис, но еще имел кучу синтаксического сахара и большое количество улучшений. И честно говоря, если бы они изначально отказались от привязки только к в windows и создали свою .net платформу для всех основных ОС, то они бы жестко откусили рынок JAVA и возможно даже бы сместили его с лидирующих позиций. Основной плюс JAVA был, да и основная концепция, что напиши один раз и будет работать везде. Правда Microsoft к этому пришли только сейчас и уже активно продвигают .NET в другие ОС, и видимо пытаются все же откусить кусок от JAVA. Да и вообще свои продукты активно продвигают в опенсорс, и создают лояльную аудиторию.
В нормальных проектах:
1. У вас не примут коммит, если вы не придерживаетесь правил форматирования и оформления кода. На то майнтайнер, чтобы следить за всем этим. Или например вы не придерживаетесь нужной методологии в стилях, к примеру вы не придерживаетесь БЭМ.
2. Есть автоматические системы проверки репозитория на соответствие правилам оформления кода. Если у вас где-то пробелы вместо табуляции, или у вас 4 пробела вместо 2, это сразу покажет. Это же покажут линтеры при загрузке конфига с проекта, и нормальный редактор загрузит c проекта автоматически editor config, чтобы форматирование производить по правилам.
3. Есть автоматические системы сборки и тестирования, чтобы быстро отловить кривые коммиты и их отклонить.
Меня всегда убивало, что в языках программирования ради парсинга исходников добавляли дополнительные символы, например в R дико не удобно использовать <= для присвоения значения, pascal go :=, где-то помню было +=. Зачастую подобные вещи просто убавляют читаемости.