Comments 272
Поэтому для задач, где критична производительность, используют либо другие языки
Ну разумеется. Все сразу идут и переписывают десятки тысяч строк готового кода на другой язык, если в одном месте оказалось узкое место через годы разработки. Кто же использует Cython, по вашему, если для критичных задач используют другие языки?
Cython
Так ведь и получается, что "медленный" Python преобразуется в "быстрый" C. Формально "используют либо другие языки" и происходит.
Он, как и описываемый в статье Mojo - надмножество.
Любой корректный код на Python будет нормально обработан Cython. То есть Cython расширяет Python, добавляя новые синтаксические конструкции, которые полезны, но не обязательны.
Если верить Курту Смиту, автору учебника по Cython, то трансляция обычного питонячьего кода ускоряет его в среднем на 30%
Так в чём фокус?
Фокус думаю (я тоже не особенно питонист) в решении описанной выше проблемы
Все сразу идут и переписывают десятки тысяч строк готового кода на другой язык, если в одном месте оказалось узкое место через годы разработки.
Тут при обнаружении узкого места не надо всё переписывать на другом языке, достаточно расставить типы и чуть модифицировать код, чтобы получить разумную производительность.
Так все эти приколы с микросервисами и т.п. как раз ради того, что бц именно узкое место можно было написать на более подхожящем языке без переписывания всей кодовой базы.
Общее - это что вы имеете ввиду? Что никто не использует другие языки для узких чуть мест? Этого из моих слов никак не выжать. Что всем нужен более быстрый питон? Тоже никак. Какой всё-таки "общий" тезис я, на ваш взгляд, пытаюсь доказать?
Это у вас скорее общий тезис - сначала сомнения, есть ли у питона проблемы с производительностью и потом утверждение, что люди в таких случаях используют другие языки (или библиотеки на других языках). Выглядит как неявный намёк, что решать проблемы с производительностью не надо, потому что их, якобы, нет, а если уж есть, то есть си.
переходе с Python на Cython код не нужно переписывать :)
Частично нужно и это минус.
Вы правы, говоря, что низкая производительность - не всегда проблема. Вы правы, говоря, что проблема не существует вне контекста. Вы правы, утверждая, что проблемы языка - лишь подмножество возможных проблем с производительностью.
Но всё это расширение контекста разговора никак не влияет на тезис. Контекст, в котором низкая производительность питона - это проблема - существует. И контекст, в котором GIL - это проблема, тоже существует. И если пара вложенных циклов занимают 300мс вместо 30 - это тоже может быть проблемой. Но это не значит, что это ошибка проектирования или что проект такого масштаба, что в нём вообще есть архитектор и техлид. Вероятно, вы работаете сейчас в таком и это накладывает отпечаток на ваши рассуждения.
Иногда просто долго и сложно писать свой особенный модуль на расте и с проблемой просто миришься. Но это не значит, что проблемы нет.
А насчёт веры в новый язык я сказать ничего не могу. Выйдет, можно будет посмотреть. Если у него будет совместимость с существующей экосистемой и при этом, как минимум, решена проблема GIL - это будет очень круто. Хотя верится слабо.
Послушайте, если в задаче критично, чтоб вложенные циклы обрабатывались за 20мс, а не за 300, значит такие специфические проблемы обговариваются в дизайн-документе. Если это не указано, значит это не такая уж и проблема, а мастурбация на циферки.
Если же код уже написан, а потом вдруг обнаружилось, что он неработоспособен из-за циклов в 300мс - кто ж вам доктор, что это не учли и выбрали в итоге питон?
Не придумывайте проблемы на ровном месте. Питон медленный, и это специфика языка, а не его проблема. Скоростью оплачивается простота программирования на нем.
А идея «нового языка, который решит все-все проблемы языка N» доходит нынче до абсурда. Зачем мне учить Groovy для написания пайплайнов в дженкинсе, если существовуют другие скриптовые языки, например Lua? Да, Груви очень простой и синтаксис его милипиздрический, но зачем мне забивать голову, запоминая его особенности?
Просто скорость - не то, что выходит в круг ваших рабочих обязанностей. Потому вам и кажется, что это "проблема на ровном месте". Голова болит у того, кто дизайн-документ пишет для вас.
Разумеется, в дизайн-проекте может быть описано требование в 20мс. Если оно там будет описано, питон быстрее станет? Нет. Вот тогда и будет проблема. Искать обходной путь, менять язык, писать библиотеку на си, жить с тормозами. А уж менять на си или на Mojo - это по ситуации.
Если в вашей практике таких проблем не возникало - значит у вас такие проекты, вам решение не нужно. У других возникало.
Просто в этом ITT тренде два человека, не знающие питон, обсуждают питон.
По пунктам:
У питона нет никаких проблем ни с GIL, ни с производительностью, но есть некоторые частные проблемы с многопоточкой в CPython, которых нет в других реализациях (IronPython, Jython, PyPy), и есть некоторые проблемы со скоростью исполнения некоторых частных случаев кода, впрочем, не имеющие большого значения в огромном количестве случаев (например, там, где узкое место какой-нибудь IO)
Cython сам по себе не решает никакой проблемы: например, если скормить итерирование по ключам и значениям словаря cython, тот сгенерирует то же самое, что CPython и так сгенерирует при компиляции скрипта в байт-код, то есть, последующая компиляция выхлопа cython ни при каких -O не даст исполнения быстрее самого интерпретатора, хоть с типами, хоть без
Более того, cython генерирует очень много бойлерплейта, который нужен не всегда (например, ОДЗ входных параметров функции уже проверена в вызывающем коде, но cython проверит ещё раз, потратив процессор)
То же самое, если переписать обход словаря на чистом Python C-API — там просто негде ускоряться, потому что сишный код вызывает другой сишный код, который на чистом питоне и так вызывается ровно в той же последовательности и с теми же проверками и параметрами
Cython имеет смысл при написании оберток к внешним бинарным библиотекам (чтобы писать более понятный питонистам код, вместо шаманства над ctypes и cffi)
А там, где нужна именно многопоточность, на C-API пишется небольшая прослойка-переходник, далее чистые posix треды на голом Си, ну и структурки на нём же, обратно через такой же переходник конвертируем в PyObject* и возвращаем
С учётом того, что основной рантайм даже смысла нет бить на потоки, в сишном коде можно без Py_ReleaseState(), если память не изменяет, обойтись
Из вышесказанного у меня рождаются сильные боли ниже спины, когда я вижу "ускорители питона" на cython, типа https://github.com/sqlalchemy/sqlalchemy/blob/main/lib/sqlalchemy/cyextension/collections.pyx
У питона нет никаких проблем ни с GIL
где нужна именно многопоточность, на C-API пишется небольшая прослойка-переходник, далее чистые posix треды на голом Си
Действительно. Никаких проблем с GIL, просто пишешь на голом си в нужных местах.
Легко сказать, "он просто не знает питон" и таким образом субъективно оказаться выше собеседника. Но последующие тезисы не должны хотя бы противоречить друг другу.
Они не противоречат, если понять простую вещь: язык Python не имеет ничего общего с GIL. Одна (чуть ли не единственная) реализация его CPython -- имеет. Таким образом, ничто из сказанного мной не противоречит реальности, и не имеется взаимоисключающих утверждений в сказанном мной выше.
Что касается "просто пишешь на голом Си" -- тоже не совсем верно. Можно вместо threading воткнуть multiprocessing, который разработчики языка специально сделали совместимым по интерфейсам с threading, таким образом реализация на тредах заменяется на такую же на многопроцессную просто подменой импорта. Но везде есть трейд-оффы. Например, обмен данными между процессами -- это очень большая боль. Поэтому, если надо именно общее пространство разделяемой памяти с аккуратным использованием синхронизационных примитивов -- добро пожаловать в PyPy/Jython/IronPython/CPython+C-API+POSIX.
И да, с учетом того, куда ушло обсуждение "питон -- медленный", я делаю вывод, что обсуждатели не знают языка и, как минимум, той его реализации, которую обсуждают (с учетом постоянных тыканий в GIL, это, очевидно, CPython)
Когда вы ставите питон на сервер - вы ставите эталонную реализацию. Когда вы ставите условный JAX, разумеется вы рассчитываете, что он работает под эталонной реализацией.
Разве нужно это упоминать в каждом комментарии? Конечно GIL не имеет прямого отношения к синтаксису, а именно к реализации (но косвенное всё же имеет).
Но это очень странный подход - если вы обсуждаете gcc - вы не знаете язык, ведь есть clang. Если обсуждаете php - вы не знаете язык, потому что есть hacklang. Что в вашем понимании "знать язык" - это иметь опыт от трёх лет как минимум в двух -трёх реализациях или что?
Что ж, вы правы. Вы сказали собеседнику, что он не знает языка, поэтому проблем с производительностью в питоне нет. Ведь есть С-апи и альтернативные реализации.
Альтернативные реализации так же не имеют проблем с производительностью, ведь ваш собеседник не знает языка. Именно так этот довод и работает, верно?
Но это очень странный подход - если вы обсуждаете gcc - вы не знаете язык, ведь есть clang
Интересный подход. В обсуждениях Си обычно рубилово идёт за чистый стандарт. А всякие расширения (у них даже название есть: gcc-измы) -- это фу-фу-фу, в приличном обществе не принято их упоминать.
А с Python стрелочка не поворачивается вот. Хотя есть, например, PyPy, удовлетворяющий потребностям, пожалуй, большинства проектов, за исключением уж совсем смузи-блидинг-едж, которым прям без функций Python 3.10 не обойтись.
Что в вашем понимании "знать язык"
Это знать, где его не только слабые стороны, огульно распространяя эти частные случаи на весь язык (разных реализаций тоже касается), но и где сильные стороны. Туда же пишем понимание, где "скорость питона" не имеет никакого значения (почти любой IO), поэтому и обсуждать какие-то там мифические сотни терабит в секунду на сях, которые невозможно на питоне (имея канал в пару десятков мегабит при этом), не имеет смысла.
Альтернативные реализации так же не имеют проблем с производительностью
Именно так этот довод и работает, верно?
Нет, этот довод работает так: собеседник, распространяющий частный случай какой-то конкретной проблемы какой-то конкретной реализации на общий случай, возможно, не ведая того, признается, что не знает предмета, о котором говорит. В противном случае придётся признать, вот здесь я обнаружил, что С++ -- убогий тормозной язык (и мой питон в десятки, если не сотни раз быстрее решает такую же задачу).
Можно вместо threading воткнуть multiprocessing
И огрести проблем с переносимостью, потому что под виндой оно себя ведет по-другому из-за отсутствия форка, и то что работало на линухе просто так не заведется.
Можно подумать, без каких-либо замен раньше это не было проблемой. Вспомнить, к примеру, проблему с кириллицей в file path на винде. Казалось бы, даже os.sep везде, чтоб уж точно исключить \ vs. /, файлы и каталоги для переносимости всегда исключительно lowercased, и тут бах! Один кирилличный символ всё ломает. И я уже сейчас не воспроизведу, но os.getfilesystemencoding() не помогал.
Послушайте, если в задаче критично, чтоб вложенные циклы обрабатывались за 20мс, а не за 300, значит такие специфические проблемы обговариваются в дизайн-документе. Если это не указано, значит это не такая уж и проблема, а мастурбация на циферки.
ТЗ (видимо, вы его имеете в виду под словами "дизайн-документ") обычно не является неизменным за весь жизненный цикл ПО.
Например, вы разрабатываете некий сервис. В начале пути у вас в бизнес-плане мало пользователей, высокая производительность не является критичной, питон с его экосистемой отлично подходит для вашего функционала.
Через год вы стали таким успешным, что у вас стало сильно больше пользователей, чем было в планах, и вот уже высокая производительность становится критичным требованием, вам надо сократить обработку вложенных циклов с 300 мс до 20, а ещё лучше до 2, и вообще чем выше будет производительность, тем меньше будет стоить аренда серверов.
Пожалуй, самый серьёзный аргумент – что над языком работает создатель Swift
Ну над Golang тоже Роб Пайк работал, и что с того.
> О БОЖЕ, ЭТО УЖАСНО! Я невероятно взволнован этой информацией!
А это уже наши надмозги так перевели сложнопередаваемое по оттенку слово excited :)
О БОЖЕ, ЭТО УЖАСНО! Я невероятно взволнован этой информацией!
Это объективный минус Питона. Если вы написали программу с PiL и Matplotlib, на другом компе запустить ее нереально без установки всего этого барахла. Поражает, что в Питон вливают миллионы денег, но до сих пор не додумались, как сделать распространяемые артефакты.
Файлик requirements.txt ??? Возможно вы не знаете, но с ним бывает одна проблема, превращающая инсталляцию во что-то похожее на "запусти и молись" - что на х86-х64 windows-машинах, что на linux. Машины на ARM - отдельная тема.
И имхо - это проблема Python. Рекурсивность ошибок в процессе постоянного улучшения-исправления и случайного ломания того, что исправно работало. Не устанавливается модуль А. Идём по шагам, ставим вручную необходимые модули В, С, D. Не ставится модуль Е. ему требуется модуль А. сюр. Дальше - либо искать и править код вручную, заодно отправив сообщение разработчикам, либо найти версию Python, где этот замкнутый круг отсутствует.
Ага, бывает еще что в свежей версии модуля что-нибудь поломают и нужно ставить более старую, или модуль Е работает только с модулем А определенной версии.
Везде читал рекомендации фиксировать версии. Обновлять сначала на тестинге и тестить.
И это везде такое может быть, не только в питоне.
Мне ещё нравится что некоторые либы при установке компилят сишные модули которые на некоторых архитектурах не компилятся или не совместимы с окружением… вот это цирк начинается...(ох уж этот альпайн с musl) все правильно, все работает, в requirments ничего специфичного, а в альпайне или не собирается или криво работает… да ещё иногда требует установить звезду смерти чтобы оно скомпилилось)
Поражает, что в Питон вливают миллионы денег, но до сих пор не додумались, как сделать распространяемые артефакты.
Wheel (для библиотек) и PyInstaller (для готовой программы)?
Программы, использующие Matplotlib, иногда не работают даже после установки Matplotlib, так как оказывается, что между версиями Matplotlib для линукса и винды какая-то драматическая разница.
Objective-C великолепен
Будет ли у Mojo такая же возможность занять "жирную" нишу и развиваться в ней?
Вытеснит Cython (наверное). Всё.
> Да, вот это ключевое. Когда будет завершён, тогда всех и победит...
Щас подожди, Godot перевернёт игровую индустрию...
> Поэтому для задач, где критична производительность, используют либо другие языки, либо библиотеки для Python вроде Numpy, у которых нет проблем с производительностью.
Гляньте на редактор QuArK (quark.sourceforge.net). Он прикольный, но весь на Питоне и от этого дико тормозной как только начинаешь более-менее полно использовать его возможности. Буквально несколько секунд можно ждать пока по клику что-то выделится. Вот ему бы инъекция скорости не помешала бы.
Поэтому для задач, где критична производительность, используют либо другие языки, либо библиотеки для Python вроде Numpy, у которых нет проблем с производительностью.
как показывает практика не используют. хочется и рыбки съесть и попу не поколоть. начинается всё с того, что "ну пол секунды это ж не много, можно работать короче" (хотя на плюсах это всё за миллисекунды отработает), а заканчивается тем, что скрипт не заканчивается :)
Swift
На самом деле из прикладных компилируемых языков свифт это лучшее что есть. Он не настолько замороченный как плюсы или раст, ему не нужен рантайм как котлу, джаве или шарпу, и не такой кусок говна как голанг. И откровенно дебильных моментов в нем очень мало, на нем можно просто решать прикладные задачи и не напрягать голову.
Но то что он гвоздями к епплу прикручен, наоборот убивает распространение.
Это не так. Swift вполне универсальный язык
У него в качестве стандартной либы NSFoundation, который только под мак с иосом есть. Компилять на свифте и под другие платформы можно, но без стандартной либы оно не юзабельно. Так то и objc в gcc есть.
Чувствую зрелость суждений и экспертность оценки
У голанга есть ровно 2 жирных плюса - куча готовых вещей для бекенда из коробки и статический бинарник на выходе. Но сам язык это просто кусок говна, на нем не пишешь, на нем пальцы ломаешь и с языком борешься. Дебильный синтаксис, дебильный менеджмент пекеджей (это еще маразм с GOPATH убрали), все прибито гвоздями, причем неудобно прибито. Не будь вышеперечисленых плюсов, на го бы не писал вообще никто.
О, вы из фанбоев голанга, здравствуйте.
Чистая вкусовщина.
Причем тут вкусовщина? Это наверное единственный язык в котором вместо синтаксического сараха, синтаксический чили перец.
Тернарных операторов нет, поэтому сиди пиши вместо этого if {} else {} аж в 5 строчек, потому что форматирование кода прибито к gofmt. Веселые и офигенно понятные конструкции типа make([]*Type, 0, len(items)) , make(map[string][]*Type{}),map[string]interface{}{}которые правило, а не исключение. В одних случаях мы объявляем переменную так name := "value", а в других var name Type. Лямбды в которых надо полностью тип описать func(a Type, b Type) ReturnType { }и обязательно с переносом строк со скобками, потому что gofmt. Спасибо хоть что дженерики завезли.
А что не так с go modules?
Структура каталогов прибита гвоздями. Хочешь код в подпапке отдельно от мусора вроде cmd и vendor и прочих захардкоженных каталогов? Добавляй уровень вложенности в модуль и таскай его везде "modname/src".
Хочешь разбить код по подпапкам как везде? Хаха 3 раза. Каждая подпапка это отдельный модуль, а не сабмодуль. Импортировать код из модуля выше по течению нельзя. Гемор с cyclic import, прям как в инклудами в си или плюсах. Хочешь неймспейсы типа domain.Function? Пихай функции в папку domain и геморойся с ипмортами, привет пакеты из одного файла. Или городи пустые классы с методами. Или вообще префиксы функциям добавляй типа domain_function, как в си.
Понятно почему почти все пакеты для go имеют плоскую структуру, с 1-2 подпапками с мелочью, иначе это менеджить невозможно.
Есть примеры, где это реализовано лучше?
Любой другой язык.
Да, у них есть потокобезопасные аналоги
В которых обязательно что-то отломано, как, например, взять текущий размер потокобезопасного варианта Map :)
Или вы про то, что у него нет метода Len()
Ага, про именно это. Очень весёлые у Байка типы. То заставит всех пользователей раз за разом повторять реализации одного и того же метода для интерфейсов разных типов (uint32 != uint64, пиши, условно, divmod для каждого свой), пока всё же не прогнули на дженерики.
То запретит пользователям вставлять в середину списка (как будто от этого все перестали вставлять в середину списка, по крайней мере, если говорить про тех, кто до Байка именно так и делал). Следовательно что? Правильно, каждый снова и снова велосипедит вставку в середину списка. А предыдущий пункт помним? Да, для каждого типа отдельно, пока не подвезли дженерики.
То вот длину у потокобезопасного Map отломал. Хотя, казалось бы, самый нужный метод в конкуррентном программировании: понять, надо ли трахаться с входом в блок обхода или другой обработки значений, проще проверкой на ноль его длины. А ее нету. https://github.com/golang/go/issues/20680 ("What is the use case?" -- это самая смешная шутка про то, что ЯП Go разрабатывают опытные дизайнеры).
Ну, вкусовщина же. Мне вот не нравится абсолютно наркоманский синтаксис тернарного оператора в питоне,
Да, писать бойлерплет вместо понятной строчки это вкусовщина, ок. Мне тоже не нравятся тернарники в питоне. Но я не удивлюсь, что если в го всетаки решат впилить тернарники, то сделают именно как в питоне, потому что оно вполне себе go-way.
С каких пор единый стиль форматирования кода перестал быть абсолютным благом?
А где я говорю что единый стиль это плохо? Я говорю что есть куча моментов где надо писать бойлерплет на несколько строчек, только потому что в gofmt это захардкожено.
С каких пор они захардкожены-то. С чего вы это взяли вообще?
Хорошо, разложите мне код в папки так, чтобы например код не валялся в одной папке с vendor, и так чтобы мне не надо было импортить везде модуль как "project/src"
project/
src/
vendor/
go.modИмпортировать код из модуля выше по течению нельзя.
Можно. Кто вам сказал, что нельзя?
В теории можно, а на практике скорее всего будет cyclic import
А зачем именно как везде, почему не делать идиоматично?
Потому что идиоматично в go это через жопу, а это неудобно.
Не припомню, когда мне последний раз что-то подобное понадобилось писать
А говорите глубоко знаете язык. Открываете любой проект, и там такие конструкции будут почти в каждом файле.
Ну например какой?
Java, Kotlin, C#, Swift
Да, это философия го – простота вплоть до примитивности
Не надо путать простоту и ущербность. Сделать просто и при этом качественно не самая простая задача, и авторы го с ней не справились.
К слову о тернарниках, раз уж мы заговорили об if'ах, то в го ведь есть вполне пристойный switch.
Аргумент уровня go.
Мало того, что vendor не нужна (ну кроме каких-нибудь совсем редких кейсов), так и зачем код в одну папку к ней пихать?
Нужна. Если вы считаете что зависимости дожны лежать отдельно от проекта, желаю вам столкнуться с выпилом зависимости из репы или недоступностью гитхаба.
Ну так vendor гвоздями прибит, как его передвинуть?
Не будет, если нормально делать. Это уже скорее архитектурная проблема
Это не архитектурная проблема, это блок на использование архитектуры. Я смотрел как решают проблему с пакеджами в популярных проектах на гитхабе - очень просто, почти везде пихают все в одну папку и все. Потому что делать иначе это куча гемороя.
Ну правда, мапа слайсов указателей – это какой-то треш
Мапа слайсов может и треш, а слайс указателей обычное дело make([]*Type, 0, len(items))
Только не говорите, что вы имеете в виду gradle
Я имею ввиду что в джаве я раскладываю файлы по подпапкам как хочу и спокойно делаю import чего хочу и куда хочу и не имею гемороя. А gradle кусок говна уровня golang.
C# – увы, не знаком с ним. Swift... Ну... У него свои приколы есть всё-таки.
Шарп - это копия джавы по большей части. Про приколы свифта хотелось бы услышать, на фоне косяков голанга приколы свифта это ерунда.
Почему? Go – самый простой язык из ныне существующих (намного проще того же питона). Сравниться с ним может разве что Swift. Так что просто – получилось.
Получилось ущербно, с дебильным синтаксисом. На свифте писать приятно, на го - пальцы ломаешь. Вещи типа отстутсвия тернарников и make([]*Type, 0, len(items)) простотой объяснить нельзя, это просто дебильное решение. Как и куча всего другого в го. Тот же маразм с GOPATH это типичный go-way.
Хотите простоты - посмотрите на какойнибудь lua, вот там реально красиво и просто сделано. Более того, специально делался простой синтаксис с минимальным кол-вом конструкций, чтобы был максимально быстрый и простой интерпретатор. И такого говна как в го, там и близко нет.
А для крупных проектов, представьте себе, есть стандарт, где всё украдено до нас.
Ага, в котором основной код проекта лежит в папке с очевидным названием internals. Кроме того этот стандарт вообще не описывает структуру папок внутри пакета, а только куда класть доки, схемы, сторонние тулзы, экзамплы и прочий мусор.
go mod vendor -o <your_path>
Можете абсолютный путь указать, можете относительный. Куда запихнёте, там и будет.
О, за это спасибо.
Так и я в go раскладываю файлы по подпапкам как хочу
Так вы хотите как в go принято, а я хочу нормально.
Он предлагает просто.
В го есть мнгого гемороя в стандартных вещах, это не просто, это ущербно.
Да, это директория для внутренних модулей проекта. Не основной код. Внутренние. Модули.
У вас основной код проекта во внешних модулях?
Что означает, что вы вольны делать всё, что угодно. Это же хорошо?
Это означает что стандарт который вы скинули, не решает вопросов на которые вы этой ссылкой отвечали
К слову о тернарниках, раз уж мы заговорили об if'ах, то в го ведь есть вполне пристойный switch.
- Аргумент уровня go.
По существу будет что возразить?
Это и есть возражение по существу. Насколько вообще можно найти существо в ответе типа "да, в го нету тернарников, но послушайте какой там свитч!".
Чего вы так к тернарникам привязались) пишу на python, иногда пишу на dart, когда-то немного писал на шарпе и ещё чем-то и просто не терплю тернарники по причине того, что в каждом языке их умудряются реализовать по-своему. У одних сперва может идти стейтмент для проверки, потом присваивание, а у других наоборот. Символы тоже разные используются везде. Даже синтаксис такой простой вещи как тернарник приходится иногда гуглить чтоб вспомнить ...) Неужели так сложно было не пилить всем свои велосипеды
В го даже не в тернарниках проблема. Даже банальное:
if cond returnне написать. Только так:
if cond {
return
}а вместо короткого тернарника только так:
if cond {
return true
} else {
return false
}в каждом языке их умудряются реализовать по-своему
Это в питоне тернарники конченые, в остальных языках они почти везде одинаково сделаны
return condне благодарите
А если серьезно - какой бы 3х этажный cond не был return будет всегда на новой строке и его будет видно это будет читаться
у го есть проблемы, но тернарники не одна из них
А в той же Яве разве можно так писать?
Что-то навскидку не могу языков вспомнить
Да, и в котлине, и в шарпах, и в си, и в плюсах и в js\ts. Даже в ruby и lua можно. Проще назвать где нельзя. Вы воообще на чемто кроме го вообще писали?
Скобочки таки придётся расставить.
В свифте скобочки можно и на одной строчке поставить, они гвоздями не прибиты.
Вот только в свифте есть guard else, тернарники и optional, что у меньшает количество if else бойлерплета в нулину.
но там за такое в любом нормальном проекте бьют по рукам. Если ревью кода есть, конечно.
if return на одной строчке это нормальная практика. Если за нее бьют по рукам, то с ревью чето очень сильно не так. Потому что пара строчек с if return в начале функции сильно читабельнее чем лестницы из ифов.
Вот это нормально и читабельно:
if (one_case) return
if (two_case) return
if (three_case) returnА вот это нет:
if (one_case) {
return
}
if (two_case) {
return
}
if (three_case) {
return
}Вот это нормально, и читабельно:
var a = one_case ? 10 : 5
var b = two_case ? "a" : "b"А вот это и не читабельно, и печатать неудобно, и поддерживать неудобно:
var a: int
var b: string
if (one_case) {
a = 10
} else {
a = 5
}
if (one_case) {
b = "a"
} else {
b = "b"
}А теперь давайте смешаем две эти проблемы, и получим ifelse hell. Когда в функции логики на 5 строчек, а кода на 30. И это простой пример, а если посложнее будет? (А она регулярно такой бывает)
Если в коде есть if else бойлерплейт, то он по определению с душком. Лично для меня даже один else в коде – это повод прикопаться
Попробуйте пописать чтото сложнее складывания джейсонов в бд, отпустит. А про то что с ревью у вас чето явно не так, я сказал еще в прошлом коменте.
На одной строчке нормальная, без ограничения скобками – нет
Я подобным задротством по скобкам и прочим выдрачиванием запятых давно не страдаю, извините. Когда (а скорее если) уровень мидла перерастете, тоже перестанете заниматься этой ерундой.
Вы буквально этим и занимаетесь весь тред. Задротство на количество строк. Или "ЭТО ДРУГОЕ"?
Вы передергиваете. Я говорю что го заставляет даже для относительно простой логики писать 15-этажные конструкции. Логики с гулькин хер, а писанины и бойлерплета на пол экрана.
не рассказывайте сказок о том, что тернарники решают проблему ifelse hell. Согласен, что они чертовски хороши, когда нужно продемонстрировать преимущество на вырожденном коде из 30 строк.
Тернарники позволяют ее до нее не доводить. Я показал типичнейший кейс для использования тернарников, а в го в этом месте уже писанина и бойлерплет.
Для 1000 строк тоже через тернарники будете ситуацию разруливать?
А сколько значимого кода из этой 1000 будет в го? 50 строк? А остальное безполезный бойлерплет
Выносите код в функции, используйте полиморфизм, и не будет никакого ада.
Я же говорил, попишите чтото более сложное чем складывание джейсонов в бд. Вы видимо бизнес-логику или алгоритмы сложнее одного ифа не видели. А про то что объекты с полиморфизмом сами по себе добавляют немало сложности вам только предстоит узнать.
С ревью у меня всё хорошо, когда 90% его покрывается линтером.
Вот я про это и говорю. Для вас 90% ревью это синтаксис, а не логика и архитектура. Основные проблемы всегда в них, а не в том то ктото скобочку не там поставил.
я несколько раз в этом треде подлавливал на незнании каких-то моментов.
И че? Я не считаю зашкварным чего-то не знать, тем более специфические моменты языков, на которых я не пишу каждый день, или писал, но 5 лет назад.
Наоборот, то что ты эти мелочи помнишь и считаешь важными говорит об узости опыта. Писал бы на разных стеках, сам бы не помнил.
А дрочево на красоту кода, форматтеры и линтеры и максимализм типа "если у тебя в коде есть else, то твой код говно" говорит о том что опыта у тебя не особо много.
Код в программировании это вообще второстепенная вещь. Выкупаешь? Я думаю нет.
То что ты считаешь переделку содержимого нескольких функций рефакторнгом, это отдельный лол.
Задевает пункт про джейсоны в базу? Это потому что ты и сам сомневаешься в своих скиллах. Могу ток сказать что правильно сомневаешься.
Не нравится менторский тон? Так ты сам еще несколько коментов назад сказал что ливаешь из дискуссии. А теперь жалуешься что тебе не нравится как я ее веду.
Я понимаю что тебе кажется что пара-тройка лет опыта это уже дофига. Но дофига — это когда больше чем тебе лет.
Мне как-то доводилось писать реализацию алгоритмов Paxos и Raft
Это реализации которых загуглить можно? Любой свой алгоритм для задачи у которой нет готового решения разработать сложнее. Я не бекендщик, но думаю что для бека пример сложной задачи — это спроектировать, а затем несколько лет дорабатывать и поддерживать любой реально высоконагруженный бек. Какой-нибудь тиндер, или сервер для csgo. И принимать решение самостоятельно, а не тасочки от типлида клепать, и не копипаст из статей про микросервисы.
90% для красного словца. Линтеры и за чистотой кода следят
Ну да, 90% это для красного словца, но специальную дрочилку которая следит за тем чтобы никто не испачкал лишней запятой идеальный код ты всетаки настроил
Польза примерно как от лямбд
В го от лябмд больше боли, чем пользы. Пот тем же причинам. Например написать так нельзя:
result := map(list, (item) { item.value }) А это основной кейс для лямбд. Пишите в 3 строчки, еще и со всеми типами. Ненужная писанина на пустом месте.
Не изволите ли пояснить, какого лешего у вас в начале функции три ифа, когда можно обойтись одним?
Можно. Только если условие if(case) будет не 4 буквы как в примере, а 10-15 как в реальной жизни, это все превратится в кашу. А если условия еще и придется править (а это придется), то менять их по отдельности намного проще.
Есть типичная функция, в ней пара проверок в начале и бизнес-логика. А теперь найдите бизнес-логику. Это нечитаемо.
Люди выносят if return в начало, чтобы сместить фокус на бизнес-логику. А в го все наоборот, большая часть кода это бесконечные скобки, в ифах, вложеных структурах, лямбдах, несущие 0 информации.
func doSomething(data SomeData) {
if (!data.value1) {
return
}
if (!data.value2) {
return
}
if (!data.value3) {
return
}
if (businessLogic1()) {
businessLogic2();
}
yetAnotherBusinessLogin3();
}Меня раздражает писать кучу ненужной писанины вместо кода который решает мою задачу. И не по адекватной причине, а изза дебильных решений в языке.
И их, конечно, красивее обработать через тернарники. А если условий будет 5?
А если условия сложнее, то наверное просто не надо использовать тернарники? Тернарники придуманы для вещей типа var n = bool ? a : b, а не чтобы на них сложную логику городить. Это очевидно.
Это реализации которых загуглить можно?
Я как-то лет 4-5 назад как раз гуглил. Тогда гуглилось, что реализаций PAXOS не существует, а те реализации RAFT, что были -- все были кривые. Оно как бы рафт консенсус запускало, но ни одна реализация не переживала изменений членства в консенсусе. Некоторые даже проваливали node-down, node-restore.
Понимаю, что в кровавых закрытых интерпрайзах полноценные работающие реализации могут быть, но эта закрытость противоречит "загуглить".
Чувак, ты в деталях палишься. Пишешь на разных стеках, но все еще считаешь что бывает какойто основной. Значит либо не так давно вылез из уровня когда пишешь на чем то одном, либо приукрашиваешь.
Говоришь что так шаришь, что можешь решить любую задачу, но при этом пригораешь от шутейки про джейсоны в базу? Был бы уверен в скиллах, тебе было бы пофиг.
Причём тебе не нравится именно писать
Ну да, я же написал. Мне не нравится писать кучу лишнего безполезного бойлерплета, который сущестует только потому что дизайн языка сделан мудаками.
хотя я много раз сказал, что мне не важно, на каком языке писать и плевать на красоту кода
Видимо ты это много раз сказал за пределами этой дискуссии. Ну и ты сначала говоришь одно, а в следующем коменте переобуваешься, я уже даже не обращаю на это внимания.
говоришь что я чего-то не выкупаю? Чел… Ну ты сейчас конкретно гонишь.
Я же говорю не выкупаешь. Вспомни этот момент лет через 5, тогда может уже и выкупишь.
Я говорил о том, что если у тебя настолько дерьмовые функции, то вероятно код нуждается в рефакторинге.
Я прекрасно понял что ты говоришь. Если функции реально дерьмовые, то скорее всего код настолько плох, что безнадежен. Ты просто слово рефакторинг используешь с такой легкостью, как будто никогда по серьезке им не занимался. Это значит что ты относительно мелкие переделки на серьезных щах называешь рефакторингом, что несколько наивно звучит.
Я понимаю что если часто говорить такие слова как "рефакторинг", "чистота кода", "покрытие тестами" и прочие баззворды, то кажется что ты настоящий программист, прям как крутые чуваки. Но это херня.
Скажи, пожалуйста, ты знаешь, что такое линтер
Конечно, это херня которой обмазываются второсортные программисты, вместо того чтобы делами заниматься.
Не, может в этом есть какойто смысл для динамических языков типа питона, потому что есть много ошибок которые на этапе компиляции не поймаются. Но если для задачи это критично, то тогда динамический язык просто не подходит. Такие языки берут когда надо быстро клепать и не париться за надежность.
Ты сейчас даже не понимаешь
Про PAXOS и RAFT? Ну да, я же сказал что не бекендщик, было бы странно если бы я понимал.
С ребятами, которые разрабатывали
высоконагруженный бэк мне кстати доводилось общаться
А я один раз в живую Роберта Пайка видел, я теперь лучше тебя го знаю чтоли? Это троллинг юмором такой?
в том числе и по сложности задач, да, всё было намного проще и понятнее
Естественно. Потому что все ключевые вещи там уже грамотно реализованы до тебя
Если бы ты писал с нуля крупные проекты, я не просто в них учавствовал сидя и клепая таски от тимлида, с объяснением что и как делать, ты бы рассуждал по другому. Говорю же, ты палишься на мелочах.
Не будет человек с опытом, всерьез такое писать: "return на той же строчке это потенциально хрупкий код, так низя!"
Не от этого, а от постоянных переходов на личности.
Так я именно про это и говорю. Если бы ты в себе не сомневался, тебя бы это не парило. Тем более ты сам первый начал переходить на личности, а теперь жалуешься.
И каких аргументов по существу ты хочешь? Ты говоришь "я считаю что Х важно, рря". Что я тебе должен ответить, если ты так считаешь изза неопытности? Я может тоже точно так же считал, 10 лет назад.
В то время как сеньоры пишут простой, тупой и читабельный код.
Не, сеньеры пишут очень много говна. Просто знают где это можно, а где нет. А идеальный код это иллюзии.
Ну извини, но у рефакторинга нет размера.
Ну да, можно построить собачью будку и говорить что ты занимаешься архитектурой, лол. А можно пару классов передвинуть и гордо сказать что делал рефакторинг. Формально верно, а на деле рофл.
Гошные функции на несколько тысяч строк видел когда-нибудь? :)
Видел плюсовое говнище на десятки тысяч. Один файл столько, не весь проект.
<менторский тон mode on>
У тебя неестественно получается, старайся лучше.
Открой как-нибудь блог PVS-Studio вот прям тут на Хабре и посмотри, чем они занимаются.
Видел. В плюсах, где можно выстрелить себе не то что в ногу, а в спину, если моргнуть не в тот момент, это оправдано. И то, далеко не во всех проектах. И судя по тому сколько они косяков находят в распространенном софте, PVS проблему в итоге не решает.
Когда каждая мелочь, каждая ошибка – это потенциально горящий прод. И ты мне такой на серьёзных щщах заявляешь, что линтер – это какая-то ненужная дрочилка.
В реальности, всем плевать. И без авто-форматтеров пишут, прикинь? И без стайлгайдов. Ты наверное не поверишь в то что бывают проекты трипл-ей-уровня в виде древнего монолита на php, оужас без микросервисов. И прочие подобные приколы.
Я тебе объясняю, что вся эта поверхностная дрочь переоценена, а ты видишь только нападки на личность.
Ты правда не понимаешь, почему популярный C++-паттерн вида if (x) doSomething; – хрупкий?
Прекрасно понимаю, просто это не настолько важно как тебе кажется. Вот именно это (то что в реальности это не сильно важная вещь) ты и не выкупаешь.
Хайлоад – это обязательно уровень Роберта Пайка?
Про Пайка это же рофл. Того же уровня, как и твой аргумент что ты с кемто там общался и чето там видел.
Нет, им как раз нужен был чувак, который разберётся с неграмотной реализацией, и сможет превратить лапшу в нормальный, поддерживаемый код.
Не отказался бы у них тогда поработать
Но чето тебя туда не взяли, походу, да?
Какой-то там алгоритм, для которого не существует корректной реализации, да… Ерунда
Слушай, я конечно ничо не знаю за ваш paxos с raftом. Но алгоритм для которого в природе не существует корректной реализации звучит как какойто маркетинговый буллшит.
Вот тот же го – это же чисто бэкендный язык.
То что я не бекендщик, не значит что я не писал бекенд. Это значит что не писал ничего серьезного.
Казалось бы, в чём проблема – прошёл по участку кода, по пути подвигал пару классов. А для него нужно у менеджмента выбить пару месяцев, ведь это же так невероятно важно
Потому что на внесение больших изменений в архитектуру на живом проекте с большой кодовой базой реально нужно пару месяцев. Большую часть на отлов косяков после этих изменений. То что ты движение пары классов называешь рефакторингом, а мелочь которая фиксится по пути техдолгом, это, ну я уже говорил почему ты это делаешь.
Правда, с чего ты решил, что для меня это важно
Было бы не важно, ты бы про это не говорил.
О БОЖЕ ТРИ СТРОКИ ВМЕСТО ОДНОЙ
Три строки вместо одной превращаются в 30 вместо пяти. А потом ты удивляешься откуда в коде функции на тысячу строк. Да там 70% это бойлерплет, не отменяя того сам что код говно.
Алгоритм распределённого консенсуса он маркетинговым булшитом называет.
Я просто не могу понять как может существовать алгоритм, и при этом не существовать корректной реализации.
На бэкенде или вообще?
Подкол защитан. Ответ сам знаешь
Для тех, кто не использует линтер, и не покрывает код автотестами – да
Скажи еще что если по скраму работать, то багов не будет
Я написал, что у меня такая конструкция не пройдёт ревью
Я и говорю ту мач внимания всякой херне
И нигде фактически нет по-настоящему корректной реализации
Ну это скорее значит что алгоритма в полном виде просто нет. Т.е. какойто алгоритм есть, но он все кейсы не покрывает. А допилить его так, чтобы покрывал — нетривиальная задача.
Я собеседовал джунов, которые говорили очень зрелые вещи
То что слова джунов кажутся тебе зрелыми, как раз и говорит о твоем уровне.
Не, чувак, если для тебя так это важно, ты не тупой и не безнадежный. Нормальный мидл. С абсолютно типичным мидловским взглядом на вещи. Через несколько лет дурь из башки выветрится, и станешь хорошим сеньером.
Ты специально штампы собираешь
Токсично хейтить популярные технологии, фреймворки и методики
Просто отвечаю штампом на штамп. Я называю вещи своими именами, а ты в этом хейт видишь.
но твоя легенда
Легенда? Я о себе написал буквально пару строчек, половина которых это "этого я не знаю, а тут у меня нет опыта". Так что легенду ты сам придумал.
неспособные что-либо реализовать на практике, прекрасно умеют теоретизировать,
Люди, не имеющие практики, нормально теоретизировать не могут. И это палится буквально сразу. Они могут только начитаться говнотеорий и потом их повторять. А ты их бредни слушаешь, и называешь зрелыми рассуждениями. Это значит что ты сам гдето начитался этих говнотеорий, и что у тебя самого не хватает нормальной практики.
Обрати внимание, ты достаточно много вещей, которые я тебя говорю, не понимаешь, но объясняешь это моей тупостью, лол. Ну ладно, будет сюрприз через пяток лет, когда поймешь.
У тебя просто нет опыта общения с такими.
Прямо сейчас с таким общаюсь. Типичные рассуждения на самом деле про покрытие тестами, правильные названия, код с душком и прочее. Даже фразы шаблонные.
твой язык дерьмо", "твои линтеры бесполезная дрочилка", "мне так не нравится, поэтому это дерьмо", "я хочу в го писать как в яве, потому что только в яве нормально, а в го дерьмо"
Почему тебя это так бесит? По фактам же разложено.
Взять даже такой невинный момент – ты на полном серьёзе перепутал прозвище го-программистов с оскорблением
Как же я ору. Ты че, реально считаешь что я перепутал?
Во-первых я так пытался подколоть того чувака. А во-вторых "гофер" среди разрабов реально считается оскорблением. Потому что большинство гоферов — иррациональные фанбои хуже фанатов джиеса. А сам го это язык написаный мудаками (судя по самому языку), для дебилов (это прямое заявление авторов языка, цитаты гуглятся). Поэтому с фанбоев го все рофлят. Странно что ты этого не знаешь.
Давай-ка без детской демагогии.
Где тут демагогия? Ты думаешь что троллинг заключается в передергивании? Нет никакого передергивания, "троллинг" заключается в том что пишу свое реальное мнение, причем с реальными аргументами, а ты от этого рвешься. "Да меня не бесит! Да я могу любую задачу сделать! Да это просто для красного словца написал, на самом деле нет!"
В сотый раз в этом диалоге спрашиваю – с чего ты взял?
С того что ты полдня эмоционально мне пытаешься чето доказать. Я уже даже перестал понимать что именно.
Ты просто отрицаешь неприятные факты.
или молодёжную литературу не читаешь? :)
Ох, а ты Сэшими Хокагайо читал? Почитай, там много интересных мыслей, хоть и достаточно андеграундный автор. Или ты только хайповое предпочитаешь?
Я полдня назад предложил тебе остановиться
Не, ты ливнул из треда, а потом пригорел и вернулся обратно. Стыдно должно быть так часто переобуваться.
Нет, может я тоже в таком же стиле общаюсь, а за собой не замечаю. Скажите если так, буду вести себя уважительнее.
Можно я отвечу? Спасибо.
Ну и в питоне можно ломать ифы, слава великим отступам, но это ж питон, чего от него ожидать.
Крайне непрофессионально и оскорбительно. У меня есть очень хороший обратный пример Го-паттерна сравнимой значимости, но не оскорбляю гоферов же направо-налево.
if return на одной строчке это нормальная практика
Здесь начинается холивар про early return. У него на моей собственной памяти ни разу не было какого-либо выхлопа, кроме "спорщики подрались или, по крайней мере, пообещали друг другу лицо побить".
Я этого не говорил, не нужно мои слова перевирать
Это рофл такой? Вот ваша цитата:
К слову о тернарниках, раз уж мы заговорили об if'ах, то в го ведь есть вполне пристойный switch. Хотя чуть похуже, чем в свифте.
Тернарники и свитч это вообще совершенно разные кейсы.
Свитч подходит когда есть много условий для одной переменной. А если мне надо в соотвествии с парой булек значения для пары переменных выбрать, сиди пиши бойлерплет из ифов которые в большом количестве убивают читабельность.
Вы хотите, чтобы в го было как в яве
Нет, я хочу чтобы было нормально. В яве импорты сделаны хорошо. А в го импорты и модули имеют проблемы как у сишных инклудов, при этом тянут ограничения изза которых плоский список самый популярный вид организации кода в проектах.
у меня нет проблемы с тем, чтобы принять правила языка и следовать им, даже если они отличаются от парадигм, принятых в других языках. Если только это не Objective C, конечно.
У меня тоже нет проблем принять правила языка, если они отличаются в лучшую сторону, или хотябы несут какойто смысл. А не являются ущербной копией плохих решений из других языков.
А в objc просто у вызова функций скобочки другой формы.
Я и не говорил что я много на go писал. Даже если брать не из коробки, а с гитхаба, то для бекенда понаписано все что нужно. ORM, мидлвейр и тп.
ORM
Этого быть не может. Он не способен в ORM. Например, в https://gorm.io/docs/models.html мы видим вместо OOP (или хотя бы его куцего аналога, доступного в Go) какие-то костыли на текстовых портянках. Само собой, для этого либо специальный плагин под конкретный ORM надо пихать (и следить, чтоб не отстал от актуальной версии GORM), либо отказаться от проверки синтаксиса.
Сравнить с:
impoort sqlalchemy as sa
Base = sa.orm.declarative_base()
class MahModel(Base):
__tablename__ = "test_table"
a = sa.Column(sa.Integer, primary_key=True, autoincrement=True)
b = sa.Column(sa.Text)
mah_query = (
sa.select(
MahModel.b
)
.where(
MahModel.a == 1
)
)
# SELECT b FROM test_table WHERE a = 1И обычный стандартный PyCharm без дополнительных плагинов полностью сопровождает написание запроса code completion и даёт прочий анализ, в алхимии 2.0 из коробки, а в предыдущих версиях -- сразу после установки пакета sqlalchemy2-stubs.
Я тут в своё время еще глянул Hibernate, который самый оопэшный ORM, да еще и статически типизированный в отличие от рутнопа. Оказалось, там до сих пор не прикрутили BindParam с code compile time query-to-text compilations. Ужас-ужас.
Я не настоящий бекендщик, эта штука https://gorm.io/docs/models.html умеет модельки туда-обратно гонять, мне показалось норм. Тут спорить не буду
Если уж совсем к терминологии придираться, то ORM == Object-Relational Mapping.
Go is not an object oriented language per se
Я, кстати, попробовал перепроверить это утверждение на их официальном сайте, но так и не нашел нигде утверждений о том, является ли он OOP или нет. Получается, официальная веб-страничка этого, по крайней мере, не опровергает.
Следовательно, поскольку в Go ООПэ -- это, скорее, костыли над структурками, чем ООП, мечтать об именно ORM там не приходится.
Уже лучше. Разве что мне резануло глаза то, что структурка объявляется "пустая", а набивается отдельными функциями. Но выглядит офигенно, да.
А скомпилировать в текстовые представления эти самые запросы оно умеет? Ну, в смысле, не в рантайме, а во время компиляции самого проекта (или, еще лучше, по запросу)?
Никто не мешает его использовать в Linux, Windows или там для написания микросервисов
такая (для меня) хорошая новость, что аж не верится, правда правда?
тоже этот язык понравился, но его ограниченность платформой отпугнула.
открыла для себя Kotlin. попробовала его для JVM (и в серверной части, и в мобильной), JS - везде осталась удовлетворена (вот только выхлоп не слишком смотрела, а поверхностно - то да, пока что в jvm компилируется приемлемо, а для js конечно ужасно, возможно, пока что). сейчас мучаюсь с пониманием, как писать в Kotlin/Native - и вот первое же впечатление: чтобы там писать, недостаточно быть разработчиком на Java, нужно иметь понимание сишника, и желательно сначала написать код на С, чтобы понять, как писать правильно в K/N; т.е. написать k-jvm программулинку и скомпилировать её в native не получится от слова совсем (конечно, примерно также было и с Kotlin-JS(React), но всё же этот ночной кошмар хуже).
интересно, как тогда обстоят дела со Swift на данный момент?
про "понимание сишника" чуть подробнее: пришлось вспомнить, что event loop надо писать ручками, ручное же управление памятью (хотя в оф.доке и пишут про сборку мусора), и все эти приколы с выделением памяти необходимого размера с последующим копированием, передача структур как указателя и размерностью, С-строки в виде массивов, необходимость заголовков и т.п., о чем в jvm не думаешь вообще. и это только начало - далее идут особенности самого интерфейса в K/N в виде удивительных понятий и приёмов, которых нет ни в k-jvm ни в C.
Боже, ну и джинса.
Почти всё в Julia построено поверх этого, используя Julia
Мы встречали разные переводы на Хабре, но это... Это шедевр!
перевод достиг уровня искусства, чтоб вы понимали
Ага, а уж слой самоконтроля - это шедевр.
ах Юлька-Юлька(сучка). конечно, в своё время было удивительно прочесть "компилятор Java написан на Java", но... про Julia, кажется, написано статей-дифирамбов больше, чем собственно кода. похоже, и статья про сабж из той же категории - всмысле, настолько всё круто, что даже...не нужно.
в самом деле, чтобы занять определенную нишу, к новичку в области ЯВУ, нужно ухитриться выполнить много требований:
принцип наименьшей неожиданности, интуитивная понятность. т.е. все конструкции языка должны работать точно так же, как в похожих языках. пример - для блоков используются фигурные скобки, а не круглые, лисп в этом плане проиграл. или switch-case конструкция работает так же с необходимым break, либо выглядит иначе. нумерация индексов так же с 0 (бейсикам с их 1 - минус в карму от многих) и т.д. и т.д. сложнее всего помнить, что везде (или там, где пишешь чаще всего) так, а тут - вводе также, но, упс, забыл, вот тебе бага на ровном месте
большая стандартная библиотека с почти всеми функциями, чтобы не нужно было мучаться и адаптировать, а брать и пользоваться
высокая интеграция с платформой и существующими языками/библиотеками - берешь и подключаешь. например, успех (и то, очень и очень небольшой) того же Kotlin отчасти в том, что он запросто интегрируется в/из Java - отсюда, можно часть написать на одном языке, а небольшую - на другом, и они будут уживаться, и при желании медленно переписывать на другой язык
как можно меньше усилий по созданию окружения: например, тут писали про Python, мол, а вдруг не окажется интерпретатора (и незаслуженно), хотя, как правило, он есть, либо можно подготовить распространяемый пакет. а вот для языка-новичка это критично: "твоя программа не работает!" может стать непреодолимым барьером. и лучше всего, чтобы всё необходимое, с разрешения пользователя, ставилось автоматически (или, если пользователь сказал нет, то и не запустилось с человекопонятным изложением проблемы)
низкий порог вхождения менее важный, но всё же важный фактор. или - как не затеряться в толпе существующих языков. есть и Rust, и Go... да даже про тот же Dart не слышно, потому что есть Typescript (да, пример из web)
(добавлено) чуть не забыла. кроссплатформенность. тоже очень важно для популярности языка то, чтобы на одном языке можно было писать всё: и дрова, и сервер-софт, и мобилк, и десктоп под винь/линух. ладно, пусть с перекомпиляцией и с особенностями написания кода, но чтобы кодовую базу можно было переиспользовать. потому что часто бывало - задумывался язык для одного, а занял совсем другую сферу. а так и выживаемость выше, и удобство
Я правильно понял, что главное отличие от Cython в том, что Cython писал некрутой дядька, а это - крутой дядька?
Про Julia, упомянутую в статье, уже много-много лет пишут с предыханием мол это убийца питона для дата саенса и вообще всего, вот-вот, почти. А воз и ныне тем.
В Julia ещё пару лет назад находили серьёзные ошибки в алгоритмах стандартной библиотеки. Причём не ошибки типа "падает", а ошибки типа "молча даёт неправильный результат". Вот датасатанисты её и обходят сторонкой.
Для питона есть модули и библиотеки на любой вкус и чих, с более-менее стандартным синтаксисом. Аналогично с R, хоть и более узкоспециализировано. А Джулия может сим похвастаться? То есть я не исключаю что она взлетит. Но пока предпосылок не вижу.
А Джулия может сим похвастаться?
Пишете using PyCall, а потом используете модули и библиотеки на любой вкус и чих для питона в юле.
Нативные библиотеки для джулии есть? Потому что зачем мне джудлия если я могу все это сделать в питоне?
Было бы странным, если бы не было. Посмотреть список можно, например, здесь. Но, даже при использовании питонячьих библиотек, юля может быть удобнее. Например, сравните код для создания матрицы:
# Python
A = numpy.array([[1, 2, 3], [4, 5, 6], [7, 8, 9]])#Julia
A = [1 2 3; 4 5 6; 7 8 9]
Датасатанисты обходят её стороной потому что им не хочется писать код, они хотят писать на английском или прям формулками, а не языки эти ваши учить. И писать они хотят очень быстро и много, проверяя гипотезы а не думая об архитектуре программ и производительности.
На самом деле, питон это проклятье датасаенса в проде, математиков во время не били по рукам и они успели написать критический объём питоньей легаси-лапши, который стал самоподдерживающимся.
Слава всем богам что хоть матлаб не стал мейнстримом, а то было опасно близко.
они хотят писать на английском
Гм, а вот этот адок в Pandas/Numpy с переназначением всех операторов и всякими loc/iloc и прочей неочевидной лексикой - это уже аглицкий?
Чем математики не угодили датасатанистам? Numpy не для них писался, я для учёных и инженеров. Он вообще поначалу был (и до сих пор частично остаётся) обёрткой над кодом на F77, который никто больше не хочет видеть, не то что редактировать. Т.е. его "лепили из того, что было", а потом сами знаете...
Матлаб не стал мэйнстримом, потому что, во-первых, -- это нишевый язык для расчётов, а, во-вторых, потому что Mathworks -- жадные жабы. Если бы они отвязали язык от своей платформы и выпустили бы его в свободное плавание хотя бы с частью библиотек, то, может быть, расчётчики и не стали бы мигрировать на Питон. И, кстати, базовый синтаксис матлаба переживёт саму платформу, потому что его частично заимствовали в Julia (это, конечно, при условии, что Julia выживет в долгосрочной перспективе).
Если б так, то языком учёных был бы Inform 7. А то на нём только примитивные игры делают.
Пример куска живого кода на Inform7 из игры:
Things have a number called point value. The point value of a thing is usually 0. The temple has point value 5.
Check photographing:
if the point value of the noun is 0, say "*click*[line break]You take a picture of a totally uninteresting [printed name]." instead;
if the point value of the noun is -1, say "You already got a picture of that." instead.просто, гибкие типы с проверками на этапе компиляции - в теории звучат настолько круто, что аж у меня бабочки. а на практике - это не петтинг, а изнасилование, когда код не просто не работает в парад планет, а вообще хз почему не компилится. или х как раз з, но не з, как с этим быть. отсюда вполне очевидный вывод - да ну эту Юльку в п... пешее эротическое.
Людям не нужен еще один язык с синтаксисом Python, им нужен Python без GIL. Вот и все. Скорость Python легко увеличивается через C, Rust, Cython, PyPy, Nuitka, Numba, etc...
можете смеяться, а мне Python не зашёл как раз потому, что полагается на форматирование (а вдруг у меня табы поломались, и я не заметила, как смешиваю табы и пробелы) и выглядит, как процедурное программирование, несмотря на все развитые средства. ах да, и недостаточная строгость типов.
и я не заметила, как смешиваю табы и пробелы
Писать надо в нормальной IDE с линтерами, а не в notepad.exe и будете всё замечать. Серьёзно, ну что за детский сад?
Типизация в Python строгая сильная. Так что к строгости типов вопрос не в кассу, это скорее к динамической типизации претензии у вас.
это скорее к динамической типизации претензии у вас
я имела ввиду не строгость/динамику типов, а... ну в общем да, больше динамику, но строгость именно в объявлении: мол, здесь именно этот тип и никакой другой, и здесь ожидается именно этот тип, а не как там получится в рантайме. в этом плане мне даже больше нравится Visual Basic с типом Var - все типы как типы, а эта переменная/аргумент может быть любого типа. ещё больше нравится концепция , объединений из Typescript:
может быть этот тип или этот
строка, но только определенных значений (вроде как enum, но без введения нового типа)
я переводила немало проектов из Python,и Typescript, и всегда именно такие моменты тормозили больше всего
Так проверки в python вполне строгие. Но толку-то, если они обязательно спотыкаются об код, в котором типы не проставлены?
Более того, аннотации типов — лишь вспомогательный инструмент для различных анализаторов. Интерпретатор ничего не скажет, если, например, передать два числа в функцию
def concat(a: str, b: str) -> str:
return a + bещё раз поясню мысль: на этапе чтения исходников типы не объявлены, поэтому, несмотря на их контроль в рантайме, сложно переводить в язык со строгой статичной типизацией, как например, Java
язык бы сильно выиграл, будь там требование указывать явно тип либо отсутствие типа (как я приводила в пример бейсик). а так... приходится догадываться...
Если вам так нужны типы в компил-тайме, просто не пишите на питоне. Питон и подобные хорош для скриптов, текстодрочилок и протипов. Можно быстро херачить и не думать про гемор с типами. А для проектов где важно не иметь приколов с тем что код в рантайме падает потому что тип не тот прилетел, есть другие языки.
ещё больше нравится концепция , объединений из Typescripte
В тайпскрипте типизация ужасная, как раз потому что в райнтайме её считай не существует. Она очень сложная и навороченная, но при этом очевидных вещей типа instanceof interface просто нету. Можно нагородить гиганские конструкции из дженериков и юнионов, но зато просто проверить тип переменной в рантайме полноценно нельзя.
просто не пишите на питоне.
и не пишу, выше писала почему. но читаю, перевожу... и это сложно
была, конечно, безумная мысль повторить 0х52 URM, но благо, не настолько хорошо знаю питон и и его надмножество RenPy
Intersection types есть, union types есть, рекурсивные дженерики, адекватно работающие с сабтайпингом, есть.
А instanceof interface нет. Т.е. букально так написать нельзя (да, при том что тип для аргумента явно указан):
function a(b: number | InterfaceName) {
if (b instanceof IntefaceName) {
}
}Зато нечитаемую монструозную херню на дженериках можно навертеть, да.
Еще экстеншенов нет. Т.е. можно написать модельку с полями, а хелперы к ней красиво не сделаешь. А добавить их как методы не вариант, потому что метод это поле объекта.
Типы должны стираться, если вы не попросили явно обратное. Зачем их в рантайме таскать?
Это для компилируемых языков нормально. А ts транслируется в js, и соответственно объекты ts это объекты js с прототипами и прочей херней. Но рефлексия при этом неполноценная.
то понимаете, что вам это не нужно.
В теории не нужно, а на практике нужно.
то всё там читаемо
Если писать нормально, то читаемо. А если делать миллион дженериков через дженерики и сверху закидывать юнионами, а потом еще тянуть типы с других мест через AnotherType['fieldName'] как любят делать в ts, то не читаемо. Код с кучей конструкций, априори читается хуже чем код, где конструкций мало, от знаний это не зависит.
Настолько же, насколько в ООП нужно писать
да, иногда так делают, но чаще всего потому, что налажали с архитектурой.
Это все теоретические разговоры про ерунду. В реальной жизни instanceof бывает нужен, и то что он работает для типов и не работает для интерфейсов это просто косяк языка.
Но если этих прочих равных нет (код с кучей конструкций короче выражает мысль, например), то это уже совсем зависит.
Это все верно, но когда код с кучей конструкций короче выражает мысль это редкий кейс.
Typescript это язык на котором кнопки красят. В какихнибудь плюсах я могу понять кейсы когда нужно городить огород на вариадик темлейтах. А тут можно конечно на типах интересные штуки делать ради прикола, но в реальных проектах на них в основном делают себе проблемы.
instanceof бывает нужен, и то что он работает для типов и не работает для интерфейсов это просто косяк языка
По-моему, это косяк не TS т.к. в JS интерфейсов нет, соответственно, как они могут работать если в JS-машина про них не в курсе :)
Интерфейсы в JS нужны во время написания кода, чтобы IDE-шка нормально работала, подсказывала мне поля, чтобы не надо было метаться по вкладам :)
Я вот тоже наверное небольшой frontend. Мне там нужна была иерархия типов. Сделал всё через интерфейсы, получилось красиво-воздушно, любо-дорого. Но ни хрена не запустились. Ошибок в IDE нет, но не работает. Пока допёр что интерфейсов на самом деле нет, весь извёлся :) Пришлось переделывать на классы, получилось уже не так воздушно.....
А так, TS очень хорош..... по сравнению с JS, особенно для нас, бэкендеров, привыкших что IDE "за нас половину кода пишет" и за какими-то лешим притащившихся пилить фронт :)
Типы должны стираться, если вы не попросили явно обратное. Зачем их в рантайме таскать?
Например, получаете вы списки товаров с ценами по API, а там внезапно цена стала в виде строки прилетать из-за косяка в стороннем сервисе. Если типизация есть в рантайме, то это дело сразу свалится в ошибку, и вы узнаете о проблеме. Эту проблему можно, конечно, решить, если добавить валидатор или приводить типы явным образом, но тем не менее.
Надо просто однажды пересилить себя и начать использовать IDE вместо vim. В профессиональной разработке требуется профессиональный инструмент. В PyCharm есть и type inference, например, который IDE использует, чтобы максимально точно подобрать тип параметра функции или переменной, исходя из наблюдений за всем возможным стеком вызовов. Тем более, уж стандартную библиотеку в CPython семимильными шагами типизируют (там, где это требуется).
Прикрученный сбоку инференс — это всегда фигня.
Это как раз очень даже годно. Поскольку сам язык не требует типизации и разрешает модули без единого тайп-хинта даже в последних версиях, а сами тайп-хинты в рантайме просто игнорирует (покуда они импортированы и использованы правильно), то это очень-очень годно. Берешь старую какашку мамонта, запихиваешь в PyCharm, а он тебе на выходе "хоба! там должно быть что-то, что удовлетворяет интерфейсу __divmod__", например. И сразу видно, что твоя строка в этот вызов не катит.
Чуть не забыл. Есть у меня пепяка на втором питоне, которую приходится периодически ковырять. Мне ее лень переписывать на 3-й. Так вот, я просто подсовываю этой пепяке .pyi и... «Она работает! ©». То есть, у меня получается второй питон с тайпхинтами. Каково?
Типизировали, типизировали, да всё ещё не вытипизировали. Шёл 2023-й год.
Я же написал: "там, где это требуется". Там, где не вытипизировали, это, очевидно, не критично (любой самый исхудалый инферер разматывает простецкие деки или Decimal, например). Может, дотипизируют, когда руки доберутся. Даже в ВСКоде, наверное, инферер справляется.
и потом пишет
Я точно так же могу не открывать идешечку и зарежектить PR, если стайлгайды у нас в проекте требуют аннотации. Могу даже зарежектить, если аннотации не в .pyi вынесены, как того требует стайлгайд, а прямо по коду размазаны. И что?
Полный инференс для любого интересного языка, незадизайненного изначально с прицелом в этот инференс, алгоритмически неразрешим.
А полный не требуется. Мне достаточно знать, что код не упадёт от того, что в переданном аргументе нет свойства (потому что обычно, если он упадёт, это означает, мы не привели тип правильного аргумента к требуемому, а не просто от балды любое рандомное значение из globals() воткнули), которое используется внутри вызываемой функции. Впрочем, sa.Column.__divmod__ это не то же самое, что int.__divmod__, но это ловится уже автотестами и QA.
И аннотации типов у вас и так уже есть
Там, где они есть, они, очевидно, IDE не требуют inference. Сверяются типы напрямую. Впрочем, я не готов утверждать, что это в PyCharm всегда будет так. Ребята иногда умеют очень качественно сломать то, что до этого работало.
Там, где аннотаций нет (например, во внешней библиотеке), IDE пытается (но не гарантирует, что хоть что-то найдёт) вывести минимальный интерфейс, которому должно удовлетворять значение. Это не int или str чаще всего, это именно наличие или отсутствие обязательных свойств (к которым относятся и методы), таких как возможность поделить это значение на целочисленный аргумент, или доступность операции сложения (что для None не выполняется ни в первом, ни во втором случае).
В общем, PyCharm более-менее справляется, покуда не спотыкается об стек, который из-за мета-программистов где-нибудь в дебрях внешней либы размотать не может даже приблизительно.
Что-нибудь типа:
def fn_a(arg):
"""implementation follows"""
return some_val_derived_from_arg
def fn_b(arg):
"""implementation_follows"""
return some_val_derived_from_arg
def call_my_fn(arg):
if moon_clock().to_int() & 1:
return fn_a(arg)
return fn_b(arg)
# Other module:
from some_module import call_my_fn
call_my_fn(2) # inference would get brokenНу так объявите, аннотации работают хорошо.
Visual Basic с типом Var
Ох, да божечки же мои!
from typing import Any
vb_var_typed_variable: Any = None # now it's the same as `Var` in VBможет быть этот тип или этот
from typing import Union
restricted_variadic_type_var: Union[int, float, str] = ""
restricted_variadic_type_var = None # type checker warning: expected int, float or str, found NoneTypeстрока, но только определенных значений (вроде как enum, но без введения нового типа)
from typing import Literal
restricted_values_set_variable: Literal["A", "B", "C"]
restricted_values_set_variable = "A" # OK
restricted_values_set_variable = "D" # type checker warning
У Julia помнится были проблемы с воспроизводимостью результатов, ибо в некоторый момент заигрались с оптимизацией вычислений с плавающей точкой и округление пошло слегка не в ту сторону, после чего посчитанное на новых версиях существенно отличалось от старых. Как бы и здесь не вляпались.
В Java в свое время тоже был такой момент, а потом ещё и переход обратно к прошлому способу вычисления для чисел с плавающей точкой.
в Java с вычислениями были (и есть) свои проблемы с точностью, типами и округлением (например, деление целого на целое даёт целое?!), тихое переполнение, и другие - например, ключевое слово strictfp тоже не просто так появилось.
что прямо указывает на то, что баги, связанные с точными вычислениями и в приграничных условиях - будут просто так, если о них не знать или забыть
деление целого на целое даёт целое
Эээм, стесняюсь спросить, а что неправильного в этой логике?
Ну в математике деление целого на целое не всегда целое. Если ты не программист, то очень неочевидно, что 3/2 вдруг равно 1. В питоне 3/2 = 1.5, что правильно с точки зрения математики. Хочешь целое - округляй или отбрасывай дробную часть вручную. Во многих других языках приходится всегда держать в уме, какой же именно тип числа тут используется, что неудобно.
PS в лиспах и всяких мат. языках 3/2 будет именно 3/2, рациональной дробью. Чтобы получить десятичную дробь, надо уже вручную преобразовывать. Этот вариант самый правильный, но в большинстве задач ненужный.
Если ты не программист, то очень неочевидно, что 3/2 вдруг равно 1.
Ну может инженеру да (хотя он умеет округлять), но математику может быть вполне очевидно (особенно который знаком с алгебраическими системами).
С округлением в Python надо быть осторожным, поскольку там применяется стандарт Banker's Rounding (округление половины целого до ближайшего четного целого).
Ну и существует специальная операция целочисленного деления: //
Ну в математике деление целого на целое не всегда целое.
Ну, если уж мы коснулись математики, то там как раз таки при определении операции над элементами одного множества, результат, как правило, является элементом того же самого множества. Так что операция над двумя Int вполне логично должна давать Int.
"Проблема" же в том, что С++ спокойно и молча позволяет вам производить "странные" операции, вроде деления Int на Float, что, в результате, приводит к конфузам даже у достаточно опытных разработчиков.
Вот Swift, например, такой фигни не позволяет и заставляет явно приводить переменные к одному типу, что сильно снижает шансы на ошибку, но добавляет много лишних телодвижений.
например, деление целого на целое даёт целое?!
Это не баг, а фича. Так и должно быть — это быстро, точно (в отличие от float), не размывает тип (результат можно использовать в дальнейших целочисленных операциях) и часто нужно именно целое значение (а еще иногда остаток).
тихое переполнение
Это тоже можно рассматривать как фичу, потому что проверка на переполнение дорогая, для этого есть специальные функции. Ну и иногда нужен именно "переполнившийся" результат (особенно для побитовых операций).
Я в матлабе и по круче баги находил.
Округление это вообще та ещё головная боль, как вам код дающий разные результаты при смене процессора? Матлаб на запрос фикса вежливо положил его в бэклог неизвестной длинны и сказал что им важнее писать новый глючный код чем чинить старый, хотя я им даже написал как это чинится не напрягаясь за пару <s>часов</s>дней.
Ничего не понял, но Оччень интересно!
Шутка :)
Удачи тебе Jeremy Howard! Причём скорейшей!
Если коротко, то Mojo – это всё тот же хорошо всем знакомый Python, только практически без архитектурных недостатков своего прародителя, с поддержкой возможностей современных аппаратных средств (многопоточность, GPU и т.д.) и новыми фичами. Он создаётся не столько как замена существующим языкам, а как улучшенная версия (т.н. upgrade) Python. Поэтому область применения Mojo – это в первую очередь те же области, в которых активно используется Python: искусственный интеллект, машинное обучение, Data Science, Big Data и т.д. Возможное успешное применение в других областях – это просто приятной бонус.
Спасибо за ликбез. В принципе, я так статью и понял. Просто мне фиолетово. Я не программист. :))
Я любитель. Изучаю языки просто для тренировки мозга, как хобби. В том числе и Python (по книгам Лутца, Бэрри, Матрелли и т.д.)
Как до него Fortran, Basic, Small Basic, Visual Basic, Turbo Pascal, HTML, CSS, Java, JS...
Сейчас долблю С++. Просто потому, что он сложный. :)) Ну и пишу приложуху для себя на Kotlin.
Просто так. Чтобы мозги упражнять. Дл себя.
Так что сам Mojo мне мало интересен. ИИ пока заниматься планов нет. Но если Mojo только улучшит Python - я только За! :))
Однако у Python есть один козырь: он может обращаться к коду, написанному на быстрых языках. Таким образом, программисты Python учатся избегать его использования для реализации критичных к производительности участков, вместо этого используя Python-оболочки для кода C, FORTRAN, Rust и т. д. Такие библиотеки, как Numpy и PyTorch, предоставляют интерфейсы Python для высокопроизводительного кода, позволяя программистам Python чувствовать себя как в родной среде, даже если они используют высокооптимизированные числовые библиотеки.
Стоп, то есть на Mojo такую тему замутить нельзя? Не, чет статья вообще шляпная шляпа, как какая-то сказка.
Питон был и остается клеем, в свое время как перловка, скрепляя вместе мощные кирпичи. А это новое чудо получается что нет, он на позицию кирпича метит. Причем общая конструкция похоже без единого гвоздя без клея, один большой кирпич.
Сопромат учит, что чем больше объект, тем больше в нём внутренние напряжения. Которые могут привести к саморазрушению.
Ну и разбирать стену из кирпичиков и из монолитного бетона - два совсем разных удовольствия. :)
а можно со своим дилетантским мнением влезть? про то, что сложнее разбирать стену с разными кирпичиками. когда у нас в проекте такой замес технологий и подходов разных эпох (например, спринг на хмл файлах, если везде jee, или на фронте и jsf и react, иногда даже struts попадается, где мавен и где градл, где джава а где котлин) а где сложно ускакать по микросервисам где откуда вызывается. а не тай пох где-то ещё подключена магия, которая плюс меняет на минус а true на false меняет поведение на неочевидное. то есть, нетривиальная такая задача быть экспертом по всему, наверное монолитный блок было бы разобрать легче...
Из плюсов увидел передачу аргумента по референсу. Остальное выглядит реально как эсперанто - я питон юзаю для уменьшения телодвижений, а тут какой-то микс - то-ли паскаль, то-ли бейсик, то-ли объектный си. Сдается мне, писать на нем будет еще то приключение, учитывая заковырки с переносом строк и отступами в питоне. Ну или экраны придется делать с пропорциями 41:9
Интересный перевод! Посмотрим, что будет в будущем. Реализуют его или нет... Обгонит он Julia по количеству ошибок и использований в проектах
P.S. Посмотрел видос и код сего чудного нового ЯП.
Человечек использует нативный python...Даже учитывая библиотеку numpy - это просто базовый python, который не является супер быстрым... И он с ним сравнивал :( А тесты его ЯП точно объективны? Кто-то использует нативный python в проде для расчета матриц?
Классная тройная вложенность! Просто восхитительно!
P.P.S. Синтаксис у нового ЯП тоже не блещет супер-пупер качеством...Он конечно пытается подражать ЯП, которые были созданы в прошлом веке. Но что-то как-то не огонь :(
На 5:44 посмотрите ячейку с кодом...Вы метод инициализации понимаете? Сможете повторить для сложного класса?
По хорошему, новый ЯП должен быть лучше предыдущего хотя бы в чем-то.
P.P.P.S. Статья очень восторженная. Прямо чувствуется приторная сладость.
Mojo выглядит потенциально неплохо, но он никак не может стать крупнейшим достижением, потому что крупнейшее достижение — это Rust.
Достижение чего? Поищите CVE по ключевому слову rust, их дохренища. Убийца ошибок как-то не справляется, вопреки рекламе. Да и по рейтингу всё ещё на задворках, хотя его уже который год называют "языком будущего" и всячески нахваливают - хотя он не тянет не то что на "крупнейшее", но даже просто на "достижение".
У каждого языка есть своя ниша и свои поклонники, язык - это инструмент, и как в случае с обычными (железными, деревянными и прочими) инструментами всё зависит от профессионализма того кто им пользуется, а от простоты, удобства и функциональности - количество тех кто им пользуется, это и определяет популярность.
С учётом этого, rust- точно не достижение, он всего лишь один из многих с весьма неопределённым будущим, и пока (вспомним про CVE) ещё не достигший заявленных целей, более того, пока программы пишут люди - они всегда (если не тривиальные) будут с ошибками разной критичности и никакой супер-язык в этом не поможет, никогда.
Я также сильно подозреваю что вряд-ли у вас есть работающий хрустальный шар, так что утверждение в духе "никак не может" лишено всяких оснований - это будет ясно только в будущем, причём далёком будущем.
Ну в ядро Linux на нем писать разрешили. Microsoft тоже его в системном ПО использует...
Ну, я пока тоже не любитель ржавчины, хоть и приходится писать на нём на работе. Я больше Го люблю.
Что могу сказать - выбора системных языков почти нет. Либо плюсы, либо раст. Си уже не в счёт, слишком низкоуровнево.
И тут я лучше выберу раст, чем буду мучиться со всякими UB в плюсах и прочими сюрпризами.
А CVE всегда были и будут, раст не гарантирует безопасный код, особенно если юзать его некорректно.
Go - язык высокого уровня, Rust - низкого. Это как сравнивать трактор и автомобиль.
Да я бы не сказал что прям такие большие отличия. Языки очень похожи, библиотека стандартная в Go конечно сильно побогаче, в Rust больше на внешние крейты ставка сделана.
Подходы к управлению памятью разные, да, но на "уровень" языка (низкий, высокий) я не уверен что это влияет. Если хочется упороться то и в Go можно руками управлять до некоторой степени.
В общем и целом за год, прошедший с комментария, я Rust полюбил и писать на нём доставляет удовольствие. Принцип "если оно собралось - то, скорее всего, работает как задумано" очень радует, а уж если тесты есть... У меня сервисы ни разу не падали в рантайме пока что, в отличии от Go где нет-нет да `Nil pointer dereference` вылезет.
я бы за километр обходил сложный язык общего применения, который якобы популярный и распространённый (или хотябы не бетта) и у которого при этом нет ни CVE, ни иных известных проблем/багов и тд. (потому что такой язык чем то похож на неуловимого Джо)
Поищите CVE по ключевому слову rust, их дохренища.
А по мне так очень мало.
У меня есть хрустальный шар.
Впервые столкнулся с багами Rust лет пять назад, даже парочку исправил. Оказалось, для того, чтобы Rust можно было использовать с либами на Си, к либе нужно написать враппер. Вот там и проблемы. Да, из программ на Rust баги ушли, но они пришли во врапперы.
А почему не Lean4?
Ну когда ты напишешь обзорную, научно-популярную статью про Agda, Coq (Gallina), Idris 2 и ATS? Я джва года жду такую статью. Она бы очень зашла.
Да, может это и не просто, но обзорная статья от человека "в теме" очень нужна. Потому что инфы вообще очень мало. А на русском вообще, по-моему, нет. Про Idris 2 не видел ничего. К тому же и я и, уверен, весь Хабр любим читать людей, которые угорают по какой-то теме. А уж если обычным, человеческим языком рассказать о таких неведомых вещах, показать, порассуждать, сделать хорошее, доступное введение - то я такую статью с руками оторву. И можно, например, минимально практическую задачку порешать на каждом языке - будет видна разница, а это очень круто для понимания. Ну и прочувствовать применимость в реальности - невероятно полезно.
(Ещё можно обрисовать некую условную градацию/"уровень" ЯП - императивные → функциональные без завтипов → функциональные с завтипами - чтобы понимать, на какой "высоте" Computer Science мы находимся и в чём, собсно, крутизна.)
Если дать мало-мальский ориентир читателям - это уже будет гигантская польза. Дать минимальную почву под ногами - а дальше уже сами. Представь, сколько людей могут серьёзно загореться этой темой?
Да, тут вырисовывается цикл статей, да, работа тяжёлая и серьёзная - но она того стоит.
Лично мне интересно, зачем вот это все и как оно применяется на практике. Имхо, языки и прочие инструменты задумывались или для повышение скорости исполнения программы, или для повышения скорости написания кода, или для повышения скорости промышленной разработки. По идее, доказательное программирование нужно для отказа от тестов без потери надежности и для выявления лакун в ТЗ, т.е. для вычленения жестко детерминированных задач и написания соответствующих библиотек, которые потом уже можно пихать в проекты без страха и стеснения, но я не видел подтверждения, что оплачивать разработку на Coq дешевле, чем набрать плюсовиков, тестировщиков и юристов на всякий случай.
[Здесь должна быть картинка с длинным рядом писсуаров]
Для расчётчиков Раст ничем не лучше C++. А для датасатанистов и то, и другое -- это какие-то иероглифы марсианской цивилизации.
Нет, в расте вообще почти никаких неявных приведений типов нет. Есть только неявные приведения используя сабтайпинг по лайфтаймам, приведения типа &mut (или *mut) в & (или *), приведения указателей на функции к замыканиям (и наоборот, если замыкание не является на самом деле замыканием - не захватывает контекст), deref coercion и bottom к любому типу. Возможно что-то еще несущественное забыл.
что же является «синтаксическим сахаром для MLIR»? Ответ — Mojo!
MLIR, по сути, гибкая инфраструктура для современных оптимизирующих компиляторов. Это значит, что она состоит из спецификации промежуточного представления (IR) и набора инструментов для преобразования этого представления.
Так а чо, c этим Mojo сишный синтаксис наконец-то будет возможен в Питоне? Или может быть Mojo позволит сконвертить медленные питонистые программы для быстрого и дешёвого повышения производительности?
можете в любое время перейти в более быстрый «режим», используя «fn» вместо «def» для создания своей функции.
А нельзя было просто декоратор придумать?
Думается каждом овощу... это - своя грядка.
Мне как-то пришла в голову некая гм... гениальная идея, нужно было хитрым обработать видео, а я не умел. Попросил знакомую которая видимо умела - я читал, что на Питоне можно много чего делать легко и просто. Она сделала за день, результат мне понравился. Я спросил - сколько времени у тебя файл обрабатывается? Она - пять часов. Мы вдохновленными успехами и тем, что задача в принципе решается, почитали книжки, переписали обработку на Си, и... теперь файл обрабатывается две минуты.
Я задам идиотские вопросы. Потому что я совсем (почти) не понимаю в языках. Я заранее извиняюсь!
Язык и Компилятор(Интерпретатор) языка - это одно и тоже?
Обязательно ли нужно придумывать новый язык чтобы сделать новый компилятор?
Создаст ли новый супер-пупер компилятор "старого" языка столько-же хайпа (денег, славы, самомнения, нужное подчеркнуть) как новый язык?
Или можно взять текст программы (старой) пропустить его через (новый) компилятор и получить (новый) исполняемый код?
Или в каждом языке существуют ОДНОЗНАЧНЫЕ соответствия между Текстом программы и Двоичным кодом?
В чём преимущество нового именно языка (не компилятора) перед старым? Он короче? Более понятен? Меньше\больше инструкций?
Ещё раз заранее извиняюсь!
Вы подняли сложные вопросы, на которые в действительности нет однозначного ответа. Новые языки программирования создаются по разным причинам, например:
чтобы упростить программирование, повысить надёжность кода, увеличить скорость разработки или поддержать новые парадигмы программирования;
чтобы помочь исследованиям в определённой области или решить специфические задачи, для которых существующие языки не совсем подходят или не оптимальны;
чтобы захватить рыночную нишу в борьбе с конкурентами или привлечь внимание сообщества к своему продукту или технологии.
Язык и компилятор (интерпретатор) языка — это не одно и то же. Язык — это набор правил и соглашений, которые определяют, как писать программы на этом языке. Компилятор (интерпретатор) — это программа, которая переводит код с одного языка на код в другом языке (обычно в машинный код) и/или выполняет его построчно.
Не обязательно нужно придумывать новый язык, чтобы сделать новый компилятор. Можно сделать компилятор для уже существующего языка, который будет иметь какие-то преимущества перед другими компиляторами этого же языка, например, быстрее работать, лучше оптимизировать код, поддерживать новые платформы или возможности и т.д.
Новый супер-пупер компилятор «старого» языка может создать столько же хайпа (денег, славы, самомнения — это всегда индивидуально), как новый язык, если он будет решать какие-то актуальные проблемы разработчиков или предлагать какие-то инновационные решения. Например, компилятор LLVM стал очень популярным и востребованным благодаря своей гибкости, модульности и поддержке множества языков и платформ.
Можно взять код (старой) программы, пропустить его через (новый) компилятор и получить (новый) исполняемый код, если этот компилятор поддерживает этот язык и целевую платформу. Но это не значит, что новый код должен работать лучше или хуже старого. Это зависит от того, насколько хорошо написан компилятор и как он оптимизирует код.
Строго говоря, ни в одном высокоуровневом языке программирования не существует однозначного соответствия между кодом программы и машинным (т.е. исполняемым) кодом. Разные компиляторы могут переводить один и тот же «текст» программы в разный двоичный код, в зависимости от используемых алгоритмов и оптимизаций.
Преимущество нового языка (не компилятора) перед старым может быть в том, что он короче, более понятен, меньше устаревших и/или больше полезных инструкций, лучше подходит для определённой задачи или области, использует новые возможности аппаратных средств или парадигм программирования. Но это не значит, что новый язык всегда лучше старого. Каждый язык имеет свои сильные и слабые стороны, свои преимущества и недостатки. Важно выбирать язык в соответствии с целями и требованиями проекта.
При этом важно продолжать разрабатывать новые языки программирования, потому что это способствует инновациям в области разработки программного обеспечения. Новые языки могут предлагать новые возможности, решать новые задачи, улучшать производительность, надёжность или удобство кодирования. Новые языки также могут влиять на существующие языки, вдохновляя их на внедрение новых функций, конструкций или парадигм.
Например, язык TypeScript, созданный в 2012 году, добавил строгую типизацию к языку JavaScript, что повысило его надёжность и масштабируемость. TypeScript стал очень популярным среди разработчиков веб-приложений и веб-сайтов. В 2020 году язык JavaScript получил поддержку опциональной цепочки (optional chaining), которая позволяет безопасно обращаться к свойствам объектов, которые могут быть неопределёнными или равными null. Эта функция была заимствована из TypeScript.
Другой пример — язык Kotlin, созданный в 2011 году как альтернатива Java для разработки на платформе Android. Kotlin предлагает более краткий и выразительный синтаксис, поддержку функционального программирования, безопасность от нулевых указателей и многие другие преимущества перед Java. В 2017 году Google объявил о том, что Kotlin становится официальным языком для разработки на Android. В 2019 году Java получила поддержку текстовых блоков (text blocks), которые позволяют легко записывать многострочные строки без экранирования специальных символов. Эта функция была заимствована из Kotlin.
Создавать новые языки нужно, даже если они не всегда успешны. Потому что изучение новых языков помогает развивать целое направление отрасли — дизайн/проектирование языков, а также способствует расширению кругозора, пониманию различных подходов к программированию и обнаружению нестандартных решений. Кроме того, нельзя заранее знать, какой язык станет успешным или неуспешным. Иногда языки, которые кажутся непопулярными или устаревшими, могут вновь стать востребованными из-за каких-то изменений на рынке или в технологиях. Например, язык Fortran, созданный в 1957 году, до сих пор используется для научных и инженерных расчётов и имеет сравнительно высокую производительность.
Зачем? Ну правда, зачем? Python - это язык с динамической типизацией, так он работает, так он устроен, он медленный именно по этому, по сути любой объект питона - это хеш таблица со строковыми ключами, где ключи - имена полей и методов объекта. Быть медленнее Си - имманентное свойство виртуальной машины питона именно ввиду его динамической природы. Хотите виртуальную машину со статической типизацией, ну так их уже есть несколько - Java, .Net. Для этих ВМ придумывают по языку программирования в год, в том числе и динамические языки работающие через рефлексию. И если я не ошибаюсь, скрестить ежа с ужом пытались уже неоднократно - всякие JPython и IronPython тому примеры. Из текста статьи я лично не понял, каким именно образом авторы инновационного языка пытаются усидеть на двух стульях - сделать питон быстрым и динамическим одновременно. Если же ЯП не будет динамическим, то нафига вы его сравниваете с питоном, сравнивайте с языками из этой категории - с джавой, котлином, c#.
А в чем преимущества динамической модели языка программирования?
А я не про преимущества/недостатки говорил, а про то, что язык заявляется как убийца питона, при этом - очевидно - является чем-то совсем иным и несравнимым.
Преимущества и недостатки вещь довольно субъективная, назовем их особенностями. Особенности вытекают из того факта, что объекты питона не обязаны соответствовать известной на момент компиляции схеме. Список полей и методов может быть изменен в рантайме и более того, новые классы можно создавать прямо во время выполнения. Это дает простор для творчества и позволяет вытворять что-то такое https://docs.djangoproject.com/en/4.2/topics/db/queries/#retrieving-specific-objects-with-filters
Не подумайте, что я спорю, я всего-лишь ищу истину или новые горизонты. Но вот в языке C# есть механизмы для конструирования классов. Правда не знаю насколько это остается в русле статической типизации. Мне кажется, свободна интерпретируемого языка в том чтобы в процессе выполнения создавать и исполнять код больше относится к метапрограммированию и вроде этот подход не особо распространен.
Давайте для начала отделим мух от котлет и разберемся в терминологии. Когда мы говорим C#, Java или python, что мы имеем в виду? Мы говорим про язык программирования, как набор синтаксических правил? Или мы говорим про байткод виртуальной машины? Или про саму виртуальную машину? Или про всё вместе? Тут легко запутаться, потому что один и тот же текст программы может компилироваться в нечто совершенно разное, например Котлин может компилироваться в байткод джавы, в нативный код и в веб-ассемблер. В то же время, десятки языков компилируются в аналогичный байткод - языки .Net, языки JVM - их десятки, но все компилируются в байткод соответствующей ВМ. Реализаций ВМ тоже десятки. Вы можете придумать свою виртуальную машину питона, которая будет несовместима с байткодом cpython, но полностью поддерживать python. Или вы можете реализовать совместимую с cpython виртуальную машину, которая будет быстрее за счет каких-то оптимизаций, jit-компиляции или еще чего-то. Или вы можете придумать компилятор JavaScript в байт-код питона.
С другой стороны, сам ЯП на уровне стандарта языка может диктовать пределы в которых вы можете оптимизировать байт-код и виртуальную машину. Например вот так https://docs.python.org/3/reference/datamodel.html Как в питоне происходит обращение к члену объекта? (всё нижеследующее дано грубо и для примера, в действительности всё сложнее). Когда в программе мы пишем my_object.my_method(), питон идет в __dict__ объекта, это хеш-таблица, в которой он ищет ключ __get_attr__, если такового не находится, то питон обращается в классу объекта (который тоже объект), читает dict этого объекта, и ищет get_attr, если и там не находит он получает родителей класса и для каждого производит этот поиск пока не найдет или не упрется в самый базовый класс. Далее вызывается найденный __get_attr__('my_method'), что значит вызывается? А это значит что аналогично вышеописанным манипуляциям питон ищет атрибут __call__, ну и так далее, почитайте по ссыке. Что из этого следует? А то, что как бы вы не хитрили с байт-кодом и виртуальной машиной, чтобы это был питон - вот эта вся пляска по хеш-таблицам обязана выполнятся на каждый чих. В результате, любая функция в питоней программе вольна вернуть что угодно, нет вообще понятия тип возвращаемого значения. Это особенность питона диктуемая его динамической природой. Это не аналогично тому, что из каждого метода С# я буду возвращать object, это совсем другая идиология.
Вот из таких соображений у меня складывается претензия к статье. Может быть я невнимательно прочитал, но я решительно не понял, что из себя представляет новый язык, и почему он убийца питона
именно ввиду его динамической природы. Хотите виртуальную машину со статической типизацией, ну так их уже есть несколько - Java, .Net.
В C# есть dynamic
Существуют также неизбежные проблемы с производительностью, даже если для библиотеки используется быстро компилируемый язык.
"faster compiled implementation" - "более быстрая, компилируемая реализация". Скорость компиляции тут ни при чём, мягко говоря.
Что-то у меня Mojo перекликается с Codon и Seq. Не по звучанию, конечно.
Не понимаю, отчего такой язвительный сепсис. Вполне себе заслуженный человек увидел проблемы и пытается решить. И тут хобана - специальная олимпиада доказательств что и проблем нет и вообще всё зря. Видимо пишется в перерывах между чистками террариума из разных питонов.
Вполне себе заслуженный человек
Вот. Именно в этом проблема. Вот если бы без имён, мол, некто нашёл такие и такие проблемы, пытается решить так и так, думаю, как минимум, части комментариев бы и не было. А то прям "вот не хрен с горы, а аж целый {{ NAME }} нашёл", будто это что-то в корне менять должно.
О "проблемах":
Но Python во много тысяч раз медленнее, чем C++ подобные языки.
Такой проблемы в general case нет. В частных случаях в CPython (не путать с Python) есть, в общем случае нет. Там, где есть, решается как раз теми же плюсами, например. Или PyPy, если ограничения RPython не отгрызают половину архитектуры.
внутренних циклов, где производительность имеет решающее значение
И, конечно, как пример подан вырожденный случай.
Проблема двуязычности мешает обучению
И решение: еще один язык. Гениально.
Вместо того чтобы иметь возможность приступить к реализации алгоритма во время выполнения вашего кода или перейти к определению интересующего метода, вы оказываетесь глубоко в зарослях библиотек C и больших двоичных объектов
И это нормально. В мылорушечке, например, просят отсортировать 100ГБ строку при верхнем лимите памяти в 128ГБ на чистом питоне (по крайней мере, собес про питон). Тогда как это очень быстро и просто решается крайне простым и быстрым расширением для питона на C-API, при необходимости можно даже распилить на куски и скормить тредпулу. Где проблема-то? Надо срочно всё-всё-всё переписать на одном единственном языке, чтобы ну ни в кошмарном сне не привиделось, что у нас есть что-то, кроме ${lang_name}? Расстрою: это более-менее можно тогда с тайпскриптом на фулстеке. Да и то, как только системные администраторы начнут паковать это в контейнеры, добавится YAML и всё, мечта не сбылась.
Продолжать?
Я правильно понимаю это перевод статьи от автора непопулярного фреймворка fast.ai ?
Существует также подход, используемый Go, который не может генерировать такие небольшие приложения, как это делает C, а вместо этого включает «среду выполнения» в каждое упакованное приложение.
простите, но я думал (читать рассказывали коллеги по цеху) что Go как и Rust может не только в статическую линковку но и в динамическую, просто так "не принято" делать..
Я оставил один из моментов, который меня больше всего волнует, на потом: развёртывание. В настоящее время, если вы хотите дать другу свою крутую программу на Python, вам придётся сказать ему, чтобы он сначала установил Python!
так питон сейчас помоему во всех десктопных дистрибутивах встроен из коробки, другой вопрос что в репозиториях не всех дистрибутивов есть все необходимые питонолибы нужных версий, а тянуть с pip такое себе.
Уже появились вакансии Mojo с опытом от 3 лет?
Извините за оффтоп, но мне вспоминается, что когда clang был темой диссертации, предполагалась постоянная оптимизация во время использования кода на конкретной машине под сценарий использования. Эту стюардессу окончательно закопали?
Симпсоны как всегда напророчили
В самом начале была поднята проблема "с отсутствием эффективной параллельной обработки в Python"... так что с ней в Mojo?
Непонятно зачем Python улучшать — всех, кто на нем работает, он устраивает. Есть куча предметных областей, где нужны новые ЯП (системное программирование, например).
Поясню. Улучшения Python это все полумеры. А вот что действительно нужно — это совершенно новый язык для "склейки". Почему новый? Да потому что требования к нему следующие: компилируемый, без GC, легкое написание + легкое чтение, без зависимостей, и т.д. Не вижу смысла в том, чтобы при таких радикальных изменениях тащить в него синтаксис и слабости питона. Если язык будет относительно простой, то все программисты со временем перейдут на него. А дата-сайентистов и так почти все устраивает.
А сделаю-ка я закладку для этого комментария :-)
компилируемый
Jython, PyPy, IronPython, в некоторой степени Cython
без GC
Jython, PyPy, IronPython, в некоторой степени Cython
легкое написание + легкое чтение
Любая реализация Python
без зависимостей
CPython, PyPy; Cython, Jython и IronPython зависят от соответствующих рантаймов.
Итого: всё уже украдено придумано до нас.
С одной стороны да, всё это так и есть, диалекты Пайтона расширяют его возможности, поэтому Python-II (с таким же синтаксисом и даже семантикой) и не нужен. А с другой стороны, с нуля можно создать гораздо более чистый язык, сделав его более мощным и гибким одновременно. И уж точно он не будет похож на Python (ну не более, чем другие ЯП).
Mojo может стать крупнейшим достижением в области разработки языков программирования за последние десятилетия