1. Вы высосали проблему из пальца. Таких проблем в принципе нет в нормальных проектах, такое пресекают на корню, закомитили косячный код, первый раз предупреждение, дальше лишение премии. Дисциплину в нормальных проектах так прививают, чтобы не делали кривые коммиты, и тестировали код перед отправкой. Вы видимо даже с гитом дело не имеете, так как в нормальном открытом проекте такие вещи не пройдут, сначала вам сделают замечание и попросят оформить код как надо, а дальше просто отклонят пулреквест, если вы не исправите код!
2. У вас код кривой и это сразу глазами видно, что не соблюдены отступы. Плюс редактор на него ругается! Видимо у вас майтенеру глаза выкололи и вы работаете по старинке в блокноте?
3. Видимо по вашему мнению миллионы пользователей python, стоит заметить, который входит в топ 5 языков по пулярности, настолько тупы, что у них все на отступах и они программируют на нем? По некоторым рейтингам python занимает 1 и 2е место. Мне в python лично не нравится только отсутствие строгой типизации, отчего там с производительность не все хорошо. В остальном он практически идеален.
lany лично по моему опыту язык программирования не так сильно влияет на производительность, значительно больше влияет на производительность опыт и знания программистов. Можно даже на nodejs найти очень тяжелые, большие и быстрые проекты. И вы правильно написали про миграцию, это самое дорогое. Во вторых те же же Java и nodejs можно спрофилировать на рабочем бэкенде с помощью утилиты perf, а дальше критический код переписать на C++ или C.
Лично флюку больше доверяю хоть там отсчетов меньше. У моего brymen 869s вообще 500000 отсчетов. Что fluke, что brymen работают отлично, у обоих отлично с высоковольтной безопасностью и точностью, не плывут. Мне не очень понятна ценовая политика на метрахит, что есть в нем такого чего нет во fluke и brymen. За цену метрахта можно купить совсем крутой fluke.
Upd. Посмотрел обзор на этот метрахит, там совсем все печально жестко плывет на последних разрядах и не может стабилизироваться в показаниях, ловит не понятные наводки по воздуху, его надо было назвать мегарахит… Категории только до 600в, ну совсем ни о чем. 600в даже у моего китай unit-t ut61e plus есть, и не плывет он на последних разрядах. А brymen 869 как вкопанный показывает…
Вы точно уверены, что яндекс не использует 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 :=, где-то помню было +=. Зачастую подобные вещи просто убавляют читаемости.
2. У вас код кривой и это сразу глазами видно, что не соблюдены отступы. Плюс редактор на него ругается! Видимо у вас майтенеру глаза выкололи и вы работаете по старинке в блокноте?
3. Видимо по вашему мнению миллионы пользователей python, стоит заметить, который входит в топ 5 языков по пулярности, настолько тупы, что у них все на отступах и они программируют на нем? По некоторым рейтингам python занимает 1 и 2е место. Мне в python лично не нравится только отсутствие строгой типизации, отчего там с производительность не все хорошо. В остальном он практически идеален.
Upd. Посмотрел обзор на этот метрахит, там совсем все печально жестко плывет на последних разрядах и не может стабилизироваться в показаниях, ловит не понятные наводки по воздуху, его надо было назвать мегарахит… Категории только до 600в, ну совсем ни о чем. 600в даже у моего китай unit-t ut61e plus есть, и не плывет он на последних разрядах. А brymen 869 как вкопанный показывает…
В нормальных проектах:
1. У вас не примут коммит, если вы не придерживаетесь правил форматирования и оформления кода. На то майнтайнер, чтобы следить за всем этим. Или например вы не придерживаетесь нужной методологии в стилях, к примеру вы не придерживаетесь БЭМ.
2. Есть автоматические системы проверки репозитория на соответствие правилам оформления кода. Если у вас где-то пробелы вместо табуляции, или у вас 4 пробела вместо 2, это сразу покажет. Это же покажут линтеры при загрузке конфига с проекта, и нормальный редактор загрузит c проекта автоматически editor config, чтобы форматирование производить по правилам.
3. Есть автоматические системы сборки и тестирования, чтобы быстро отловить кривые коммиты и их отклонить.
Меня всегда убивало, что в языках программирования ради парсинга исходников добавляли дополнительные символы, например в R дико не удобно использовать <= для присвоения значения, pascal go :=, где-то помню было +=. Зачастую подобные вещи просто убавляют читаемости.