LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на Crates.io.

Стабилизация libcore

Самым большим нововведением в 1.6 является стабилизация libcore. Стандартная библиотека Rust состоит из двух уровней: небольшая базовая библиотека libcore и полная стандартная библиотека libstd, которая построена на основе libcore. libcore является полностью платформонезависимой, и требует только горстку внешних функций. libstd строится на основе libcore, добавляя поддержку выделения памяти, операций ввода-вывода и параллелизма. При использовании Rust во встраиваемых средах и при написании операционных систем, разработчики часто избегают libstd, используя только libcore.

Стабилизация libcore являтся важным шагом к возможности писать самое низкоуровневое ПО, используя стабильный Rust. Это позволит развиваться экосистеме библиотек вокруг libcore, но приложения пока полностью не поддерживаются. Ожидайте изменения в этой области в будущих релизах.

Стабилизации библиотеки

Около 30 библиотечных функций и методов теперь являются стабильными в 1.6. Заметные улучшения включают в себя:

  • Семейство функций drain() для коллекций. Эти методы позволяют перемещать элементы из коллекций, сохраняя память, в которой они размещены, тем самым снижая выделение памяти в некоторых ситуациях.
  • Ряд реализаций типажа From для конвертирования между типами стандартной библиотеки, в основном между целочисленными типами и числами с плавающей точкой.
  • Наконец, Vec::extend_from_slice(), ранее известный как push_all(). Этот метод существенно быстрее, чем более общий метод extend().

Crates.io запрещает использование масок в версиях зависимостей

Если вы являетесь мейнтейнером контейнера на Crates.io, возможно вы видели следующее предупреждение:

новые контейнеры более не могут использовать маски при описании зависимостей.

Другими словами, это запрещено:

[dependencies]
regex = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

Использование маски означает, что вы можете работать с любой возможной версией зависимости. Скорее всего это не так, и может являться причиной ненужных проблем в экосистеме. Прошло достаточно времени с момента появления этого предупреждения, теперь пришло время превратить его в ошибку.

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)
Ответ на: комментарий от eao197

В Java такого не было, там рулили трюки с рефлекшеном.

Так может тут тоже наоборот? В джаве есть рефлекшн - нет нужны в «трюках» с иклюдами.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Для этого в Лиспах и есть возможность дёргать GC, скажем, каждые t секунд :-)

Математически смысла в этом никакого. Для отладки разве или еще каких инструментальных вещей. А так, он и так дергается каждые t секунд. Для более точного управления нужно знать текущую статистику аллокации. Некоторые рантаймы позволяют прикладному коду вмешиваться в этот процесс. Но большинство — нет.

anonymous
()
Ответ на: комментарий от Oxdeadbeef

То есть, не пруфа. Ок.

А вы здесь прям одоказывались и подкрепили каждое свое слово ссылкой на десяток авторитетных источников. На Great Language Shootout Game загляните, если совсем ничего не умеете.

Написал ли ты большое приложение на Haskell используя эти прелестные инструменты опять же на Haskell, чтобы мнение не было голословным?

Примечательно, что из всего списка вы решили доколупаться именно к Haskell-ю. Ok.

Сам я ничего большого ни на Haskell-е, ни на Scala, ни на C#, ни на Java 8 не писал. Можно ли по этому факту судить об отсутствии подобных разработок на этих языках?

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Понт защитан %)

Благодарю :)

//Психиатр

anonymous
()
Ответ на: комментарий от DarkEld3r

В джаве есть рефлекшн - нет нужны в «трюках» с иклюдами.

Есть, если есть необходимость работать с external DSL.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Я делаю софт не для того, чтобы им или мной восхищались

Речь идет не о восхищении. А об удивительной способности обосрать результаты чужого труда, даже не удосужившись ознакомиться с этими результатами. Что вы и продемонстрировали заявив о говняных библиотеках.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Ответ очевиден - Линус мастер по C :-) Не нужны ему ни цепепи, ни лиспы :-)

Тем не менее, С++ у него в репе имеется.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Точно так же, хватало противников, скажем, лямбд в плюсах - мнол жили и без них неплохо.

Никогда не понимал такого аргумента по поводу лямд. Без них как-то жили, пока STL с функторами не была доступна. Как только пришлось наследоваться от unary_function или binary_function, так сразу отсутствие лямбд сказалось.

Ну и, повторюсь, речь не о том, что задач для метапрограммирования нет. Речь о том, что их количество преувеличивается, имхо.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

На Great Language Shootout Game загляните

Это все игрушки на локалхосте.

вы решили доколупаться именно к Haskell

потому что комьюнити не сравнимо с Scala, C#, и Java 8 — маргинальщина как и лисп.

Можно ли по этому факту судить об отсутствии подобных разработок на этих языках?

они конечно есть, только почему то вы решили, что на лиспе их нет или они хуже.

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

Действительно, туда наконец добавили const и void. Ах да, это было в 89-м...

А С99 и С11? Тут ведь кто-то любит размером стандарта мериться - так вот он растёт.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Это все игрушки на локалхосте.

Да, бл*, по сравнению с этим результаты замеров Clasp-а — это что-то запредельно объективное. Причем, что забавно, эти замеры здесь отнюдь не лисперы упомянули.

потому что комьюнити не сравнимо с Scala, C#, и Java 8 — маргинальщина как и лисп.

Не льстите себе. Haskell уже давно намного ближе к мейнстриму, чем Lisp.

eao197 ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Ну уж прям никакой пользы нет: кто-то узнает о альтернативах не уступающих (и даже лучших чем) C++.

С первой частью соглашусь - узнать о лиспе и поковырять его будет весьма полезно для новичков. Хотя и сомневаюсь, что люди, не слышавшие о лиспе, доберутся до 14 страницы этой темы.

А вот со второй частью ты сильно лукавишь. На С++ давно не пишут «всё подряд» и, как правило, это осознанное решение. Очень сомневаюсь, что для таких проектов лисп хорошо подошёл бы.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

Что мешает управлять GC в определенных точках выполнения вручную, если очень надо?

Так ведь, если это надо «везде», то мы теряем преимущества автоматизации. Не говоря уже о том, что с GC приходится наоборот бороться.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

А вот как реализовать stagging для нативных языков вроде C++... Понятия не имею.

В расте есть, так называемые, «плагины для компилятора» - это как раз возможно исполнять произвольный код на этапе компиляции. Правда они пока нестабильные, но штука весьма мощная, так что уже активно используется, ну и работа над стабилизацией как раз идёт.

А не SO-ка, подгружаемая компилятором и работающая у компилятора внутрях.

Может я чего-то не понимаю, но не вижу каких-то особых сложностей. Библиотека, точно так же, может иметь свои тесты, изначально ведь речь о них шла.

Хотя, наверное, какие-то сложности будут, но новые фичи «просто» требуют новых инструментов. Вон в теме кто-то ссылался на Metashell - эта штука ведь тоже возникла в ответ на сложности с шаблонами. И раз уж тут столько раз на лисп ссылались, то там инструменты для разворачивания макросов из коробки имеются.

С другой стороны, есть у тебя генератор в виде (стороннего) приложения есть и в нём что-то не устраивает, то бороться с этим будет ничуть не проще. Особенно если исходников нет.

DarkEld3r ★★★★★
()
Ответ на: комментарий от Oxdeadbeef

С++ используют, когда:

  • Задача хорошо вписывается в систему типов языка. Например, выигрывает от момноморфных генериков.
  • Когда нужен детерминированный механизм управления разнородными ресурсами.
  • Когда необходим специфический механизм работы с памятью.
  • Когда нужен максимально тонкий контроль кодогенерации — для достижения наивысшей эффективности времи выполнения.
  • Когда нужно использовать какой-то специфический набор библиотек, существующих только для C++.
  • Когда С++ — основной и уже хорошо знакомый инструмент.

В нагрузку получают весь набор сложностей языка и платформы в целом, с которой (сложностью) придется бадаться. Если ничего из вышеобозначенного не нужно, то зачем связываться с С++? Есть другие языки, куда более удачные как языки общего назначения для повседневного использования.

//Психиатр

anonymous
()
Ответ на: комментарий от anonymous

Это уже сейчас видно в обсуждениях фич, что они вынуждены реализовывать то, что изначально не планировалось.

Это как раз нормально и много где они закладывались на расширение. Хуже то, что кое-где они, хоть и понимали, что придётся дополнять/переделывать, но всё равно «поторопились». Хотя, наверное, без этого никак. Иначе 1.0 пришлось бы ещё пару лет ждать.

Так что ждем Rust2, в котором, как в D2, учтут ошибки Rust :)

Нее, как D2 точно не надо. Лучше как С++11. (:

Ну и вопрос, собственно, в том насколько много костылей подставлять придётся и насколько они будут кривыми. Пока что меня сильно смущает разве что откладывание HKT надолго, ну и «временные решения» для обработки ошибок.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Лучше как С++11. (:

Два чая тебе, умный человек! :)

Пока что меня сильно смущает разве что откладывание HKT надолго, ну и «временные решения» для обработки ошибок.

О чем речь?

anonymous
()
Ответ на: комментарий от eao197

Есть, если есть необходимость работать с external DSL.

В смысле? В джаве разве рефлексия не работает с внешним кодом? Или о чём речь?

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

В смысле? В джаве разве рефлексия не работает с внешним кодом? Или о чём речь?

В смысле, что ты написал, например, описание грамматики для ANTLR, получил файлик с external DSL, из которого тебе нужно получить набор Java-классов для компиляции в составе своего проекта. Тебе результат преобразования external DSL нужен во время компиляции, а не в run-time.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Математически смысла в этом никакого. Для отладки разве или еще каких инструментальных вещей.

Это ты так думаешь :-)

А так, он и так дергается каждые t секунд.

Эти t секунд определяются рантаймом по многим факторам - в зависимости от стратегии GC :-) За эти t секунд мусора может сгенерироваться разное количество и стратегия рантайма не всегда будет оптимальной для всех случаев :-)

Для более точного управления нужно знать текущую статистику аллокации. Некоторые рантаймы позволяют прикладному коду вмешиваться в этот процесс. Но большинство — нет.

Если интересно, то вот про ручное дёрганье GC в SBCL с практической т.з. - https://habrahabr.ru/post/262225/ :-)

anonymous
()
Ответ на: комментарий от eao197

Никогда не понимал такого аргумента по поводу лямд.

Ну просто многие люди «реально не понимали» нафига они не нужны, пока не попробовали. Причём есть ретрограды, которые и сейчас скажут, что пользы нет.

Речь о том, что их количество преувеличивается, имхо.

Не спорю. Возможно, но подозреваю, что многое в бусте можно было короче/удобнее/быстрее написать, если бы метапрограммирование было бы удобнее. Понятное дело, что «конечного пользователя библиотек» это не особо затронет, но удобнее писать библиотеки = больше их количество и качество.

Опять же, хватает пуристов, которым Qt не нравится из-за мока. Да, идут подвижки по замене его на «новые возможности», но метапрограммирование и тут помогло бы.

Кстати, насчёт «преувеличения количества» - разве много народу жалуется, что нужных возможностей нет? По моему, это больше делают тролли (ну с ними понятно) и «лисперы». Так вот, возможно, последние как раз успели оценить удобство?

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Если интересно, то вот про ручное дёрганье GC в SBCL с практической т.з. - https://habrahabr.ru/post/262225/ :-)

Ну ладно, убедил. Кому-то это помогло. После того, как размер кучи выставили в 10 раз больше рабочего множества. Совсем не тот случай, на который алгоритмы управления GC затачиваются)))

//Психиатр

anonymous
()
Ответ на: комментарий от eao197

Речь идет не о восхищении. А об удивительной способности обосрать результаты чужого труда, даже не удосужившись ознакомиться с этими результатами. Что вы и продемонстрировали заявив о говняных библиотеках.

Насчёт говняных библиотек - это чисто субъективно :-) Я же не могу перебрать тысячи библиотек, чтобы в споре с Женей выкатить ему список говняных и список достойных библиотек :-) Но моя практика показывает, что распиаренные библиотеки, в частности, на том же C++, оставляют в плане кол-ва глюков на мегабайт исходников желать многим лучшего :-) Я могу назвать распиаренные либы на том же цепепе, с которыми работал и задолбался слать их авторам патчи, но не хочу, т.к. в процессе пересылки патчей познакомился с этими людьми и не хочу их позорить :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

Ну раз сомневаешься то не используй, твоё право.

Не надо видеть везде врагов. Тем более, что я тебя, отчасти, понимаю (наверное). Как «сторонник раста», в смысле. Люди, конечно, инертны в своей массе, но надо признавать, что у того же С++ есть вполне объективные преимущества. Даже если это, по твоему мнению, такие «мелочи» как библиотеки, тулзы, готовые специалисты и т.д. Плюс ГЦ далеко не всегда можно объявить «деталью реализации» и закрыть на это глаза.

Ну и если ты видишь пользу в «пропаганде» лиспа, то подумай о том, что явный фанатизм тоже отталкивает.

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

такие «мелочи» как библиотеки

Их тонны на цепепе :-) Но ты посмотри на современные либы цепепе-14 :-) Пишут их кто во что горазд :-) Понятно, что на цепепе можно писать по-разному, но любой код ещё надо и сопровождать :-) А сопровождать тонны библиотек, написанных по-разному (ковыряться в исходниках чужих либ тебе все равно придется, т.к. нет софта без ошибок), искать в них баги, это трата многих месяцев :-) Тебе нравится тратить годы на поиск багов в тонне либ? Мне - нет :-) Чтобы реально красиво писать на Си++, чтобы научиться эффективно с ним работать, с теми самыми либами, чтобы не писать ещё одну унылую и неразберимую лапшу, нужен такой уровень мастерства, которого нужно достигать десятками лет :-) Это тяжёлый язык, с тяжёлым наследием, в его т.н. наворотах пользы меньше, чем проблем :-)

anonymous
()
Ответ на: комментарий от anonymous

Насчёт говняных библиотек - это чисто субъективно

Ну вот и по поводу ваших творений будет точно так же, чисто субъективно. А судя по качеству C-шого кода, который вы на LOR-е демонстрируете, то и объективно.

Кроме того, нет ни одной библиотеки, которая активно используется, активно развивается и в которой нет ошибок. Нигде. Ни для одного языка.

А если качество C++ вас не устраивает, то почему бы не оставить его тем, кого устраивает? Взяли бы свой любимый Lisp, написали бы на нем супер-пупер приложение, заткнув за пояс всех конкурентов и гребли бы деньги лопатой.

eao197 ★★★★★
()
Ответ на: комментарий от DarkEld3r

многое в бусте можно было короче/удобнее/быстрее написать

Boost — это отдельный случай. Цель Boost-а (по крайней мере раньше) — это способствование развитию языка и создание новых вещей для C++.

Инструменты для решения прикладных задач зачастую выглядят не как либы из Boost-а.

Так вот, возможно, последние как раз успели оценить удобство?

Имхо, единственное, что доказал Lisp, так это то, что его могут применять только отдельные личности с определенным стилем мышления. И что Lisp плохо уживается с командной разработкой.

Аналогичную картину можно было увидеть и с недавней историей вокруг Nemerle.

Так что у метапрограммирования есть своя темная сторона.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну вот и по поводу ваших творений будет точно так же, чисто субъективно

Почему будет? :-) Именно так и есть :-)

А судя по качеству C-шого кода, который вы на LOR-е демонстрируете, то и объективно.

Те два жалких куска кода я написал на 15 минут в общей сложности забавы ради :-) Последнее говно trim написал на коленках как попало :-) И то, судя по тестам, эта реализация оказалась быстрее, чем trim из boost :-) Оказалась, оказалась :-)

Кроме того, нет ни одной библиотеки, которая активно используется, активно развивается и в которой нет ошибок. Нигде. Ни для одного языка.

Это точно :-) Но в Лиспе есть REPL :-) За счёт этого, отладка в Лиспе считается дурным тоном :-) Инрементальная разработка способствует тому, что за время написания код отлаживается самим автором поневоле - в REPL, путём экспериментов :-) Можно так писать и в цепепе, и в це, но в Лиспе это из коробки, без лишних телодвижений :-) Сделал изменение в ф-ии - перекомпилил только ф-ю за 0.0001 сек и тестируй дальше :-) Не надо ждать 10 секунд :-) 7 секунд - это то время, за которое человек уже выпадает из т.н. «состояния потока», т.е. отвлекается от workflow :-) Поэтому Лисп - рульнейшая вещь для хакеров, а не для карьеристов программистов :-)

Взяли бы свой любимый Lisp, написали бы на нем супер-пупер приложение, заткнув за пояс всех конкурентов и гребли бы деньги лопатой.

Мне это не надо :-)

anonymous
()
Ответ на: комментарий от DarkEld3r

Не надо видеть везде врагов.

Да нет, я всех люблю, какие враги? 😘😍

Oxdeadbeef ★★★
()
Ответ на: комментарий от anonymous

Инрементальная разработка способствует тому, что за время написания код отлаживается самим автором поневоле - в REPL, путём экспериментов

Детский сад, младшая ясельная группа. Простенький GUI, может, вы так и напишете. После чего посчитаете себя мегакулхацкером и придете на LOR рассказывать, каким говном пользуются C++ники.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Детский сад, младшая ясельная группа.

Ага :-)

Простенький GUI, может, вы так и напишете.

Значит и всё остальное напишу :-)

Детский сад, младшая ясельная группа. Простенький GUI, может, вы так и напишете.

Так я и сам цепепешник, если кто не понял :-)

anonymous
()
Ответ на: комментарий от anonymous

Значит и всё остальное напишу

Когда напишете, тогда и возвращайтесь.

Так я и сам цепепешник

С чего бы? Сами же про себя говорили, что лиспер, но агитируете за C.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Так я и сам цепепешник, если кто не понял :-)

Str *str_init(const char *value)
{
     Str *result = NULL;
     size_t size = 0;
     if (result = malloc(sizeof(Str))) {
          memset(result, 0, sizeof(Str));
          size = strlen(value);
          if (result->value = malloc(size + 1)) {
               result->size = size;
               memset(result->value, 0, size + 1);
               strncpy(result->value, value, size);
          }
     }
     return result;
}

Ага,цепепешник уровня «сделал две лабы, и они даже сконпелировались».

anonymous
()
Ответ на: комментарий от anonymous

О чем речь?

Например, try/catch отсюда. С появлением HKT есть какие-то планы (ну или, по крайней мере, надежды) на dо-нотацию и т.д. Есть опасения, что все эти try/catch станут не особо нужны. Не такая и большая беда, наверное, но «лишняя сущность».

Если ещё про костыли говорить, то мне «не очень понятно» нафига было стабилизировать (простые) макросы не продумав полностью, хотя бы, их импорт/экспорт. Но это, вроде, малой кровью могут починить.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Тебе нравится тратить годы на поиск багов в тонне либ? Мне - нет :-)

Мне тоже нет. Но точно так же, мне не нравится тратить годы на собственноручное написание «тонны либ». Опыт показывает, что зачастую подходящее решение достаточного качества найти можно.

DarkEld3r ★★★★★
()
Ответ на: комментарий от eao197

Boost — это отдельный случай. Цель Boost-а (по крайней мере раньше) — это способствование развитию языка и создание новых вещей для C++.

Так-то да, но я буст на работе использую, например. Для решения «прикладных задач».

Опять же, будь у нас продвинутое метапрограммирование, то для ряда вещей не пришлось бы ждать принятия в стандарт. Вместо этого эффективные реализации могли бы появляться в библиотеках.

Так что у метапрограммирования есть своя темная сторона.

Она у всего есть, особенно, если судить по холиварам на форуме.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Ну вообще-то они делали и делают язык для сервы на замену С++.

Так что ничего не оказалось, все just as planed... почти...

Спонсор заставил их влезть в сишную нишу, чтобы не устранить конкурента своему продукту.

shkolnick-kun ★★★★★
()
Ответ на: комментарий от anonymous

Ага,цепепешник уровня «сделал две лабы, и они даже сконпелировались».

Ну а чем не цепепешный ОО-стиль в этом примере сишного кода? :-) Пара ф-й конструктор/деструктор str_init/str_free, структура Str с членами size и data :-) Конечно, это не конкурент <string> из стандартной либы, но и набросал её я практически не думая за 10 минут :-) И какие у тебя претензии к этому коду? :-) То, что init не на стеке аллоцирует структуру? :-) Так зато я могу эту ф-ю дёрнуть из того же Лиспа, чего не смог бы, если бы не malloc :-) И представь себе, оно заработало с 1-го раза :-) Так что давай, до свидания :-)

anonymous
()
Ответ на: комментарий от Oxdeadbeef

это все не то, нужно как минимум изучить несколько инструментов, IDE, настроить всю эту галиматью, молится чтобы все это сработало и не сломалось по середине. Тогда как в например в CL это делается стандартными языковыми средствами, без привлечения внешних инструментов и сложности.

Ну вот, приехали, сначала ФП-фаги говорят о нужности DSL, теперь о ненужности DSL, когда есть божественный лишп.

Вы определитесь уже нужно или ненужно вам DSL...

shkolnick-kun ★★★★★
()
Ответ на: комментарий от eao197

Как ОЧЕНЬ СУРОВЫЙ имбедщик ответственно заявляю: «Нинужно, потому, что очень сильно усложняет код (увеличивает количество букаф)! А безопасность получается за счет применяемых архитектурных решений, а не за счет языка, один хрен мне придется unsafe во все дыры пихать.»

shkolnick-kun ★★★★★
()
Ответ на: комментарий от shkolnick-kun

Ну вообще-то они делали и делают язык для сервы на замену С++.

На сколько я помню то, что уловил вокруг Rust (я не следи с самого начала), они хотели взять некое прагматичное подмножетсво С++ и добавить афинные типы (т.е. то, что нужно было именно им для servo).

А теперь они вынуждены навешивать на язык всё, что есть в С++, но еще нет в Rust. При этом получается С++ (в плане угрозы разбалансировки абстракций), но с афиинными типами.

Насчет самих афинных типов народ не просто так сомневается в их полезности. Дело в том, что вывод в любой системе типов на основе формальных логик — вещь очень непредсказуемая в плане вычислительной трудоемкости. Т.е. могут существовать такие программы, совсем невинные на вид, которые просто не скопилируются за разумное время. Точно такая же проблема есть и в С++, но там можно более-менее эффективно предсказывать время выполнения метапрограмм, потому что это фсего лишь ФП. Масштабируемый вывод в выразительных логиках может быть только неполным, а это своидт на нет все заявления о гарантиях языка. Т.е. реальной альтернативы «ручной» работе с типами а-ля С++ пока что нет, к сожадению.

Спонсор заставил их влезть в сишную нишу, чтобы не устранить конкурента своему продукту.

Поясни, пожалуйста))

anonymous
()
Ответ на: комментарий от anonymous

Поясни, пожалуйста))

Я поясню: школьник - поклонник теорий заговора. Embedded не проходит бесследно.

anonymous
()
Ответ на: комментарий от anonymous

А теперь они вынуждены навешивать на язык всё, что есть в С++, но еще нет в Rust. При этом получается С++ (в плане угрозы разбалансировки абстракций), но с афиинными типами.

Ну и зря! Получится гуано в духе С++, да еще с изначально трешёвым синтаксисом. То есть код будет не просто сложный, а сложный в квадрате!

shkolnick-kun ★★★★★
()
Ответ на: комментарий от shkolnick-kun

Ой, лишнее слово написал. Должно быть так:

Спонсор заставил их влезть в сишную нишу, чтобы устранить конкурента своему продукту.

shkolnick-kun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.