Комментарии 110
Реакция на язык X, который пророчат на замену си.
Ну в свое время Паскаль был более востребованным и быстрым. Да и сейчас вполне даст просраться всяким Питонам :)
Но времена Борландов прошли :((
Этот - не взлетит. Т.к. " Это — системный язык программирования, заточенный под написание компиляторов и сетевого ПО." Т.е. охват - минимальный
Борланд не только паскалем занимался, но этот язык там всегда занимал особое место.
pascal по каким-то причинам (говорят что из-за := вместо =) завоевал уважение в академической среде, его использовали для обучения, а потом студенты-выпускники несли в индустрию
кстати, будут пруфы что borland pascal был "быстрее" borland c и что это вообще значит? скомпилированный код похожих программ работал быстрее? (да скорее всего, у этих компиляторов вообще внутри было почти всё общее и тупо разные фронтенды)
что borland pascal был "быстрее" borland c и что это вообще значит?
В данном контексте значит что компилировался сильно быстрее. Это заслуга не реализации борландовских компиляторов, а паскаля, для которого возможен однопроходный компилятор.
Код похожих программ работал сильно зависимо от ключей сборки и особенностей алгоритма, как и везде.
Я думаю, что это всё-таки заслуга template и include *.hpp из С++.
И более продвинутого подхода с interface \ implementation из Pascal, который позволял не делать кучу работы.
ПС
Так-то парсер для Pascal попроще парсера C - но сам парсинг близко к о-малому в оптимизирующем компиляторе таких ЯП.
Вообще-то C принципиально однопроходный. Например, tcc (Tiny C Compiler) реализован как однопроходный, и поддерживает весь стандартный С и много GCC расширений.
Проблема C в инклудах и макросах: каждый файл приходится компилить заново вычитывая и парься все include, т.к. их содержимое может в буквальном смысле меняться от определённых макросов.
Правда, tcc все равно делает это чертовски быстро. Но почти не оптимизирует код.
? (да скорее всего, у этих компиляторов вообще внутри было почти всё общее и тупо разные фронтенды)
Нет. Это были разные компиляторы.
Выходцы из Borland создали компанию, которая под маркой TopSpeed как раз такую идею и хотели сделать. Один бакенд, и куча фронтендов.
А почему Borland Pascal не стал "промышленным стандартом".
Так всё просто. Библиотеки (.tpu) были не совместимы между версиями, даже минорными. Например библиотеки от Turbo Pascal 5 нельзя было использовать в Turbo Pascal 5.5. Это затрудняло распространение коммерческих библиотек. Грубо говоря нужно было поддерживать несколько вариантов .tpu под разные компиляторы.
А распространять библиотеки в исходных кодах тогда было ещё не модно.
Так что для коммерческой разработки Turbo Pascal не очень хорошо подходил.
Мне кажется, Паскаль не особо подходил для реализации больших проектов. Или эти возможности были ему сильно "сбоку" добавлены. Так как исходная идея - это объемлющая процедура Program с бесконечной вложенностью подпроцедур, в С все же подход более "горизонтальный"
Тогда же завозили ООП в Delphi, было очень модным, а с 95-го и вовсе Oak(Java) подлетел с ещё более новой фишечкой многоплатформенности, подсадив на себя банковские структуры. И теперь эту джаву оттуда не выбить никак с таким багажом Легаси, но работающим относительно надёжно. Это и понятно, в таком бизнесе ради нового функционала никто рисковать не будет. Что-то менять там можно только через "деньги". Имеется в виду, когда выгода будет доказана и являтся ощутимой.
Не поверите, но знаю несколько банков из Топ-10 где джаву и близко не подпускают к mission-critical части - ядру АБС (а это самая критичная по скорости и устойчивости часть банка, где времена простоя/недоступности исчисляются минутами, жестко регламентированы регулятором и строго мониторятся).
И делается это не из нелюбви к джаве, а от того, что она проигрывает в эффективности (как по скорости, так и по потреблению ресурсов) специализированным языкам для коммерческих расчетов Тем, где нативно поддерживаются типы с фиксированной точкой (в том числе арифметика с ними типа "присвоение с округлением"), работа с датами во всевозможных форматах (например, одной строкой преобразовать число, представляющее дату в формате *CYMD в строку, представляющую дату в формате *ISO или *EUR). Где нет дикого динамического выделения-освобождения памяти на каждый чих. Где есть втреоненные средства работы с БД без SQL (и плюс к тому есть возможность встраивать SQL выражения непосредственно в код).
И все это появилось и развивалось с тех пор, когда создатели джавы были блеском в глазах из родителей.
Исключения известны и как бы даже логичны, никто и не говорил, что джава - лучший язык. При этом я как раз согласен и с замечаниями по скорости, и с потреблением, но оно и понятно, кроссплатформенность и поднятие JVM как бы изначально намекают на некую унификацию, которая неоптимальна в узких местах.
Но широта применения для всех остальных огромна и это не похоронить ни в ближашие 5 лет, ни в течении 10 лет.
Эффект джавы как раз в том, что сложнее и не надо, сели гребцы после полугодовых курсов и гребут джунами и мидлами без особой оптимизации памяти, без указателей и без желания копать "в железо". Вайтишникам другого и не надо, а бизнес ещё и на старом поживёт.
Миллионы леммингов не пересядут на "заточенное под написание компиляторов и сетевого ПО".
П.С. вы посмотрите ютуберские курсы, что не курс, то - "не надо "высшку" получать, я вас научу на практике как надо программировать". Фундаментальные знания не в приоритете, а без них редко кто влетает в "нелюбовь к джаве". И это очень печально!
Я полностью согласен. Прежде всего с тем, что для узкоспецифических задач (а коммерческие расчеты так или иначе имеют свою специфику) столь универсальное средство как Java не очень пригодно. Тем более, что есть специальные инструменты, оптимизированные именно под это класс задач. И тут уже нужна некоторая широта взглядов и умение использовать разные инструменты под разные задачи. У нас, к примеру (платформа IBM i), постоянно используется как минимум три языка - CL там, где требуется много манипуляций с системными объектами, RPG для реализации бизнеслогики и С/С++ для реализации низкоуровневых функций. Благо, на платформе есть "концепция ILE - Integrated Language Environment", позволяющая собирать модули на разных языках в один программный объект (например, из кода на RPG вызывать функции, написанные на С/С++, реализующие какие-то низкоуровневые операции). И это удобно и эффективно.
И опять же согласен, что найти хорошего разработчика под такие инструменты сложнее - "вайтишники" считают что "это не даст мне релевантного экспириенса и оно мне не надо". Ну действительно, для человека, основной целью которого является прыгать с проекта на проект с основной целью чтобы на следующем месте работы платили хоть чуть больше (при тех же, а лучше меньших, трудозатратах) чем на предыдущем, все это неинтересно - развиваться в рамках одной тематики временами бывает скучно.
И снова согласен, что такие вещи как С, Java уже настолько "набрали обороты" что похоронить их не получится. Да и не надо - они доказали свою применимость для решения широкого круга задач.
Вообще то ООП в Borland'овских Pascal был начиная с Turbo Pascal 5.5 ещё под DOS.
Насчёт легаси и java это было правда лет 5 назад. Сейчас я в основном вижу вакансии в стильномолодежных проектах с CI/CD и микросеврисами.
Ну и старые легаси-монолиты переводят на микросервисы.
Возможно, но вы смотрите только регионально. Мы же говорим о взлёте языка, а там на мировых "затворках" пока поиск джавистов живее всех живых. Легаси ещё на Делфи существует, но вайтишники уже не пополняют ряды, поэтому и дефицит на программеров тут никуда не делся.
Мне не совсем понятно почему вы решили микросервисы ставить против Джавы, да и в общем, разговор не только про неё, мне так C# более по душе. И волна перехода на микросервисы уже не так сильно набирает обороты, не всё так радужно оказалось с ними. Но где тут затесаться новому ЯП-у?
Касаемо ООП в ТП, то Делфи бы не взлетел, если так прекрасно было бы с ООП у Паскакаля. Да, какие-то фичи были реализованы, но не полностью вся концепция, да и на 7.0-версии ничего толком не поменялось, после которой "ждун" скончался. Это я вам из личного опыта озвучиваю, а не по рассказам. Я прекрасно помню DOS, тогда "окна" были лишь графической оболочкой до 95-й версии. Но тогда пользователи были другого покроя и каждый второй лично редактировал config.sys и autoexec.bat, чтобы память освободить. Сейчас тренда изучения языков программирования низкого уровня я не вижу. За счёт чего должны слететь монстры высокого уровня - непонятно.
Сейчас тренда изучения языков программирования низкого уровня я не вижу.
А он есть. Даже Ассемблер в десятке Тиобе
Нет такого одного единственного Ассемблера. Изучение было и раньше, но тренд где?
Ну и Тиобе, такое себе... может на SO посмотреть или на PyPL?
Нет такого одного единственного Ассемблера.
Более того, сейчас работаю на платформе, где ассемблер вообще недоступен разработчику (только разработчикам самой системы, но этот уровень закрыт для обычных пользователей). Есть т.н. Machine Instructions (MI), но это более высокий уровень, да и сейчас и их прикрыли (убрали компилятор MI, оставили только обертки на С для некоторых MI).
Ну и если говорить о шкале соотношения скорости разработки и эффективности программы, то на одном краю окажется ассемблер (минимальная скорость, максимальная эффективность), на другой - использование различных "универсальных фреймворков с высокой степенью интеграции" - скорость разработки максимальная, эффективность минимальная за счет неизбежного в силу универсальности "на все случаи жизни" оверкода внутри фреймворка.
Легаси ещё на Делфи существует, но вайтишники уже не пополняют ряды, поэтому и дефицит на программеров тут никуда не делся.
Вайтишники все ломятся туда, где меньшими усилиями получается наиболее быстрый результат. Т.е. на "другой край" вышеупомянутой шкалы, где можно выучить пару-тройку фреймворков и быстро начать "рубить бабло" (большинство из них идет "вайти" именно за баблом).
Читаешь бесчисленные истории вайтишников - сплошь веб, мобильная разработка, фреймворки. Никто не идет в embedded, hft, промавтоматизацию и т.п. Из личных знакомых перед глазами только один случай, когда человек с нуля (первая работа после института, специальность техническая, но не IT) пришел к нам в разработку на IBM i и его зацепило - за пару лет стал ведущим разработчиком.
Ну и когда я "вайтишел" (конец 80-х - начало 90-х) никакого веба и мобильной разработки не было. Фреймворков тоже. Да и денег таких не крутилось тут. И шли те, кому это реально было интересно и цепляло. Несмотря на отсутствие фреймворков, документации толковой и т.п. Совсем другая мотивация была. Соответственно, другие взгляды на все это и другие подходы. Своего рода "романтики от IT".
SpiderEkb , я это в общем и имел в виду, как говорится, ГППС. Романтики с начала 90-х к концу 90-х хлебнули даже снижение оценки своего труда, админы многие теряли работы, пытались пробиться в программеры и т.д. Это сейчас ребрендинг под девопсов поднимает оценку их труда.
Но меня больше всего волнует, что многие считают, что айтишники - это прямо какие-то великие стратеги, поэтому достойны огромной оплаты. Давайте скажем честно, в это время многим из АйТи повезло, что попали в струю. Но и этим приходится расплачиваться, когда движуха с оплатой привлекает остальной люд. И мы даже не можем их винить за это. Се ля ви!
Для такого провокационного названия статья слишком уж пустая.
Я совершенно не понял, что за харэ, на кой чёрт оно нужно и почему оно должно заменить си, а не паскаль, например?
Крошка сын к отцу пришел, и спросила кроха: - Что такое хорошо и что такое плохо?
Каким должен быть хороший язык? Возможно ли, что везение зависит не только от стратегических ошибок, а, например, еще и от парадигмы, ниши, екосистемы?
Каким должен быть хороший язык?
Да Вы правы, "хороший" - это больше из области вкусовщины. Кому-то нравится функциональный подход, кому-то - императивный. Кто-то любит циклы, кто-то рекурсии. И т.д. В этих ваших интернетах только и споры об этом.
По моему скромному мнению, новый ЯП, претендующий на статус "хорошего", обязательно должен впитать в себя все сильные стороны других ЯП, учитывать их опыт, и по максимуму нивелировать выявленные недостатки. Хочешь ручную работу памяти - пожалуйста; хочешь сборщик мусора - тоже. Хочешь строгих типов - используй. Хочешь сейчас писать без типов - пожалуйста. Не мешать опытному программисту писать потенциально опасный системный код, но помогать неопытному (и опытному тоже) не допускать типовых и серьезных ошибок.
Хороший ЯП не должен иметь конструкций или предъявлять каких-то требований, от которых большая часть программистов будет страдать. Не должно быть перекоса в какую-то одну область или парадигму. Синтаксис языка не должен сильно отличаться от мейнстрима и вызывать боль.
Новый современный ЯП должен быть универсальным: позволять писать как драйвера и компоненты ОС, так и простые сценарии для веб-страниц, компьютерных игр.
И это лишь малая часть требований к хорошему языку. Но как я уже сказал ранее: термин "хороший" сильно завязан на вкусы.
Есть еще требование, такой язык должен существовать
Кроме отсутствия контроля типов, в D вышеперечисленное есть.
С таким языком можно грабить "корованы".
Хочешь строгих типов — используй. Хочешь сейчас писать без типов — пожалуйста.
Не существует такой ситуации, когда имеет смысл писать без типов. И да, gradual typing на практике немного не работает.
Хороший язык должен иметь прозрачную логику. В этом плане "базовые" языки ещё никто "нормально " не переплюнул. А новые языки должны ещё уметь компилировать базовые языки + иметь поддержку бизнеса, иначе не взлетает.
Ассемблер - лучший язык. Но больше НИКОГДА не хочу на нем ничего писать )))
Нельзя , тогда получиться диалект Паскаля :-) :-) :-)
А какая стратегическая ошибка у D (на исправление которой создатели тратят годы)?
Так-то я вижу разве что "неверный таргетинг" (user-friendly С++ оказался не очень нужен), но тут проще этого выбросить и нового заделать, а не накромождать кучу костылей многолентим переделыванием.
Ну еще:
чехарда с версиями языка когда синтаксис по чуть-чуть постоянно меняется
ломающий переход D1->D2 с абсолютно новой стандартной библиотекой
не всем понравился Dub
плохенько с IDE
Но в целом, BetterC + ImportC это киллер фича для обновления С-программ и почти ничего не надо переписывать.
В основу языка положена идея ручного управления памятью и статическая типизация.
Но зачем, нам уже показали что борроу-чекер может заниматься выделением памяти автоматически одновременно защищая от любых ошибок с этим связанных?
Не автоматически, а очень-очень вручную и все время бьет линейкой по пальцам =)
Не автоматически, а очень-очень вручную
Вероятно ваше определение АУП отличается от общепринятого.
и все время бьет линейкой по пальцам =)
Новичкам в программировании все время что-то бьет по пальцам, это нормальный процесс обучения.
Строго говоря, borrow checker вообще не является инструментом выделения памяти, а всего лишь контроля.
И опять вы ошибаетесь.
BC — это и есть механизм автоматического управления памятью в Rust, который эволюционировал из "всего лишь контроля" в версии 1.0
Советую читать историю и делать фактчекинг, прежде чем утверждать что-то громкое, гугл в этом неплохо помогает, например по первым же трем ссылкам из запроса "borrow checker automatic memory management" выдаются неплохие статьи:
https://steveklabnik.com/writing/borrow-checking-escape-analysis-and-the-generational-hypothesis
https://blog.logrocket.com/introducing-the-rust-borrow-checker/
Я в курсе этой оскопленной примитивной механики. Спорить с сектантами смысла не вижу.
Выделением памяти занимается аллокатор, а не борроу чекер. Не видите разницы между выделением и управлением?
Перепутали кому отвечать? Да и в целом, все равно все понимают, какой смысл в том что вы тут надушнили, теперь проветривать придется (
Современные программисты игнорируют аллокаторы памяти, считая их какой-то жутко низкоуровневой штукой, в которую вообще не нужно лезть. При этом кастомные аллокаторы упрощают ручное управление памятью и дают больше контроля. Я не представляю себе альтернативу Си без возможности хотя бы контекстный аллокатор выставить.
функциональной точки зрения язык сильно напоминает Си, но значительно проще.
Мне до сих пор казалось, что описание языка Си Эндрю Таненбаумом на 12 страницах самое крутое.
У Оберона краткое описание языка одну страницу вообще занимает. Правда полное больше , чем у Си, целых 20.
Но язык, котороый он описывал, и для которого описание достаточно и корректно, уже лет 30 компилировать нечем.
Для реального современного Си надо указать еще сравнимый объем случаев, которые с буквоедской точностью надо помнить, чтобы довольно простой и очевидный код не превратился в тыкву при компиляции. Да, это не плюсы, но и этих граблей хватает чтобы считать Си чуть ли не вредным и точно крайне сложным языком.
Конечно, хотелось бы узнать, как мог бы выглядеть язык программирования ++C. Или C--. Или --C...
Начать новый язык следовало бы с концепции. Или прямиком с основной идеи. Например, LISP. А давайте сделаем так, чтобы каждый объект был списком! (Сейчас, разумеется, следовало бы создавать язык программирования GRAPH, где каждый объект является графом или сетью.)
Что еще за Hare
Это — системный язык программирования, заточенный под написание компиляторов и сетевого ПО.
Почему именно такое смешение? Если пишется под создание компиляторов, то, наверное, должны быть одни языковые средства, а если под создание сетевого ПО, то — другие средства.
И, вообще, раньше языки появлялись при решении конкретных задач. Было бы здорово однажды увидеть: мы взяли такую-то задачу, помучились при её решении, используя традиционные средства, и предложили новый подход, который преодолевает недостатки предыдущих решений.
Конечно, хотелось бы узнать, как мог бы выглядеть язык программирования ++C. Или C--. Или --C...
Вот вы, наверно, пошутить хотели. А был такой язык C--, потом он в Haskell уехал.
Начать новый язык следовало бы с концепции. Или прямиком с основной идеи.
А это точно подмечено. Из статьи так и непонятно в чём основные фишки Hare, ради которых его задумали.
Я помню другой C--, компилятор под MS-DOS который собирал на удивление компактные исполняемые модули, не exe, а com. Скомпилированный резидентный драйвер клавиатуры написанный на C-- весил меньше 256 байт. Давно это было. До 1997 года.
Вероятно, это был Sphinx C--
Сперва убийцей был назван D.
Версия продержалась недолго и назван был D2.
Потом подозрения пали на Haxe.
Следующим кандидатом стал Nim.
У Go было алиби и его исключили из подозрения.
Наконец большинство начало склонятся в сторону Rust.
С появлением Zig мнения разделились.
Казалось бы зачем нужен убийца убийцы, но Hare уже не остановить.
В итоге все "убийцы Си" в итоге проигрывают на tiobe "мёртвому" Delphi :-)
Haxe? Подозрения могли возникнуть разве что у смузи программистов по отзывам из твиттера. Достаточно написать 100 строк кода на этом языке и скомпилировать под разные платформы, чтобы понять что этот язык вообще один маркетинговый буллшит.
А что не так с Haxe?
Примерно всё.
Хорошая задумка — транслировать код и алгоритмы, написанный один раз на десяток других языков, но просто адски кошмарная реализация. Чтения результатов этой трансляции хватило, чтобы понять что не взлетело и уже не взлетит. В python, например, эта штука транслируется в кошмарно качества код с глобальными переменным (!). PHP и Java-бекенды аналогично.
Нормального интеропа по этой причине не будет, а стандартной библиотеки не хватает, хотя бы через фасады и адаптеры. Придется писать нужные библиотеки самому, то есть значит что не придется — возьмут другой язык.
Очень куцые возможности самого программирования из-за помешательства на одной-единственной парадигме — ООП через классы выдержки Java 5 и ActionScript, которым, по сути, Haxe и является. Очень не вкусно. И ладно бы только это — так эта единственная парадигма не помогла наверстать упущенное в том, что я перечислил выше. Ощущение от программирования, будто на дворе 1999-й, и ты сейчас своим Haxe накажешь соперников с Java 1 и Delphi.
Комьюнити маленькое и заточено на написание игрушек. Всё. Собственно, всё развитие языка и экосистемы крутится вокруг пары фреймворков для геймдева.
Очень пытался его полюбить и надеялся, что с его помощью уж напишу один раз либу по музыкальной теории под всё языки. Не вышло. То что получалось на выходе невозможно было использовать. Пришлось писать нативно несколько раз под каждый язык. В моём случае это были Python и JS.
Стоило бы разделить на "убийц" С и "убийц" С++
Еще для полноты картины стоит добавить V
Не может претендовать на роль убийцы тот о котором нет сведений в Википедии.
Ну, тогда добавьте Crystal )
Интересно. Не слышал о таком.
На нём ещё не написали движок JS ?:)
Не знаю, речь ведь про убийц C++, а не про убийц JS xD
На Хабре давно ещё анонс был: https://habr.com/ru/post/328364/
И язык всё ещё активно развивается, причём уже в стабильной версии.
Это я с отсылкой к https://habr.com/ru/news/t/676102/
Сегодня каждый уважающий себя «убийца» должен написать движок JS.
Мне кажется haxe никогда не позиционировался как убийца C.
Можно исправить :) Что поставить вместо него ?
Широкий выбор) Например: C2, C3, C∀, Jai, Rio, V, Vale ну и другие.
Haxe вроде убийцей С ни когда не был. Он точно целился (успешно) в ActionScript. Но тут назло тот сдох сам по себе.
Я общался раз с игроделом, который хвалил Haxe: типа, на клиенте в один язык компилится (наверное, как раз ActionScript), а на сервере - в C#.
В общем, в качестве замены Си подойдёт любой относительно новый новый язык без стандарта и с неопределённым поведением.
Самый унылый язык из всех "альтернатив C или C++". Из новшеств только какая-то синтаксическая чепуха про массивы.
В кач-ве альтернативы Си нравится Zig. Он достаточно компактный, разработчики не пытаются впихнуть в него всё подряд, но, при этом, он имеет всё необходимое для современной разработки. И над скоростью компиляции автор заморачивается - https://vimeo.com/491488902
Ну, прикольно, интересно. Правда, зачем нужен Hare, если уже есть Rust?
Честно пытался освоить Rust, прочитал rust-book, выполнил все задания, потом наткнулся на статью как читать rust-book в правильном порядке, прочитал еще раз в правильном порядке. Потом отвлекся на месяц и все забыл ((( Основной язык сейчас python, много писал на C++, С#... Знакомился с java, kotlin, f#. Хочется иметь в своем арсенале компилируемый язык со статической типизацией, чтобы оптимизировать те 5% кода, которые выполняются 95% времени.
Rust - замена не Си, а, скорее, С++. Для Си Rust слишком сложный.
Rust и близко к C++ не стоял. Многие свойства C++ в Rust просто не реализуемы. Казалось бы очевидный факт и спорить бессмысленно. Начиная с автоматического преобразования типов.
Вообще для меня все языки разделяются на "нежизнеспособные" по типу Паскаля, где средствами самого языка невозможно реализовать функцию "WriteLine", и "жизнеспособные" вроде C/C++, где printf/std::cout реализованы средствами самого языка, а не компиляторной магией.
Так вот в Rust -- компиляторная магия. Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/* compiler builtin*/". Из чего понимаешь, что сам так -- не сделаешь.
К слову в C/C++ компиляторная магия в единичных местах. В голом C наверное и не скажешь где, не знаю. В C++ очевидными местами являются std::array и std::initializer_list (невозможно сделать собственные такие классы с другими именами). Есть какое-то третье место, но я не помню. Но это отнюдь не функция уровня printf, а какой-то очень базовый примитив.
Начиная с автоматического преобразования типов.
Еще goto нормального нет!
Вообще для меня все языки разделяются на "нежизнеспособные" по типу Паскаля, где средствами самого языка невозможно реализовать функцию "WriteLine", и "жизнеспособные" вроде C/C++, где printf/std::cout реализованы средствами самого языка, а не компиляторной магией.
Так вот в Rust -- компиляторная магия.
https://os.phil-opp.com/vga-text-mode/
Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/* compiler builtin*/". Из чего понимаешь, что сам так -- не сделаешь.
https://github.com/rust-lang/rust/blob/master/library/std/src/io/stdio.rs#L995
Макросы нужны для того, чтобы можно было print отдавать любое количество аргументов и делать другие полезные штуки, вроде именованных аргументов.
А какая магия в std::array? Там простой класс с массивом внутри.
Может имелось ввиду std::type_info ?
Компиляторной магии в основном можно найти в type_traits и там это вполне обосновано.
На самом деле и в type_traits значительная часть (а может и все - не проверял) шаблонов реализованы средствами языка
Например?
Нашел в доках LLVM: https://clang.llvm.org/docs/LanguageExtensions.html#type-trait-primitives
Хотя вот "чувство языка" подсказывает, что еще до С++ 11 часть этих проверок реализовывали разными языковыми хаками. Какой-нибудь __is_same к примеру
Многие свойства C++ в Rust просто не реализуемы
Например, самоломающийся (пре переносе между платформами) код, если в описании структур использовать обычные типы вместо тех, что с фиксированной размерностью.
На днях у нас так сломался минипарсер WAV-заголовков — всё время запускали под Windows, а потом понадобилось под Linux погонять. Долго искали, что же там могло отвалиться, а это оказался unsigned long, который в Windows 4 байта, а в Linux — 8.
Зато C/C++ переносимый, а самое главное — стандартизованный да.
Справедливости ради, в Си типы вроде int32_t называют переносимыми, и наоборот всякие unsigned long — непереносимыми.
Ну и int32_t всё же вторичный для C тип, потому что он объявлен как typedef над int, а не наоборот.
Так вот в Rust — компиляторная магия. Они говорят, мол у них макросы, на которых можно сделать что угодно. Но зарывшись в дебри поглубже видишь там "/ compiler builtin/". Из чего понимаешь, что сам так — не сделаешь.
Если говорить конкретно о println!, то в виде "compiler builtin" оно реализовано потому, что к версии 1.0 макросы ещё не были стабилизированы. Сейчас аналог можно написать самому.
А что плохого в компиляторной магии? На худой конец есть кодогенерация - там любой каприз за ваши деньги время. Сборочные скрипты все равно на других языках пишутся
Мне кажется, что rust проще, чем си. Как минимум не нужно думать про управление памятью, а про разыменовывание указателей думать надо только в unsafe блоках. Плюс отсутствие UB. После rust писать на си уже не очень хочется, единственная его проблема - раздутый рантайм, но она существенна только для неприкладного кода. Кресты для меня - это вообще страшный сон, о котором не хочется вспоминать.
Про какой рантайм идёт речь? Про опциональную раскрутку стека?
Я не особо подробно вдавался в вопрос, но когда последний раз писал на расте приложение под UEFI, у меня возникла проблема с core::fmt. Из-за него бинарник выходил достаточно жирным, поэтому пришлось от него отказаться и использовать для вывода встроенные в UEFI функции. Надо будет попробовать использовать ufmt. Есть ещё целый репозиторий, посвящённый уменьшению бинарников на расте.
Пример меня огорчил.
Разве то, что в данном приложении функция выбрана точкой входа, является свойством функции? Ладно, думать сейчас не те времена чтобы. Но одновременно export, предполагающий использование функции где-то там далеко, и фиксированное имя для точки входа - это режет глаз.
Разве любая коллекция не должна уметь выполнять функцию для каждого своего элемента?
Может и взлетит, и тогда это будет, как писала Сэй Сёнагон, очень печально.
Шило на мыло заменили? Я, честно говоря, смысла в этом не вижу
Название нового ЯП говорит само за себя. Хватит уже плодить новые ЯП, научитесь использовать существующие.
Просто это уже стало самовыражением. Вы же не можете запретить художнику писать пейзаж Елисейских полей только потому, что таких картин уже тысячи. При этом покупать его картины вы тоже не обязаны.
Не совсем корректный пример. ЯП - это инструмент програмиста, продуктом же является код, программа. Картина(не зависимо от сюжета) - это продукт, инструментом же являются руки, кисти и краски, карандаши, мелки, палец обмокнутый в ... Но хороший художник и пальцем обмокнутым в ... нарисует такой пейзаж Елисейских полей что закачаешься.
ИМХО дело не в кисточке а в том кто её держит. Верно и для ЯПов. Можно бесконечно искать(изобретать) чудесный ЯП а можно просто еbashit'ь такие штуки как piu-piu )
Такое ощущение, что авторы решили сделать урезанный Rust.
Как-то слишком мало примеров кода привели.
Взлетит или нет — сможет ли новый язык программирования Hare стать альтернативой Си