Комментарии 49
Насчет Julia мысль не раскрыта. Мне лично не понятно, почему вдруг Python медленее C или С++ в контексте математических вычислений, если для этого используются numpy и scipy, которые по факту просто обертки над сишными функциями. И чем Julia в данном случае принципиально лучше?
Rust абыдэлса на эту статью.
Юлечка на HEPесах с бриллиантами.
https://hepsoftwarefoundation.org/activities/juliahep.html
https://github.com/JuliaHEP/ROOT.jl
Были бы у нее яйца так бы маханул по ним с плеча бритвой Оккама!
Думаю, что ценность этой статьи стремиться к нулю. Нет, не пользуюсь. Вместо Джулии взял бы Фортран. Вместо F# - OCaml. Остальные вообще непонятно зачем нужны.
D:
Functions
Arrays
OOP
Single inheritance of implementation/multiple inheritance of interfaces
No built-in dynamic class loading
Performance
Direct access to hardware
Independent of VM
Direct native code gen
Generic Programming
Metaprogramming
Reliability
Concurrency & Parallelism
Types
Compatibility
C-like syntax
Use existing debuggers
Generates standard object files
Other
Мне нравился D в свое время, но в итоге я пришел к выводу что он для меня слишком низкоуровневый. Для любой мелочи типа "удалить элемент из массива по значению" или "взять из массива случайный элемент" идешь в гугл и выясняешь что надо написать свой хелпер, потому что в стдлибе такой функции нет. А в руби (а потом и кристалле) чаще бывало наоборот - пишешь или собираешься писать свой хелпер (например чтобы из массива сделать хеш значение->число элементов), а потом узнаешь что ахаха, оказывается в стдлибе даже такое уже есть (tally).
Первая ссылка это удаление по предикату. А мне не нужно по предикату - мне нужно удалить первое вхождение элемента. Есть там возможность сделать break из лямбды?
Во второй ссылке смущает разве что
version (D_LP64) // https://issues.dlang.org/show_bug.cgi?id=15147
Ну, да, там нужно написать короткий хелпер из find+remove+popBack. Маленькая какуля посреди большого прекрасного сада.
вот из-за таких какуль я пришел к выводу что трачу больше времени на проблемы языка чем на творчество. В руби написал и понеслась (кристалл, честно говоря, занимает промежуточное положение - разбираться с проблемами тоже надо, но общее ощущение все-таки ближе к руби),а тут напиши хелпер, разберись с ошибкой шаблона, багом линкера, неожиданным поведением alias this. Не спорю что намного лучше чем в C/C++, но все еще далеко от идеального языка. Конечно это личный опыт - у кого-то иначе, кому-то D идеален, кому-то вообще С топ.
Если что, самое большое что я писал на D было https://sourceforge.net/projects/gatewayrl/
А в руби уже завезли статическую типизацию или это до сих пор язык для персональных домашних страничек, на котором час пишешь, потом неделю дебажишь?
иронично но это было и моей главной претензией к руби. что медленный и динамически типизированный. Так что я не мог поверить своим глазам когда увидел https://crystal-lang.org/
Это уже другое дело, конечно. Но они слишком уж много всего засунули в стандартную библиотеку: от http сервера, до библиотеки тестирования. И первое же, что хочется с ними сделать - выпилить и заменить на что-то более адекватное.
Из любопытства - что именно в них показалось неадекватным? Потому что конкретно реализация тестирования в Кристалле (скопированная из rspec ruby) сделала меня сторонником TDD. Потому что способ который я видел до нее в Delphi и D (писать тесты в тех же файлах что и реализацию) делал код нечитаемым.
А HTTP сервер - в techempower benchmarks он правда раза в 2 отстает от лидеров, но раза в 2 обгоняет vibe.d, высокоуровневые вещи типа роутинга конечно надо делать самому (или брать любую из библиотек\фреймворков), но то что низкоуровневую часть сделали частью стдлибы и не надо парится о кроссплатформенности мне нравится.
Карго-культ с подражанием BDD и запуском тестов в недетерминиированном порядке, вместо лаконичных тестовых блоков в D с запуском тестов в порядке, соответствующем коду.
Ну а если для сервера всё равно приходится искать сторонний высокоуровневый фреймворк (или пилить его самому), то какая разница есть ли в стандартной библиотеке какая-то низкоуровневая апишка? На самом деле идеальная стандартная библиотека должна быть не более чем набором алиасов на лучшие решения от сообщества, а не форсировать этому сообществу использование сомнительных решений из других языков.
хм, и там и там тесты внутри одного файла запускаются последовательно, при этом есть возможность запустить их в рандомном порядке (в d для этого потребуется поставить доп. библиотеку и указать ей список файлов вручную, в crystal - передать ключ компилятору). На мой взгляд тесты зависящие от порядка запуска - скорее недостаток.
а низкоуровневая апишка позволяет как раз то что должна - абстрагироваться от особенностей различных ОС и тонкостей протоколов и писать высокоуровневую логику. Что для доступа к файловой системе, что для http-сервера.
сомнительных решений из других языков.
в чем же сомнительность? В любом случае да, дело видимо скорее в философии чем в конкретных решениях. Мне нравится что crystal предлагает унифицированные решения (юниттесты, http сервер, пакетный менеджер, автоформатирование и т.д.) чтобы избежать зоопарка реализаций и ненужных споров по поводу "snake_case vs PascalCase", "вон тот веб-сервер более производительный а вон тот зато кроссплатформенный". Но для кого-то это может наоборот быть минусом.
Речь про разные файлы, разумеется. По поводу порядка гляньте фрактальное тестирование. Про TDD, кстати, тоже есть разбор.
У меня тут вьетнамские флешбеки. Когда-то Wrike переходил на Dart под лозунги "нет зоопарку, нет спорам, даёшь стандартную библиотеку от Google!", а спустя 10 лет уже ломились обратно с лозунгами "даёшь современные решения, даёшь богатство библиотек, нет велосипедам".
Про тесты я это уже читал и в целом согласен. Т.к. программа не упадет на первом же проваленном тесте а покажет все непрошедшие, то не вижу недостатков в случайном порядке запуска.
а спустя 10 лет уже ломились обратно с лозунгами
нормальная история когда один язык намного популярнее другого, зоопарк тут не главное. Помню проект (клон Neverwinter) также с D на С++ переходил с лозунгом "специалистов по D невозможно найти".
Случайный порядок всего-лишь усложнит поиск причины сбоя.
Любой C++ специалист, прекрасно справится и с D.
Зато он гарантирует отсутствие неявных зависимостей между тестами (когда в одном тесте мы меняем глобальное состояние и только за счет этого последующие тесты успешно выполняются).
За соответствующие деньги - конечно справится. А вот на энтузиазме он (как выяснилось) вряд ли захочет изучать новый язык только ради того чтоб законтрибутить в интересный ему проект.
В результате получаем огромное число медленных тестов со слабым покрытием, которые нагревают воздух по чём зря (ибо нет смысла гонять 90% тестов, если база сломана).
На энтузиазме вон в ядро линукса тянут код на Rust, который там вообще не к месту, а вот D осваивается C++ником за один день.
Экономим время на том что провальный тестовый прогон завершится раньше успешного, но зато тесты не отлавливают целый класс ошибок. В лучшем случае дело вкуса.
Будем объективны - раст сейчас на хайпе, D, как и Crystal, как и Dart с которого начался разговор намного менее популярны. Пример с ядром это подтверждает - даже туда протащили.
В D вон в вашем списке до сих пор 80-битные флоаты упоминают, хотя FPU за пределами легаси неактуален лет так 20.
Пишете ли вы тесты на стандартную библиотеку или запускаете хотя бы её собственные тесты? Это ведь тоже целый класс ошибок.
Пишете ли вы тесты на стандартную библиотеку или запускаете хотя бы её собственные тесты? Это ведь тоже целый класс ошибок.
Я бы отличал ошибки которые могу допустить я сам (их число пропорционально написанным строкам кода). К ним относятся тесты которые успешно проходят только в определенном порядке из-за глобального состояния.
И ошибки которые за меня допустили другие. К ним относятся ошибки в стандартной библиотеке. Их на каждую написанную мной строчку запускать не вижу смысла.
Но если уж о том речь, то в репозитории Crystal эти тесты и так прогоняются на каждый PR, я могу их конечно запустить еще и локально но не вижу смысла
конечно я перед тем как писать сверился с википедией, вдруг что-то упущу. Но нет - ARM их не поддерживает, SIMD (SSE) их не поддерживает, только тормозной FPU сохранившийся в архитектуре x86 с первых процессоров Intel. Соответственно никакого смысла их использовать если производительность важна - SSE работает быстрее за счет отсутствия fwait, регистровой модели вместо стека и конечно векторизации.
Попробуйте не использовать глобальное состояние - станет легче не только тесты писать, но и рефакторить код. Кроме того, полезная практика - писать не только пост условия в тестах, но и предусловия - помогает не только от наводок между тестами, но и в случае изменения дефолтного поведения.
А смысл запуска, разумеется, есть, ибо ваше окружение отличается от CI-сервера и нужно понимать где ваша ошибка, а где не ваша.
Расширенная точность используется для повышения точности вычислений, а не для их ускорения. SSE оперирует 4 числами одинарной точности, а не одним числом четверной точности.
Ну а по поводу актуальности поспорьте с этими ребятами сперва:
https://github.com/rust-lang/rust/issues/116909
https://ziglang.org/documentation/master/#Floats
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#floating-point-types
А смысл запуска, разумеется, есть, ибо ваше окружение отличается от CI-сервера и нужно понимать где ваша ошибка, а где не ваша.
Я что-то не встречал на практике случая когда это могло бы как-то помочь. А вот то что ловилось изменением порядка тестов - встречал.
Предусловия конечно могут быть полезны в каких-то случаях, но гхм, писать их только потому что язык не поддерживает запуск тестов в случайном порядке это лишняя работа.
Расширенная точность используется для повышения точности вычислений, а не для их ускорения. SSE оперирует 4 числами одинарной точности, а не одним числом четверной точности.
Или двумя числами двойной точности (f64). Которой более чем достаточно для практических задач. Ну и конечно есть софтварная произвольная точность для тех кому действительно нужна точность.
Процитированный issuе для Rust не упоминает f80, только f16 и f128 (f16 полезен для видеокарт, f128 тоже отнюдь не f80). zig добавил f80, насколько я помню, как раз чтоб с легаси кодом взаимодействовать.
Одни проблемы раздуваем, а на другие внимания не обращаем. Классика.
В D тип real имеет минимум 80 бит, чтобы поддерживать максимальное количество архитектур процессоров. И расширенная точность с парой доп байтов была введена именно для того, чтобы вычисления над f64 не накапливали ошибку. А так, да, f64 более чем достаточно для большинства задач.
В D тип real имеет минимум 80 бит, чтобы поддерживать максимальное количество архитектур процессоров.
Он имеет 80 бит т.к. это битность блока FPU в 8087 (https://ru.wikipedia.org/wiki/X87). Насчет "минимума" вы ошибаетесь, уверен что на арм там 64 бита и по ссылке там говорится "On Intel x86 machines, for example, it is expected (but not required) that the intermediate calculations be done to the full 80 bits of precision implemented by the hardware. ".
Но и на Intel смысл использовать 80 бит минимален, т.к. ни один новый набор инструкций их не поддерживает.
При этом всем я видел только один пример использования - https://github.com/gnunn1/tilix, и больше ничего, увы =)
Зачем разбираться, если можно глупо улыбаться, да? https://dlang.org/orgs-using-d.html
Для 20+лет существования этого языка как-то негусто честно говоря
из всего списка я видел только weka, все остальное прошло мимо меня, как и мимо многих кто использует D, и как я увидел из списка применения по ссылке то оч много кто таи просто для рекламы, даже нету case stadies, а банально указали его использование и не более
Как там, допилили @nogc чтобы хотя бы половина стандартной библиотеки с ним работала, или он по-прежнему для галочки?
Не хватает первого пункта. "Александреску"
Я фанат (фанатик?) Crystal с тех пор узнал о нем много лет назад. В статье сделали акцент на веб-сервисы, но я с вебом почти не знаком, пишу на нем инди-игры на джемы (есть байндинги к SFML, SDL, Raylib, в целом есть автогенератор байндингов к сишным библиотекам, ну а у меня свой движок есть), потихоньку протаскиваю на работе (делал на нем пару гуи для встраиваемых пультов, а теперь еще и под микроконтроллеры можно писать). В целом очень нравится что он по большому счету низкоуровневый язык (как и Nim или Zig), но при этом с крутым автовыводом типов и изящным синтаксисом Руби.
Минусы конечно тоже есть - маленькое сообщество, невозможность инкрементальной компиляции.
Если кто интересуется - у русскоязычного сообщества Crystal есть тг-канал https://t.me/crystal_ru
Ну сделай бесплатные курсы для них, что-ли.
Раз в статье упоминается о транспиляции и метапрограммировании, то я приплету Haxe.
Это всё конечно хорошо. Но для практического применения лучше изучить Elixir, во всяком случае если вас backend-разработка интересует.
Да-с F# пожалуй для видны да-с, но тоже народ не любит, а любит C#, все остальное Юля, яндекс, так себе, надож было чтоб как у людей, свой язык, под тарантул, ним вам зачем совсем не понимаю, хотите компиляцию, берите го, или что у них есть еще там, зих вам не нужен есть руст, поскольку люблю хаскел, то рекомендую
Не только Python и JavaScript: пять крутых языков программирования для изучения в 2025 году