Но зачем? Этот корявый, мертворожденный язык скоро придется закапывать. Вместе с «технологией», ради которой он создавался - Серво. И вместе с Мозиллой.

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

Хочешь мне денег послать?

И всё это - в пяти страницах текста? Серьезно?

Думаю, хватило бы и двух страниц, правда не факт, что я бы их понял.

Нет, хочу, чтобы ты избавил от своей глупости.

1С уже наскучил?

Какие грабли уже проявили себя.

Где-то проскакивала инфа что их хваленое compile-time управление памятью просто эпически провалилось.

Думаю, хватило бы и двух страниц

Ну, я думаю, что для всего, кроме «положение Rust в контексте других языков» хватило бы «memory safety via static typing and linear typing» и «native compilation via LLVM».

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

Где-то проскакивала инфа что их хваленое compile-time управление памятью просто эпически провалилось.

Ссылкой не порадуешь?

Ну... там же вроде синтаксис ещё есть. Модули. Инструментарий.

А как же Apple? Они что, неверно выбрали, что украсть?

Это уже не 2 и не 5 страниц.

Чисто технические причины НЕ любить Rust [holywar mode activated] (комментарий)

Ну, если у тебя такого текста нет, то жаль. Давай сколько есть.

https://github.com/rust-lang/rust/issues/24292

Это имеет очень косвенное отношение к «compile-time управлению памяти». Ну да, написали unsound-код, бывает.

Я слишком давно слежу за языком и просто пропускаю материалы вводного уровня, так что... но были неплохие статьи на LWN.net: https://lwn.net/Articles/548560/ https://lwn.net/Articles/547145/

Ну и что там не так? При помощи unsafe можно написать небезопасную функцию, в стандартной библиотеке такое сделали по ошибке, не понятно как это связано с тем что compile-time проверки в safe функциях провалились?

Ну... там же вроде синтаксис ещё есть. Модули. Инструментарий.

И какая в модулях новизна? Да и новизна синтаксиса редко имеет ценность сама по себе.

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

Ты вообще встречал такое описание для других языков?

Что-то затянулся взлет раста и серво. Тут уже сама мозилла на ладан дышит, скоро просто некому будет оценить их поделие.

Зачем тебе это г-но для «продвинутых» хипсторов?

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

необходимого количества преимуществ чтобы взять и прям сейчас бросить C++

Интересно как ты представляешь себе такие преимущества.

Например: быть компилируемым в нативный код, в байт код для JVM/CLI, в JavaScript, прочие ВМ; иметь возможность исполняться «как скрипт»; иметь модульную стандартную библиотеку (с минимальной базой); легкая интеграция с модулями на Си (ну это не редкость); максимально Си-подобный синтаксис; с автоматическим управлением памятью но с возможностью ручного управления где надо; иметь сразу биндинги к развитому GUI такому как Qt/QML.

Я фантазер и много хочу? Нет, есть ряд языков которые стремятся к этому идеалу (по моим представлениям). Python, D - ближе всего, но части «фич мячты» явно нет. Чтоб всё сразу... Пока не видно, только через сторонние костыли и дополнения. Нет пока того что бы сманило с C++ таких быдлокодеров типа меня.

Тебе хватает C++ потому что ты на нем не пишешь. Ты пишешь на Qt.

Rust это C++ без совместимости на уровне исходников с C, если грубо говорить. Концепция: фичи без runtime overhead-а. Из отличительного: очень необычная система типов, в итоге компилятор гарантирует корректность кода без утечек памяти и некоторых других проблем (в том числе решаются некоторые проблемы с многопоточностью), при отсутствии runtime overhead-а вроде сборщика мусора или счётчика ссылок на всех указателях. При необходимости можно безопасностью жертвовать, спускаясь хоть до языка ассемблера.

В остальном — нормальная модульность, нормальные шаблоны, нормальные макросы, хорошая стандартная библиотека. Вообще всё сделано добротно и качественно.

Rust это C++

Это правда. Но возникает вопрос: а нахуа нам ещё один макаронный монстр? Не было печали, крестов понаклепали.

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

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

...когда на плюсы с раста код переделывал.

Вся суть недоязычков, претендующих на «убийцу крестов».

Хорошая система типов с закосом под хаскелл, уебанская обработка ошибок, паттер-матчинг, макросы, модули, ссылки. Громоздкий как С++. Новизны нет.

Rust это C++ без совместимости на уровне исходников с C

Полная чушь.

Но возникает вопрос: а нахуа нам ещё один макаронный монстр? Не было печали, крестов понаклепали.

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

Например: быть компилируемым в нативный код, в байт код для JVM/CLI, в JavaScript, прочие ВМ;

Это не так полезно и востребовано как кажется. Вон скалу затащили под .net, но не взлетело. Просто потому что те, кто уже пишут на скале - используют джавовские фреймворки и библиотеки. Вот пишешь ты с использованием Qt и бросать его ради того чтобы перетащить приложение на другую ВМ не захочешь.

с автоматическим управлением памятью но с возможностью ручного управления где надо

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

Такая же скорость кода, но при этом гарантии безопасности.

Так тебе раст подошёл?

Ну а вообще я как раз намекал на то, что это штука довольно субьективная. Кто-то меньше на инфраструктуру завязан, кто-то больше. Если человек жизни без Qt не представляет, то ясное дело, что новый язык без биндингов ему не подойдёт.

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

Новизны нет.

А как же borrow checker? Не Cyclone же использовать.

кривой стандартной библиотеки тоже не было

Можно примеры кривости и того как она мешает жить?

шаблоны использовались для векторов и списков, а не для факториалов

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

Согласен с тем, что кривости в языке имеются, но как по мне, перечисленное и близко к ним не относится.

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

http://paulkoerbitz.de/posts/Understanding-Pointers-Ownership-and-Lifetimes-i...

2. Критика. Какие грабли уже проявили себя.

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

Можно примеры кривости и того как она мешает жить?

Массив байтов, обозванный строкой, например. Ну и в принципе отсутствие поддержки обработки текста, жить можно только с библиотеками вроде Qt. Побитовый сдвиг, обозванный оператором вывода. В принципе отсутствие нормальной библиотеки потоков (streams), с композициями и прочими удобствами. Какие-то безумные сложности для банального преобразования числа в строку (правда тут может были подвижки в последних стандартах, по крайней мере в бусте это было проще). Какие-то придуманные на ровном месте проблемы с исключениями в деструкторе. Вот закрыл я файл в деструкторе, а он не закрылся, close() вернул ошибку. И что мне делать? В любом другом языке я выкину ошибку тем или иным образом. В C++ я могу только поругаться в консоль. Ну или упасть. Хороший выбор. Отсутствие стектрейсов у исключений. Зоопарк реализаций стандартных структур данных. Слишком гибкая система классов (нет общего предка, полноценное множественное наследование), которая в итоге получилась переусложнённой и тянущей слишком сложную реализацию (например указатель на базовый класс может не совпадать с указателем на класс-наследник) без каких-либо преимуществ в итоге.

И, что самое обидное, несмотря на всю заявленную мощь и выразительность C++ залазишь в реализацию STL и видишь

  iterator _M_allocate_and_copy(size_type __n, const_iterator __first, 
                                               const_iterator __last)

это ведь ужасно.

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

Когда отвёрткой забивают гвозди, ничего хорошего в этом нет. Если нормальное метапрограммирование добавят, мне это понравится. Нормальное это либо как в Scheme (и как в Rust-е) — через макросы и паттерн-матчинг, либо как в старом Lisp-е — просто через функции, преобразующие AST и запускаемые при компиляции. Может ещё варианты есть, не знаю. Но шаблоны это плохой вариант.

Ну по-мне C++ был прекрасен в своём, так сказать, начале пути, когда он был простой и понятный, как два рубля...
...Побитовый сдвиг, обозванный оператором вывода.

Такое ощущение, что вы начали программировать на C++ еще раньше Страуструпа. Т.к. iostreams с operator<< были в C++ с самого начала. Да и виртуальное множественное наследование появилось практически в одно время с шаблонами.

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

Расскажите, плиз, как вы будете это делать, скажем, в Java.

Массив байтов, обозванный строкой, например.

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

моё впечатление

1. В сжатой, но понятной форме изложено положение Rust в контексте других языков. В чём суть его новизны. В качестве базы ожидается C++, Java, Common Lisp.

язык, в котором реформировали модель памяти (ср.: «модель памяти Си», «си-машина») за счёт:
а) семантики владения/одалживания, и учёта времени жизни объектов
б) лучшей многопоточности

при этом оставили идею «не платишь за то, что не используешь»:
а) большинство вещей, встроенных в рантайм — вынесено в библиотеки. язык более модульный
например: в Go «зелёные нитки» реализованы как корутины в семантике процессоров Хоара, наподобие Occam и мониторов (и в сторону Plan 9, Limbo/Alef/Newsqueak, а также Icon/Unicon) — через каналы и посылку сообщений в канал между корутинами, при этом функции или лямбды являются «объектами первого порядка», которые можно запустить асинхронно, через go myFunc()() (или go с лямбдой). при этом в GoLang goroutines, каналы и интерфейсы реализованы в рантайме, завязаны в том числе и на сборщик мусора.
в RustLang же вынесли их в библиотеку, реализовали корутины и каналы через библиотеку. при этом передача «одолженного» объекта влияет на его семантику владения/перемещения, что удобно например в контексте проблемы 10к хайлоада.
для примера, см. статью про «порталы» как можно реализовать корутины на С++ через Boost и лямбды с примерами применения семантики перемещения для реализации сервера.
всё это завязано на модель памяти, реализацию многопоточности/многопроцессности внутри раст приложения, семантику panic! (без возможности размотать стек и восстановиться рестартом, как в «сигнальном протоколе ошибок» — всё всегда разматывается и всё всегда падает, как в ерланге)

б) язык более модульный и за счёт отказа от объектов в пользу трейтов, реализации подмножества метаобъектного протокола на трейтах (примерно как мультиметоды на С++). то есть: похоже на то как и в GoLang, аггрегация вместо наследования, миксины вместо наследования, только наследование трейтов, то есть — интерфейсов. см. статью про lisp-interface-library, а также google://«Interface Passing Style» в CL — чем-то похоже.
тут всё более завязано на ADT, абстрактные типы данных: в духе Ocaml, Haskell и т.п.
в том смысле, что например типы Maybe Some/None используются вместо исключений или сигнального протокола ошибок (падать-то нельзя, сразу panic!)
то есть, системные библиотеки более модульны

в) поверх этого всего есть макросы, двух типов: с гигиеной и паттерн матчингом выражений (то есть, в «дырку» шаблона можно подставлять только выражения, например, а не типы — или наоброт) и AST макросы, которые можно реализовать как плагины компилятору (compiler-macro в CL)

г) модули есть, разумеется

д) готовый «пакетный менеджер» cargo (вместо quicklisp) для скачивания и установки «батареек» а также сборки и запуска тестов.

е) прозрачность линковки с Си и написания биндингов с Си.

лично для Раст вызывает интерес как очевидную цель для компиляции вместо «компиляторов через Си» с кодогенерацией в Си — «компиляция через Раст» ничем не хуже.

да, ещё можно программировать непосредственно на нём (а не на метаязыке поверх раста :-))

в сравнении «минималистичного helloworld-a» на Java/C++/Common Lisp/Rust:

C++ — зависимости от libstdc++, libc; если аккуратно пользоваться фичами — те же 20к, что и в С; если заменить libc на сисколлы — менее 1к

Java — зависимости от JRE; Gcj — компактнее, но недоJDK; Excelsior Jet — те же 20 Мб рантайма в одном .EXE + smart linking = 2 .. 5 Мб реально, в зависимости от библиотек (консольный хелловорд менее мегабайта)

Common Lisp — толстый стандарт, плохая модульность, классная семантика, практичная; тот же SBCL — 60 Мб .exe (кстати, ни GNU Emacs/XEmacs, ни твой clcon особо менее 300 Мб не занимает, что довольно таки толстовато будет; почти как у Nim)

Rust — более компактно это всё, в том числе можно и до 150 байт сократить если поизвращаться с сисколлами/заголовком ELF (см. в гугле статьи «минимальный хелловорд на Rust и на Nim 150 байт размером»).

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

В целом, сопоставимо с С++, только компактнее, и более модульно.

перечитывая "Unix Haters Handbook"

«Unix Haters Handbook», стр. 239, глава 10:

10 C++ The COBOL of the 90s

Q. Where did the names “C” and “C++” come from? A. They were grades.
—Jerry Leichter

It was perhaps inevitable that out of the Unix philosophy of not ever making anything easy for the user would come a language like C++. The idea of object-oriented programming dates back to Simula in the 60s, hitting the big time with Smalltalk in the early 70s. Other books can tell you how using any of dozens of object-oriented languages can make programmers more productive, make code more robust, and reduce maintenance costs. Don’t expect to see any of these advantages in C++. That’s because C++ misses the point of what being object-oriented was all about. Instead of simplifying things, C++ sets a new world record for complexity. Like Unix, C++ was never designed, it mutated as one goofy mistake after another became obvious. It’s just one big mess of afterthoughts. There is no grammar specifying the language (something practically all other languages have), so you can’t even tell when a given line of code is legitimate or not. 204 C++ Comparing C++ to COBOL is unfair to COBOL, which actually was a marvelous feat of engineering, given the technology of its day. The only marvelous thing about C++ is that anyone manages to get any work done in it at all. Fortunately, most good programmers know that they can avoid C++ by writing largely in C, steering clear of most of the ridiculous features that they’ll probably never understand anyway. Usually, this means writing their own non-object-oriented tools to get just the features they need. Of course, this means their code will be idiosyncratic, incompatible, and impossible to understand or reuse. But a thin veneer of C++ here and there is just enough to fool managers into approving their projects. Companies that are now desperate to rid themselves of the tangled, unreadable, patchwork messes of COBOL legacy code are in for a nasty shock. The ones who have already switched to C++ are only just starting to realize that the payoffs just aren’t there. Of course, it’s already too late. The seeds of software disasters for decades to come have already been planted and well fertilized.

The Assembly Language of Object-Oriented Programming

The Assembly Language of Object-Oriented Programming There’s nothing high-level about C++.There’s nothing high-level about C++. To see why, let us look at the properties of a true high-level language: • Elegance: there is a simple, easily understood relationship between the notation used by a high-level language and the concepts expressed. • Abstraction: each expression in a high-level language describes one and only one concept. Concepts may be described independently and combined freely. • Power: with a high-level language, any precise and complete description of the desired behavior of a program may be expressed straightforwardly in that language. A high-level language lets programmers express solutions in a manner appropriate to the problem. High-level programs are relatively easy to maintain because their intent is clear. From one piece of high-level source code, modern compilers can generate very efficient code for a wide variety of platforms, so high-level code is naturally very portable and reusable.

A low-level language demands attention to myriad details, most of which have more to do with the machine’s internal operation than with the problem being solved. Not only does this make the code inscrutible, but it builds in obsolescence. As new systems come along, practically every other year these days, low-level code becomes out of date and must be manually patched or converted at enormous expense.

сколько лет прошло с 1994 года, когда книжка вышла — а в С++ ничего не меняется.

Хейтеры повылезали. Вроде не весна ещё.

И это прекрасно.

Что же прекрасного в классе std::string, который почти ни на что не годен?

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

Даже в рамках C++ можно было узаконить 4-байтовость wchar_t и объявить std::string устаревшей.

Расскажите, плиз, как вы будете это делать, скажем, в Java.

В Java по крайней мере поведение более приемлемо: дальше полетит исключение из деструктора (то бишь finally блока), а более раннее исчезнет. Что тоже плохо, но лучше, чем запрещать исключения в finally в принципе и стопать приложение, если это таки случилось. А правильно просто сделать единый класс исключений, от которого наследовать все остальные и держать в нём список всех вылетевших при раскрутке стека исключений. Вот и всё.