The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск Rust 1.91"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск Rust 1.91"  +/
Сообщение от opennews (??), 31-Окт-25, 12:32 
Опубликован релиз языка программирования  Rust 1.91, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64149

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

4. Сообщение от Аноним Мю (?), 31-Окт-25, 12:36   –1 +/
Что за ABI такой: gnullvm?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11, #37

10. Сообщение от Аноним (10), 31-Окт-25, 12:49   +2 +/
Хороший язык для начинающих - этакий надувной круг-уточка, не дающий чайнику утонуть.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #13

11. Сообщение от Archer73 (ok), 31-Окт-25, 12:50   +3 +/
Windows targets similar to *-pc-windows-gnu but using UCRT as the runtime and various LLVM tools/libraries instead of GCC/Binutils.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #173

12. Сообщение от kravich (ok), 31-Окт-25, 12:53   +10 +/
Хорошая шутка
Скорее, это бассейн, заполненный смолой, в которой предлагают плыть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #62

13. Сообщение от Аноним (-), 31-Окт-25, 12:56   +9 +/
> Хороший язык для начинающих - этакий надувной круг-уточка, не дающий чайнику утонуть.

Вот только обычно инструментами "не дающими утонуть" пользуются профи.
Это чайник скажет "да тут всего щиток на ХЗ сколько вольт, я сейчас возьму дидовые пассатижи и всё поправлю".
А потом его аккуратно сметают веничком в пакет и выкидывают.

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

Чайники и бракоделы делают как попало, а потом C̶V̶E̶ получается фигня)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16, #40, #224

14. Сообщение от Аноним (14), 31-Окт-25, 12:56   –18 +/
Лучший язык программирования! Хай языков вроде си прошёл - Правительство США призывает отказаться от небищопасных языков.
А раст это навсегда! В отличии от других языков, которые ну выучили, может даже и лучше, но их хайп пройдёт и работу не найдёте! А если у вас проект - будите платить огромные деньги за переписывание, ибо кто поддерживать будет? Никто!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17, #35, #50, #207, #212, #229, #359

16. Сообщение от Аноним (16), 31-Окт-25, 12:59   –2 +/
> Чайники и бракоделы делают как попало, а потом CVE получается фигня)

это как в CVE-2025-62518 aka TARmageddon?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18, #19, #61, #63, #90, #168

17. Сообщение от Анонимусс (-), 31-Окт-25, 13:02   –2 +/
> А раст это навсегда!

Не дай боже!
Если раст застрянет как дыряха на 40+ лет, то это будет просто ужасно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #296, #346

18. Сообщение от kravich (ok), 31-Окт-25, 13:03   +5 +/
А что намекает на то, будто tar-это хороший формат?
Встроенного сжатия нет, расчитан изначально на запись на магнитных стримерах, 100500 вариантов формата, насильно объединенных во франкенштейна в попытке стандартизовать...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #22, #70, #79

19. Сообщение от Аноним (-), 31-Окт-25, 13:05   +3 +/
>> Чайники и бракоделы делают как попало, а потом CVE получается фигня)
> это как в CVE-2025-62518 aka TARmageddon?

Нет, как CVE в ХОрг или ядре линукс).
Раст предотвращает и дает гарантии на конкретный список проблем.

Ты же не будешь ныть что книпексовые клещи на 1000 вольт пробиваются на 10000?
Если вам нужно больше - то АДА или формальная верификация, если у вас хватит денег))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #82

22. Сообщение от Аноним (16), 31-Окт-25, 13:11   +13 +/
> Встроенного сжатия нет

Ага, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.

> изначально на запись на магнитных стримерах

Какая разница что там было изначально?

> 100500 вариантов формата

Поменьше: по сути вам (растаманам) надо было реализовать только ustar и pax. Но вы и тут облажались. И, кстати, у сишников что-то не было такой проблемы с кучей форматов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #230, #276

23. Сообщение от Аноним (23), 31-Окт-25, 13:14   +1 +/
Не люблил раст, но вот сейчас сижу и смотрю почему течет flutterJNI на android и rust уже не кажется таким уж переусложненным на ровном месте. Если посмотреть на существующие распространенные решения, то rust там мог бы решить большой спектр проблем.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #72

24. Сообщение от cheburnator9000 (ok), 31-Окт-25, 13:16   –1 +/
carbon похоронит ржавчину, вот как только зарелизится так сразу!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #202

25. Сообщение от senaemail (ok), 31-Окт-25, 13:17   +1 +/
И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?

Завтра какая-то новая идея возникнет, опять новый язык появится?

Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи? Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...

Надо развивать существующие а не плодить новые.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27, #29, #42, #69, #80, #84, #93, #223, #291

27. Сообщение от Бьяерне Страуструп (?), 31-Окт-25, 13:26   +1 +/
От чего мы все запихиваем в наш любимый C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

28. Сообщение от Аноним (16), 31-Окт-25, 13:27   –5 +/
> почему течет flutterJNI на android и rust уже не кажется таким уж переусложненным

дак он раст написан

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #65, #67

29. Сообщение от Аноним (-), 31-Окт-25, 13:27   +3 +/
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?

Ну... так обычно и происходит)

> Завтра какая-то новая идея возникнет, опять новый язык появится?

Зависит от...
Например если у нас древний ЯП, который писали в прошлом тысячелетии, адепты которого молятся на "ОБРАТНУЮ СОВМЕСТИМОСТЬ!!!" и поддержку железок из 70х, то нет.
Они упрутся, скажут зачем нам прогресс, мы можем в луже и палкой копалкой работать.

Второй вариант - сделать версию ЯП, которая ломает совместимость.
Но это тоже не очень, тк народ будет их путать.

> Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?

Зато выкидываем старые стандарты производства или строительства.

> Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...

Чего? В 18 и 56 году хорошо так поменяли.
Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.
По сути получили новый "русскоподобный язык".

Те кто жил в те смутные времена даже ругались:
"Зачем все эти искажения? Для чего это умопомрачающее снижение? Кому нужна эта смута в мысли и в языковом творчестве?? Ответ может быть только один: всё это нужно врагам национальной России. Им; именно им, и только им." - Иван Александрович Ильин

> Надо развивать существующие а не плодить новые.

А если не хотят развивать?
Если держатся за священную корову "я могу скомпилять для 8008!!"
Если не хотя учиться новому?
Проще не спорить и создать новый ЯП.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #44, #45, #46, #94

31. Сообщение от Аноним (110), 31-Окт-25, 13:29   –1 +/
>Методы работы с памятью в Rust избавляют разработчика от ошибок при манипулировании указателями и защищают от проблем, возникающих из-за низкоуровневой работы с памятью

Не избавляют.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #66

35. Сообщение от Аноним (110), 31-Окт-25, 13:33   +/
Смысл в языке, в котором без ИИ никуда?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #190

36. Сообщение от Аноним (-), 31-Окт-25, 13:37   +3 +/
> carbon похоронит ржавчину, вот как только зарелизится так сразу!

Пфф, манямирок анонов такой маня)

Авторы carbonʼа сами пишут вот прям в описании проекта:
Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should.
github.com/carbon-language/carbon-lang?tab=readme-ov-file#why-build-carbon

Более того, расширяют мысль
If you can use Rust, ignore Carbon
https://github.com/carbon-language/carbon-lang/blob/trunk/do...

Что-то я им больше верю, чем твоим фантазиям.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

37. Сообщение от анондр (?), 31-Окт-25, 13:41   +2 +/
ни с чем не совместимое нечто :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

39. Сообщение от Аноним (39), 31-Окт-25, 13:42   +4 +/
fn f() -> *const u8 {
       let x = 0;
       &x
   }

чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны. а тут они в версии 2.91 выдали предупреждение. мдя. и сколько ещё подобного "безопасного" на расте можно написать?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #112, #309

40. Сообщение от gi (??), 31-Окт-25, 13:43   –1 +/
додо...
это поэтому хоккеисты сначало играют в шлеме с Ме решёткой на все щи, потом со стекляшкой в половину, ну а профи уже и без стекла

а чем "дидовые" пасатижи хуже так плохи? нет предохранителя от попадания пальца?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #64

42. Сообщение от Аноним (42), 31-Окт-25, 13:44   +2 +/
Русский язык - плохой пример . Над тем что "отцам и детям" требуется переводчик - шутили ещё в 70х . А многие ли могут перевести на современный выражение "не мытьём , так катаньем" ? Справка: мытьё - сбор налогов , катанье - телесные и финансовые наказания .
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #390

44. Сообщение от Аноним (44), 31-Окт-25, 13:47    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

45. Сообщение от senaemail (ok), 31-Окт-25, 13:48   +/
>> Да, мы проводим реформы (принимаем новые стандарты). Но блин, никому не приходит в голову, русский язык устарел, давайте теперь говорить на иксигрекзетовом...
> Чего? В 18 и 56 году хорошо так поменяли.
> Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.
> По сути получили новый "русскоподобный язык".

В смысле? Мы не получили "русскоподобный язык", мы говорим на русском языке. Он видоизменяется со временем, поэтому приходится стандарты подгонять под современность.

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

Понятно, что аналогия не полная, фактически каждый из нас является сотворцом языка и может придумать новое слово или конструкцию, которое лет через 200 может попасть в толковый словарь.

>> Надо развивать существующие а не плодить новые.
> А если не хотят развивать?

Кто не хочет? Покажите мне этого человека.

> Если держатся за священную корову "я могу скомпилять для 8008!!"

Рано или поздно придётся отказаться от этого.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #51, #97

46. Сообщение от gj (?), 31-Окт-25, 13:52   +/
> можем в луже и палкой копалкой работать.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

50. Сообщение от zionist (ok), 31-Окт-25, 14:00   +2 +/
Раньше правительство США ратовало за язык Ада.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #242

51. Сообщение от Аноним (-), 31-Окт-25, 14:02   +1 +/
>> По сути получили новый "русскоподобный язык".
> В смысле? Мы не получили "русскоподобный язык", мы говорим на русском языке.

Неа!
Язык настолько покромсали и переделали, что от старого остались только какие-то общие структуры.
Как сейчас говорят "СИ подобный синтаксис"))

ru.wikipedia.org/wiki/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%B4%D0%BE%D1%80%D0%B5%D1%84%D0%BE%D1%80%D0%BC%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BE%D1%80%D1%84%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D1%8F

> Он видоизменяется со временем, поэтому приходится стандарты подгонять под современность.

Его видоизменили буквально за год.
Причем насильно, через монополию напечатную продукцию.
ru.wikipedia.org/wiki/%D0%A0%D0%B5%D1%84%D0%BE%D1%80%D0%BC%D0%B0_%D1%80%D1%83%D1%81%D1%81%D0%BA%D0%BE%D0%B9_%D0%BE%D1%80%D1%84%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%B8_1918_%D0%B3%D0%BE%D0%B4%D0%B0

> Понятно, что аналогия не полная, фактически каждый из нас является сотворцом языка и может придумать новое слово или конструкцию, которое лет через 200  может попасть в толковый словарь.

Ну попробуйте прочитать, а тем более написать (по правилам!)
въ​ смꙑслѣ? мꙑ ​не​ полѫчили "роусскопѫдобнꙑи ​ѩꙁꙑкъ​" мꙑ ​говоримъ​ на ​роусскомъ​ ​ѩꙁꙑкѣ​. ​ѻнъ​ видоиꙁменѧѥтсѧ ​со​ ​врѣменемъ​ ​поѥтомоу​ ​приходитсѧ​ стандартꙑ пѫдгонѧть пѫдъ соврѣменность.
да ѥсть ​въ​ ​немъ​ ​какꙑѥ​-​то​ ​неоудобнꙑѥ​ моментꙑ ​и​ проблемꙑ исключенїꙗ неѻдноꙁначности ​сѫщественнꙑѥ​ ѿличїꙗ съ раꙁговорномꙑмъ ​и​ т.п. да ​ѻнъ​ ​не​ самꙑи распространеннꙑи ​въ​ ​мире​.
понѧтно что ꙗналогꙑа ​не​ полнаꙗ фактическꙑ каждꙑи иꙁъ насъ ꙗвлѧѥтсѧ ​сотворцомъ​ ​ѩꙁꙑка​ ​и​ можетъ придоумать новоѥ слово или констроукцїю ​котраѥ​ лѣтъ чрѣꙁъ 200 можетъ ​пѫпасть​ ​въ​ толковꙑи ​словарь​.

> Кто не хочет? Покажите мне этого человека.

Коммитет С?

> Рано или поздно придётся отказаться от этого.

Ага.
И проще заменить ЯП, чем лепить горбатого до стены.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #98, #164

61. Сообщение от Аноним (166), 31-Окт-25, 14:24   +1 +/
А на СИ там бы еще за границу буфера вышли и обратились бы к освобождённой памяти, не забыл вызвать переполнение. А раст, да, плохой, не позволяет все это сделать, и потому тебе пришлось искать CVE с !логической! ошибкой (а раст то тут причем?) в реализации кривого формата.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

62. Сообщение от Аноним (62), 31-Окт-25, 14:24   +1 +/
во-во, особенно кто старых как рыба, да хоть в том же пыхе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

63. Сообщение от Аноним (63), 31-Окт-25, 14:26   +1 +/
Нет. Это остальные 9 миллиардов CVE в переполнением памяти/буфера/кучи/стэка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

64. Сообщение от Аноним (166), 31-Окт-25, 14:27   +1 +/
Ну вообще-то профи давно заковали в броню, спонсоры команд больше не готовы платить миллионы за контракты, чтобы потом смотреть, как очередного "профессионала" уносят на носилках со льда, т.к. ему шайба попала в голову, т.к. он не надел шлем (да-да, таки без шлема больше на лед не пускают).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

65. Сообщение от Аноним (63), 31-Окт-25, 14:29   +4 +/
Interface between Flutter embedding's Java code and Flutter engine's C/C++ code.

Раст во все поля.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

66. Сообщение от Аноним (66), 31-Окт-25, 14:31   +1 +/
избавляют
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #73

67. Сообщение от Аноним (166), 31-Окт-25, 14:31   +1 +/
C/C++ https://api.flutter.dev/javadoc/io/flutter/embedding/engine/...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

68. Сообщение от Шарп (ok), 31-Окт-25, 14:33   +/
Какая-то минорщина с обновлением линтера. Где фичи?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #108, #478

69. Сообщение от Аноним (166), 31-Окт-25, 14:33   +/
Согласен, возвращаемся на Lisp и Fortran! Ну ладно, можно еще COBOL для хипстеров, которые любят все новое!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

70. Сообщение от Медведь (ok), 31-Окт-25, 14:44   +3 +/
Ну все как всегда -- этот мир нам не подходит, дайте другой, с правильным tar, рулеткой и стюардессами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

71. Сообщение от Аноним (71), 31-Окт-25, 14:44   –1 +/
К чему такие мелкие выпуски? Это какой-то майлстоун или как? Вот завтра выйдет новая версия - в ней можно ли будет указать для компиляции любую предыдущую вплоть до 0.01?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #99

72. Сообщение от Медведь (ok), 31-Окт-25, 14:48   +6 +/
А rust нифига не гарантирует отсутствие утечек памяти. Сюрприз! Меньше слушай хайповые крики растунов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #92, #420, #477

73. Сообщение от Аноним (110), 31-Окт-25, 14:53   –1 +/
Только от очень небольшого списка, а этого недостаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #221, #352

75. Сообщение от Аноним (110), 31-Окт-25, 15:02   +/
И в то же время часть пакетов всегда требует ночную экспериментальную сборку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #101

79. Сообщение от Аноним (79), 31-Окт-25, 15:09   +1 +/
Встроенное сжатие зачем гвоздями прибивать? Для tar есть возможность выбора сжимальщиков: gz, bz2, lzma, xz, ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #118, #194, #275

80. Сообщение от Аноним (80), 31-Окт-25, 15:11   +/
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?

Да. В чём проблема?

> Я понимаю, конечно, развитие не остановить. Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?

Доброе утро, русский давно выкинули.

> Надо развивать существующие а не плодить новые.

Ну вот C++ развивают, и кому от этого хорошо?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

82. Сообщение от Аноним (79), 31-Окт-25, 15:13   –3 +/
> Раст предотвращает и дает гарантии на конкретный список проблем.

Вот когда на деле _реально_ предотвратит, тогда и приходите. А пока один булшит про безопастность.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #91, #197

84. Сообщение от Медведь (ok), 31-Окт-25, 15:15   –1 +/
> И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?

Вот как раз относительно новых идей в программировании -- раст обречен на застой и стагнацию.

Во-первых, добавить в ядро языка новые идеи и концепции или очень сложно, или невозможно: а вдруг они нарушат "бизапаснасть"? а кто будет допиливать боровчекер? а насколько еще более тормозным он станет после изменений? Даже довольно простая идея со специализацией генериков висит в nightly много лет и провисит еще столько же.

Во-вторых, растуны, радостно повизгивая, ломанулись в критически важный код, не обратив внимания, что это ловушка, в которую попал, увы, C: "что? доработать язык под новые идеи? а кто гарантирует, что старый код не сломается? нет уж, вот у нас тут архимегаважный пакетик собирается -- и пусть его собирается, никто экспериментировать не будет! в этих ваших закорючках пока разберешься, ишь чо удумали!"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #95, #113, #152, #406

90. Сообщение от Аноним (91), 31-Окт-25, 15:29   +5 +/
Вы как всегда не различаете ошибк управления памятью и прочие уязвимости. Как и ожидалось от ненависников раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #105, #129, #169

91. Сообщение от Аноним (91), 31-Окт-25, 15:30   +2 +/
>Вот когда на деле _реально_ предотвратит, тогда и приходите.

Возьмите и начните писать аналогичную программу на си и на расте. Первая же ошибка компиляции - ура проблема поймана.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #102, #109, #110

92. Сообщение от Аноним (91), 31-Окт-25, 15:32   +/
Так растеры это прямо говорят. Это сишники возмонили, что раст должен все проблемы решать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #96, #126

93. Сообщение от Аноним (91), 31-Окт-25, 15:37   +1 +/
>И это всегда будет так? Появились новые идеи в программировании - делаем новый язык?

Это всегда так было. Вы новые идеи к старым языкам либо не прикрутите вообще, либо через огромную кучу костылей.
>Завтра какая-то новая идея возникнет, опять новый язык появится?

Совершенно верно.
>Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?

Какие новые идеи? Между си и растом - фундаментальная разница: концепция владения, алгебраические типы данных, гигиенические макросы и так далее.
>Да, мы проводим реформы (принимаем новые стандарты)

Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
>Надо развивать существующие а не плодить новые.

Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст, ничуть не лучше текущего.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #289

94. Сообщение от Аноним (94), 31-Окт-25, 15:40   –1 +/
> В 18 и 56 году хорошо так поменяли.
> Выкинули кучу букв Ѣ, Ѳ, І. Убрали из окончаний Ъ. Изменили грамматику.

Ну это в начала 20-го века, а в 1956 что русском меняли?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #104

95. Сообщение от Анонимусс (-), 31-Окт-25, 15:41   +/
О! Какие люди! Медведь вылез из берлоги.
А чего не посетили тему про очередные дырени в дидовых иксах?
Неужели так него сказать было, а тут есть?))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

96. Сообщение от Медведь (ok), 31-Окт-25, 15:43   +/
> Так растеры это прямо говорят. Это сишники возмонили, что раст должен все проблемы решать.

Это они прямо говорят, когда носом ткнешь. В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.

> Не люблил раст, но вот сейчас сижу и смотрю почему течет flutterJNI на android и rust уже не кажется таким уж переусложненным на ровном месте.

Откуда бы у товарища такие умонастроения, уж не из-за рекламы ли раста из всех утюгов?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #131, #134

97. Сообщение от Аноним (91), 31-Окт-25, 15:44   +1 +/
>Мы не получили "русскоподобный язык", мы говорим на русском языке.

Нет. Возьмите дореволюционные учебники, научите по ним ученика, чтобы он ставил "ъ" в конце слов, и так далее, а потом дайте ему сдать ЕГЭ. Если уж на то пошло, то говорим мы на языке образца какого-то года, но сами эти образцы между собой несовместимы.

В качестве хорошего примера возьмите китайский. У вас есть 中文(简体)и 中文(繁體). Как не сложно догадаться, зная один вы мало что поймёте в другом.
>Кто не хочет? Покажите мне этого человека.

Посмотрите местных: линтеры не нужны, концепция владения не нужна, и так далее.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #159

98. Сообщение от Аноним (91), 31-Окт-25, 15:45   +1 +/
>Ну попробуйте прочитать, а тем более написать (по правилам!)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

99. Сообщение от Аноним (142), 31-Окт-25, 15:51   +1 +/
> crates in one edition *must* seamlessly interoperate with those compiled with other editions

https://doc.rust-lang.org/edition-guide/editions/

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #254

101. Сообщение от Аноним (-), 31-Окт-25, 15:52   –1 +/
Пишиьте письма разработчикам пакетов.
Точно так же они погут использовать С23.

AOSP например позволяет использовать Edition 2015, 2018, и 2021.
Вот прям в доке записано.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #151

102. Сообщение от Аноним (102), 31-Окт-25, 15:54   –3 +/
TARmageddon компилировался. И в Бубунте утили компилировались... Пришлось потом на ужасносишной старьё руками откатывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #123, #192

104. Сообщение от Аноним (-), 31-Окт-25, 15:55   +/
Посмотрите на изменения с 1918 по 1956

gramota.ru/journal/stati/yazykovaya-politika/reformy-russkoy-orfografii
wikiwand.com/ru/articles/Орфография_русского_языка_до_1956_года

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

105. Сообщение от Аноним (102), 31-Окт-25, 15:55   –3 +/
У программы есть два состояния: с ошибками и без ошибок.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90

107. Сообщение от Анонимemail (107), 31-Окт-25, 15:56   +/
Rust отличный язык для написания софта где требуется работа в реальном времени без сборщика мусора, к примеру пишем софт аи модуля автоматического наведения дрона на двигатели самолетов, собственно для сбития вражеских транспортных, и не только, самолетов, то есть дрон сам может находить взлетающую цель, наводится на двигатели, ну а дальше в полезной нагрузке дрона просто стальной брусок, который весело попадает прямо в движок. Несколько таких дронов почти гарантированно сбивают самолет на начальном этапе взлета, и все благодаря Rust + ИИ, компьютерному зрению и так далее, даже оператор дрона не нужен, надо лишь заранее разместить дрон и дать когда требуется указание на взлет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #119, #143, #209

108. Сообщение от нах. (?), 31-Окт-25, 15:58   –1 +/
> Где фичи?

Как где - вон тебе на два экрана мелким шрифтиком подвезли "новых шт@6ильных" закорючек, иди зубри.

И так раз в неделю, а то немодным и немолодежным окажешься.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

109. Сообщение от Медведь (ok), 31-Окт-25, 16:00   –2 +/
И снова: "компилируется -- значит работает!" Я смотрю, растуны оригинальностью не отличаются, исправно пересказывают рекламу. Парни, серебряных пуль не бывает, это вас обманули.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #127

110. Сообщение от Аноним (110), 31-Окт-25, 16:02   +/
Компилируется значит работает? Неудивительно, почему столько проблем у uutils...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #189

111. Сообщение от Аноним (111), 31-Окт-25, 16:04   +/
Интересно, а подойдет rust - как первый язык программирования? Да и действия насильственного характера с borrow checker пугают. Не будет ли это напрасной потерей времени и сил?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #120, #121, #124, #125, #136, #247, #324, #422

112. Сообщение от Аноним (91), 31-Окт-25, 16:04   +1 +/
>чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны.

Вы путаете указатели и ссылки. С вашим уровнем знаний вам на си и крестах писать противопоказано
>и сколько ещё подобного "безопасного" на расте можно написать?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #132, #236

113. Сообщение от Аноним (-), 31-Окт-25, 16:05   +/
Пффф, от это забористый копиум)

> Во-первых, добавить в ядро языка новые идеи и концепции или очень сложно, или невозможно:

С чего вдруг? Открой ченджлоги для edition и увидь, что постоянно что-то меняется.

> а кто будет допиливать боровчекер?

Те же кто пишет язык сейчас.

> а насколько еще более тормозным он станет после изменений?

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

> Даже довольно простая идея со специализацией генериков висит в nightly много лет и провисит еще столько же.

А она готовая? Или автор хочет чтобы за него сделали? Если ты про 1210, то там почти нифига не сделано, суда по чекам.
Если мало кому нужны такие "фичи", то оно будет висеть еще очень долго.

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

Судя по теме визжат только СИшники, которым что-то не нравится)

> доработать язык под новые идеи? а кто гарантирует, что старый код не сломается?

Концепция Edition и гарантирует.

> нет уж, вот у нас тут архимегаважный пакетик собирается -- и пусть его собирается, никто экспериментировать не будет!

Ну так сидите на старых версиях, чего бухтеть?

> в этих ваших закорючках пока разберешься, ишь чо удумали!"

Такое может сказать только неосилятор, которые раст в жизни не видел.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #135, #145

118. Сообщение от Аноним (16), 31-Окт-25, 16:08   +/
Ой, да они там без встроенного сжатия не смогли два формата архивов реализовать, аж целую CVE создали. А прикинь если бы в tar'е было еще и встроенное сжатие? - была бы еще одна CVE как минимум
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #166, #186

119. Сообщение от Медведь (ok), 31-Окт-25, 16:08   +1 +/
> в полезной нагрузке дрона просто стальной брусок

Ну раз в нагрузке стальной брусок, то да -- только rust, однозначно. Какой же стальной брусок без rust? Разве что наждачкой начищать каждый день, особенно в агрессивном климате.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

120. Сообщение от Аноним (91), 31-Окт-25, 16:11   +/
>Интересно, а подойдет rust - как первый язык программирования?

А вам зачем, что вы собираетесь делать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #128

121. Сообщение от Аноним (-), 31-Окт-25, 16:11   +2 +/
Думаю нет.
Т.к он сразу подразумевает понимание сложных концепций.
Для первого ЯП нужно что-то простое, что позволит освоить алгоритмы и структуры данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #237, #421

122. Сообщение от Аноним (122), 31-Окт-25, 16:13   +1 +/
Мда, пока в других сферах специалисты с каждой итерацией стараются как-то упростить себе работу, программисты все делают наоборот. Мало того, что нужно разбираться в бизнес-логике, так еще и в синтаксисе ржавого. Грядет коллапс разработки ПО!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #137, #138, #150, #325

123. Сообщение от Аноним (91), 31-Окт-25, 16:14   +3 +/
>TARmageddon компилировался.

А там ошибок управления памятью почему-то нет. Логическая ошибка != управлению памятью.
>И в Бубунте утили компилировались...

Ну так сама утилита на расте работала, не работала убунтовская обвязка.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

124. Сообщение от Аноним (124), 31-Окт-25, 16:15   +/
Дело не в языке программирования. Просто занимайся тем что лично тебе кажется интересным. Если прёт от Раста - занимайся Растом, если не прёт - лучше им не занимайся. Главное глаза должны гореть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #140

125. Сообщение от Аноним (142), 31-Окт-25, 16:16   +2 +/
Подойдет. И вообще, новичкам советуют для начала вообще не париться с lifetime. То есть, .clone() везде, Rc/Arc, а потом, как освоишься, можно и оптимизировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #130, #157

126. Сообщение от Аноним (16), 31-Окт-25, 16:17   –1 +/
Всмысле прямо говорят? Они прямо говорят обратное - раст это безопасный язык, позволяющий безопасно работать с памятью и избавляющий программист от ручного управления памятью. Нахера там утечки тогда нужны в расте? Это типа избавление от ручного управления памятью путем добавления утечек памяти? А хитро вы это придумали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #141

127. Сообщение от Аноним (91), 31-Окт-25, 16:18   +3 +/
>И снова: "компилируется -- значит работает!"

Удивительно, но факт.
>Парни, серебряных пуль не бывает, это вас обманули.

Давайте ищите CVE, в которых проблема в любом управлении памятью: хоть висячий указатель, хоть двойное освобождение, хоть ещё что-то. Когда найдёте, тогда и приходите.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #165

128. Сообщение от Аноним (128), 31-Окт-25, 16:19   –1 +/
>А вам зачем, что вы собираетесь делать?

А с какой целью вы интересуетесь? Вам это знать не нужно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #437

129. Сообщение от Аноним (91), 31-Окт-25, 16:19   +2 +/
>У программы есть два состояния: с ошибками и без ошибок.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #139

130. Сообщение от Аноним (128), 31-Окт-25, 16:20   –1 +/
>Подойдет.

Одежда должна подойти. С ЯП это так не работает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

131. Сообщение от Анонимусс (-), 31-Окт-25, 16:20   +1 +/
> Это они прямо говорят, когда носом ткнешь.

Ну, мы подразумеваем, что для нормального хейта хейтеры хотя бы доку прочитать должны.
"Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust."
(doc.rust-lang.org/book/ch15-06-reference-cycles.html)

> В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.

Разумеется! Потому что утечки не дарят рут и не выполняют произвольный код :)
Максимум что можешь произойти - oomkiller сработает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

132. Сообщение от Аноним (132), 31-Окт-25, 16:24   –3 +/
> В том, что вы возвратите указатель нет ничего страшного. А для разыменновывания указателей нужен unsafe.

Т.е. вон то - safe код? Но ведь реально ошибка не по месту разыменования, получается, всё это время пропаганда врала что якобы нужно внимательно проверять только unsafe блоки а во всём остальном коде ошибок с памятью быть не может?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #142, #227, #231

134. Сообщение от Аноним (91), 31-Окт-25, 16:25   +2 +/
>В самой новости: куча текста про "бизапаснасть", ни слова про возможные утечки.

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

А что вы у меня спрашиваете, у него самого спросите. Вы лучше скажите, откуда у вас столь искажённое представление о расте: когда вам прямо указывают на систему гарантий, вы галлюцинируете и видите то, чего нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #215

135. Сообщение от Аноним (110), 31-Окт-25, 16:28   –1 +/
>С чего вдруг? Открой ченджлоги для edition и увидь, что постоянно что-то меняется.

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

А на Си и код быстрый, и компиляция, а ошибки можно статическим анализатором найти.
>Судя по теме визжат только СИшники, которым что-то не нравится)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #146, #160

136. Сообщение от Аноним (136), 31-Окт-25, 16:29   –1 +/
Не будет. В отличии от дырявого ты сразу будешь учиться писать код правильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #147

137. Сообщение от Аноним (-), 31-Окт-25, 16:29   +5 +/
> стараются как-то упростить себе работу

Да, напр. сделать так, чтобы за владением следил компилятор, а не разработчик.
Wait, oh shi...

> так еще и в синтаксисе ржавого

Плюсовики смотрят на это утверждение с недоумением

> Грядет коллапс разработки ПО!

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #144, #161

138. Сообщение от Аноним (79), 31-Окт-25, 16:33   +/
Так вот, похоже, что это AI за него всюду топит. Чтобы человека из сферы программинга вытеснить поскорее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

139. Сообщение от Аноним (16), 31-Окт-25, 16:33   +/
И как тогда компилятор написать? Или драйвер в ядре?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #148

140. Сообщение от Аноним (111), 31-Окт-25, 16:34   +/
К сожалению, для "горящих глаз" - возраст совсем не подходящий. Меня больше интересует вопрос соотношение времени написания кода к его отладке в сравнении с тем же С и С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #149, #154, #162

141. Сообщение от Аноним (91), 31-Окт-25, 16:35   +/
>Всмысле прямо говорят?

С разморозкой. Берём первый попавшийся материал https://github.com/brson/rust-anthology/commits/master/src/m...
>Commits on Jun 12, 2016

Материалу 9 полных лет, а вы об этом впервые слышите. Очень хороший уровень компетенции.
>Нахера там утечки тогда нужны в расте?

Да будет вам известно, что даже языки с GC не гарантируют отсутствие утечек памяти.
>Это типа избавление от ручного управления памятью путем добавления утечек памяти?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #357

142. Сообщение от Аноним (142), 31-Окт-25, 16:36   +3 +/
> нужно внимательно проверять только unsafe блоки а во всём остальном коде ошибок с памятью быть не может

Да. Именно так.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

143. Сообщение от Аноним (132), 31-Окт-25, 16:38   +4 +/
Это не будет работать, т.к. раст предоставляет гарантии безопасности использования, а эта затея выглядит опасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

144. Сообщение от Аноним (79), 31-Окт-25, 16:39   +/
А что у плюсовиков? Вот только необычным было применение <..> для параметров шаблонов, когда их добаввили. Но это было уж давно, все уже привыкли. И ничего экстравагантного в синтаксисе с тех пор не добавилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

145. Сообщение от Медведь (ok), 31-Окт-25, 16:40   –1 +/
> Концепция Edition и гарантирует.

А растики смешные. Сам сообразишь, насколько гарантии поддержки старых editions и их совместимости относительно совместной линковки "вдохновляют" разработчиков компилятора вносить даже самые расчудесные улучшения в язык? А когда этих editions станет не 4-5, а 10? 20?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #156

146. Сообщение от васян (?), 31-Окт-25, 16:40   +1 +/
> Какое мнение будет у человека

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

147. Сообщение от Аноним (79), 31-Окт-25, 16:42   +/
Поэтому учись на Python.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #167, #419

148. Сообщение от Аноним (91), 31-Окт-25, 16:42   +1 +/
>И как тогда компилятор написать?

Зачем вам для компилятора указатели?
>Или драйвер в ядре?

Для драйвера придётся придётся написать какое-то количество unsafe кода, но это гораздо лучше, чем когда весь код - unsafe.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #252

149. Сообщение от Анонимусс (-), 31-Окт-25, 16:44   +/
Времени написания кода больше чем на с/с++ и иногда существенно.
Особенно если не продумал архитектуру и взаимодействие компонент, то придется много переписывать и не получиться "х-к, х-к и в прод", потому что оно просто не скомпилируется.
Для геймдева подходит так себе.

Зато нет бессонных ночей с поиском "а кто же испортил память на проде когда меркурий был ретроградным"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #178

150. Сообщение от Аноним (150), 31-Окт-25, 16:49   +/
Ага, свет клином сошелся у кодеров на этих Си,Раст. Остальное либо ругать не за что,либо просто нечего. D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #158

151. Сообщение от Аноним (110), 31-Окт-25, 16:52   –1 +/
>Пишиьте письма разработчикам пакетов.

Точно так же они погут использовать С23.
Зачем? Они делом заняты, а не переписыванием. Выбрали нужную версию и с ней работают, а обновляться будут при необходимости.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #174

152. Сообщение от Аноним (152), 31-Окт-25, 16:54   +/
Многие вещи висят годами нестабильными не потому что есть какие-то технические ограничения, а потому что не понято вообще нужно ли это тащить в язык.

Те же специализации темплейтов в плюсах настолько сложные и непредсказуемые, с кучей правил и мелких факторов, что зачастую лучше бы их и не было. Уже десять лет в расте живут без специализаций дженериков и всем нормально. Хочешь другую реализацию — ну создай еще одну функцию с новым именем. Зато явно будет видно, что в коде вызывается.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

154. Сообщение от Аноним (110), 31-Окт-25, 16:57   +/
Посмотрите реализацию сортировки вставками на каждом языке и вам станет понятно, на чем программировать проще и быстрее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

156. Сообщение от Аноним (-), 31-Окт-25, 17:00   +1 +/
> Сам сообразишь, насколько гарантии поддержки старых editions и их совместимости относительно совместной линковки "вдохновляют" разработчиков компилятора вносить даже самые расчудесные улучшения в язык?

Может ты не будешь трепать языком как помелом, а просто приведешь пример(ы)?
Думаю какого-то сообщения от разработчика "ой, у вас тут Editionʼы? Не не буду добавлять свою убер фичу!" будет достаточно.

> А когда этих editions станет не 4-5, а 10? 20?

От когда станет, тогда и поговрим.
Пока разработка идет, фичи добавляются.
20 Edition по 3 года каждый... ты думаешь прожить еще лет 60?
Боюсь что ты, что я до этого не доживем.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145

157. Сообщение от Аноним (110), 31-Окт-25, 17:00   +/
На С++ учат сразу использовать умные указатели и семантику перемещений, а в раст наоборот учат не использовать его фичи, потому что сложно и непонятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #163

158. Сообщение от Аноним (-), 31-Окт-25, 17:03   –2 +/
> Ага, свет клином сошелся у кодеров на этих Си,Раст. Остальное либо ругать не за что,либо просто нечего. D

А остальные тут причем?
У всяких пихонов и жабаскриптов своя ниша.
У шишарпов и джавы - тоже своя.

А СИшка и Раст играют на одном поле, даже в одном ядре.
Логично что их сравнивают.
Всякие D и форты не взлетели по разным причинам.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #245

159. Сообщение от senaemail (ok), 31-Окт-25, 17:03   +/
> Нет.

Да. Это русский язык, немного изменённый, но всё ещё русский.

> сами эти образцы между собой несовместимы.

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

Но речь не о том, сильно изменили или не сильно, пусть даже изменили сильно. Речь о том что не ввели его параллельно, а заместили им старый язык, как новый стандарт С++ заменяет старый.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97 Ответы: #172, #184, #284

160. Сообщение от Аноним (91), 31-Окт-25, 17:03   +1 +/
>У других  языков как-то получается обходиться без частых обновлений.

У других - это у каких? Может быть у питона?
>А на Си и код быстрый, и компиляция

Очень быстрая, да
Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%  - https://www.opennet.dev/opennews/art.shtml?num=56449
>а ошибки можно статическим анализатором найти.

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

Человек установил убунту, а мнение будет о расте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #175

161. Сообщение от Аноним (110), 31-Окт-25, 17:03   +1 +/
>Плюсовики смотрят на это утверждение с недоумением

С недоумением, потому что сделать синтаксис хуже C++ нужно было суметь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #182

162. Сообщение от Медведь (ok), 31-Окт-25, 17:04   +/
Смотря какого кода.

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

Вместо наследования -- исключительно композиция: Truck будет владеть Car, а не наследовать от него. Ничто не мешает ему владеть хоть десятком Car.

Делегирование реализации методов вложенному объекту -- только явное: если Car и Truck имплементят трейт Vehicle, то Truck должен явно реализовать каждый метод из Vehicle, даже если он сводится к простому вызову такого же метода у Car. Ну или обмазываемся макросами.

Полиморфизм -- исключительно через трейты.

То есть если предметная область подразумевает иерархическую модель сущностей, то абзац.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #179, #320

163. Сообщение от Аноним (-), 31-Окт-25, 17:04   +1 +/
> На С++ учат сразу использовать умные указатели и семантику перемещений,

И продолжают пложить CVEшки.
Даже всякие костыли в виде MiraclePTR или Safe C++ пытаются делать, но выходит не очень

> а в раст наоборот учат не использовать его фичи, потому что

C++ так и остается дырявым.
И UBшным.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #177

164. Сообщение от senaemail (ok), 31-Окт-25, 17:06   –1 +/
> Язык настолько покромсали и переделали, что от старого остались только какие-то общие структуры. Как сейчас говорят "СИ подобный синтаксис"))

Да пожалуйста, кромсайте, переделывайте. Только не вводите ещё два десятка новых.

> И проще заменить ЯП, чем лепить горбатого до стены.

Заменить - пожалуйста, вводить два десятка языков параллельно - нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #402

165. Сообщение от Медведь (ok), 31-Окт-25, 17:12   –3 +/
>> И снова: "компилируется -- значит работает!"
> Удивительно, но факт.
> ...
> раст обещал снижение проблем управления памятью, а не абсолютно всех проблем сразу,

И эти две фразы в одном посте, а две мысли -- в одной голове...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #187

166. Сообщение от Аноним (166), 31-Окт-25, 17:13   +3 +/
Всего одна CVE у растоманов в tar? Да, до Сишников им еще учиться и учиться:

CVE-2025-45582: Directory traversal vulnerability in crafted TAR archives, potentially leading to file overwrites.
CVE-2022-48303: A heap-based buffer overflow in versions up to 1.34 that can allow for remote code execution.
CVE-2021-20193: Flaw found in src/list.c in versions 1.33 and earlier.
CVE-2019-9923: A NULL pointer dereference in pax_decode_header in versions before 1.32.
CVE-2018-20482: Mishandling of file shrinkage when using the --sparse option in versions through 1.30, which could lead to a denial of service.
CVE-2016-6321: Directory traversal vulnerability that can bypass protection mechanisms to write to arbitrary files, affecting versions 1.14 through 1.29.
CVE-2010-0624: A heap-based buffer overflow in the rmt_read__ function in versions prior to 1.23, potentially allowing remote code execution.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #176

167. Сообщение от Аноним (142), 31-Окт-25, 17:14   +/
Неиронично да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

168. Сообщение от Аноним (166), 31-Окт-25, 17:15   +/
Псс, смотри что я нашел:

https://nvd.nist.gov/vuln/detail/CVE-2025-45582

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

169. Сообщение от Аноним (110), 31-Окт-25, 17:16   +/
У программистов на раст слишком много проблем с прочими уязвимостями. Флагманский проект uutils столько ошибок имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #188, #191

170. Сообщение от Аноним (170), 31-Окт-25, 17:17   –1 +/
>Последующее разыменование подобного указателя приводит к неопределённому поведению.

Как же так, как же могла быть в таком безопасном языке разрешена такая ситуация? Видимо надо было просто сишку юзать, а не на пустые обещания вестись.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #181, #295

172. Сообщение от Аноним (-), 31-Окт-25, 17:20   +/
> Дореформенные тексты вполне можно прочитать даже без подготовки

А писать?
Сможете без ошибок расставить все яти?

>  Речь о том что не ввели его параллельно,

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

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

> а заместили им старый язык, как новый стандарт С++ заменяет старый.

А он не заменяет. Он дополняет.
Можно продолжать пользоваться старым. Вон ядро до 22го года было на С89. И что?

Если нужно "расширять старый", то почему у нас не Алгол-2025?
Почему появился СИ, хотя был B?
Зачем сделали С++, если можно было расширить СИшку?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #183

173. Сообщение от Аноним (173), 31-Окт-25, 17:22   +/
https://visualstudio.microsoft.com/ru/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

174. Сообщение от Аноним (-), 31-Окт-25, 17:23   +1 +/
Значит у авторов пакетов тоже была необходимость использовать найтли.
Они же лучше разбираются чего им надо.
Вы потребитель, а они создатели.
Максимау что вы можете - не пользоваться этим пакетом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #300

175. Сообщение от Аноним (110), 31-Окт-25, 17:27   +/
>У других - это у каких?

С++
>Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%

Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).
>Почему до сих пор не нашли?

Регулярно находят.
>Человек установил убунту, а мнение будет о расте.

Будет плохое мнение о Линукс в целом, а все из-за дыр в коде на раст.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #180, #210

176. Сообщение от Аноним (16), 31-Окт-25, 17:31   –1 +/
>[оверквотинг удален]
> CVE-2022-48303: A heap-based buffer overflow in versions up to 1.34 that can
> allow for remote code execution.
> CVE-2021-20193: Flaw found in src/list.c in versions 1.33 and earlier.
> CVE-2019-9923: A NULL pointer dereference in pax_decode_header in versions before 1.32.
> CVE-2018-20482: Mishandling of file shrinkage when using the --sparse option in versions
> through 1.30, which could lead to a denial of service.
> CVE-2016-6321: Directory traversal vulnerability that can bypass protection mechanisms
> to write to arbitrary files, affecting versions 1.14 through 1.29.
> CVE-2010-0624: A heap-based buffer overflow in the rmt_read__ function in versions prior
> to 1.23, potentially allowing remote code execution.

Дак сишники пишут на небезопасном языке поэтому такое бывает. А растаманы то пишут на безопасном языке, а все равно CVE допускают.

Да и можно подумать если бы растаманы писали на Си, то не допускали бы ошибок? Растаман, пишущий на Си, допустил бы куда больше ошибок, чем сишник пишущий на Си.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #394

177. Сообщение от Аноним (110), 31-Окт-25, 17:34   –1 +/
И что за CVE с умными указателями? Покажите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #270

178. Сообщение от Аноним (111), 31-Окт-25, 17:35   +1 +/
Это самое главное, что мне и хотелось узнать. Благодарю! Значит, связка Python/C++ - будет  наилучшим возможным решением.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #203, #240

179. Сообщение от Аноним (111), 31-Окт-25, 17:38   +1 +/
Да, отсутствие нормального наследования - это весомый недостаток.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #226

180. Сообщение от Аноним (-), 31-Окт-25, 17:39   +1 +/
>>Опубликован набор патчей, ускоряющих сборку ядра Linux на 50-80%
> Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).

Вранье.
Вон в ядро добавили биндер для андроида.
opennet.ru/opennews/art.shtml?num=64092

И что?
Кода получилось даже меньше, скорость не пострадала.

> Будет плохое мнение о Линукс в целом, а все из-за дыр в коде на раст.

Но дыр станет меньше.
Просто по причине, что так написать не позволят автоматические проверки.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #185

181. Сообщение от Facemakeremail (?), 31-Окт-25, 17:41   +2 +/
Разыменование голого указателя возможно только внутри блока unsafe.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

182. Сообщение от Facemakeremail (?), 31-Окт-25, 17:44   +2 +/
>сделать синтаксис хуже C++ нужно было суметь

Сначала было прилично. То есть не хотели. Но потом... одно за другое, и имеем:

<pre>
template<typename T> requires requires (T x) { x + x; }
</pre>

Вот зачем там двойной requires, я уже никогда не пойму (потому что потерял к C++ всякий интерес).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #243, #341

183. Сообщение от senaemail (ok), 31-Окт-25, 17:45   +/
> А писать?

без тренировки не смогу, разумеется

> Зачем сделали С++, если можно было расширить СИшку?

Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.

Когда-то надо выкидывать совместимость со старым кодом. Это произойдёт рано или поздно и с с++ (или же его самого выкинут как алгол). Вопрос только, когда и как. Объявить какие-то конструкции устаревшими и перестать их поддерживать лет через какой-то разумный срок - почему нет? Да, это не так быстро, как сляпать новый язык, но это правильный, разумный, эволюционный путь развития.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #195, #198

184. Сообщение от Аноним (91), 31-Окт-25, 17:48   +/
>Да. Это русский язык, немного изменённый, но всё ещё русский.

У вас не будет дискретного перехода, типа говорили не на русском, а потом вдруг раз и на русском. Но вот историки и лингвисты, описывая тот старый язык будут называть его по другому, вроде древнерусского и так далее.
>Совместимость понятие растяжимое.

Вы просто не чувствуете изменений. Возьмём для примера шутку
>мальчик склеил модель в клубе

Если бы вас изолировали от изменений в языке, вы бы поняли данную фразу иначе. И таких фраз, которые приобретают новый смысл с течением времени становится всё больше. В какой-то момент вы перестанете понимать язык настолько сильно, что он для вас будет звучать как иностранный.
>Дореформенные тексты вполне можно прочитать даже без подготовки.

Прочитать - понятие растяжимое. Как только меняется алфавит, так сразу же меняется и чтение. А алфавит менялся не раз и не два, в том числе и количество букв. В частности, беглый поиск говорит о том, что букву й как удаляли, так и восстанавливали. А это значит, что правильно прочитать этот символ вы попросту не в состоянии, как минимум не зная дату публикации текста. Просто у лингвистов нет ни системы контроля версий ни даже такого понятия, вот они и не пишут русский язык 1780, русский язык 2025. А то, что у них начало названия совпадает "русский язык", так это так, совпадение.
>Речь о том что не ввели его параллельно, а заместили им старый язык

Как вы себе это представляете? Вот возьмут и внедрят самую малость - запретят нулевые указатели. И всё - почти весь код, за исключение совсем hello world перестал собираться.
>как новый стандарт С++ заменяет старый.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #193

185. Сообщение от Аноним (110), 31-Окт-25, 17:50   –1 +/
>И что?
>Кода получилось даже меньше, скорость не пострадала.

Я про скорость компиляции, если что.
>Но дыр станет меньше.
>Просто по причине, что так написать не позволят автоматические проверки.

Дыр касательно памяти может быть и будет меньше, а вот касательно логики работы будет больше. Кто просил их добавлять новые в uutils?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #211

186. Сообщение от Аноним (166), 31-Окт-25, 17:55   +2 +/
Всего одну? Считаю, что отлично! А вот в GNU tar совсем все плохо с безопасностью, в свежем CVE за этот год опять относительные пути при распаковке не проверяли, и тут дело даже не в языке...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

187. Сообщение от Аноним (91), 31-Окт-25, 17:57   +3 +/
>И эти две фразы в одном посте, а две мысли -- в одной голове...

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #233

188. Сообщение от Аноним (166), 31-Окт-25, 17:58   +4 +/
Но ведь такой же сишечный проект от gnu на порядки больше ошибок/CVE имеет. Неудобно как-то получилось...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

189. Сообщение от Аноним (166), 31-Окт-25, 17:59   +3 +/
Ho ведь в GNU coreutils на порядки больше ошибок, особенно CVE...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #281

190. Сообщение от Онанимус (?), 31-Окт-25, 17:59   +1 +/
Неосилятор? Без ИИшки в простом языке разобраться не можешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #196, #208

191. Сообщение от Аноним (91), 31-Окт-25, 17:59   +1 +/
>У программистов на раст слишком много проблем с прочими уязвимостями.

Вы так говорите, словно от того, что проект писался бы на си, уязвимостей у него было бы меньше.
>Флагманский проект uutils столько ошибок имеет.

Ошибки != уязвимости

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

192. Сообщение от Аноним (166), 31-Окт-25, 18:00   +2 +/
> TARmageddon компилировался.

Тем временем в gnu tar все еще (в 2025) путаются в относительных путях:
CVE-2025-45582: Directory traversal vulnerability in crafted TAR archives, potentially leading to file overwrites.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

193. Сообщение от senaemail (ok), 31-Окт-25, 18:01   +/
> Как вы себе это представляете? Вот возьмут и внедрят самую малость - запретят нулевые указатели. И всё - почти весь код, за исключение совсем hello world перестал собираться.

Всё просто по-моему. Допустим по какой-то причине решили запретить и вместо нулевого указателя теперь надо использовать nullptr. Дальше нулевые указатели продолжают работать какое-то время, на протяжении X стандартов (где Х = 1, 2, 4, 10 в зависимости от тяжести изменений и трудности поддержки), но выдаётся предупреждение. После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.

> В C++ стандарты не заменяют друг друга, они просто расширяют язык.

Никто не запрещает в новом стандарте объявить какую-то конструкцию устаревшей.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #199, #204

194. Сообщение от Аноним (194), 31-Окт-25, 18:05   +2 +/
А нафига вообще контейнер в виде тара? Это лишняя сущность, которую надо просто выкинуть и никогда больше не вспоминать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #213

195. Сообщение от Аноним (91), 31-Окт-25, 18:06   +/
>В 99% случаев сишный код компилируется в с++.

Слова эксперта. Сишный код компилируется во что угодно - в ассемблер, промежуточное представление, во что угодно, только не в c++.
>Объявить какие-то конструкции устаревшими

Ну и чем это будет лучше раста?
>и перестать их поддерживать лет через какой-то разумный срок - почему нет?

Разумный срок - это какой? У вас будет всё равно тот же самый раст, только лет на сто позже.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #280

196. Сообщение от Аноним (91), 31-Окт-25, 18:08   +/
Конечно неосилятор. Иначе бы знал, что раст появился до ИИ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #262

197. Сообщение от Аноним (194), 31-Окт-25, 18:08   +2 +/
> Вот когда на деле _реально_ предотвратит

Вас в РГУ логике обучали? Утверждение «Х противоречит Y” (то есть предотвращает) доказывается математически, а не бытовыми примерами. А вот опровергается элементарно - достаточно 1 примера, когда не предотвратил. Примеры есть? Нету? До свидания.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

198. Сообщение от Аноним (-), 31-Окт-25, 18:09   +/
> без тренировки не смогу, разумеется

Ну, т.е придется брать учебни и учиться.
На учебние будет написанно Церковный Русский Язык.
А я мог бы вспомнить старославянский.

"Не лѣполи ны бяшетъ, братіе, начяти старыми словесы трудныхъ повѣстій о пълку Игоревѣ, Игоря Святъславлича!"
От чо такое "лѣполи ны бяшетъ"?

А ведь его же тоже можно было расширать, а не делать отдельно русский, украинский, белорусский?))

> Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.

Что-то меня терзают смутные сомнения про 99%.
Скомпилироваться оно то сможет, а вот корректно работать...
Посмотри сколько ерраты пишут для разных версий компиляторов, да еще и для разных версий языков.

> Когда-то надо выкидывать совместимость со старым кодом. Это произойдёт рано или поздно и с с++ (или же его самого выкинут как алгол). Вопрос только, когда и как.

Ну как мы наблюдаем прямо сейчас.
Примерно так же было и 20 лет назад. И 30 тоже.

> Объявить какие-то конструкции устаревшими и перестать их поддерживать лет через какой-то разумный срок - почему нет? Да, это не так быстро, как сляпать новый язык,

Ну думаю что добавить deprecated это сложнее чем сделать новый язык.
Как добавить боров в СИ, чтобы не сломать совместимость?
А если коммитет не хочет?

> но это правильный, разумный, эволюционный путь развития.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #279

199. Сообщение от Аноним (-), 31-Окт-25, 18:13   +/
> Дальше нулевые указатели продолжают работать какое-то время, на протяжении X стандартов (где Х = 1, 2, 4, 10 в зависимости от тяжести изменений и трудности поддержки), но выдаётся предупреждение.

Предупреждение затыкается, как было в ядре, где попытались сдалеть "warning == error".
Оказалось тонных дидовых хаков отвалились.

> После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.

Народ сидит на старом.
Те кто решил пользоваться новым приходится спотыкаться о старые костыли, которые еще поддерживаются.

> Никто не запрещает в новом стандарте объявить какую-то конструкцию устаревшей.

Конечно.
Но если у тебя ломается вся логика языка, то так будет очень сложно.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #282

201. Сообщение от ptr (ok), 31-Окт-25, 18:20   +/
Уфф, пронесло. На этот раз нигде в std типы аргументов или возвращаемых значений не меняли. Так что есть все шансы на перекомпиляцию без правок исходников.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #206

202. Сообщение от Аноним (202), 31-Окт-25, 18:21   +/
Проблема с Карбоном что он сложный. Не менее сложный чем C++ и Rust. Почему первые версии Java и C# привлекли разработчиков ? Потому что были проще C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #217

203. Сообщение от Аноним (-), 31-Окт-25, 18:27   +/
А да ты ленивый программист! Ну так бы сразу и сказал бы, типа я ленивый! А то у людей спрашиаешь, типа интересен Rust. Да не интересен тебе Rust! Тебе надо чтобы всё легко было.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #205, #303

204. Сообщение от Аноним (91), 31-Окт-25, 18:27   +/
>Допустим по какой-то причине решили запретить и вместо нулевого указателя теперь надо использовать nullptr

Нет. У вас будет option.
>в зависимости от тяжести изменений и трудности поддержки

У вас поломались абсолютно все сишные проекты.
>но выдаётся предупреждение

Вы масштабы себе представляете? Ядро Linux - более 40 000 000 строк кода. Допустим, каждая 1 000 строка имеет проблему, у вас 40 000 предупреждений. Всё, вы утонули в этих предупреждениях, поскольку ну даже 10 ошибок в коде, никак не связанных с этой проблемой просто потеряются во всех этих 40 000-ах. Вам нужно прямо сейчас бросать всё и идти чинить эти предупреждения, так как иначе, если вы будете их откладывать, то никогда не закончите. Далее, у вас появились гигиенические макросы, держите ещё 40 000 предупреждений. Это не говоря уже о том, что какие-то моменты автоматически доказать нельзя, и код придётся переписывать целиком.
>в зависимости от тяжести изменений и трудности поддержки

Ну дадут вам лет 50 на исправление ошибок, а сейчас как жить?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #193 Ответы: #283

205. Сообщение от Аноним (111), 31-Окт-25, 18:30   +1 +/
Чем проще, тем лучше. Прототипирование на Python, с последующим переписыванием на С++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #225, #232

206. Сообщение от Аноним (-), 31-Окт-25, 18:37   +1 +/
Хм, мне казалось что такая проблема может быть только с хоббийными проектами.
В тех проектах в которых я принимал участие фиксировалась версия языка (что для СИ, что для С++).

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #218

207. Сообщение от Аноним (207), 31-Окт-25, 18:40   +/
> Правительство США призывает отказаться

нашли кому верить

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #248

208. Сообщение от Аноним (110), 31-Окт-25, 18:48   +/
Так не только я разобраться не могу. Повальное большинство программистов на раст тоже не может без ИИ в нем разобраться. Иначе почему в рейтингах раст ниже php?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #239

209. Сообщение от Аноним (209), 31-Окт-25, 18:58   +/
брусок утечет из-за oomkiller
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107

210. Сообщение от Аноним (91), 31-Окт-25, 19:16   +1 +/
>С++

Ага, и выбрали язык с UB, отвратительным временем компиляции и колосальной сложностью в освоении
>Добавят еще раста и станет на 50%-80% медленнее (на самом деле больше).

Ну разумеется никаких доказательств этому у вас нет.
>Регулярно находят.

Старые находят, новые добавляют.
>а все из-за дыр в коде на раст

Очень ловко вы ошибку(а не дыру) в убунте записали в дыру раста. А давайте ещё сишные ошибки туда же засунем?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

211. Сообщение от Анонимусс (?), 31-Окт-25, 19:26   +1 +/
Ты бы хоть разобрался в чем проблема была в uutils, прежде чем набрасывать.
Они использовали какой-то флаг, который используется исключительно в гнутых утилитах. Причем этот флаг был добавлен за месяц до релиза убунты, но они не обновили свою версию.
Но виноваты конечно растеры))

> Кто просил их добавлять новые в uutils?

Да куча причин.
Дыры обычных гнутых утилит.
Раковая лицуха.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

212. Сообщение от анодр (?), 31-Окт-25, 19:33   +/
TIOBE врать не будет;) Интерес к Rust в поисковиках падает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #216

213. Сообщение от Аноним (166), 31-Окт-25, 19:35   +/
Права доступа и прочие атрибуты хранить. Кто так умеет ещё? RAA мог бы, но он поддерживает только метаданные NTFS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #214, #277

214. Сообщение от Аноним (166), 31-Окт-25, 19:35   +/
*RAR
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

215. Сообщение от анодр (?), 31-Окт-25, 19:40   +/
Улыбнуло. В Rust реализуемо переполнение буфера cve-rs и другие уязвимости 100 проценто безопасно (без unsafe кода)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #220, #222

216. Сообщение от Аноним (-), 31-Окт-25, 19:40   –1 +/
> TIOBE врать не будет;) Интерес к Rust в поисковиках падает...

Это тот у которого Visual Basic на 7 месте и опережает Go?
А Delphi опереждает SQL?
Swift проигрывает Classic Visual Basic?

Однозначно серьезный рейтинг)))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #258

217. Сообщение от анодр (?), 31-Окт-25, 19:42   –1 +/
Java с идеей стирания типов в генериках небезопасна на что сверху может накладываться динамическое разрешение методов. Все есть Object
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202

218. Сообщение от ptr (ok), 31-Окт-25, 19:43   +1 +/
Последний раз мне больно досталось с выходом Rust Version 1.85.0 (2025-02-20), когда core::ffi::c_char сменился с i8 на u8. https://doc.rust-lang.org/stable/releases.html#version-1851-...
Они честно написали "The new definition may result in compilation failures but fixes compatibility issues with C". Но мне от этого легче не стало.

> Там завезли какие-то супер фичи или фиксы, чтобы была необходимость всять самую свежу версию?

Проблема в том, что желающих поддерживать свои библиотеке для всех версий Rust исчезающе мало. Поэтому исправление критической уязвимости где-нибудь в ESP-IDF-HAL требует перехода на новую версию компилятора. Или же твой ESP32 окажется уязвим и будет торчать дырой в эфире, доступный любому желающему уже известной уязвимостью воспользоваться.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #238, #274

220. Сообщение от Аноним (220), 31-Окт-25, 19:47   +1 +/
> Улыбнуло. В Rust реализуемо переполнение буфера cve-rs и другие уязвимости 100 проценто безопасно (без unsafe кода)

Ага, та самая которую неделю ломали, и в итоге пришлось писать самописный null_mute,  велосипедно-обфусцированный transmute и тд?

Так это отличный пример!
Вам придется хорошо напрячься, написать кучу кода, чтобы получить ошибку.

ps кажется ваша методичка уже не актуальна
https://github.com/Speykious/cve-rs/issues/3


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #454

221. Сообщение от Аноним (230), 31-Окт-25, 19:52   +2 +/
Достаточно, чтобы избавиться от 70% проблем C/C++. Гугл с Майкрософтом приводили статистику.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #253

222. Сообщение от dhsksje (?), 31-Окт-25, 19:53   +1 +/
cve-rs это баг компилятора если что, да, представляете, даже в компиляторе написанном на расте оказывается есть баги!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #371

223. Сообщение от Аноним (223), 31-Окт-25, 19:53   +1 +/
Реализовывать идеи в виде нового языка - это нормально.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #228, #285

224. Сообщение от Аноним (224), 31-Окт-25, 19:53   +/
> кольчужные перчатки хирургам

Черт! В следующий раз операцию себе сам делаю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

225. Сообщение от Аноним (230), 31-Окт-25, 19:55   +2 +/
> Чем проще, тем лучше.
> С++

Ты то ли тролль, то ли тебя ждет много интересных открытий.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

226. Сообщение от Аноним (230), 31-Окт-25, 19:56   +2 +/
> Да, отсутствие нормального наследования

С каких это пор наследование в стиле C++ начало считаться нормальным?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #234

227. Сообщение от dhsksjed (?), 31-Окт-25, 19:58   +1 +/
включите немного голову, пока указатель не разыменован есть ли разница что за адрес в нем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

228. Сообщение от Аноним (-), 31-Окт-25, 20:04   +3 +/
> А вот начинать его всюду пропихивать, в т.ч. в прекрасно существующие проекты на других языках,

А это уже закрещено?
К создателям проекта приходят с предложением. Они могут принять или нет.
Никакого пропихивания.

Да и никто не может запретить переписать любой софт на другой ЯП.
Сколько там было версий emacs на разных языках от разных создателей?

> и переписывать всё подряд на своём самом лутшем языке -

Напомню что СИ был создан для того, чтобы переписать unix.
ПЕРЕПИСАТЬ, тк оно уже было и работало.

> это уже нездоровое.

Только в твоих фантазиях)
Серьезыне организации, как например разработчики ядра уже оценили достоинства новых подходов.
Корпорации уже массово используют.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223

229. Сообщение от OpenEcho (?), 31-Окт-25, 20:33   +/
> А раст это навсегда!

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #400

230. Сообщение от Аноним (230), 31-Окт-25, 20:35   +3 +/
>> Встроенного сжатия нет
> Ага, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.

Чел, изначально было заявление, что tar - плохой формат. Архиватор, а не компрессор говоришь? Ну так подскажи, эксперт, как в твоем "хорошем" tar.gz получить список файлов (не говоря уж о том, чтобы извлечь один последний файл) в 10 GB архиве, не перечитывая-распаковывая при этом весь tar.gz?

Прекрасный формат, да. Прямо хрестоматийный пример тупиковости подхода Unix-way. Диды дизайнили!

Господи, и твоему же комментарию еще плюстки ставят! В очередной раз показывает уровень местных экспертов.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #250

231. Сообщение от Аноним (91), 31-Окт-25, 20:36   +4 +/
>а во всём остальном коде ошибок с памятью быть не может?

Безусловно.
>нужно внимательно проверять только unsafe блоки

Совершенно верно. Вы не сможете разыменновать в safe блоке указатель.
>Но ведь реально ошибка не по месту разыменования

Слушайте, а вы что, реально не понимаете разницу между указателем и ссылкой? По умолчанию, программист на rust использует ссылки - они висячими не бывают. Программист может безопасно превратить любую ссылку в указатель, от этого ничего плохого не будет. А вот разыменновывание указателя - это вещь опасная, и каждый раз, когда программист это делает, он принимает риск на себя. Как только вы видите в коде на rust блок unsafe, вы должны сразу же задать вопрос - а зачем он здесь есть? Если же блок действительно нужен, то следом вы должны проверить, что все приходящие в него данные полностью корректны. Указатели нужны только для особых, исключительных случаев.
>всё это время

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132

232. Сообщение от Аноним (91), 31-Окт-25, 20:40   +/
>Чем проще, тем лучше.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #235

233. Сообщение от Аноним (230), 31-Окт-25, 20:44   +/
>>И эти две фразы в одном посте, а две мысли -- в одной голове...
> Я не пойму, вы что, ни разу код не писали?

Конкретно этот воин - нет, не писал. Он же в предыдущих темах о Расте предлагал ошибки работы с памятью ловить при помощи юнит-тестов и интеграционного тестирования. А еще искренне недоумевал, почему borrow checker не помогает при работе с растовым Arc/Rc.

Это чтобы ты понимал уровень этого персонажа.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187

234. Сообщение от Аноним (-), 31-Окт-25, 20:46   +/
> С каких это пор наследование в стиле C++ начало считаться нормальным?

Уточка увидила наследование как в с++ первым и теперь считает что это единстванное верное наследование :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #246

235. Сообщение от Аноним (-), 31-Окт-25, 20:46   +1 +/
> Ну так берите си, тогда без питона прототипировать будете. Зачем лишний раз переписывать?

И начать с реализации String-типа потому что в недоязыке такого нету из коробки?
А потом плавно переходить к поддержке юникода.
Примерно через год, можно будет посмотреть в сторону работы с сетью.
И тд))


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #232 Ответы: #259

236. Сообщение от OpenEcho (?), 31-Окт-25, 20:47   –3 +/
> В том, что вы возвратите указатель нет ничего страшного.

Т.е. созданая на стеке локальная переменная изчезнет при выходе из функции, а возвращенный указатель на нее где-то там всё еще может "безопастно" указывать на... что?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #257

237. Сообщение от OpenEcho (?), 31-Окт-25, 20:52   +/
> Для первого ЯП нужно что-то простое, что позволит освоить алгоритмы и структуры данных.

Basic ! No, PowerBasic ! Хотя не, Повер уже был довольно мощной штучкой, лучше в руки детям не давать :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

238. Сообщение от Медведь (ok), 31-Окт-25, 20:53   +/
Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно все, ну вот прям совсем все проблемы с поддержкой легаси-кода. Неужто врали? ;)

Спасибо за ваш пост.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #244, #249, #267, #290

239. Сообщение от Аноним (239), 31-Окт-25, 20:53   +2 +/
Феноменальная логика. В коболе видимо даже ИИ не помогает, а чтобы писать на Форте нужен оракул, не иначе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208 Ответы: #286

240. Сообщение от анодр (?), 31-Окт-25, 20:53   +/
Nim - простота Python, сборка мусора, производительность C/C++, трансляция в C++, C, JavaScript, и WebAssembly
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #313

242. Сообщение от Аноним (239), 31-Окт-25, 20:57   +/
Ох, ну куда вы лезете? Оно за аду ратовало, потому что оно ее создало!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #260

243. Сообщение от анодттт (?), 31-Окт-25, 21:00   –1 +/
Одно ограничивает тип, второе возвращает булево значение. Отделите второе в концепт:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

244. Сообщение от Аноним (-), 31-Окт-25, 21:03   –2 +/
> с пеной у рта доказывали,

Это ты сам выдумал?

> что editions решают абсолютно все, ну вот прям совсем все

И это то же)?

> проблемы с поддержкой легаси-кода. Неужто врали? ;)

Если выдумывать несущесвующие "постулаты", то та - вам все врут.

Напомнило одного местного, который носился с "раст не защищает от всех уязвимостей!!11"
Его спрашиваешь "а кто тебе такое обещал?"
В ответ "Абырвалг!!!"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

245. Сообщение от анодттт (?), 31-Окт-25, 21:04   +/
Rust пытается играть на поле C. Это C подобный язык, но не C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #251

246. Сообщение от Медведь (ok), 31-Окт-25, 21:04   –1 +/
> Уточка увидила наследование как в с++ первым и теперь считает что это единстванное верное наследование :)

... завопили адепты языка, где наследования реализации нет совсем, ни в каком виде. Ну покажите в расте ООП как в smalltalk, или что вы там считаете классикой ООП.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #234 Ответы: #265

247. Сообщение от Аноним324 (ok), 31-Окт-25, 21:06   +/
Ну скорее всего да, и это фактически единственный верный способ его понять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

248. Сообщение от агент госдепа (?), 31-Окт-25, 21:08   +3 +/
ну не тебе же !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207

249. Сообщение от анодттт (?), 31-Окт-25, 21:08   +1 +/
Rust это про супер супер вау, но не поддержку и фичи. Все недоделанное какое-то и несовместимое между собой. Даже в core utils на Rust налажали, но зато "безопасно"🤷‍♂️
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

250. Сообщение от Аноним (16), 31-Окт-25, 21:14    Скрыто ботом-модератором–2 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #230

251. Сообщение от Аноним (-), 31-Окт-25, 21:15   –2 +/
У Чистой нет конкуррентов. Раст конкурент C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245 Ответы: #376, #417

252. Сообщение от Аноним (16), 31-Окт-25, 21:19   +/
> Зачем вам для компилятора указатели?

В смысле зачем? Потому что я не хочу все AST-дерево копировать при передачи в функцию. Открой хотя бы gcc и посмотри зачем там указатели.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #255

253. Сообщение от Аноним (110), 31-Окт-25, 21:27   –2 +/
Если бы раст помог избавиться от всех проблем работы с памятью, но это не так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221

254. Сообщение от Аноним (254), 31-Окт-25, 21:54   +/
Ты походу не догнал вопрос... Речь не про какие-то там кря-кря, а про компилятор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

255. Сообщение от Аноним (91), 31-Окт-25, 22:09   +/
>Потому что я не хочу все AST-дерево копировать при передачи в функцию.

Эм. Если вы пишете на языке со сборщиком мусора, то у вас из коробки данные будут автоматически передаваться по ссылке, послностью прозрачно для вас. Если вы пишите на расте, то у вас будут самые обыкновенные ссылки, с контролем владения, которые разыменновывать надо руками. Если у вас c++, swift, и целой плеяде кучи других языков - у вас будут умные указатели. В 2025 году даже в исключительных случаях, вроде драйверов и операционных систем, указатели нужны только в исключительных случаях, когда по другому просто никак.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #252

257. Сообщение от Аноним (91), 31-Окт-25, 22:14   +3 +/
>а возвращенный указатель на нее где-то там всё еще может "безопастно" указывать на... что?

Указатель на то и указатель, что для него не осуществляется никаких проверок. Хотите проверок - берите ссылку. Поскольку выход из функции, это не единственная причина, по которой указаетль может стать висячим.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #236

258. Сообщение от Аноним (258), 31-Окт-25, 22:16   +2 +/
А вот если бы VB был на 7-м месте, опережая Go, Delphi опережал SQL, а Swift проигрывал CVB, но Раст был бы на первом месте, то ты бы первый орал, что рейтинг самый правильный. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216 Ответы: #272

259. Сообщение от Аноним (91), 31-Окт-25, 22:17   +/
>И начать с реализации String-типа потому что в недоязыке такого нету из коробки?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #235

260. Сообщение от zionist (ok), 31-Окт-25, 22:29   +/
Без разницы кто его создал. В обоих случаях правительством был выбран некий язык, казавшийся серебрянной пулей в программировании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242 Ответы: #398

262. Сообщение от x3who (?), 31-Окт-25, 22:56   +/
Но он получился как будто бы специально для ИИ!
1. Ещё не подтянулись всякие ЛГБТшники со своим инклюзивным кодом - ИИшка учится на хороших примерах, написанных умными человеками
2. Строгий конпилястор - бьёт ИИ-шке по рукам в случае чего

Только я этого не понил: "Добавлено lint-предупреждение "dangling_pointers_from_locals" "разыменование подобного указателя приводит к неопределённому поведению" - это же должен быть егог, а не вагнинг!?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196 Ответы: #263

263. Сообщение от Аноним (-), 31-Окт-25, 23:28   +/
> Только я этого не понил: "Добавлено lint-предупреждение "dangling_pointers_from_locals"

Не удивительно.

> "разыменование подобного указателя приводит к неопределённому
> поведению" - это же должен быть егог, а не вагнинг!?

Так там же другой ворниниг "a dangling pointer will be produced" - вы создаете dangling pointer, а не разыменоваваете.
Если ты его вернешь и никто не будет его использовать - то ничего страшного не случится.
А в safe коде ты просто не сможешь его разыменовать. Вот вообще))

Значит тебе придется писать unsafe, а раз ты это сделал - то знаешь что делаешь.
А если не знаешь - то не пиши unsafe, пользуйся ссылкой, а не указателем.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #262 Ответы: #269

265. Сообщение от Аноним (230), 01-Ноя-25, 00:16   +1 +/
>> Уточка увидила наследование как в с++ первым
> Ну покажите в расте ООП как в smalltalk, или что вы там считаете классикой ООП.

Чел, иди проспись. Ты сам заливал про ООП именно в том виде, которое оно есть в C++, а теперь вдруг запел про Smalltalk и какую-то "классику ООП". Ты из нейронки бред копипастишь, или как это объяснить?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #246 Ответы: #294

267. Сообщение от Аноним (230), 01-Ноя-25, 00:25   –3 +/
>> Последний раз мне больно досталось с выходом Rust Version 1.85.0
> Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно все

Чел, он пишет как раз о новом edition (2024). Перестань позориться наконец-то...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238 Ответы: #292, #299

269. Сообщение от Аноним (16), 01-Ноя-25, 01:02   –1 +/
И все это добро потом компилируется компилятором, написанным на плюсах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #263 Ответы: #273

270. Сообщение от Аноним (-), 01-Ноя-25, 01:07   +1 +/
> И что за CVE с умными указателями?

CVE-2024-5839 напр. MiraclePtr bypass due to PtrCount overflow

Но с ними другие проблемы - они потребляют ресурсы. Даже тут новость была opennet.ru/60482
"Потребление памяти основным процессом браузера при применении MiraclePtr увеличивается на 5.5-8% в сборках для настольных систем". И они защищают в основном от use-after-free.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #288

272. Сообщение от Аноним (272), 01-Ноя-25, 01:27   –1 +/
> то ты бы первый орал, что рейтинг самый правильный.

Нет конечно!
Я спросил бы "а где толпы веб-камак? ну всякие бессмертные ПХПшники и прочие жабаскриптеры?".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #258

273. Сообщение от Аноним (-), 01-Ноя-25, 01:32   +1 +/
> И все это добро потом компилируется компилятором, написанным на плюсах?

Нет, компилируется компилятором написанным на раст. rustc называется.
В нем и происходят все валидации типов, проверки времени жизни, владения и тд.
На выходе получаем LLVM-IR.

А вот LLVM-IR компилируется llvm в машинные коды.
Но llvm не единственный кодогенератор для раста.
Есть еще и Cranelift, написанный тоже на расте, которых хоть и отстает от llvm по количеству оптимизаций и поддерживаемых платформ, тоже неплохая альтернатива.

ЗЫ: а вас не смущает что ядро и весь остальной код на си компилирует компилятор на с++?
Неужели на сишечке не осилили?))


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #269 Ответы: #384

274. Сообщение от morphe (?), 01-Ноя-25, 01:55   +1 +/
> Они честно написали "The new definition may result in compilation failures but fixes compatibility issues with C". Но мне от этого легче не стало.

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

Неприятно, да, но у кода изначально была проблема с портабельностью

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #218 Ответы: #297

275. Сообщение от Аноним (276), 01-Ноя-25, 02:06   +3 +/
> Встроенное сжатие зачем гвоздями прибивать?

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79

276. Сообщение от Аноним (276), 01-Ноя-25, 02:28   +2 +/
> Какая разница что там было изначально?

Намекну: ленты где-то с 1984 (DLT) имеют своё сжатие, а индекс для ускорения случайного доступа там не требуется, потому что случайного доступа нет.

> Ага, и mp4 воспроизводить не умеет. Наверно потому что это архиватор, а не видеоплеер или компрессор.

В разделении на компрессор и архиватор нет чего-то такого, чем стоит гордиться.

Противоположный путь выбрали не только в винде, но и в макоси (.sit, .xar, .aa), и в линуксовых ФС. Помимо очевидного, EROFS, SquashFS, DwarFS - по сути монтируемые архивы (в которых не реализовали функцию добавления файла ради простоты или по идеологическим причинам...).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

277. Сообщение от alex74 (?), 01-Ноя-25, 02:29   +/
ZIP умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #213

279. Сообщение от senaemail (ok), 01-Ноя-25, 02:55   +/
> Ну, т.е придется брать учебни и учиться.

А зачем мне учиться писать на устаревшем языке?

>> Не можно, а нужно. Как раз с++ и есть по-большому счёту расширение с. В 99% случаев сишный код компилируется в с++.
> Что-то меня терзают смутные сомнения про 99%.
> Скомпилироваться оно то сможет, а вот корректно работать...

В том и дело, что нормально работает, проверено, с минимальной обработкой напильником. И это правильный подход.

> Ну думаю что добавить deprecated это сложнее чем сделать новый язык.

Сложнее конечно, но это правильный путь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #403

280. Сообщение от senaemail (ok), 01-Ноя-25, 02:57   +/
> Разумный срок - это какой? У вас будет всё равно тот же
> самый раст, только лет на сто позже.

Да, позже, но всё старое спокойно перекочует в этот новый "раст".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

281. Сообщение от Аноним (102), 01-Ноя-25, 03:11   –1 +/
> Ho ведь в GNU coreutils на порядки больше ошибок, особенно CVE...

А в Линукс-ядре сколько дыр-то! Переходите на венду, там с растом будет идеал безопасности!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #395

282. Сообщение от senaemail (ok), 01-Ноя-25, 03:11   +/
> Предупреждение затыкается, как было в ядре, где попытались сдалеть "warning == error".
> Оказалось тонных дидовых хаков отвалились.

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


>> После этого в очередном новом стандарте старый код перестаёт компилироваться и выдаёт ошибку.
> Народ сидит на старом.

Когда-то придётся переходить на новый (когда поддержку старого стандарта выкинут). Тут уж хозяин-барин. Есть однако большая разница между "подправить проблемные места" и "перейти на принципиально другой язык".


> Те кто решил пользоваться новым приходится спотыкаться о старые костыли, которые еще
> поддерживаются.

Да, так сейчас в с++, к сожалению. Потому что старые костыли надо всё-таки постепенно выкидывать. А в современном с++ всё ещё bool при вызове функции автоматически конвертируется во float...


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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

283. Сообщение от senaemail (ok), 01-Ноя-25, 03:17   +/
>[оверквотинг удален]
> 000 предупреждений. Всё, вы утонули в этих предупреждениях, поскольку ну даже
> 10 ошибок в коде, никак не связанных с этой проблемой просто
> потеряются во всех этих 40 000-ах. Вам нужно прямо сейчас бросать
> всё и идти чинить эти предупреждения, так как иначе, если вы
> будете их откладывать, то никогда не закончите. Далее, у вас появились
> гигиенические макросы, держите ещё 40 000 предупреждений. Это не говоря уже
> о том, что какие-то моменты автоматически доказать нельзя, и код придётся
> переписывать целиком.
>>в зависимости от тяжести изменений и трудности поддержки
> Ну дадут вам лет 50 на исправление ошибок, а сейчас как жить?

А зачем исправлять сразу все 40000000 строк? Включил для одного модуля (файла), исправил, включил для другого - исправил... Делов-то... Какие-то высосанные из пальца проблемы придумываешь.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204 Ответы: #327

284. Сообщение от Аноним (102), 01-Ноя-25, 03:21   +/
> Совместимость понятие растяжимое. Дореформенные тексты вполне можно прочитать даже без
> подготовки.

О какой реформе идёт речь? Их было сильно больше чем та, что была в начале 20-го века.

Попробуйте почитать тексты середины, а ещё лучше начала тысячелетия, сильно удивитесь, как русский язык, живой язык (!), менялся со временем.

А выпячивание псевдорусскости оставьте показушникам, стремящимся на её основании заявить о воображаемом величии.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #287

285. Сообщение от senaemail (ok), 01-Ноя-25, 03:29   +/
> Реализовывать идеи в виде нового языка - это нормально.
> А вот начинать его всюду пропихивать, в т.ч. в прекрасно существующие проекты на других языках, и переписывать всё подряд на своём самом лутшем языке - это уже нездоровое.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223

286. Сообщение от Аноним (286), 01-Ноя-25, 03:41   –3 +/
На коболе и фортране почти уже никто не пишет. Вы хотите сказать, что на раст тоже никто не пишет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #239 Ответы: #397

287. Сообщение от senaemail (ok), 01-Ноя-25, 03:51   +/
>> Совместимость понятие растяжимое. Дореформенные тексты вполне можно прочитать даже без
>> подготовки.
> О какой реформе идёт речь? Их было сильно больше чем та, что
> была в начале 20-го века.

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

Желание выкинуть один популярнейший язык и заменить его новым, в котором ОДНА какая-то идея реализована лучше это просто безумие...

Но если с++-ный комитет не будет решать насущные проблемы, то так и будет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284 Ответы: #328, #404

288. Сообщение от Аноним (286), 01-Ноя-25, 03:57   +1 +/
Это велосипед от гугла, а нормальный умный указатель из стандартной библиотеки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #270

289. Сообщение от senaemail (ok), 01-Ноя-25, 04:21   +/
> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих
> пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит
> память.

Согласен.

> Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст,
> ничуть не лучше текущего.

Ну и прекрасно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #407, #408

290. Сообщение от Аноним (-), 01-Ноя-25, 05:06   +3 +/
> Странно, а мне вот чуть выше по треду с пеной у рта доказывали, что editions решают абсолютно все, ну вот прям совсем все проблемы с поддержкой легаси-кода. Неужто врали? ;)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #238

291. Сообщение от Аноним (276), 01-Ноя-25, 05:55   +/
> Но ведь мы не выкидываем русский язык из-за того что появились новые идеи?

Поэтому
- в C++ и D хорошая совместимость с C.
- языков для JVM или .NET сильно больше одного
- JS продолжают развивать
- TS строят поверх JS
- питону уже 34 года
- к питону прикручивают аннотации
- живёт идея, что из питона можно сделать что угодно (sympy, jax, triton)
- мейнстримная функциональщина успешно проникает в живые языки, независимо от их возраста (pattern matching в Java 17, лямбды в C++11)

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

292. Сообщение от Медведь (ok), 01-Ноя-25, 08:23   –3 +/
Позорятся тут в основном растуны. Если проект развивается на моменты выхода свежатинки, ты всерьез предлагаешь одну половину оставить на старой редакции, другую допиливать на новой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #339

294. Сообщение от Медведь (ok), 01-Ноя-25, 08:29   +/
Да хоть какое-то ООП покажи уже в этом своем убогом расте, дятел. Какая на фиг разница, говорю я про ООП в стиле C++ или smalltalk, если в твоем жалком недоязычке нет ни того ни другого.

Внимание, сейчас растуны начнут вопить, что в коране... ой, в расте есть все что нужно, а если чего-то в расте нет, то  оно и не нужно.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265 Ответы: #314, #315, #361, #399

295. Сообщение от dhsksjed (?), 01-Ноя-25, 08:31   +2 +/
тут в соседней ветке уже ответили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170

296. Сообщение от Аноним (296), 01-Ноя-25, 09:10   +1 +/
> Раст должен будет заменить еще более безопасный язык, напр. с автоматической или хотя бы с дешевой верификацией, который будет не давать сделать хотя бы часть логических ошибок.

Не туда смотришь. Нужен язык умеющий работать с владениями и коллекциями (разными структурами).

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #326

297. Сообщение от ptr (ok), 01-Ноя-25, 09:15   –1 +/
> Неприятно, да, но у кода изначально была проблема с портабельностью

Очень интересно, как под ESP32 на уровне HAL можно писать кроссплатформенный код. Поделитесь опытом?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #274 Ответы: #372

299. Сообщение от ptr (ok), 01-Ноя-25, 09:23   +/
>>> Последний раз мне больно досталось с выходом Rust Version 1.85.0
> Чел, он пишет как раз о новом edition (2024). Перестань позориться наконец-то...

Очень интересно, а почему новый edition (2024-N?) вышел в феврале 2025 года? Или всё же в прошлогодний edition внесли изменения?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #267 Ответы: #301

300. Сообщение от Аноним (296), 01-Ноя-25, 09:55   +/
> Значит у авторов пакетов тоже была необходимость использовать найтли.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #308

301. Сообщение от Аноним (-), 01-Ноя-25, 10:02   –2 +/
> Или всё же в прошлогодний edition внесли изменения?

Откройте указанную вами же ссылку на список изменений.

Version 1.85.0 (2025-02-20)
The 2024 Edition is now stable. See the edition guide for more details.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299 Ответы: #304, #307

302. Сообщение от Аноним (303), 01-Ноя-25, 10:28   +/
>"dangling_pointers_from_locals"

Это же не имеет смысла. Как такое концептуально допускает Rust, который как раз призван бороться с этим?
Такие предупреждения и C выдает.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #323, #329

303. Сообщение от Аноним (303), 01-Ноя-25, 10:38   +/
По вашему выходит, что Rust придуман, чтобы программист страдал? Столько страданий, а язык допускает висячие сырые указатели. Просто предупреждение, которое можно и проигнорировать ради дела. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #413

304. Сообщение от ptr (ok), 01-Ноя-25, 10:46   –1 +/
Ну и что толку с такого edition, который стабилизировали больше года?
А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было. Разве что nightly.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301 Ответы: #338

307. Сообщение от Аноним (71), 01-Ноя-25, 11:46   +1 +/
> The 2024 Edition is now stable

Пока пациента стабилизировали - он протух.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301

308. Сообщение от Аноним (-), 01-Ноя-25, 11:52   +1 +/
Правильно! Я же об этом и говорю.
Это хобби проект, его делают для себя.
Делают так, как они хотят в удобном для них окружении. Может им просто хочется попробовать новые функции.

Это и есть - "достаточная необходимость" использовать найтли.

То что вы взяли такой пакет, это ваши личные трудности.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300

309. Сообщение от Аноним (-), 01-Ноя-25, 11:56   +/
> чесногря читая о безопасном языке раст думал, что подобные конструкции на нём компилироваться в принципе не должны.

Это raw-указатели. Они всегда идут без каких-либо гарантий. Поэтому любая разадресация raw-указателя -- это unsafe операция. Но присвоение raw-указателю значения -- это вполне себе safe операция, потому что она не лезет в память.

Вот если ты попытаешься вернуть ссылку:

fn f() -> &u8 {
       let x = 0;
       &x
}

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

Просто не надо трогать unsafe, и всё будет хорошо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

313. Сообщение от Аноним (313), 01-Ноя-25, 12:52   +/
> сборка мусора

Опциональная. На выбор разные gc, а так же счётчики ссылок. Arc/orc могут работать (и это подтверждено на практике) на микроконтроллерах, даже таких дохлых как avr.
Можно вообще отключить сборщик и работать руками. И стандартная библиотека от этого не пострадает.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #240

314. Сообщение от Советский инженер (ok), 01-Ноя-25, 13:02   +/
и что? помогло твое ООП С++ в ядро попасть? А?
так что, знай свое место !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #317

315. Сообщение от Очевидность (?), 01-Ноя-25, 13:05   +1 +/
Зачем ты споришь, если ты не программист? Это же видно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #316

316. Сообщение от Медведь (ok), 01-Ноя-25, 13:11   –1 +/
А, пошли финальные аргументы... Завидую твоему зрению -- видишь то, чего нет. По сути вопроса есть что сказать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315

317. Сообщение от Медведь (ok), 01-Ноя-25, 13:20   +/
> и что? помогло твое ООП С++ в ядро попасть? А?
> так что, знай свое место !

На Linux свет клином не сошелся, в ряде ОС компоненты ядра написаны на С++, а, к примеру, BeOS|Haiku так и вообще целиком на C++ и отлично себя чувствует. Так что сиди там у себя на коврике под дверью и не отсвечивай.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #314 Ответы: #318

318. Сообщение от Аноним (-), 01-Ноя-25, 13:31   +/
> а, к примеру, BeOS|Haiku так и вообще целиком на C++ и отлично себя чувствует.

Настолько отлично, что никому нафиг не нужна)
Ты бы еще более марнинальных маргиналов привел в пример.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #317 Ответы: #321

320. Сообщение от Вася (??), 01-Ноя-25, 13:34   +1 +/
> Truck будет владеть Car, а не наследовать от него.

Господи! Гуру ООП в треде!
Есть ли хоть что-то в чем ты разбираешься вообще?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #322

321. Сообщение от Медведь (ok), 01-Ноя-25, 13:40   +/
> Ты бы еще более марнинальных маргиналов привел в пример.

Ну раз ты просишь -- Windows NT. ЕМНИП, графическая подсистема и ряд сервисов там активно используют C++.

По поводу маргинальных примеров: как полагаешь, что показательнее: написать практически всё ядро haiku на C++ или полтора нерабочих драйвера в ядре Linux -- на рже?

Да, и не забудь сравнить haiku с redox -- если haiku маргинальщина, то как назвать это ржавоподелие я даже не знаю.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318

322. Сообщение от Медведь (ok), 01-Ноя-25, 13:44   –1 +/
Растуны такие растуны. Когда возразить по сути нечего, начинают разговор в духе гопников: "А ты кто такой?" Фу таким быть!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #320 Ответы: #340, #344

323. Сообщение от Медведь (ok), 01-Ноя-25, 14:15   –1 +/
Он и не такое допускает. Скажем, runtime panics из-за неверного обращения с владением, которое чекер зевает на этапе компиляции, причем ни разу не в unsafe коде.


use std::cell::RefCell;

fn main() {
    let data = RefCell::new(0);

    let mut first_borrow = data.borrow_mut();
    *first_borrow = 50;
    println!("Первая ссылка: {}", *first_borrow);
    // ...
    let mut second_borrow = data.borrow_mut();
    *second_borrow = 100;
    println!("Этот код никогда не выполнится");
}

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302 Ответы: #330, #331, #347

324. Сообщение от Тфьу (?), 01-Ноя-25, 14:16   +/
Нет. Не подойдёт. Лучше начать с книги "Structure and Interpretation of Computer Programs".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

325. Сообщение от Тфьу (?), 01-Ноя-25, 14:17   +/
Коллапс разработки начался как только придумали языки программирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

326. Сообщение от Аноним (91), 01-Ноя-25, 14:40    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #296

327. Сообщение от Аноним (91), 01-Ноя-25, 14:46   +/
>А зачем исправлять сразу все 40000000 строк?

Не сразу, а когда? Через сто лет? Вы понимаете, что либо эти строки исправляются здесь и сейчас, либо откладываются на неопределённое будущее?
>Включил для одного модуля (файла), исправил, включил для другого - исправил... Делов-то...

Именно такой подход и используют программисты на расте.
>Какие-то высосанные из пальца проблемы придумываешь.

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

Вы всё равно будете переписывать. Либо на C 2.0, чуть лучшем чем текущий C, либо на rust. Поскольку с текузими технологиями можно без особых проблем сконвертировать почти всё ядро на unsafe rust, и тогда сишных файлов либо не останется совсем, либо доли процента, полностью автоматически. Но вот этот вот unsafe rust всё равно придётся переписывать вручную.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #283 Ответы: #386

328. Сообщение от Аноним (91), 01-Ноя-25, 14:48   +/
>Сравни теперь с языками программирования.

У языков программирования стремительный прогресс. Вас же не смущает, что ламповые радиоприёмники уже не продаются в магазинах?
>Но если с++-ный комитет не будет решать насущные проблемы, то так и будет.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #387

329. Сообщение от Аноним (91), 01-Ноя-25, 14:49   –1 +/
>Это же не имеет смысла.

Ещё один не осиливший разницу между указателем и ссылкой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #302 Ответы: #336

330. Сообщение от Аноним (91), 01-Ноя-25, 14:55   +/
>Он и не такое допускает

Ух, вот это ыкспердище!
>Скажем, runtime panics

Ыкспердище не понимает, что даже в этом случае семантика программы сохраняется, и порчи памяти не происходит. Си в данном случае просто попортит память, либо упадёт с сегфолтом, в зависимости от фазы луны.
>что так никто в здравом уме не напишет

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323 Ответы: #333

331. Сообщение от Анончоус (?), 01-Ноя-25, 14:56   +1 +/
Эмммм... А читать мы разучились?

Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types which are entirely tracked statically, at compile time.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323 Ответы: #332, #343, #345

332. Сообщение от Медведь (ok), 01-Ноя-25, 15:08   –1 +/
> Эмммм... А читать мы разучились?
> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types
> which are entirely tracked statically, at compile time.

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

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

И еще: А читать мы разучились? Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как. От этого дизайн C стал лучше?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331 Ответы: #334, #349, #366, #388

333. Сообщение от Медведь (ok), 01-Ноя-25, 15:14   +/
Нет, ребятки, это вы, когда вас тыкаешь носом в косяки дизайна, вопите "так это же описано, вот, смотрите! мы от такого и не договаривались спасать! вы это, RTFM со своими претензиями!" Вопрос как раз в том, нафига так спроектировано? Зачем было реализовать такой хороший способ грохнуть софтину в рантайме? Пусть без порчи памяти и фатальных последствий, но для критичного софта и это как-то не комильфо, разве нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #330 Ответы: #335, #348, #364

334. Сообщение от Аноним (-), 01-Ноя-25, 15:26    Скрыто ботом-модератором–1 +/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332

335. Сообщение от Аноним (-), 01-Ноя-25, 15:34   +/
> Нет, ребятки, это вы, когда вас тыкаешь носом в косяки дизайна,

Кто определает "косяки"?
Чувак который показывает чудеса своек кекспертноти вот прям щас?

> вопите "так это же описано, вот, смотрите! мы от такого и не договаривались спасать!

Именно.
Есть четки определения от чего и как спасает.
Требовать чтобы авто выдерживало падение в жерло вулкана с криками "вы сказали что там ремни и подушки и вообще самый безопасный авто на рынке!!!" это просто идьйотизм.

> вы это, RTFM со своими претензиями!"

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

> Вопрос как раз в том, нафига так спроектировано?

Because we can (c)
Тебе не нравится? Можешь сделать лучше?
RFC принимаются от любого. Можешь прийти и показать "как надо".

> Зачем было реализовать такой хороший способ грохнуть софтину в рантайме? Пусть без порчи памяти и фатальных последствий,

Фатальные последствия бывают разные.
Если у тебя упадет сервак это печально.
А если он не упадет, но там будет дырочка для кахеров - то может быть и фатально для бизнеса.

> но для критичного софта и это как-то не комильфо, разве нет?

Ну так разрабатывай критичный софт, соответственно. Пиши тесты, проектируй архитектуру.
Знаешь, раст не защитит например, от логической ошибки и бесконечного зацикливания конечного автомата.
И? Поэтому его не использовать?
Ну так не используй. Пользуйся СИшкой, там же такого не может быть, бггг))


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333

336. Сообщение от Медведь (ok), 01-Ноя-25, 15:35   +/
>> Это же не имеет смысла. Как такое концептуально допускает Rust, который как раз призван бороться с этим?
> Ещё один не осиливший разницу между указателем и ссылкой.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329 Ответы: #351

338. Сообщение от Аноним (230), 01-Ноя-25, 16:02   +/
> Ну и что толку с такого edition, который стабилизировали больше года?
> А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было.

Чел, предыдущий edition был 2021 (1.56). Если ты использовал компилятор равной или более новой версии, то у тебя БЫЛА ВОЗМОЖНОСТЬ зафиксировать ее. Но ты этого не сделал, и сидел на нестабильной edition, который - ВНЕЗАПНО111 - сломал совместимость. Но виноват при этом Раст, да.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304 Ответы: #358

339. Сообщение от Аноним (230), 01-Ноя-25, 16:06    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #342

340. Сообщение от Вася (??), 01-Ноя-25, 16:10   +1 +/
При чем тут раст и растуны, ты примитивнейшую иерархию классов даже для примера описать не смог, а ведешь себя будто что-то понимаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

341. Сообщение от uchiuroki (-), 01-Ноя-25, 16:13   +/
Типичная ситуация. Мы видим альтернативы? Видим описание проблемы? Видим проблему? Нет. Жалкий наброс.

Давай я тебе научу как это делается. Есть цпп-синтаксис с <>-скобками, который использует правктически любой язык. И вот там `foo<bar>` это базовый синтаксис. Раст не смог это родить и потому там `foo::<bar>`. Сравнение есть, эквивалетный код есть. Позор есть.


Что же набрасывает этот персонаж? Там нет никакого двойного requires. А даже если бы был, то к чему это? Ты можешь показать альтернативный синтаксис? Альтернативую реализацию? А её нет. С чем ты синтаксис сравнивал?

Такого синтаксиса в принципе нет requires не может существовать сам по себе. Ему кто-то сказал про двойной и он нелепо побежал генерировать чушь. Невежество твоё второе имя, а какие-то сказки про интерес - оправдания. Ты не можешь в базовую логику. Да и в принципе программировать не оубчен потому как в примере написана полнейшая ахинея. Даже вне относительного того что ты не знаешь что такое requires.

В реальности же requires это часть декларации, предикат. Каким образом ты на его место запишешь второй, если это совершенно иное? Убрать его нельзя потому что `requires !requires` и прочее.

Наверное сложно жить когда человек не можето сознать омонимы. Это му ещё в детсаде учат. Ты ушлышал в детстве ел ель и обнулился?

```
x = requires{}
requires x
```

Второе requires это просто выражение. Очевидно что ты его можешь подставить куда угодно в том числе под предикат. Претензия в чём? В том что не сделали сахарок? Ну так ! тебя бы тоже обнулило. Тебе сложно от того что у них одинаковое название? Причём тут синтаксис?

Ты от `{foo: foo{}}` тоже обнулишься?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182 Ответы: #355, #393

342. Сообщение от Анонимусс (-), 01-Ноя-25, 16:15   +/
> Проект должен развиваться с фиксированным
> стабильным edition, но персонаж этого сделать не удосужился.

Ну вообще-то проект никому ничего не должен, особенно если он сторонний.
Вот хочу и использую найтли, и что ты мне сделаешь?))

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #339

343. Сообщение от uchiuroki (-), 01-Ноя-25, 16:26   +/
Двойное враньё от адепта. Первое раст завяляет зерокост/кт-проверки. Как только адепта ловят он начинает маневрировать "а зерокост ненужен", "а рт тоже проверки".

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

И что показывает этот фанатик? Он пишет "ну там сказано рантайм", но здесь есть подлог. Есть рантайм-проверка, а есть рантайм-семантика. Вот рантайм-семантику мы можем проверить только в рантайме, очевидно. Но в расте рантайм-проверки никак не связаны с рантайм-семантикой что и показано в примере выше. Её там нет.

Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в оригинале её не было. Это ещё одно враньё от секты "ой у нас проверки всего", "ой у нас нельзя игнорировать ошибки" можно. Именно поэтому там и сделан borrow_mut чтобы скрывать эти проблему, а так же чтобы ты его мог писать в случаях когда у тебя кт-семантика и ты точно знаешь что ошибки не будет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331 Ответы: #350, #353, #354, #365

344. Сообщение от Аноним (230), 01-Ноя-25, 16:27   +1 +/
> Когда возразить по сути нечего, начинают разговор

Чел, по сути ти написал чистый бред "Truck будет владеть Car, а не наследовать от него" - что тут возражать, если ты сам расписался в своем уровне экспертизы?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

345. Сообщение от Аноним (230), 01-Ноя-25, 16:35   +/
> Эмммм... А читать мы разучились?
> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types which are entirely tracked statically, at compile time.

Это бесполезно. Этому персонажу уже в других темах не раз повторяли, что borrow checker работает во время компиляции, а Rc/Arc - во время выполнения. Но персонажу не доходит и он продолжает всплывать с той же темой...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #331

346. Сообщение от Аноним (346), 01-Ноя-25, 16:40   +/
> язык, ..., который будет не давать сделать хотя бы часть логических ошибок.

предположу, ИИ, после 10 лет эволюции, отменит эту необходимость в большинстве областей программирования. Он почти не будет ошибаться, будет "внимательный" и "всёзнающий" в этой "узкой" области. В том числе, по причине всё той же своей "внимательности", не будет и необходимости в безопасности по памяти, хотя я полностью за раст. Т.е. ИИ и на сишке сможет безопасно (во всех смыслах) писАть. Главное суметь ему объяснить, что тебе надо.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #389

347. Сообщение от Аноним (230), 01-Ноя-25, 16:40   +/
> RefCell
> странно, что их святой практически боровчекер такую элементарную ошибку пропускает.

Чел, ну тебе черным по белому написано "RefCell A mutable memory location with dynamically checked borrow rules". DYNAMICALLY, понимаешь?

> Сейчас набигут растуны и завопят, что я ничего не понимаю

Ну да, ты действительно не понимаешь, что такое "dynamically checked" и "statically checked". Или в инглише не бум-бум, я хз.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323

348. Сообщение от Аноним (230), 01-Ноя-25, 16:46   +/
> Вопрос как раз в том, нафига так спроектировано? Зачем было реализовать такой хороший способ грохнуть софтину в рантайме?

Не вопрос: покажи, как делать рантаймовые проверки владения БЕЗ использования GC.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333

349. Сообщение от Аноним (230), 01-Ноя-25, 16:49   +1 +/
>> Borrows for RefCell<T>s are tracked at runtime, unlike Rust’s native reference types
> Вопрос в другом -- зачем он, такой дизайн

В смысле, зачем? Если ты явно использовал RefCell всесто нативных ссылок, что очевидно, у тебя были причины для этого - и ответ на вопрос "зачем" как бы должен быть очевидным.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332

350. Сообщение от Анонимусс (-), 01-Ноя-25, 16:50   +1 +/
> Первое раст завяляет зерокост/кт-проверки.

Да, именно так.
Компайлтайм проверки есть? Есть.
Работают? Работаю.
Чего тебе надо, @?

> Как только адепта ловят

Ловят на чем? Что не все проверки в компайлтайме? А это вы сами придумали.
Зерокост еще как нужен. И чем больше перенесется в компайлтам, тем лучше.

> Для людей мало знакомых с темой

Людей вроде тебя?)) Попробуй открыть доку и почитать.

> на самом деле в 95% случаев не работают

Пруфы приведешь? Или ты сюда так, пришел лужи погазифицировать?

> Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в
> оригинале её не было.

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

> "ой у нас проверки всего"

Про "всего" - это фантазии растохейтеров.
Но проверка прошла и программа запаниковала - отлично, цель достигнута, потому что программа не попортила память и не подарила рут.

> Именно поэтому там и сделан borrow_mut чтобы скрывать эти проблему

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343 Ответы: #356

351. Сообщение от Аноним (230), 01-Ноя-25, 16:51   +/
> Ещё один, не понимающий (или притворяющийся), что вопрос был именно о концепции и дизайне языка

Если ты спрашиваешь, зачем существует RefCell/Rc/Arc - то очевидно, что для случаев, когда проверки времени компиляции физически невозможны. Разве не очевидно?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #336 Ответы: #367

352. Сообщение от Аноним (346), 01-Ноя-25, 16:52   +/
> Только от очень небольшого списка

Только этот список генерирует наибольший список _опасных_ проблем. Т.е. даже не то правило "20/80", а наверное все "5/95" получается.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

353. Сообщение от Анончоус (?), 01-Ноя-25, 17:00   +/
Ты хоть понял, что сам написал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

354. Сообщение от Аноним (230), 01-Ноя-25, 17:07   +/
> Но в расте рантайм-проверки никак не связаны с рантайм-семантикой

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

355. Сообщение от Анончоус (?), 01-Ноя-25, 17:26   +/
Да не трясись ты так.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341

356. Сообщение от uchiuroki (-), 01-Ноя-25, 17:41   –2 +/
Мне настолько лень с тутошними одноклеточными спорить. Паника существует - существует. Проверки нет - нет. Почему каждый сектант ссылается на какую-то свою доку?

>Но проверка прошла и программа запаниковала - отлично, цель достигнута, потому что программа не попортила память и не подарила рут.

Проверок никаких нет. То, что ты где-то украл тормозящие рт-проверки они к тебе отношения не имеют. Они есть везде и ничего не стоят. Их даже специально выключают чтобы не тормозило, собственно твой рантайм на 95% и состоит из подобного ворованного кода. Как и то, твоя секта называет компилятором.

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

В результате сравнивается фентезийный "дал рут", который буквально недавно растосекта давала не осилив реализацию архиватора.

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


И в этом проблема сектантов. Любой раст-адепт это малообразованный школьник. Он почему-то решил что ворованная сишная паника это какая-то раст-инновация. И что сишный софт не паникует/не проверяет всё подряд просто потому что там глупые люди.

>Пруфы приведешь? Или ты сюда так, пришел лужи погазифицировать?

Это ты должен приводить, а не я. Ты как сектант утверждаешь что твои заявления работают, а значит ты должен доказывать что-то, а не я.

Тебе как раз таки показали пример где заявления не работают - проверки нет. Поверка в контексте растосекты это именно кт-проверка.

>Rust is blazingly fast and memory-efficient: with no runtime or garbage collector, it can power performance-critical services, run on embedded devices, and easily integrate with other languages.

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


Тех кто захочет подобных убогих глушить достаточно anyhow/unwrap и количество arc и им подобных в любой раст-клоаке, а так же попыткой реализовать любой примитив из стд. Ничто в расте за пределами букваря не проверятся в кт.

Такая же ситуация с тем как раст-сектанты орали про "исключения плохо/типы непонятно", а в реальности в ядре инт ворованный из сишки, а везде anyhow и подобный нелепой косплей на исключения. Ноль кт хотя каждый сектант тебе будет орать про result и типы, которые в реальности никто не использует.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #350 Ответы: #370, #373

357. Сообщение от uchiuroki (-), 01-Ноя-25, 17:57   +/
>С разморозкой. Берём первый попавшийся материал

Зачем мне брать какой-то материал. Очевидно что где-то там наверху никто не будет отрицать очевидное. В материал написано так же что и от гонок раст не спасает и не может спасать, но каждый адепт же об этом орёт?

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

>Да будет вам известно, что в си тоже есть утечки памяти. И утечки памяти от подхода в расте не добавляются.

Никакого "подхода раста" в природе не существует. Раст это ворованный огрызок цпп-семантики. Скоре более сишный cleanup aka defer. Но всё это так же огрызки цпп-семантики, потому что это пытаются обернуть в какие-то более связанные с временем жизни примитивы, а это именно цпп-семантика.

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


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

Это без учёта захардкоженного глобального аллокатора(и то ворованного сишного) и прочих приключений.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #363

358. Сообщение от ptr (ok), 01-Ноя-25, 18:01   +/
>> Ну и что толку с такого edition, который стабилизировали больше года?
>> А для ESP32-C3 (RISC-V) использовать предыдущий edition возможности не было.
> Чел, предыдущий edition был 2021 (1.56).

Читать умеете?

> Если ты использовал компилятор равной или
> более новой версии, то у тебя БЫЛА ВОЗМОЖНОСТЬ зафиксировать ее.

Мда, явно читать не умеете. Прочитайте выше, я популярно всё описал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #338 Ответы: #378

359. Сообщение от Shantikov (?), 01-Ноя-25, 18:06   +/
Вы забыли пометку "сарказм" или "ирония" поставить, здесь это нужно - большинство тут социопаты с фобией общения и не выкупают иронию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

361. Сообщение от Аноним (91), 01-Ноя-25, 18:23   +2 +/
>если в твоем жалком недоязычке нет ни того ни другого.

Вот интересно, а многоуважаемый эксперт не знает, что существует целая куча языков без ООП? Haskell, SML, Go, C, Lua и так далее?
>в расте есть все что нужно, а если чего-то в расте нет, то  оно и не нужно.

У ООП есть недостатки, и протаскивать всюду ООП излишне.
>если в твоем жалком недоязычке нет ни того ни другого.

Если вам вдруг действительно нужно именно ООП, то вы можете реализовать его в стиле Lua или JS. Как минимум можно реализовать что-то вроде этого(пусть настоящие растовики предложат вариант получше):

struct Animal {
    my_type : String,
    say : fn (&Box<Animal>) -> (),
    say_type : fn (&Box<Animal>) -> ()
}

fn new_animal() -> Box<Animal> {
    Box::new(
        Animal {
            my_type: String::from("Animal"),
            say : |_a : &Box<Animal>| {
                println!("Couldn't say");
            },
            say_type: |a : &Box<Animal>| { println!("{}", a.my_type) }
        }
    )
}

fn new_cat() -> Box<Animal> {
    let a = new_animal();
    Box::new(
        Animal {
            my_type: String::from("Cat"),
            say : |_a : &Box<Animal>| {
                println!("Meo");
            },
            ..*a
        }
    )
}

fn main() {
    let a = new_animal();
    (a.say_type)(&a);
    (a.say)(&a);
    let c = new_cat();
    (c.say_type)(&c);
    (c.say)(&c);
}

Вот просто удивительно, как легко и просто мы взяли и унаследовали say_type.
>я про ООП в стиле C++

То-то же в C++ изобретаютс вякие CRTP.

Короче говоря, очередной плач неосилятора.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #411

363. Сообщение от Аноним (91), 01-Ноя-25, 18:34   +1 +/
>Зачем мне брать какой-то материал.

Затем, что ты  - классический неосилятор, из палаты мер и весов. Прибежал с набросом, а когда указали, что это общеизвестный факт, сразу же дал заднюю.
>98% раст-адептов не знают что утечки проблемами не считаются.

А что сразу не 100%? Не стоит проецировать свою абслоютную некомпитетность на всех остальных.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #357

364. Сообщение от Аноним (91), 01-Ноя-25, 18:39   +/
>Вопрос как раз в том, нафига так спроектировано?

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

А что для критичного софта комильфо? Попорить памяти и попытаться продолжать работать?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333

365. Сообщение от Аноним (91), 01-Ноя-25, 18:46   +/
>Двойное враньё от адепта. Первое раст завяляет зерокост/кт-проверки. Как только адепта ловят он начинает маневрировать "а зерокост ненужен", "а рт тоже проверки".

Вы настолько необразованы, что не понимаете разницу между тем, что в расте есть проверки нулевой цены и тем, что в расте абсолютно все проверки нулевой цены?
>Поэтому ты вынужден использовать рт-проверку не потому что там есть какой-то рантайм, а потому что иначе нельзя.

Что? А что, на си тоже нельзя без проверок времени выполнения? Да как же так? А в крестах тоже нельзя? Тогда в чём ваша претензия?
>Вон там ещё один сектант пытается манипулировать. Нейробот родил try_borrow_mut, но в оригинале её не было.

А вот это тогда что? https://doc.rust-lang.org/std/cell/struct.RefCell.html#metho...
>Для людей мало знакомых с темой сложно понять манипуляцию сектантов

Вот действительно. Если для вас rust слишком сложный, то пишите на Go, Ocaml, но не вкоем случае не на си и не на крестах. Поскольку сишные сектанты убеждают как у них всё хорошо, но продолжают плодить очередные дыры.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

366. Сообщение от Аноним (91), 01-Ноя-25, 18:50   +/
>и получают пинок туда, где не ожидали

Семантика раст программы - она либо выполняется, либо паникует, но не портит память. Сколько лет расту, а вы настолько некомпитетны, что до сих пор этого не узнали.
>Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332

367. Сообщение от uchiuroki (-), 01-Ноя-25, 19:01   +/
Нет, раст-сектант опять врёт. Как было сказано выше в 95% случаев раст-сектант пишет подсчёт ссылок не потому что требуется, а потому что его днище не смогло.

Это о чём я писал выше. Есть рантайм-семантика это то когда физически невозможно. Рантайм-проверка это просто рантайм-проверка она никак не связана с рантайм-семантикой. Её можно всунуть куда угодно. Это типичная манипуляция от сектанта.

Ну банально тот пример с которым бегают они.

```
vec v;
v.push();
r = v[0]
v.push();
```

сектанты бегают и рассказывают как они ловят эту ошибку. На самом же деле они её не ловят, а просто не могут. r алиасится с вектором и далее push не работает потому что требует mut который не работает при 1+1. Это не значит что оно понимает что здесь ошибка, либо что будет ошибка.

Поэтому в примере когда я сменил в векторе аллокатор на бесконечный, либо когда я рукой делаю

```
vec v;
v.reserve(100000);
v.push();
r = v[0];
v.push();
```

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

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

Даже slice они до сих пор не могут сделать, а может уже и сделали.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351 Ответы: #375, #391

370. Сообщение от Аноним (230), 01-Ноя-25, 19:22   +2 +/
> Мне настолько лень с тутошними одноклеточными спорить.

...и поэтому я накатаю очередную простыню текста.

> Паника существует - существует. Проверки нет - нет.

Не, ну это гениально. Проверки нет, но паника при этом откуда-то взялась.

> Проверок никаких нет. То, что ты где-то украл тормозящие рт-проверки

Опять: проверок нет, но украденные проверки есть. Ноль противоречий! Кстати, где украл? У кого?

> То, что ты где-то украл тормозящие рт-проверки они к тебе отношения не имеют. Они есть везде и ничего не стоят.

Сперва "тормозящие проверки", и тут же "они ничего не стоят". Так "тормозящие" или "ничего не стоят"? Чел, ты там в порядке вообще?

> ворованная сишная паника

В Си нет никаких паник. То о чем вообще?

Что за глупость? Паники не портят память. Или где мне увидеть пруф обратного?

>>> на самом деле в 95% случаев не работают
>> Пруфы приведешь?
> Это ты должен приводить, а не я. Ты как сектант утверждаешь что твои заявления работают

Но ведь это ты, а не он, утверждаешь, что "все эти "кт"-проверки на самом деле в 95% случаев не работают". Так что или давай пруфы, или прекращай трепать языком..

> Тебе как раз таки показали пример где заявления не работают - проверки нет.

Но ведь это вы заявляете, что RefCell должен проверяться в кт, в то время как в его документации написано о рт.

> Поверка в контексте растосекты это именно кт-проверка.

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

> в ядре инт ворованный из сишки

Оказывается, целочисленные типы в сишке изобрели! А до Сишки люди поди вообще на абаках считали.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356

371. Сообщение от uchiuroki (-), 01-Ноя-25, 19:22   –2 +/
Это не баг компилятора. Кто-то клоуна спустил методичку и они стали повторять. Это фундаментальная дыра в дизайне. Как и никакой фейкстатик до сих пор не починен и не будет никогда починен.

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


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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #401

372. Сообщение от morphe (?), 01-Ноя-25, 19:33   +/
> Очень интересно, как под ESP32 на уровне HAL можно писать кроссплатформенный код.
> Поделитесь опытом?

Окей, в ESP32 действительно обе платформы (risc-v, xtensa) используют unsigned

Я однако думал речь про linux/windows/macos, потому что на винде/macos всегда оно signed, а на linux заисит от архитектуры, и в этом случае надо поддерживать оба варианта

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297

373. Сообщение от morphe (?), 01-Ноя-25, 19:37   +2 +/
> Падение хуже порчи памяти

Дальше можно не читать, человек явно разработкой чего-либо серьёзного не занимался

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #356

375. Сообщение от Аноним (230), 01-Ноя-25, 19:45   +1 +/
> Как было сказано выше в 95% случаев раст-сектант пишет подсчёт ссылок не потому что требуется, а потому что его днище не смогло.

Ты опять набрасываешь без каких-либо пруфов. Иначе покажи сценарий, в котором "правильный" язык реализует кт-проверку там, где ростовый borrow checker "не смог".

> Есть рантайм-семантика это то когда физически невозможно. Рантайм-проверка это просто рантайм-проверка она никак не связана с рантайм-семантикой. Её можно всунуть куда угодно. Это типичная манипуляция от сектанта.

Очередное пускание абстрактной пыли в глаза без какой-либо конкретики.

> сектанты бегают и рассказывают как они ловят эту ошибку. На самом же деле они её не ловят, а просто не могут. r алиасится с вектором и далее push не работает потому что требует mut который не работает при 1+1. Это не значит что оно понимает что здесь ошибка, либо что будет ошибка.

Borrow checker срабатывает в этом случае? Срабатывает. Дальше какой-то бред про "1+1" и "оно не понимает".

> Очевидно что здесь никакой ошибки нет.

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

>  Потому что были ворованы с цпп хешей без стабильных ссылок.

Шта? Что такое "цпп-хеши"?

> какие-то цпп-хеши

А, ок - ты и сам не в курсе...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367

376. Сообщение от Аноним (71), 01-Ноя-25, 19:46   +/
> Раст конкурент C++.

раст конкурент разве что корявых шишек.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251 Ответы: #392

378. Сообщение от Аноним (230), 01-Ноя-25, 20:01   +/
> Читать умеете?
> Мда, явно читать не умеете.

Так я тебя и спрашиваю: каким таким образом у тебя не было возможности использовать предыдущий (текущий?) edition, но при это была возможность обновиться на 1.85 (да еще и с включением 2024 версии, которая до этого момента была нестабильной)?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358 Ответы: #380

380. Сообщение от ptr (ok), 01-Ноя-25, 20:35   +/
>> Мда, явно читать не умеете.
> Так я тебя и спрашиваю: каким таким образом у тебя не было
> возможности использовать предыдущий (текущий?) edition
>>> Проблема в том, что желающих поддерживать свои библиотеке для всех версий Rust исчезающе мало

Иными словами, несмотря на то, что у меня использовался edition 2021, вся сборка обвалилась, пока я не перешёл на новые версии esp-idf-svc, esp-idf-hal и esp-idf-sys.

Например, можете проверить на этом открытом проекте https://github.com/vpetryaev/GateRTO-1000
Если откатиться на один коммит, то проект не соберется c ворохом ошибок
expected `*const u8`, found `*const i8`
или
expected `*mut *const u8`, found `*mut *const i8`

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #378

384. Сообщение от uchiuroki (-), 01-Ноя-25, 22:17   –1 +/
>На выходе получаем LLVM-IR.

Ты, очередной расто-клоун который не знает что такое llvm. Никакой ir никакой раст-огрызок не генерирует.

>А вот LLVM-IR компилируется llvm в машинные коды.

Нет.

>Но llvm не единственный кодогенератор для раста.

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

>Есть еще и Cranelift, написанный тоже на расте, которых хоть и отстает от llvm по количеству оптимизаций и поддерживаемых платформ, тоже неплохая альтернатива.

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

Для тех кому интересно я помогу нейроботу. В общем когда-то давно раст-сектанты решили сделать свой ллвм, но опозорились настолько что он никак не работал. Откуда фанатик взял какое-то "отстаёт" неизвестно.

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

Это примерно как орёт о том что жвм это просто кодогенератор. Ну и да, конечно же, никакой rustc не умеет генерировать ir - его генерирует ллвм-рантайм. Это слишком сложно для этой поделки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #396

385. Сообщение от Аноним (385), 01-Ноя-25, 22:24   +/
Тут даже растсеры не могут разобраться с синтаксисом - устроили баттлы... Куда уж новичку тут соваться.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #444, #470

386. Сообщение от senaemail (ok), 01-Ноя-25, 22:57   +/
> Не сразу, а когда? Через сто лет? Вы понимаете, что либо эти
> строки исправляются здесь и сейчас, либо откладываются на неопределённое будущее?

Когда будет удобно, разумеется, по заранее разработанному плану. Раз нет необходимости одновременно исправлять сразу все предупреждения, то соответственно никто не "утонет" тысяче варнингов, то есть твой аргумент высосан из пальца. Сначала оценивается объём работ, планируются исправления в ближайшие Х месяцев, делается объявление, доводится до ответственных и дальше все работают согласно принятого плана, без паникёрста и авралов.


>>В любом случае это гораздо легче и проще, чем переписывать на совершенно другом языке.
> Вы всё равно будете переписывать. Либо на C 2.0, чуть лучшем чем
> текущий C, либо на rust.

Ну вот, лучше на C 2.0, чем на _подставить_по_вкусу_ языке.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #327

387. Сообщение от senaemail (ok), 01-Ноя-25, 23:19   +/
> ламповые радиоприёмники

мы говорили про языки, это всё же весьма далеко от радиоприёмников... :)

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

Нет. В с++ можно добавить возможность решать существующие проблемы в новом коде оставив максимум совместимости, при этом старый код можно оставить как есть, пока его не перепишут или не выкинут. Как в том же расте есть блоки "unsafe", точно так можно поступить и со старым кодом, поместив вызовы старого кода в такие блоки. Ещё большую часть проблем можно переложить на линтеры. Поскольку раст уже показал какие-то хорошие результаты, скорее всего какие-то идеи из него в каком-то виде могут быть полезны и в других языках. Вопрос времени и вдохновения комитета, а также тех, кто принимает решения по финансированию соответствующих проектов. Если эти люди решат похоронить с++, то сообществу скорее всего придётся смириться. Тут демократия не работает :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #328 Ответы: #405

388. Сообщение от Аноним (128), 01-Ноя-25, 23:43   +1 +/
Если у тебя возникают вопросы типа "зачем он, такой дизайн?", то предыдущее твоё высказвание "все строго в соответствии с дизайном языка" совершенно необосновано, потому что ты не понимаешь дизайна. Дизайн невозможно понимать, если ты не понимаешь как он такой возник.

> Документация по многострадальному C точно так же позволяет объяснить, что, отчего и как. От этого дизайн C стал лучше?

Ты в эти объяснения заглядывал? Там большая часть объяснений сводится к одному из двух:

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

2. историческая случайность: стандарт на C появился далеко не сразу, и за ~20 лет отсутствия стандарта, этих компиляторов написали десятки, и каждый понимал под C что-то своё. Стандарт постарался по-максимуму сохранить эти девиации от патриархов, чтобы с обратной совместимостью было бы получше.

Оба этих объяснения -- это не признак хорошего дизайна. Первое может быть и было таким признаком, пока компьютеры были тупые и медленные и не могли тянуть оптимизирующий компилятор, но то время давно ушло, так что сегодня оно уже не работает. Хотя у меня есть сомнения, что оно хоть когда-нибудь работало как объяснение. То, что не надо путать указатели и массивы к началу 70-х было известно уже. Но нет, патриархам показалось очень остроумным сделать оператор [] синтаксическим сахаром для *(a+b). В качестве побочного эффекта получилось, что выражение a[b] эквивалентно выражению b[a], и как минимум одно из них выглядит бессмысленным, но при этом работают оба. Мелкий косяк дизайна, но зато как остроумно, а? В результате сегодня ни C, ни C++ не могут передать массив в функцию по значению. Если очень хочется, то приходится дополнительные синтаксические заклинания произносить, например, заворачивать массив в структуру. Я не знаю, насколько это мешало в 70-х годах, но сегодня это просто фейспалм.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #332

389. Сообщение от Аноним (389), 02-Ноя-25, 01:34   +/
>> язык, ..., который будет не давать сделать хотя бы часть логических ошибок.
> предположу, ИИ, после 10 лет эволюции, отменит эту необходимость в большинстве областей
> программирования. Он почти не будет ошибаться, будет "внимательный" и "всёзнающий"

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #346 Ответы: #471

390. Сообщение от Аноним (390), 02-Ноя-25, 03:12   +/
Нам объясняли иначе. Отстирать можно всё. Катание это способ стирки. Сбор налогов это мыторство.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

391. Сообщение от mda (?), 02-Ноя-25, 04:38   +/
Ошибка в твоем банальном примере ловится - и это главное. Ествно, это не на уровне, что борроу чекер знает что-то про пуш, емкость, перераспределение памяти, - а потому что тут, как ты выразился, будет просто "1+1". Поэтому даже корректный код с достаточной емкостью будет отвергнут. Теперь зададим вопрос: это в целом хорошо или плохо? Чтобы ответить, представим большой проект на с++, написанный так, что во многих местах используются ссылки на элементы вектора, причем их валидность зависит от того, как в совершенно других местах используются reserve и push_back. Вспомним еще, что сколько именно памяти reserve выделяет - зависит от конкретной реализации stl. Это просто неподдерживаемый код. Но плюсисты-сектанты, написав такое, еще потом и пальцы гнут. Там, где стыдиться надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367

392. Сообщение от Аноним (-), 02-Ноя-25, 04:58   +/
>> Раст конкурент C++.
> раст конкурент разве что корявых шишек.

Аноним случайно доказал, что C++ -- это геморрой.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376

393. Сообщение от Аноним (-), 02-Ноя-25, 05:39   +/
> Есть цпп-синтаксис с <>-скобками, который использует правктически любой язык. И вот там `foo<bar>` это базовый синтаксис.

Синтаксис шаблонов в C++ ущербен by design.
blog.reverberate.org/2013/08/parsing-c-is-literally-undecidable.html

> Раст не смог это родить и потому там `foo::<bar>`.

Раст как раз смог, поэтому он имеет однозначный синтаксис, в отличие от.

> Ты можешь показать альтернативный синтаксис? Альтернативую реализацию? А её нет. С чем ты синтаксис сравнивал?

Хочешь посмотреть на адекватный синтаксис? Держи:

where T: Add<Output=T>

А эти твои requires как будто пятилетний ребёнок проектировал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #341

394. Сообщение от Чтото знающий (?), 02-Ноя-25, 09:25   +1 +/
>А растаманы то пишут на безопасном языке, а все равно CVE допускают.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

395. Сообщение от Чтото знающий (?), 02-Ноя-25, 09:34   +/
>А в Линукс-ядре сколько дыр-то!

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

396. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:01   +/
>Никакой ir никакой раст-огрызок не генерирует.

Военам Борьбы Супротив Раста прежде, чем брызгать слюной на оппонентов, хорошо бы ознакомиться с документацией для начала. А?

https://rustc-dev-guide.rust-lang.org/overview.html

Цитата:

Since rustc uses LLVM for code generation, the first step is to convert the MIR to LLVM-IR. This is where the MIR is actually monomorphized. The LLVM-IR is passed to LLVM, which does a lot more optimizations on it, emitting machine code which is basically assembly code with additional low-level types and annotations added (e.g. an ELF object or WASM).

И кто здесь клоун этого? 😁

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384

397. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:04   +/
Он хочет сказать, что с элементарным логическим мышлением у военов борьбы супротив Раста очень туго. Вот и ваши вопросы тому яркое подтверждение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #286 Ответы: #472

398. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:07   +/
На то время, вполне возможно, другого выбора и не было. Так что не совсем понятно, что вы сказать пытаетесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #260 Ответы: #409

399. Сообщение от Аноним (-), 02-Ноя-25, 10:10   +/
> Внимание, сейчас растуны начнут вопить, что в коране... ой, в расте есть все что нужно, а если чего-то в расте нет, то  оно и не нужно.

stlport.org/resources/StepanovUSA.html

I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people.

I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types.

I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all.

I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.

The problem that I find with OOP is not just that it is slow, but that it does not allow me to express simplest possible algorithms.

Александр Степанов, автор C++ STL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #410

400. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:10   –1 +/
>но семантика языка где в изобилии пвседо символы вместо человеческого

Вы уверены, что понимаете разницу между семантикой и синтаксисом?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #412

401. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:22   +/
>Это не баг компилятора. Кто-то клоуна спустил методичку и они стали повторять. Это фундаментальная дыра в дизайне.

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

>К тому же в растомусоре не может быть "багов" потому что основная методичка была про верификацию и ноль багов.

Ссылку на методичку дадите или это невозможно, потому что она существует только в вашем богатом воображении?

>К тому же странный баг который чинят уже второй десяток лет, а именно всё время существования этой поделки. Вернее его не чинят и не чинили.

То есть, все-таки, баг. Отлично. В зачем чинить то, что труднодостижимо и носит заведомо искусственный характер? Чтобы какую цель достичь?
>Модель в принципе не может проверять отношения лайфтаймов.

Почему? Вам так хочется, или есть более весомые основания? Может, ссылку дадите на опровержение?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #371

402. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:37   +/
>Заменить - пожалуйста, вводить два десятка языков параллельно - нет.

Вы, наверное, знаете, как достичь этого?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

403. Сообщение от Чтото знающий (?), 02-Ноя-25, 10:58   +/
>>> Ну думаю что добавить deprecated это сложнее чем сделать новый язык.
>Сложнее конечно, но это правильный путь.

Похоже, вы не понимаете, что язык программирования - это не только синтаксис, это ещё семантика и парадигма. Если будете пытаться впихнуть всё, что можно, в существующий язык, в итоге получите монстра типа C++ или SQL со спецификацией на 1500-1700 страниц, которую не в состоянии не будет освоить ни один человек в мире. В итоге один человек будет программировать на своём диалекте, который человек, использующий другой диалект, уже понимать не будет. Другими словами, у вас вместо одного языка по факту будет несколько подмножеств. Но это ещё не все проблемы. Вам же нужен будет компилятор (интерпретатор), который обязан будет поддерживать всю спецификацию от и до. А с этим в уже упомянутых меню языках есть проблемы. Разработчики таких компиляторов просто уже не в состоянии справляться с подобной сложностью в приемлемые сроки. Поэтому часто по несколько лет имеем инструментарий, который поддерживает только часть спецификации, а не всю полностью.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279 Ответы: #465

404. Сообщение от Чтото знающий (?), 02-Ноя-25, 11:08   +/
>Желание выкинуть один популярнейший язык и заменить его новым, в котором ОДНА какая-то идея реализована лучше это просто безумие...

Зависит от масштаба идеи. Например, на одном языке вы можете делать что угодно, но очень долго (язык общего назначения та Си). А другой предназначен только для извлечения данных (SQL), но делается это на этом языке гораздо быстрее и проще, чем на Си.

И так во всём. Есть два типа улучшений: первый способ - эволюционный. Второй - революционный. Оба имеют место быть в современном мире. Серебряной пули здесь нет и быть не может.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #287 Ответы: #446

405. Сообщение от Чтото знающий (?), 02-Ноя-25, 11:31   +/
>В с++ можно добавить возможность решать существующие проблемы в новом коде оставив максимум совместимости, при этом старый код можно оставить как есть, пока его не перепишут или не выкинут.

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

>Ещё большую часть проблем можно переложить на линтеры.

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

>Вопрос времени и вдохновения комитета

Комитет пришёл к мнению, что Safe C++ реализован не будет. На этом уже можно поставить жирнющую точку для ваших рассуждений о светлом будущем этого языка. И подобная ситуация, как вам неоднократно замечали, возможна в любом другом языке. Это одна из причин появления новых языков (есть и другие, я вам о них написал уже ранее).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #387 Ответы: #445

406. Сообщение от Чтото знающий (?), 02-Ноя-25, 11:39   +/
> "что? доработать язык под новые идеи? а кто гарантирует, что старый код не сломается?

Очередной воен (именно так, через букву "е") борьбы супротив Раста ожидаемо сел в лужу. Для того, чтобы гарантированно ничего не сломать при изменениях идей в Расте есть редакции (editions).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

407. Сообщение от Чтото знающий (?), 02-Ноя-25, 11:48   +/
>> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
> Согласен.

Осталось совсем немного, чтобы добиться желаемого. Да? Всего-навсего убедить комитет. Шансов нет, но вы дерзайте.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289 Ответы: #424

408. Сообщение от Чтото знающий (?), 02-Ноя-25, 11:51   +/
>> Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст, ничуть не лучше текущего.
>Ну и прекрасно.

Действительно, прекрасно. К вам начало приходить наконец-то какое-то понимание, зачем люди создают новые языки программирования.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #289 Ответы: #423

409. Сообщение от zionist (ok), 02-Ноя-25, 11:57   +/
А теперь у вас какой выбор?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #398 Ответы: #415, #416

410. Сообщение от Медведь (ok), 02-Ноя-25, 12:01   +/
Ну прям порадовал. Не забудь теперь донести эту важную мысль до разработчиков C++, Java, C#, Swift, Kotlin и т.д. И главное, не забудь выкинуть те ошметки ООП, которые удалось таки протащить в Rust. Да-да, все эти ваши трейты и полиморфизм на них -- всё еще ООП, хотя и жутко кастрированное. Не веришь -- сам почитай: https://doc.rust-lang.org/book/ch18-00-oop.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #399 Ответы: #414, #452

411. Сообщение от Медведь (ok), 02-Ноя-25, 12:42   +/
> Если вам вдруг действительно нужно именно ООП, то вы можете реализовать его в стиле Lua или JS

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #361

412. Сообщение от OpenEcho (?), 02-Ноя-25, 14:16   +/
>>но семантика языка где в изобилии пвседо символы вместо человеческого
> Вы уверены, что понимаете разницу между семантикой и синтаксисом?

И что же не так с моим пониманием?
А вы уверены что вы понимаете разницу между семантикой и синтаксисом?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #400 Ответы: #418

413. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:17   +/
>По вашему выходит, что Rust придуман, чтобы программист страдал?

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

>а язык допускает висячие сырые указатели

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #303

414. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:35   +/
Вам показали, что на ООП с наследованием свет клином не сошёлся. Вполне можно и без него, как показывает практика (в том числе практика программирования на Rust, на котором множество разных програмных продуктов написано). Вы зачем-то продолжаете настаивать на своей точке зрения, как единственно правильной.

Множественное наследование, да и наследование вообще - это зло. Почему? Потому что очень тяжело поддерживать потом такой код - в голове каждый раз надо отслеживать, как именно потомок отличается от родителя (разница может быть, как в данных, так и в методах). Rust освобождает программиста от этой совершенно лишней когнитивной нагрузки.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410

415. Сообщение от Аноним (415), 02-Ноя-25, 15:35   +/
Лебедь, рак, да щука.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #409

416. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:38   +/
А теперь у нас есть ещё Golang (с кучей недостатков, но есть) и Rust. Ada, конечно, никто не отменял. AST, вон, тоже пишут, что хорош.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #409 Ответы: #476

417. Сообщение от Аноним (415), 02-Ноя-25, 15:41   +/
> Раст конкурент C++.

Не конкурент. C++ играет на поле ООП, а там Раст аутсайдер.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #251 Ответы: #441

418. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:41   +/
Похоже, не понимаете. Семантика существует НЕЗАВИСИМО от синтаксиса (псевдосимволов, как вы изволили выразиться). Например, "алгебраический тип" - это семантичское понятие. А вот способ отображения этого понятия в языке программирования - это уже синтаксис.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412 Ответы: #425

419. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:51   +/
Питон не способствует писать код грамотно из-за динамической типизации и многого другого. Без необязательных аннотаций типов и линтера (тоже необязательного) более-менее качественный код на Питоне написать - занятие непростое (для сколь-либо сложного кода, конечно).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

420. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:55   +/
>А rust нифига не гарантирует отсутствие утечек памяти. Сюрприз!

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #426

421. Сообщение от Чтото знающий (?), 02-Ноя-25, 15:57   +/
И крайне желательно, чтобы со статической типизацией, без сборки мусора и компилируемое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

422. Сообщение от Чтото знающий (?), 02-Ноя-25, 16:07   +/
Как первый язык программирования рекомендую Pascal. Лучшего для обучения этому самому программированию найти тяжело. Хотя некоторые пытаются Питон использовать для этих же целей, но он плохо для этого подходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

423. Сообщение от senaemail (ok), 02-Ноя-25, 16:18   +/
>>> Как только условный с/c++ потеряют обратную совместимость, то получим ещё один раст, ничуть не лучше текущего.
>>Ну и прекрасно.
> Действительно, прекрасно. К вам начало приходить наконец-то какое-то понимание, зачем
> люди создают новые языки программирования.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #408 Ответы: #436

424. Сообщение от senaemail (ok), 02-Ноя-25, 16:22   +/
>>> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
>> Согласен.
> Осталось совсем немного, чтобы добиться желаемого. Да? Всего-навсего убедить комитет.
> Шансов нет, но вы дерзайте.

Шансы действительно невелики. Но в связи с происходящими тектоническми событиями в мире, может быть создан новый комитет. И вовсе не обязательно в США.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #407 Ответы: #434

425. Сообщение от OpenEcho (?), 02-Ноя-25, 16:27   +/
> Похоже, не понимаете.

С точностью до наоборот.

- Синтакс - это про граматику, про правильность, стиль
- Семантика - это про смысл, логику, которая понятна конкретному типу.

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

Синтакс пример:
- Правильный синтакс:
  fn main() {  println!("Hello, world!"); }
- Не правильный синтакс:
  fn main() {  println!("Hello, world!"; }

Теперь возьмите правильный синтакс рaста
  fn main() {  println!("Hello, world!");}
и попробуйте компильнуть в С-ях, он не поймент семантики, хотя синтаксически(граматически) С подобный руст язык оформлен правильно.

Более понятный пример чтоб запомнить:

- "Яблоко кушает человека."

Синтаксически правильно (надеюсь ошибок не сделал), семантически - нет.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #418 Ответы: #432

426. Сообщение от Медведь (ok), 02-Ноя-25, 16:33   +/
>>А rust нифига не гарантирует отсутствие утечек памяти. Сюрприз!
> Сюрприз это только для людей, которые не в состоянии читать документацию к
> языку программирования.

То есть все претензии к C решаются простым чтением документации? Отлично, вот и договорились.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #420 Ответы: #433

432. Сообщение от Чтото знающий (?), 02-Ноя-25, 18:40   +/
>> Похоже, не понимаете.
> С точностью до наоборот.
> - Синтакс - это про граматику, про правильность, стиль
> - Семантика - это про смысл, логику, которая понятна конкретному типу.

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

Теперь ещё раз попробуйте осознать, что же вы написали: "но семантика языка где в изобилии пвседо символы вместо человеческого". Семантика не зависит от синтаксиса (от псевдосимволов - это одно слово - которые и являются тем самым синтаксисом). Почему? Потому что её можно передать другим набором символов.

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

Есть ли проблемы в синтаксисе Rust, независимо от семантики? Да, есть, их никто не отрицает. Именно поэтому язык продолжает развиваться, чтобы эти проблемы решать. Разработчики в итоге добавляют "синтаксический сахар", дабы сократить многословность некоторых "высказываний".

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #425 Ответы: #468

433. Сообщение от Чтото знающий (?), 02-Ноя-25, 18:52   +/
>>>А rust нифига не гарантирует отсутствие утечек памяти. Сюрприз!
>> Сюрприз это только для людей, которые не в состоянии читать документацию к
>> языку программирования.
> То есть все претензии к C решаются простым чтением документации? Отлично, вот
> и договорились.

То есть, у вас не только плохо с работой с первичной документацией, а ещё и с логическим мышлением. Нет, все претензии к C таким образом не решаются. Кроме того, никто не выражается, критикуя этот ЯП, в вашем стиле: "Стандарт C - это сплошное UB. Сюрприз!". Почему? Потому что это никакой не сюрприз, а хорошо известный факт.

Далее. Вам уже заметили, что утечка памяти не оказывает влияние на безопасность работы с памятью существенным образом (за исключением операций по её переполнению, но это, на самом деле, относительно редкая ситуация, поэтому и не считается сколь-либо критичной). Я же добавлю, что пока миру неизвестен способ обойти эту проблему для ЯП, который предоставляет абстракции с нулевой стоимостью.

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


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #426

434. Сообщение от Чтото знающий (?), 02-Ноя-25, 18:56   +/
>>>> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
>>> Согласен.
>> Осталось совсем немного, чтобы добиться желаемого. Да? Всего-навсего убедить комитет.
>> Шансов нет, но вы дерзайте.
> Шансы действительно невелики. Но в связи с происходящими тектоническми событиями в мире,
> может быть создан новый комитет. И вовсе не обязательно в США.

Причём здесь вообще США, которые, как государство, не оказывают никакого влияния на этот ЯП и его комитет? Вы сюда потроллить пришли?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #424 Ответы: #443

436. Сообщение от Чтото знающий (?), 02-Ноя-25, 19:00   +/
> Но кое-кто предлагает всё переписать и перейти на этот язык лишь потому что
> он лучше решает какую-то одну единственную, пусть иногда важную, проблему.

1. Проблема не одна. Это, кроме борьбы с ошибками по некорректной работе с памятью, ещё и устранение UB, предоставление стандартных языковых абстракций (которые программисты на C изобретают из проекта в проект с нуля), и развитая стандартная инфраструктура разработки.

2. Кто этот таинственный серый кардинал?

> Учитывая существенную несвободу в этой области

Это в чём выражается, например? Вам кто-то запрещает на законодательном уровне форкнуть ядро Линукса (если вы на него намекаете)?

> небольшая группа людей действительно может этого добиться, нанеся большой урон.

И зачем им это? Очередная теория заговора?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #423 Ответы: #439

437. Сообщение от Чтото знающий (?), 02-Ноя-25, 19:02   +/
>>А вам зачем, что вы собираетесь делать?
> А с какой целью вы интересуетесь? Вам это знать не нужно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

439. Сообщение от senaemail (ok), 02-Ноя-25, 19:32   +/
>> Но кое-кто предлагает всё переписать и перейти на этот язык лишь потому что
>> он лучше решает какую-то одну единственную, пусть иногда важную, проблему.
> 1. Проблема не одна. Это, кроме борьбы с ошибками по некорректной работе
> с памятью, ещё и устранение UB, предоставление стандартных языковых абстракций (которые
> программисты на C изобретают из проекта в проект с нуля), и
> развитая стандартная инфраструктура разработки.

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


> 2. Кто этот таинственный серый кардинал?

Началось с правительсва США, по-моему АНБ предложила (или другая какая-то другая спецслужба), но теперь подхватили многие.


>> Учитывая существенную несвободу в этой области
> Это в чём выражается, например? Вам кто-то запрещает на законодательном уровне форкнуть
> ядро Линукса (если вы на него намекаете)?

При чём тут Линукс вообще. :) Я про идею заместить с/с++ растом. Что касается с, я ещё более-менее согласен, что что-то надо делать ещё вчера, его давно уже законсервировали по факту и никто не собирается ничего менять. Но с++ как раз начал развиваться опять, его разморозили и вполне вполне возможно доработать в нужную сторону.

> И зачем им это? Очередная теория заговора?

Потому что им это выгодно и они считают что так лучше. Причём здесь ТЗ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #436 Ответы: #451

441. Сообщение от Чтото знающий (?), 02-Ноя-25, 19:44   +/
Наоборот, лидер. Потому что избавляет программиста от излишней когнитивной нагрузки, обусловленной иерархией одиночного и множественного наследования. Создатели Rust вовремя осознали, что наследование - это зло. Поэтому решили обойтись композицией, если нужна иерархия взаимосвязанных структур данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #417 Ответы: #469

443. Сообщение от senaemail (ok), 02-Ноя-25, 19:59   +/
>>>>> Нам нужна потеря совместимости со старым кодом. Если в C++23 до сих пор можно жонглировать указателями, то это обязательно кто-то сделает и попортит память.
>>>> Согласен.
>>> Осталось совсем немного, чтобы добиться желаемого. Да? Всего-навсего убедить комитет.
>>> Шансов нет, но вы дерзайте.
>> Шансы действительно невелики. Но в связи с происходящими тектоническми событиями в мире,
>> может быть создан новый комитет. И вовсе не обязательно в США.
> Причём здесь вообще США, которые, как государство, не оказывают никакого влияния на
> этот ЯП и его комитет? Вы сюда потроллить пришли?

Исторически весь современный IT в большой мере это продукт условного Запада во главе с США. И до сих пор, если ты посмотришь, кто принимает решения в комитете, в ISO, кто это финансирует, кто ставит задачи и задаёт направление - это Западная цивилизация. Так уж сложилось. Вполне логично, что с уменьшением доминирования Запада в целом и появлением новых независимых лидеров в мире, снизится и его роль в этих вопросах.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #434 Ответы: #450

444. Сообщение от Чтото знающий (?), 02-Ноя-25, 20:21   +/
Могут, конечно, и разбираются. Баттлы устраивают в основном растохейтеры, потому что или не понимают реальных преимуществ Rust даже после прочтения документации, или просто потому, что даже не потрудились прочесть эту самую документацию. В обоих случаях речь идёт о некоторой когнитивной сложности, с которой растохейтеры не смогли справиться либо в силу лени, либо в силу своих интеллектуальных способностей.

Есть ещё и тролли, занимающиеся троллингом тупостью. Таких тоже хватает из лагеря растохейтеров.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385

445. Сообщение от senaemail (ok), 02-Ноя-25, 20:21   +/
>>В с++ можно добавить возможность решать существующие проблемы в новом коде оставив максимум совместимости, при этом старый код можно оставить как есть, пока его не перепишут или не выкинут.
> Это существенно усложнит компиляторы, разработчики которых и так уже не поспевают за
> новыми стандартами.

Такова нелёгкая судьба разработчиков компиляторов. :) Я не считаю правильным отказываться от безопасности или усложнять жизнь обыкновенным разработчикам, чтобы облегчить им работу.

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

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


>>Вопрос времени и вдохновения комитета
> Комитет пришёл к мнению, что Safe C++ реализован не будет. На этом
> уже можно поставить жирнющую точку для ваших рассуждений о светлом будущем
> этого языка.

Это не значит, что не будет предприняты другие шаги для обеспечения безопасной работы с памятью. Но я согласен, если комитет упрётся рогом (а они могут), то с++ они смогут похоронить. Ресурсов у них для этого достаточно, а альтернативных комитетов пока не возникло.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #405 Ответы: #448

446. Сообщение от senaemail (ok), 02-Ноя-25, 20:27   +/
>>Желание выкинуть один популярнейший язык и заменить его новым, в котором ОДНА какая-то идея реализована лучше это просто безумие...
> Зависит от масштаба идеи. Например, на одном языке вы можете делать что
> угодно, но очень долго (язык общего назначения та Си). А другой
> предназначен только для извлечения данных (SQL), но делается это на этом
> языке гораздо быстрее и проще, чем на Си.

Что-то я не слыхал предложений отказаться от Си в пользу SQL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #404 Ответы: #456

448. Сообщение от Чтото знающий (?), 02-Ноя-25, 20:34   +/
> Такова нелёгкая судьба разработчиков компиляторов. :) Я не считаю правильным отказываться от безопасности или усложнять жизнь обыкновенным разработчикам, чтобы облегчить им работу.

Осталось понять, интересно ли разработчикам компиляторов ваше мнение.

> В расте тоже есть небезопасные блоки и в них можно написать опасный
> код при желании.

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

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

Вполне возможно, что лично вы действительно так и поступаете. Но ваш друг Вася (гипотетический) в большом проекте может вообще не знать ни о каких линтерах, или ВНЕЗАПНО забыть его запустить после какого-то очередного коммита.

> Но может это и неплохая идея - добавить (не)безопасные блоки в с++, для ещё большей гибкости.

Дык уже пытались (Safe C++).

> Это не значит, что не будет предприняты другие шаги для обеспечения безопасной
> работы с памятью. Но я согласен, если комитет упрётся рогом (а
> они могут), то с++ они смогут похоронить. Ресурсов у них для
> этого достаточно, а альтернативных комитетов пока не возникло.

Я вам ранее описывал, что чем больше фич добавляется в новый язык без одновременного убирания поддержки обратной совместимости, тем сложнее становится разработка и последующее сопровождение проектов на таком ЯП. Потому что когнитивная нагрузка на разработчика возрастает с каждым таким новшеством. В итоге получается, что один программист использует свой диалет языка, а другой - свой. И хорошо, если эти диалекты пересекаются. А ведь может случиться, что и нет. Например, кто-то может до сих использовать стандарт 98 года, а другой - 23-го.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #445 Ответы: #466

450. Сообщение от Чтото знающий (?), 02-Ноя-25, 20:40   +/
> Исторически весь современный IT в большой мере это продукт условного Запада во
> главе с США. И до сих пор, если ты посмотришь, кто
> принимает решения в комитете, в ISO, кто это финансирует, кто ставит
> задачи и задаёт направление - это Западная цивилизация. Так уж сложилось.
> Вполне логично, что с уменьшением доминирования Запада в целом и появлением
> новых независимых лидеров в мире, снизится и его роль в этих
> вопросах.

Что за бред? Каким образом западная цивилизация оказывает влияние на семантику и синтаксис того или иного языка программирования (ну, кроме использования латиницы, очевидно, и анлицизмов в ключевых словах)? Вы там каким-то образом умудрились развидеть признаки западной культуры? Или что за чушь вы счас несёте?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #443 Ответы: #453

451. Сообщение от Чтото знающий (?), 02-Ноя-25, 20:52   +/
> Главная причина, по которой пытаются переписать (иногда успешно) некоторый код именно одна - более безопасная работа с памятью, что вроде бы как должно привести к уменьшению количества дыр в безопасности.

Ок. Если приведёт к устранению 70% ошибок в работе ПО, что здесь плохого? Как мы уже успели выяснить, ни C++, ни уж тем более C, на этот поле не преуспели.
Далее, переписывают не всё подряд, всё-таки, а или только наиболее критичные (ненадёжные) участки, или то, что легко переписать без существенных затрат на это.


>> 2. Кто этот таинственный серый кардинал?
> Началось с правительсва США, по-моему АНБ предложила (или другая какая-то другая спецслужба), но теперь подхватили многие.

Правительсто США - один из крупнейших заказчиков ПО в мире. Исходя из этого факта, они вправе требовать за деньги налогоплательщиков соблюдение должного качества заказываемого ПО. Но! Вас лично никто не заставляет работать ни на АНБ, ни на правительство США. Далее. Может приведёте хоть один законодательный акт на эту тему? Потому что я читал только о том, что если вы работаете на правительство США (читай, оно платит вам деньги), то оно вправе выдвигать какие-то требования. Если вы не работаете на правительство США - можете разрабатывать своё ПО на каком угодно ЯП.

> Я про идею заместить с/с++ растом.

Вас лично кто-то заставляет участвовать в этом процессе на уровне законодательства?


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

Теоретически - да, возможно. Практика же показывает обратное. Собственно это и стало причиной появления Rust.


> Потому что им это выгодно и они считают что так лучше.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #439 Ответы: #455

452. Сообщение от Аноним (-), 02-Ноя-25, 21:12   +/
> Ну прям порадовал. Не забудь теперь донести эту важную мысль до разработчиков C++

Зачем - они и так в курсе. Согласно опросу StackOverflow, 25% плосовиков пишут на расте.

> 10.294, Медведь
> Да хоть какое-то ООП покажи уже в этом своем убогом расте, дятел. Какая на фиг разница, говорю я про ООП в стиле C++ или smalltalk, если в твоем жалком недоязычке нет ни того ни другого.

.
> 12.410, Медведь
> И главное, не забудь выкинуть те ошметки ООП, которые удалось таки протащить в Rust. Да-да, все эти ваши трейты и полиморфизм на них -- всё еще ООП, хотя и жутко кастрированное.

Напишешь потом, кто из вас двоих победил в этом споре. Очень интересно (нет).

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410

453. Сообщение от senaemail (ok), 02-Ноя-25, 21:37   +/
> Что за бред? Каким образом западная цивилизация оказывает влияние на семантику и
> синтаксис того или иного языка программирования (ну, кроме использования латиницы, очевидно,
> и анлицизмов в ключевых словах)? Вы там каким-то образом умудрились развидеть
> признаки западной культуры? Или что за чушь вы счас несёте?

Скорее IT, с языками программирования и всем сопутствующим это и есть западная цивилизация, её составная и неотъемлемая часть. На культуру появление IT тоже оказало огромное влияние, без всякого сомнения.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #450 Ответы: #457

454. Сообщение от Аноним (389), 02-Ноя-25, 21:50    Скрыто ботом-модератором+/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220

455. Сообщение от senaemail (ok), 02-Ноя-25, 22:24   +/
>> Главная причина, по которой пытаются переписать (иногда успешно) некоторый код именно одна - более безопасная работа с памятью, что вроде бы как должно привести к уменьшению количества дыр в безопасности.
> Ок. Если приведёт к устранению 70% ошибок в работе ПО, что здесь
> плохого? Как мы уже успели выяснить, ни C++, ни уж тем
> более C, на этот поле не преуспели.
> Далее, переписывают не всё подряд, всё-таки, а или только наиболее критичные (ненадёжные)
> участки, или то, что легко переписать без существенных затрат на это.

Ещё раз, проблема не в том, что появился какой-то новый язык, их по десятку в год появляется, а то и больше. И не в том, что кто-то предлагает им заменить с/с++. Проблема в том что им предлагается заменить с/c++ такими людьми и организациями, которые смогут реально продавить это решение. И это на фоне импотенции (или саботажа) развития с/с++ соответствующими комитетами. Ну, с++ ещё как-то шевелится и на нём рано ставить крест, а уж си точно заморожен много лет. С такими раскладами си должны были похоронить уже давно, но были кое-какие области, где он ещё держался.

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

> Вас лично кто-то заставляет участвовать в этом процессе на уровне законодательства?

А тебе принципиально, чтобы тебя не заставляли участвовать в чём-то только на уровне законодательства? Если заставляют не на уровне законодательства, то ты готов смириться?

На сегодняшний день миром IT рулят корпорации, если не на 100%, то на 95% точно. А эти люди не играют в демократию, бизнес диктует, что и как будет делать программист, устраиваясь на работу. Даже будучи независимым мелким предпринимателем, я вынужден использовать те языки и компиляторы, которые мне предложат другие разработчики и комитеты, работу которых через финансирование и другие механизмы влияют, а порой и контролируют те же самые корпы.

То есть если комитет по каким-то причинам, личным или корыстным или ещё каким-то решил остановить развитие языка, то нет никакого механизма, через который мы могли бы на это повлиять. Это очень плохо.

> Теоретически - да, возможно. Практика же показывает обратное. Собственно это и стало
> причиной появления Rust.

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

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #451 Ответы: #459, #462

456. Сообщение от Чтото знающий (?), 02-Ноя-25, 22:31   +/
>>>Желание выкинуть один популярнейший язык и заменить его новым, в котором ОДНА какая-то идея реализована лучше это просто безумие...
>> Зависит от масштаба идеи. Например, на одном языке вы можете делать что
>> угодно, но очень долго (язык общего назначения та Си). А другой
>> предназначен только для извлечения данных (SQL), но делается это на этом
>> языке гораздо быстрее и проще, чем на Си.
> Что-то я не слыхал предложений отказаться от Си в пользу SQL.

Никто не говорил о полном выкидывании C в пользу SQL. Речь шла о переписывании кода на C на SQL там, где это целесообразно. И такое было на самом деле. Вспоминается Clipper - язык программирования баз данных в середине-конце девяностых. Его успешно в итоге вытеснили СУБД с поддержкой SQL.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #446 Ответы: #460

457. Сообщение от Чтото знающий (?), 02-Ноя-25, 22:33   +/
>> Что за бред? Каким образом западная цивилизация оказывает влияние на семантику и
>> синтаксис того или иного языка программирования (ну, кроме использования латиницы, очевидно,
>> и анлицизмов в ключевых словах)? Вы там каким-то образом умудрились развидеть
>> признаки западной культуры? Или что за чушь вы счас несёте?
> Скорее IT, с языками программирования и всем сопутствующим это и есть западная
> цивилизация, её составная и неотъемлемая часть. На культуру появление IT тоже
> оказало огромное влияние, без всякого сомнения.

Простите, но мне нужны конкретные факты, а не ваши фантазии на заданную тему. Причём здесь западная цивилизация (кстати, как вы её определяете) до ИТ? Где вы там усматриваете влияние западной культуры?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #453 Ответы: #458

458. Сообщение от senaemail (ok), 02-Ноя-25, 22:50   +/
> Простите, но мне нужны конкретные факты, а не ваши фантазии на заданную
> тему. Причём здесь западная цивилизация (кстати, как вы её определяете) до
> ИТ? Где вы там усматриваете влияние западной культуры?

Боюсь, если ты не знаешь даже, что такое Западная цивилизация[1], то нам будет трудно найти общий язык. Ещё посмотри историю вычислительной техники[2]. Эдак мы до букваря дойдём. Про влияние западной культуры вообще не понял, вроде такого ничего не говорил.

1. https://ru.wikipedia.org/wiki/%D0%97%D0%...
2. https://ru.wikipedia.org/wiki/%D0%98%D1%...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #457

459. Сообщение от Чтото знающий (?), 02-Ноя-25, 22:55   +/
> Проблема в том что им предлагается заменить с/c++ такими людьми и организациями, которые смогут реально продавить это решение.

Здесь нет проблемы. Новый язык объективно лучше. Разработка идёт на нём быстрее, чем на Плюсах, и с гораздо меньшим количеством ошибок, чем на Си.

> А тебе принципиально, чтобы тебя не заставляли участвовать в чём-то только на
> уровне законодательства? Если заставляют не на уровне законодательства, то ты готов
> смириться?

Мы уже на "ты" перешли? Я не заметил, чтобы мы пили на брудершафт. Меня лично никто ничего не заставляет делать. И вас, полагаю, тоже. Хотите дальше программировать на C/C++ - программируйте.


> На сегодняшний день миром IT рулят корпорации, если не на 100%, то на 95% точно. А эти люди не играют в демократию, бизнес диктует, что и как будет делать программист, устраиваясь на работу. Даже будучи независимым мелким предпринимателем, я вынужден использовать те языки и компиляторы, которые мне предложат другие разработчики и комитеты, работу которых через финансирование и другие механизмы влияют, а порой и контролируют те же самые корпы.

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


> То есть если комитет по каким-то причинам, личным или корыстным или ещё
> каким-то решил остановить развитие языка, то нет никакого механизма, через который
> мы могли бы на это повлиять. Это очень плохо.

Есть, конечно. Вы можете найти единомышленников и "форкнуть" C++, продолжив его развитие так, как считаете необходимым. Но это уже будет означать появление нового ЯП.


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

Если новый ЯП окажется существенно лучше Rust - да, будем переписывать при условии наличия финансирования, разумеется.

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

Когда вектор развития какой-то корпорации сильно не совпадает с развитием общества, обычно эту корпорацию ставят на место госорганы (в виде, например, Антимонопольного комитета).

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #455 Ответы: #461

460. Сообщение от senaemail (ok), 02-Ноя-25, 22:59   +/
>Его успешно в итоге вытеснили СУБД с поддержкой SQL. Речь шла о переписывании кода на C на SQL там, где это целесообразно.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #456

461. Сообщение от senaemail (ok), 02-Ноя-25, 23:10   +/
> Здесь нет проблемы. Новый язык объективно лучше. Разработка идёт на нём быстрее,
> чем на Плюсах, и с гораздо меньшим количеством ошибок, чем на
> Си.

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


>> А тебе принципиально, чтобы тебя не заставляли участвовать в чём-то только на
>> уровне законодательства? Если заставляют не на уровне законодательства, то ты готов
>> смириться?
> Мы уже на "ты" перешли? Я не заметил, чтобы мы пили на
> брудершафт. Меня лично никто ничего не заставляет делать. И вас, полагаю,
> тоже. Хотите дальше программировать на C/C++ - программируйте.

В Интернете и на форумах изначально было принято дружеское обращение на ты. Так что я по-старинке, уж прости старика. Но если ты пишешь (Вы пишете) "Вы" , что ни в коем случае не плохо, то следует непременно использовать заглавную букву. Это правило русского языка подчёркивает вежливовость по отношению к собеседнику. "ты" можно писать с маленькой, а "Вы" непременно с большой, если обращаешься в единственном числе.

https://gramota.ru/biblioteka/spravochniki/pismovnik/kak-pis...

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

Эх, молодость, молодость :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #459

462. Сообщение от Фнон (-), 02-Ноя-25, 23:32   +/
> Проблема в том что им предлагается заменить с/c++ такими людьми и организациями, которые смогут реально продавить это решение.

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

> И это на фоне импотенции (или саботажа) развития с/с++ соответствующими комитетами.

Вам не кажется что причина того, что заговорили о замене, как раз в импотентности и отсутствии развития?
Раст придумали как раз по причине того, что они НЕ хотят развиваться.
Они не хотя добавлять новые технологии.
Они не хотят ломать АБИ, хотя это может ускорить некоторые функции от 100 до 300%
cor3ntin.github.io/posts/abi/
www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2028r0.pdf
Коммитет может 2 поколения языка (6 лет!!) обсуждать "а надо ли?"
Они не хотят брать на себя ответственность и трясутся за кресла.

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

О, вот тут я бы записал в список и С++.

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

Можете написать письмо в комитет и сказать что они там ленивые удаки)
Но да, если там уперлись, индустрия найдет другие варианты.
Как говорилось в одном фильме "жизнь найдет выход".


> На сегодняшний день миром IT рулят корпорации, если не на 100%, то на 95% точно.

Всегда так было.
Посмотрите кто создавал UNIX с которого коммуняки тащили код в линукс.
Кто создал Хорг, RFC стандарты интернета, железо.
Даже СИ делались людьми работающими в корпорациях - Белл Лаб это весьма известная организация.

> А эти люди не играют в демократию, бизнес диктует, что и как будет делать программист, устраиваясь на работу.

И это отлично. Лебедь-рак-и-щука это один из бичей опенсорса.
Хотя в СПО проектах тоже обожают всяких пожизненных диктаторов.

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

Ну так делаейте сами!
А если не можете, скиньтесь деньгами и наймите кого-то, кто может.
Но нет! Сладкие речи Столмана и прочих адептов коммунизма приучили что "всё должно быть бесплатным".
Поэтому делают те, кто может.

> То есть если комитет по каким-то причинам, личным или корыстным или ещё каким-то решил остановить развитие языка, то нет никакого механизма, через который мы могли бы на это повлиять. Это очень плохо.

Так было всегда.
Если завтра главный разработчик уходит из проекта - он с высокой вероятностью загибается.
Пример Вим отлично это показал.

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

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

Это называется прогресс.
Люди жили в пещерах. Потом смогли в глинобитные строения из грязи и палок.
Деревянные дома были заменены каменными, потом кирпичными.
Потом появился бетон и железо.

> Но этот (многомерный) вектор может сильно не совпадать с направлением на улучшение благосостояния общества и человечества.

Так корпорации это и есть часть общества - люди из которых они состоят.


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #455 Ответы: #463

463. Сообщение от senaemail (ok), 03-Ноя-25, 00:07   +/
> Э? Я не могу уловить мысль.
> Т.е если бы пришли люди которые не захотели бы заменять было бы
> лучше?

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

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

Я думаю что здесь нет противоречия. Это примерно одни и те же люди, которые приняли решение заморозить развитие си и те же люди планируют заменить его на раст. Разумеется переписано будет 1% максимум. 99% будет написано заново. Ну ничего, не привыкать...

Мне, как программисту теоретически это выгодно, работы будет много. Но как человек я против такого расточительного подхода.


> Они не хотя добавлять новые технологии.
> Они не хотят ломать АБИ...
> Коммитет может 2 поколения языка (6 лет!!) обсуждать "а надо ли?"
> Они не хотят брать на себя ответственность и трясутся за кресла.

За ними стоит целая индустрия со своими миллиардами. Если бы кто-то из корпов захотел, то завтра бы уже был новый стандарт. Но индустрии не нужен новый с++, им нужен новый раст.


> О, вот тут я бы записал в список и С++.

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


> А если не можете, скиньтесь деньгами и наймите кого-то, кто может.
> Но нет!

Можете что? Заставить комитет принять другой стандарт? Киллера предлагаешь?

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


> Сладкие речи Столмана и прочих адептов коммунизма приучили что "всё
> должно быть бесплатным".
> Поэтому делают те, кто может.

Это жирно. Столлмана в обиду не дам, его вклад огромен и бесценен.

> Так было всегда.

Да, не спорю. Но пора бы это изменить. Как - не знаю.


> Это называется прогресс.

Ну да... плюс-минус :(

> Так корпорации это и есть часть общества - люди из которых они
> состоят.

Только вектор развития корпорации задают не все люди из которых они состоят, а только небольшая верхушка. И на них тоже можно повлиять.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #462 Ответы: #464

464. Сообщение от Аноним (-), 03-Ноя-25, 01:32   +/
> Было бы лучше, если бы эти люди продавили развитие с/с++ в этом направлении.

Мне кажется что:
а) это все-таки разные люди
б) кроме комитета есть еще пользователи ЯП, которые любят громко кричать
Например Теодор "вы не заставите меня учить раст" Тцо.
Которые тоже очень против нововведений.

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

Звучит неубедительно)
О заморозке развития СИ, я слышал уже давно под лозунгами "он и так хорошъ! зачем добавлять ненужные свистелки-перделки! это все смузихлебные фичи".

> Мне, как программисту теоретически это выгодно, работы будет много. Но как человек я против такого расточительного подхода.

Давайте не сносить старые здания, можно же просто расширять уже существующие достраивая этажи.

> За ними стоит целая индустрия со своими миллиардами. Если бы кто-то из корпов захотел, то завтра бы уже был новый стандарт. Но индустрии не нужен новый с++, им нужен новый раст.

Возможно корпы понимают что есть некий "предел улучшений", после которого проще снести и построить заново.

> Можете что? Заставить комитет принять другой стандарт? Киллера предлагаешь?

Хм... интересный вариант.

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

А никто и не пробовал.
Потому что ISO и тд.
Проще сделать новый ЯП, ни перед кем не отчитываясь, а потом, если будет нужно, стандартизоватьб

> Это жирно.

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

> Столлмана в обиду не дам, его вклад огромен и бесценен.

Ок, не буду спорить. В моем мире, кроме вредной болтовни от него толку не было.

> Да, не спорю. Но пора бы это изменить. Как - не знаю.

Никак.
Люди меняются очень неохотно и для этого нужны десятки лет.

> Только вектор развития корпорации задают не все люди из которых они состоят, а только небольшая верхушка. И на них тоже можно повлиять.

Как и политики. Как и руководители СПО проектов (особенно "диктаторских").
Всегда будет тот (или узкий круг тех), кто принимает финальное решение.
Селяви. Тут боюсь тоже ничего не сделаешь.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #463 Ответы: #467

465. Сообщение от senaemail (ok), 03-Ноя-25, 02:55   +/
> в итоге получите монстра типа C++ или SQL со спецификацией на 1500-1700 страниц, которую не в состоянии не будет освоить ни один человек в мире
> В итоге один человек будет программировать на своём диалекте, который человек, использующий другой диалект, уже понимать не будет.

Да это так, если только добавлять. Однако устаревшие конструкции со временем надо выбрасывать. Пока это делать боятся, но это не значит что так будет продолжнаться вечно. Если с++ не будет заморожен, как си, то придётся выбрасывать старые конструкции и нарушать совместимость. Да, выбрасывание старых конструкций это боль, но это однажды придётся сделать.

Возникновение диалектов (точнее версий) - да, это нормально, когда язык развивается. Это всё равно в миллион раз лучше, чем переход на принципиально другой язык.

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

Пока вполне справляются. Даже быстрее чем мы успеваем это освоить.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #403

466. Сообщение от senaemail (ok), 03-Ноя-25, 03:14   +/
>> С линтером тоже, если мне нужен гарантированно безопасный код, я его проверяю линтером и делаю эту проверку обязательной.
> Вполне возможно, что лично вы действительно так и поступаете. Но ваш друг
> Вася (гипотетический) в большом проекте может вообще не знать ни о
> каких линтерах, или ВНЕЗАПНО забыть его запустить после какого-то очередного коммита.

В большом проекте проверки запускаются автоматически. ВНЕЗАПНО. Если они не запускаются, значит эти проверки не нужны. Не всем и не всегда нужна безопасность, не всем это важно. И тогда хорошо, если можно отключить проверки.

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

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #448

467. Сообщение от senaemail (ok), 03-Ноя-25, 03:32   +/
>> Я думаю что здесь нет противоречия. Это примерно одни и те же люди, которые приняли решение заморозить развитие си и те же люди планируют заменить его на раст. Разумеется
> Звучит неубедительно)

И Гугл и Микрософт и другие принимают деятельное участие и в растфаундейшн и в работе комитета с/c++.


> Возможно корпы понимают что есть некий "предел улучшений", после которого проще снести
> и построить заново.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #464

468. Сообщение от OpenEcho (?), 03-Ноя-25, 14:12   +/
> А я что выше написал?

Вы написали, что я неправильно применил слово "семантика" в контексте языка раст

> Теперь ещё раз попробуйте осознать, что же вы написали: "но семантика языка где в изобилии пвседо символы вместо человеческого".

Теперь делаем так s/семантика/смысл/g в моем оригинальном предложении. Перепрочитываем моё и возвращаемся к вашей цитате

> плохо разбираетесь в семантике языка (его смысловом наполнении).

Я про смысл и Вы тоже. Теперь понятно?

> А синтаксис вы не понимаете (не можете освоить) только потому,

И давайте оставим вашу телепатию о глубине моего понимании раст-а за бортом,  Ок?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #432

469. Сообщение от Аноним (415), 03-Ноя-25, 14:16   +/
Так и скажем, не осилили. И этим проиграют на больших проектах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #441

470. Сообщение от freecoderemail (ok), 03-Ноя-25, 20:40   +/
Rust выбирают те, кто хорошо знают, почему они его хотят и что им не хватает в других языках. Не из-за синтаксиса его берут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385 Ответы: #473

471. Сообщение от Аноним (471), 05-Ноя-25, 14:16   +/
Обучаться на коде от нейронок - вообще беда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #389

472. Сообщение от Аноним (471), 05-Ноя-25, 14:18   +/
> Он хочет сказать, что с элементарным логическим мышлением у военов борьбы супротив Раста очень туго. Вот и ваши вопросы тому яркое подтверждение.

Но пока получается, что у евангелистов Раста с логическим мышлением вообще никак. Абсолютно не способны к критическому мышлению.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397

473. Сообщение от Аноним (471), 05-Ноя-25, 14:33   +/
> Rust выбирают те, кто хорошо знают, почему они его хотят и что им не хватает в других языках. Не из-за синтаксиса его берут.

И при этом не понимают сути. Приводящей к ограничениям использования rust.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #470

476. Сообщение от zionist (ok), 05-Ноя-25, 22:31   +/
Какие недостатки у Golang?


Ответить | Правка | Наверх | Cообщить модератору
Родитель: #416

477. Сообщение от wyry (ok), 06-Ноя-25, 21:00   +1 +/
Скорее он не только не гарантирует, но и постоянно течет, или даже не течёт, а попросту потребляет гораздо больше памяти и начинает тормозить от того что её нужно постоянно выделять и иногда освобождать. Cosmic на Rust - это позорище, кривое, глючное и при этом жрущее ресурсы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #479

478. Сообщение от Аноним (-), 06-Ноя-25, 22:46   +/
const TypeId::of очень долго ждали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

479. Сообщение от Медведь (ok), 07-Ноя-25, 00:32   +/
> Скорее он не только не гарантирует, но и постоянно течет, или даже
> не течёт, а попросту потребляет гораздо больше памяти и начинает тормозить
> от того что её нужно постоянно выделять и иногда освобождать. Cosmic
> на Rust - это позорище, кривое, глючное и при этом жрущее
> ресурсы.

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #477


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру