LINUX.ORG.RU

Rust 1.34

 ,


3

8

Вышел релиз 1.34 языка системного программирования Rust, развиваемого проектом Mozilla.

Ключевое-долгожданное:

  • Начиная с этого выпуска, Cargo может поддерживать альтернативные реестры. (Эти реестры сосуществуют с crates.io, так что вы можете писать программы, которые зависят и от crates.io и от вашего реестра.)
  • Трейты TryFrom и TryInto были стабилизированы для поддержки ошибок при преобразовании типов.

>>> Полный анонс



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Это типа попытка замолчать тот факт, что Си врастает в любое место как говно и его потом задолбаешься выковыривать? Этакий системд среди языков программирования. Чувакам даже пришлось придумывать плюсы, вместо нормального ЯП, просто потому что привязка к си, даже если его отовсюду выкинуть — остаётся.

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

Веселая писанина, жаль что действительности не соответствует =) Вообще-то можно, просто никто не хочет этим заниматься. И в итоге вы получите свой С который мало чем будет отличаться от оригинала, а возможно еще и будет хуже, потому что на один потратили уже пол века, а вы со своим новым С никому нужны не будете. А так конечно можете придумать новые принципы создания железа придумать под них языки программирования уровня С, будет весело, но смысла нуль.

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

Слово эволюция Вам о чём нибудь говорит? Аллах Акбар.

Прозвучало так, будто бы ништяк быть рыбой, крысой, волосатой, с хвостом и человеком одновременно.

Если нравиться шерсть на собственном теле — нет проблем, только не надо называть это чем-то хорошим и единственно-верным.

Что, за годы существования отмёрло из си за ненадобностью? Ничего.

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

Философия Си — говнохранительство до мозга костей. Которое отравляет вокруг себя всё. Говнохранительство без причины и цели.

Лол, порадовала та ересь про «годы разработок», как будто бы это имеет вообще хоть какое-то значение. См. ГСС ИР. Фор детаилс. Проблемы нет, Вам просто нравиться садо-мазо.

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

При чём тут memory leak? Вперёд за переполнением буфера.

при том что изначально речь велась про memory leak и потом с боку припеку кинули вброс про ошибку связанную с переполнением буфера (да некоторые люди любят подменять понятия, зачастую они делают это не специально, а просто из-за ассоциативных связей), чтобы получить такой же эффект как при переполнении буфера достаточно иметь контейнер который не следит за выходом из диапазона и не бросается исключение при этом. Да конечно это будет не совсем то же самое что в С, так как мы все еще находимся под жвм, но гипотетически если покопаться в жвм и найти и там ошибки подобного уровня (а она неожиданно написана на СС++), то вы получите то же самое.

Найдёшь большой, популярный проект на С, в котором не было проблем с памятью — возвращайся.

Лучше вы назовите мне язык в котором нет проблем с памятью (спойлер, таких не существует), тогда и поговорим.

Ты говорил, что проблемы с памятью в программе на С — это проблемы программиста?

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

Ты говорил, что если в программе на С ошибки с памятью, значит программист не умеет правильно выбирать инструмент?

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

Или может ты считаешь, что выбор правильного инструмента не входит в компетенцию программистов?

Как вы дошли да таких выводов, понятно только вам. Пруфы где я прямым текстом об этом говорил, или у вас опять проблемы возникнут?

Балаболка.

Самокритика важна, но не настолько. Нам не обязательно это озвучивать.

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

Весело спеваете, но факт остается фактом, по тому ряду причин что уже озвучены. Предложить другого никто ничего не может, да и смысла в этом нет. Это надо полностью начиная с железа все перелопачивать на иной лад если хотите чтобы не как у этих сишников мразотных(шутка сишники и си норм учитывая сколько лет это все прожило и не умирает) :)

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

сколько лет это все прожило и не умирает

потому что это говно врастает везде из-за кретинов его испольхующих и боготворящих, прогрессивное человечество отказывается от этого везде где только можно, причём даже в цщерб — иначе говно начнёт проникать и в их, новое и незапятнанное

по тому ряду причин что уже озвучены

нет причин хранить говно, нет причин использовать strcpy, когда ей есть замена, нет причин работать со стеком таким тупым способом, не причин вообще ни в чём этом

Я уже не говорю про аллокаторы и прочее — это пздц. Кто-то из си программистов умеет пулить — никто.

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

при том что изначально речь велась про memory leak

Мы с тобой, балаболка, вели речь о sendmail и багах в нём. В частности о переполнении буфера. А теперь ты опять начал юлить жопой.

Лучше вы назовите мне язык в котором нет проблем с памятью (спойлер, таких не существует), тогда и поговорим.

Тоесть ты сейчас признал, что в С есть проблемы с памятью? Хорошо, на этом спор свернули.

Я много про что говорил, потому что вы скачете с темы на тему пытаясь оправдаться, вовлекая все новые и новые темы.

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

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

Ты сейчас вякнул, что автор sendmail плохо знает С или какой-то другой вариант?

Или может ты считаешь,

Как вы дошли да таких выводов, понятно только вам. Пруфы где я прямым текстом об этом говорил, или у вас опять проблемы возникнут?

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

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

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

потому что это говно врастает везде из-за кретинов его испольхующих и боготворящих, прогрессивное человечество отказывается от этого везде где только можно, причём даже в цщерб — иначе говно начнёт проникать и в их, новое и незапятнанное

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

нет причин хранить говно, нет причин использовать strcpy, когда ей есть замена, нет причин работать со стеком таким тупым способом, не причин вообще ни в чём этом
Я уже не говорю про аллокаторы и прочее — это пздц. Кто-то из си программистов умеет пулить — никто.

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

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

Мы с тобой, балаболка, вели речь о sendmail и багах в нём. В частности о переполнении буфера. А теперь ты опять начал юлить жопой.

Ну раз уж вы так сильно просите, ткну вас носом, Rust 1.34 (комментарий)

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

Тоесть ты сейчас признал, что в С есть проблемы с памятью? Хорошо, на этом спор свернули.

Вы вновь делаете неверные выводы, это у вас прямо в крови =3. У С нет проблем с памятью, это видимо у вас есть с ней проблемы и с самим С, ну бывает, IT оно вообще не для всех так то... Я вот например пою плохо, но не кидаюсь на людей которые умеют петь и уж тем более не осждаю песни как инструмент певца, даже если мне не нравится то как он их исполняет или сама по себе песня.

Ты сейчас вякнул, что автор sendmail плохо знает С или какой-то другой вариант?

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

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

Ну раз уж вы так сильно просите, ткну вас носом,

Зачем ты меня тыкаешь в коментарий другого пользователя. Если ты хочешь поговорить с михой, то с ним и говори.

А я тебя таки ткну носом в свой, с которым ты, балаболка, начал спорить Rust 1.34 (комментарий)

В принципе вы давно перешли на личность, и откровенные оскорбления

Ты уже тут вякнул, что я не знаю, о чём говорю. И отказался так не делать. Поэтому оставь своё мимими.

назовите мне язык в котором нет проблем с памятью (спойлер, таких не существует).

Тоесть ты сейчас признал, что в С есть проблемы с памятью?

Вы вновь делаете неверные выводы,

Всё, я сдаюсь, ты победил.

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

А 25,193 пакета написал искуственный интеллект. Он же их и скачал затем 995,642,880 раза, да? Охотно верю, всё так и есть.

Подобное можно написать про любой язык. Какое это имеет отношение к «на постоянной основе».

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

тут бы нужны примеры, а то не совсем понятно что вы имеете в виду

Есть ANSI C, который прекрасно решает все проблемы. Более того, является стандартом портируемости де факто, если речь о слабом и редком железе. Есть C11 с тредами и шлюхами. На экзотику этого не воткнёшь да оно и не нужно там.

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

Можно возразить, дескать, обратная совместимость. Но кому она нужна? Компиляторы и так и так поддерживают старый си. Какой смысл компилить анси си на си11 компиляторе? Слинковать можно и так и этак.

Итог этой совмечтимости — старое не отмирает, как следствие, не нарастает и новое, но обрастает мхом.

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

Но в sjw-сообществе раста это статистическая норма.

Лолшто.

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

чтобы получить такой же эффект как при переполнении буфера достаточно иметь контейнер который не следит за выходом из диапазона и не бросается исключение при этом

А разве под jvm такое возможно?

Лучше вы назовите мне язык в котором нет проблем с памятью (спойлер, таких не существует), тогда и поговорим.

Язык ограничивает множество программ который на нем можно написать. Может быть такой язык в котором нельзя написать программу, в которой неправильно используется память. Думаю что в Хаскеле так, а еще в Charity и safe подмножестве Rust. Еще есть Verifiable C, не знаю насколько это отдельный язык.

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

А разве под jvm такое возможно?

По сути да, если jvm сама где-то будет иметь ошибку, сама-то она выполняется нативно.

Язык ограничивает множество программ который на нем можно написать. Может быть такой язык в котором нельзя написать программу, в которой неправильно используется память. Думаю что в Хаскеле так, а еще в Charity и safe подмножестве Rust. Еще есть Verifiable C, не знаю насколько это отдельный язык.

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

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

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

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

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

Можно возразить, дескать, обратная совместимость. Но кому она нужна? Компиляторы и так и так поддерживают старый си. Какой смысл компилить анси си на си11 компиляторе? Слинковать можно и так и этак.

Если вы не используете то самое экзотическое железо и хотите писать на С (ну есть желание странного) я даже бы советовал использовать и С99 и С11 там конечно не идеальные новшества, но все лучше чем АNSI, если конечно вам запрещают использовать сторонние библиотеки для тех же тредов или еще какие-либо, для каких-либо целей. А еще лучше вообще не писать на С из-за тех причин которые были озвучены ранее, просто потому что люди объективно склонны к ошибкам, особенно при монотонной работе, а С и рад стараться вам в этом помочь как достаточно низкоуровневый язык. Про смысл, такой же какой и писать в стиле например java 1.6 пользуясь новеньким jdk или писать С++ код в стиле С++98 компилируя его С++14 компилятором.

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

Зачем ты меня тыкаешь в коментарий другого пользователя. Если ты хочешь поговорить с михой, то с ним и говори.

Мы с вами беседуем в контексте всего треда, ну по крайней мере я пытался с вами беседовать, а теперь вы переобуваетесь когда вас уже ткнули лицом в то место с которого все началось, ожидаемо преобуваетесь... И именно с этого и началось про сендмеил. Понимаю, что неприятно когда вас как щенка с пруфами тыкают, так что вякаете и тявкаете все наше обсуждение увы вы. От вас же пруфов дождаться нельзя, вы только можете перевирать чужие слова под видом того, что вы их якобы так понимаете и навязывая их как будто я и правду сказал тот бред который вы скандируете под видом того, что я говорил на самом деле, хотя я ничего такого не говорил и просил у вас пруфы где бы я такое якобы мог сказать. И кстати я с вами не в чем не соревновался чтобы побеждать, можете победить если хотите. Хотя не можете вы обосрались, обтекайте. (Немного общения на доступном для вас языке)

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

Песни для геев любишь, говоришь? Ну сердцу не прикажешь.

Нет, говорю, что ты похож на того парня, которого в Химках видели.

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

По сути да, если...

Если бы да кабы... jvm - это одна программа. И пофиксить одну легче. Да и одну программу можно раз и навсегда проверить всю.

Что вообще понимается под неправильно используется память

На этот вопрос существует формализованный ответ.

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

Изобрели, точнее развили ранее изобретенные идеи - субструктурные системы типов и владение. Управляемый код - это не единственный способ. Можно ограничить язык, но оставить код нативным и этим добиться memory safety. По этому пути пошел язык о котором новость.

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

На другой - новодел, отсутствие привычного наследования, какие-то новые трейты.

Глупость же! Трейты известны так же как классы типов, которые придумали где-то на рубеже 80-х и 90-х. Новыми их никак нельзя назвать.

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

опять мы ходим по кругу, проще сказать что так сложилось исторически

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

Это не вопрос практики, а философии. Самые говнокодеры пишут как раз таки на Си. А кретенизм уровня ++и, сложно переоценить. Но проблема в том, зачем хранить и оберегать это говно? Речь, не о ссанном сишнике, а о его частях, котрые только фанатичный даун назовёт нужными, и часть из которых ловит компилятор с -Валл -Веррор, и это рекомендуется. Даунство в масштабе планеты не имеющее оправданий и существующее испокон вкеов. И да, Вы правы, эта череда даунизмов сложилась исторически.

anonymous
()

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

Кресты со своим stl пошли тем же путём, введя стандартные контейнеры.

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

Фортран разве когда-то нацеливался на какую-то иную нишу кроме научных и околонаучных вычислений? А контейнеры STL основаны на шаблонах. В Фортране и Паскале есть что-то подобное для параметрических типов, с «нулевой стоимостью» (не используешь фичу - нет накладных расходов)?

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

ты похож на того парня, которого в Химках

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

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

зачем хранить и оберегать это говно

Пишут на том, на чем возможно. Если нужен нужен гуй, то есть всего 2 варианта: либо вебмакака либо плюсы с qt. А если надо прошивку на stm-ку, то вариант вообще всего один

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

Да ёперный театр, меня не интересует под каким нелепым предлогом вы соглашаетесь с трагической нелепостью происходящего. Я лишь говорю о том, что в этом, конкретно — совместимосью между главными версиями языка, — нет никакого смысла, более того, для самого языка это губительно. Эволюция останавливается. В реальности низкий уровень запросто мог быть не таким до боли убогим. И если есть какое-то архаичное дерьмо, то вместо обретения формы оно обрастает мхом. Вот и всё. Как будто комуто весело программировать на Си. Да есть кому, тем кто дальше своего носа не видит и думает, что всё это — выглядит лучшим образом. Просто закостенелая слепота. Нежелание двигаться вперёд с прогрессивным человечеством и оправдания этого.

Отчего можно сделать вывод, что программирование на си в итоге приводит к печальным последствиям для программиста.

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

Вроде бы нету. И что, это очень страшно? Зато там есть работа с динамическою памятью, нет необходимости ручного её освобождения и нет сборщика мусора.

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

Зато там есть работа с динамическою памятью, нет необходимости ручного её освобождения

В современном С++ тоже.

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

Частично да, я согласен, уже писал выше. Тем не менее, в современном ЦПП по прежнему можно писать с использованием нескольких разных стандартных бибилиотек и выделять память вручную несколькими способами, в том числе через new и malloc.

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

Можно, но зачем? Да и библиотек для плюсцов больше. Кстати, какие у Fortran есть библиотеки для графики?

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

Fortran специфичная штука. Писать на нём программы общего назначения не рекомендуется. Есть биндинги к gtk, если вы о ГУИ, а если о построении графиков, то plplot имеет официальный биндинг. Фортран хорош моногомерными массивами, интеграцией со множеством библиотек численных алгоритмов, лёгким распараллеливанием кода.

Надо признать, что отсутствие соответствующих библиотек в основном обусловлено сравнительно поздним выходом современных стандартов (91 год) и совместимых с ними компиляторов, когда Паскаль и Си заняли место системных языков, а Матлаб стал популярен для быстрого решения численных задач (потом подтянулись его клоны и Питон с numpy и scipy).

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

Почему не рекомендуется? Отличный же язык, как и Паскаль. Уж «по-человечней», чем плюсы. При желании многое на нём можно писать.

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

Если можно, обязательно будут использовать. Именно поэтому в Питоне и пошли на обратную несовместимость. В версиях 2.5-2.6 уже практически всё было, что нужно: и нормальное деление нацело, и xrange вместо range, но всё равно народ продолжал писать по-старому.

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

Если можно, обязательно будут использовать.

Это их проблемы.

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

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

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

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

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

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

Не знаю, где вы это нашли. Вообще-то это чаще делают на Си.

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

Sounds gay

Ты очень смелый гей, молодец! Я так не могу, боюсь, а ты взял разделся и камингаут совершаешь постоянно.

anonymous
()

Очередное поделие непонятно для кого и не понятно зачем. Главное, новые названия общепринятым терминам придумать))) И можно старое выдавать за новое

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

Потому что имеется отдроченый компилятор, который умеет во все последние AVX инструкции.

А в мире Java нужно бабос на серверном железе пилить, поэтому там нет отдроченного компилятора/JVM. Это при том что была Java ME, которая работала на днищенском железе кнопочных мобилок уровня младшей линейки STM32. И вполне шустро.

Только и всего. Давно можно было бы сделать идеальный быстрый и безопасный язык для всего, но рыночек продаж железа порешал.

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

Только и всего. Давно можно было бы сделать идеальный быстрый и безопасный язык для всего

D, C#. Но из-за сборки мусора это всё сорта Java. А сделать чтоб было быстро как C++ и при этом безопасно, только недавно научились

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

https://github.com/tensorflow/tensorflow

C++ 52.7% Python 38.7%

А, и на С, есть. То есть было.

https://github.com/torch/torch7

C 65.0% Lua 29.3%

Torch is not in active developement. The functionality provided by the C backend of Torch, which are the TH, THNN, THC, THCUNN libraries is actively extended and re-written in the ATen C++11 library

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