Разница значительна.

Нет проекции человеческих качеств на неодушевленные предметы.

И да, тянки любят плохих мальчиков.

Нет проекции человеческих качеств на неодушевленные предметы.

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

тянки любят плохих мальчиков.

Школьник на самом деле школьница? Это многое объяснило бы.

А подробнее?

Да всё просто: если я в своём модуле неаккуратно использую unsafe, то выстрелить оно может где угодно. То есть, ошибка не выйдет за пределы модуля, если у модуля действительно безопасный интерфейс, но язык этого доказать не может.

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

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

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

А, так речь об unsafe... тогда это очевидно.

А, так речь об unsafe... тогда это очевидно.

А о чём ещё речь может быть? О логических ошибках? В их отношении ведь раст не делает ничего нового.

Ну так-то фиг знает, кто это.

У тянок нет совести и чувства справедливости, совсем.

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

А о чём ещё речь может быть?

О safe Rust, естественно. В котором ошибка не может «портить жизнь случайно выбранному нормально работающему модулю». И очевидно же, что unsafe Rust в этом плане качественно не лучше Си.

Паскакали почто забыл?

А разве они что-то гарантируют в этом плане?

О safe Rust, естественно. В котором ошибка не может «портить жизнь случайно выбранному нормально работающему модулю».

Ну ок, может я неправильно понял идею.

И чё?

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

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

И какой вывод ты из этого делаешь? Ну там «попытки сделать безопасный язык бесполезны», или «только Swift рулит», или еще какой-то?

Ну, например, есть в Rust такая техника (или предложение о такой технике), как выделение памяти через указание индекса в векторе. Это, ИМХО, сводит к нулю всю memory safety.

И какой вывод ты из этого делаешь? Ну там «попытки сделать безопасный язык бесполезны», или «только Swift рулит», или еще какой-то?

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

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

Почему не должны? Memory safety - единственная проблема, путь решения которой более-менее ясен.

это должно быть частным случаем.

Какой случай является общим?

кошеrнейший WinJS

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

А оно будет.

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

У колобка были проффессиональные фейлы?

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

он не утверждал, что хруст - беспомощное говно

Я, конечно, глубоко не вникал в контекст того разговора, но щщитаю, что слова «беспомощное говно, требующее современной замены» скорее можно отнести к недостатку фич языка, чем к своим фейлам на нём. Ты же не будешь спорить, что Си несколько проигрывает в плане выразительности тому же Расту, да и практически любому современному языку?

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

А как же Seamonkey?

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

Почему не должны?

Потому-что конкретно эта задача уже давно решена. Есть еще задача сделать «безопасный системный язык», но во-первых это отдельная задача, во-вторых малоперспективная из-за того, что заменить С в популярных ОС не представляется возможным, а новые хипстерские проекты попадут в статистическую погрешность. В-третьих Rust больше похож на маргинальный прикладной язык, у которого заменили GC на неудобную работу с памятью, чем на простой системный язык без GC. В идеале надо было взять С и просто улучшить работу с памятью (сделать С with classes with memory safety).

Какой случай является общим?

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

Почему не должны? Memory safety - единственная проблема, путь решения которой более-менее ясен.

Если это путь принятый в Rust - то он далеко не самый удобный. Мне больше нравится ARC из Swift ;)

пока впечатления как от исследований по термояду - оно по-своему мило, и даже кто-то что-то делает (причём уже не первое десятилетие), но как-то я не уверен, что доживу :)

Похоже, ты дальше от этого всего, чем даже я. Потому что я вижу и интерес, и реализации - Atom/Electron, Steam Client, https://trac.webkit.org/wiki/Applications using WebKit

Кстати, вопросы об использовании Servo в качестве GUI для Rust-программ периодически всплывают в reddit. «Пути меняются, Стилгар» (ц)

550

Если это путь принятый в Rust - то он далеко не самый удобный. Мне больше нравится ARC из Swift ;)

Когда-то в Rust тоже было удобно, см. ~T.

Но потом парни подумали и сделали как надо Box<T>, Rc<T>, Arc<T>.

Но! Вы говорите о разном! Ты про Arc, а тебе про безопасность работы с памятью.

Кстати, вопросы об использовании Servo в качестве GUI для Rust-программ периодически всплывают в reddit.

Использование JS вместо Rust для Rust-программ - действительно разумное решение.

Когда-то в Rust тоже было удобно, см. ~T.

Ну вот, я ж говорю - Rust это маргинальный язык, откуда выкинули GC.

Но! Вы говорите о разном! Ты про Arc, а тебе про безопасность работы с памятью.

ARC - это разновидность безопасной работы с памятью.

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

Почему не должны?

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

Не надо доколебываться до слов.

но во-первых это отдельная задача,

Это отдельная нерешенная задача.

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

Увидим.

это должно быть частным случаем.

Какой случай является общим?

Нет такого, очевидно.

«Должно быть частным случаем, но общего случая нет». Ну окей.

Мне больше нравится ARC из Swift ;)

Использование JS вместо Rust для Rust-программ - действительно разумное решение.

Это важные детали твоего анамнеза.

Когда-то в Rust тоже было удобно, см. @T.

/fixed

ARC - это разновидность безопасной работы с памятью.

Это RAII, а не разновидность безопасной работы с памятью.

Не надо доколебываться до слов.

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

Это отдельная нерешенная задача.

Т.е. ты хочешь сделать системный язык без «unsafe»? Удачи.

«Должно быть частным случаем, но общего случая нет». Ну окей.

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

Это важные детали твоего анамнеза.

Тебе пообщаться не с кем?

Т.е. ты хочешь сделать системный язык без «unsafe»?

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

Тебе пообщаться не с кем?

Просто я иногда переоцениваю людей, как в случае с тобой.

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

Тогда почему ты считаешь эту задачу нерешенной?

Просто я иногда переоцениваю людей, как в случае с тобой.

Взаимно, только у меня это заняло гораздо меньше времени.

Это RAII, а не разновидность безопасной работы с памятью.

ARC - это управление конкретно памятью, конкретным способом. RAII это более общее понятие.

Да всё просто: если я в своём модуле неаккуратно использую unsafe, то выстрелить оно может где угодно.

Как я себе вижу процесс разработки на RUST больших проектов: пару разработчиков которые могут генерировать стабильный код пишут базовые модули требующие «unsafe» - пупбличный интерфейс модулей полностью безопасен. Основная же масса девелоперов пишут модуля без использования «unsafe» и без доступа к внутренним структуром потенциально опасных частей.

ARC - это управление конкретно памятью, конкретным способом. RAII это более общее понятие.

Arc не управляет памятью, а владеет ресурсом, память - это ресурс.

Карл, управление != владение != работа с памятью.

Ownership
References and Borrowing
Lifetimes
Mutability
Static Mutability

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

А они и не упираются. Раст продолжает развиваться, даже после выхода стабильной версии. Вот, к примеру, RFC о введении в язык зачатков зависимых типов: https://github.com/rust-lang/rfcs/pull/1657. Хотя сейчас это больше о параметризации над `[T, N]`, но предусмотрена возможность расширения до чего-то больше.

В идеале надо было взять С и просто улучшить работу с памятью (сделать С with classes with memory safety).

Таким был cyclone. Но подражать C — плохая идея, по современным меркам так проектировать языки нельзя.

Arc не управляет памятью, а владеет ресурсом, память - это ресурс.
Карл, управление != владение != работа с памятью.

А ты не брат tailgunner'a?

https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_...

Swift uses Automatic Reference Counting (ARC) to track and manage your app’s memory 

ARC используется для управления памятью - официально. Так что не надо заниматься словоблудием.

ARC используется для управления памятью - официально. Так что не надо заниматься словоблудием.

Не уходи от темы.

Ты про Arc, а тебе про безопасность работы с памятью.

Не видал никаких аотов и пиков, где они есть?

У меня на телефоне, например. Мидлет при установке компилируется в бинарник и потом так исполняется. В ведроид с китката тоже завезли, ART кличут.

А картинки у меня тормозят

Ясно, сидят с кофеварки и плачутся. Не плачь, деточка, для кофеварок w3m, dillo и netsurf никто не отбирает.

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

А забавно будет, если они всякие ворстпрактисы и допотопные неиспользуемые в реальной разработке методы жабоскрипта умышленно реализовывать не станут. Ты with (map) { ... }, а двиг такой хоп: Unexpected token with. Или alert кидаешь, а window.alert-то undefined.

Не уходи от темы.
Ты про Arc, а тебе про безопасность работы с памятью.

Не я стал уходить от нее. ARC - это автоматическое управление памятью, которое не идеально, но при этом свободно от типичных ошибок при ручном управлении - висячих ссылок, double free, обращение к неинициализированной памяти и пр.

Ёпта, открываешь пкгбилд, качаешь сырцы по ссылке и собираешь, выдумал дистропроблемы на пустом месте, блин.

Чтоб ты рисовать в браузере мог, например.

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

Не я стал уходить от нее. ARC - это автоматическое управление памятью...

Это автоматическое управление ресурсом, точнее владеющий контейнер!

Люди говорят про работу с памятью в Rust (Ownership, References and Borrowing, Lifetimes, Mutability), а ты про RAII (Resource Acquisition Is Initialization).

Да, память — ресурс. Но управление != работа с памятью.

Когда же до тебя дойдёт!?

висячих ссылок

struct Foo {}

fn main() {
    let value = Foo {};
    let ptr = &value;
    
    drop(value);
    
    println!("{:p}", ptr);
}

error: cannot move out of `value` because it is borrowed
 --> a.rs:7:10
  |>
5 |>     let ptr = &value;
  |>                ----- borrow of `value` occurs here
6 |>
7 |>     drop(value);
  |>          ^^^^^ move out of `value` occurs here

double free

struct Foo {}

fn main() {
    let value = Foo {};
    drop(value);
    drop(value);
}

error: use of moved value: `value`
 --> a.rs:6:10
  |>
5 |>     drop(value);
  |>          ----- value moved here
6 |>     drop(value);
  |>          ^^^^^ value used here after move

обращение к неинициализированной памяти

fn main() {
    let value: i32;
    println!("{}", value);
}

error: use of possibly uninitialized variable: `value`
 --> a.rs:3:20
  |>
3 |>     println!("{}", value);
  |>                    ^^^^^ use of possibly uninitialized `value`

И прочее...

А как же Seamonkey?

а что с ним ? как то не слежу, пользую firefox, для почты есть gnus/alpine.

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

В идеале надо было взять С и просто улучшить работу с памятью

Убрать указатели ? :) Воткнуть GC ? :)

Если это путь принятый в Rust - то он далеко не самый удобный. Мне больше нравится ARC из Swift ;)

Это очень плохой путь. Вообще, решение проблемы управления памятью через GC или подсчёт ссылок - это не решение проблемы, это простое заметание мусора под ковёр. Типа да, память не освободится, когда хоть кто-то на неё ссылается и, следовательно, не упадёт, не получится, что та же память выделена под что-то другое и это что-то другое будет прочитано или перезаписано не тем, кому надо. Но бардак от этого никуда не денется. Более того, так как уже заплатили тормозами GC/ARC за право не париться вопросами памяти, на этот вопрос забивают и в результате начинается форменная порнография. Вот, скажем, есть у меня итератор или срез из способного расти массива (vector, arraylist), что будет если я попытаюсь прочитать из него? А чёрт его знает, может оригинальный массив уже реаллоцировался, так что могу упасть по эксепшену, могу читать из массива уже неактуальные данные, возможно сам факт, что я сохранил этот срез в то время как код, который мне его отдал, рассчитывал, что я посмотрю что надо и выброшу привёл к тому, что я держу сейчас буфер на пару сотен мегабайт. И так с любыми данными, если отдаёшь кому-то указатель на своё состояние, сиди и беспокойся, чтоб он его не правил, иначе безопасность в заднице. Хочешь по-человечески? Ну тогда создавай иммутабельную обёртку и заставляй работать через неё. Но опять же, что если получатель сохранит эту иммутабельную обёртку, рассчитывая на то, что раз она иммутабельная, то и не изменится, а ты в это время поменяешь своё состояние? Следовательно, отдавать нужно глубокую копию, а чтоб получатель не думал, что может что-то поменять и ты на это отреагируешь, эта копия должна быть иммутабельная. И в 99% он извлечёт из этой копии полтора байта и выбросит её. Короче, нормально GC и прочие подходы в стиле «любой указатель - владеющий» работают только в чисто функциональных языках, где всё константно и потому не важно, собственная копия у тебя или нет. В императивных всё равно придётся учитывать владение, только в случае GC/ARC правила будут прописываться в документации и держаться на честном слове программиста, с последующими проблемами, когда эти правила поменяются, а код, от них зависящий, не переделан. В rust это исправили, правила владения/заимствования описываются не в документации, а в интерфейсе и компилятор следит за их исполнением.

Это автоматическое управление ресурсом, точнее владеющий контейнер!

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

Люди говорят про работу с памятью в Rust (Ownership, References and Borrowing, Lifetimes, Mutability), а ты про RAII (Resource Acquisition Is Initialization).

Объясни этим «людям», что во-первых они со своим Rust влезли не в тему, если хотели обсудить ARC, а во-вторых что ARC != RAII. В том числе потому, что он не exception-safe.

Когда же до тебя дойдёт!?

Это ты тупишь.

Убрать указатели ? :) Воткнуть GC ? :)

Сделать как в Rust, например, но без изменения синтаксиса и внедрения трейтов и пр.