Здравствуйте, kaa.python, Вы писали:
KP>ПРедполагается, что програмисты, особенно системные, привыкли думать самостоятельно
Я лично не увидел для себя каких-то плюсов в этой области по сравнению с C++. Возможно есть преимущество для каких-то совсем неопытных программистов, т.к. система не позволит им совершить полные глупости. А для опытных непонятно что-то... Если они есть, то хотелось бы увидеть конкретные примеры.
KP>С C++ есть, что уже дофига.
Само собой, но речь немного не об этом. Если рассматривать эту статью как просто абстрактный обзор языка, то она мне очень понравилась. Всё понятно и с хорошими примерами. Однако, Rust у нас имеет вполне определённую миссию (точно такую же как и D кстати) — замена C++. Так что на практике максимальный интерес к этому языку должен быть у текущих C++'ов, а написанная для них статья (может быть напишете ещё такую?) должна быть не обзором языка как такового, а иметь совсем другие базовые тезисы:
1. Показать что основные плюшки C++ (полный доступ к системе/железу, быстродействие, метапрограммирование) доступны и в Rust'e.
2. Показать какие преимущества получит программист, перешедший с C++ на Rust.
3. Сравнить эти преимущества с даваемыми другими претендентами на замену C++ (D, ещё кто-то?).
Это конечно была бы совсем другая статья, но как мне кажется именно такая и нужна была бы для популяризации языка.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, kaa.python, Вы писали:
KP>>ПРедполагается, что програмисты, особенно системные, привыкли думать самостоятельно
_>Я лично не увидел для себя каких-то плюсов в этой области по сравнению с C++.
Значит ты слишком мало писал объемных проектов на C++. Ты не думал почему Mozilla вообще взялась за Rust? После того, как проект на C++ перерос определенный размер, его поддержка и развитие становится просто адом.
_> Возможно есть преимущество для каких-то совсем неопытных программистов, т.к. система не позволит им совершить полные глупости. А для опытных непонятно что-то... Если они есть, то хотелось бы увидеть конкретные примеры.
Есть преимущество для опытных. Неопытные везде граблей разложить смогут, в Rust это сделать чуть сложнее чем в C++.
_> Однако, Rust у нас имеет вполне определённую миссию (точно такую же как и D кстати) — замена C++.
Rust не замена C++. Он может его подменить в довольно узкой сфере, не более того.
_> Так что на практике максимальный интерес к этому языку должен быть у текущих C++'ов, а написанная для них статья (может быть напишете ещё такую?) должна быть не обзором языка как такового, а иметь совсем другие базовые тезисы:
Интерес будет не у текущих C++ разработчиков, а у текущих C++ разработчиков решающих очень специфические задачи. Rust – ярковыраженный нишевый язык.
_>1. Показать что основные плюшки C++ (полный доступ к системе/железу, быстродействие, метапрограммирование) доступны и в Rust'e.
Скучно, хотя изначально так и планировал. Может стоит на какой-то конференции об этом рассказать, но никак не статью писать.
_>2. Показать какие преимущества получит программист, перешедший с C++ на Rust.
Пока я бы не советовал переходить на Rust в принципе.
_>3. Сравнить эти преимущества с даваемыми другими претендентами на замену C++ (D, ещё кто-то?).
D не претендент на замену C++, тебе это любой PM или вменяемый архитектор скажет.
_>Это конечно была бы совсем другая статья, но как мне кажется именно такая и нужна была бы для популяризации языка.
В интернете я всегда преследую только одну цель – популяризацию себя любимого. Остальное – детали
Здравствуйте, C.A.B, Вы писали:
KP>>Об этом немного есть в статье, просто размазанно по тексту. Информацию на английском можно прочитать тут. CAB>Компилтайм валидация указателей — интересная проблема, некогда и я пытался её решить , ИМХО стоит написать об этом отдельную главу.
Просто для общей информации. А чем плоха, кроме того что на английском, статья на которую я дал линку? Просто надо понять что же такое писать, чего там нет, т.к. на мой взгляд, в ней все очень хорошо разжевано.
CAB>О том есть ли готовые бинденги и если нету как их можно сделать. Вообще я бы хотел тутореал "для самых маленьких" с примерами и картинками. Начиная у установки и настройки среды, далее где-то в средине "...а вот так мы можем показать MessageBox...", и где-то под конец "...ну а вод таким, хитрым способом мы можем распараллелить обработку оконных сообщений...".
Ууу... это, боюсь, не ко мне, на такое терпения не хватит. Я вот сейчас озаботился вопросом того, как Rust в драйвер вкорячить. Вот об этом статья будет
CAB>PS: Это моё ИМХО: "что бы я хотел узнать" из будущих твоих статей, если таковые будут.
Будут. Еще думаю где бы про Rust вживую в Мск рассказать. Пока только SECR приходит в голову.
Здравствуйте, kaa.python, Вы писали:
KP>Значит ты слишком мало писал объемных проектов на C++. Ты не думал почему Mozilla вообще взялась за Rust? После того, как проект на C++ перерос определенный размер, его поддержка и развитие становится просто адом.
Это всё общие слова — покажи конкретные примеры. У меня пока такое ощущение, что ты говоришь про что-то типа C++98... В современном коде собственно голых указателей вообще не должно быть.
KP>Rust не замена C++. Он может его подменить в довольно узкой сфере, не более того.
И как точно формулируется эта узкая сфера?
KP>Скучно, хотя изначально так и планировал. Может стоит на какой-то конференции об этом рассказать, но никак не статью писать.
Хм, ну а англоязычные материалы такого рода есть? ) Т.е. я имею в виду не полную документацию языка, а некое подробное сравнение с C++.
KP>D не претендент на замену C++, тебе это любой PM или вменяемый архитектор скажет.
Я говорю не про текущую ситуацию, а про предназначение языка. По текущей ситуации и Rust не замена C++ нигде.
Я вот о синтаксису не понял.
Если все новые "переменные" — по умолчанию константы, то есть язык поощряет максимальное использование констант и объявлений новых переменных (а не замен старых), то какого хрена надо писать везде это слово let?
(Для замены существующей мутабельной переменной хай будет chg, чтоб не путаться.)
Пример из статьи, было:
let x = Point {x:1, y:2};
let y = Point {x:2, y:3};
let mut px = &x; // (1)
let py = &y;
px.x = 42; // (2)
px = py; // (3)
Стало:
x = Point {x:1, y:2};
y = Point {x:2, y:3};
mut px = &x; // (1)
py = &y;
chg px.x = 42; // (2)
chg px = py; // (3)
KP>Просто для общей информации. А чем плоха, кроме того что на английском, статья на которую я дал линку? Просто надо понять что же такое писать, чего там нет, т.к. на мой взгляд, в ней все очень хорошо разжевано.
Ни чем не плоха, её бы отжать до размеров главы, и добавить в твою статью, для "полноты картины".
KP>Я вот сейчас озаботился вопросом того, как Rust в драйвер вкорячить. Вот об этом статья будет KP>Еще думаю где бы про Rust вживую в Мск рассказать. Пока только SECR приходит в голову. Ждёмс, статью и видео.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, TarasB, Вы писали:
TB>Если все новые "переменные" — по умолчанию константы, то есть язык поощряет максимальное использование констант и объявлений новых переменных (а не замен старых), то какого хрена надо писать везде это слово let?
Это уже к авторам. Вполне возможно потому, что первая версия Rust была написанна на OCaml, а там как раз используется let %)
Здравствуйте, Cyberax, Вы писали:
C>D намертво прикручен к тупому консервативному garbage collector'у. И в нём нет ничего нового для многопоточной работы. У Rust инновации в обоих областях:
Не прикручен, там принято pin-ить указатели, например.
Здравствуйте, Lazin, Вы писали:
C>>D намертво прикручен к тупому консервативному garbage collector'у. И в нём нет ничего нового для многопоточной работы. У Rust инновации в обоих областях: L>Не прикручен, там принято pin-ить указатели, например.
Прикручен. Для точного GC нужны stackmap'ы и механизмы быстрой остановки потоков. Ничего этого нет.
Здравствуйте, Cyberax, Вы писали:
C>Прикручен. Для точного GC нужны stackmap'ы и механизмы быстрой остановки потоков. Ничего этого нет.
Их нет в текущей версии компиляторов, но есть ли принципиальная проблема в том, чтобы добавить? Т.е. это проблема текущей реализации или самого языка? Когда Rainer'у Schuetze недоставало какой-то информации о типах для реализации более точного GC в D, он просто добавил недостающее в компилятор, на языке это не отразилось.
Здравствуйте, D. Mon, Вы писали:
C>>Прикручен. Для точного GC нужны stackmap'ы и механизмы быстрой остановки потоков. Ничего этого нет. DM>Их нет в текущей версии компиляторов, но есть ли принципиальная проблема в том, чтобы добавить? Т.е. это проблема текущей реализации или самого языка?
Проблема в том, что это сделано не будет никогда.
DM>Когда Rainer'у Schuetze недоставало какой-то информации о типах для реализации более точного GC в D, он просто добавил недостающее в компилятор, на языке это не отразилось.
Это совершенно другой уровень сложности. На порядок. И сразу же посыплются тонны приложений, где указатели не pin'ятся, но "всё работает" из-за того, что стек сканируется консервативно.
У Mono сейчас та же проблема — они уже который год делают точный GC, но консервативный всё ещё работает быстрее. При этом у них примерно в 10 раз больше разработчиков.
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что это сделано не будет никогда.
Возможно, к сожалению. Но это лишь спекуляции.
DM>>Когда Rainer'у Schuetze недоставало какой-то информации о типах для реализации более точного GC в D, он просто добавил недостающее в компилятор, на языке это не отразилось. C>Это совершенно другой уровень сложности. На порядок.
Он добавил карты указателей для кучи, которых раньше не было. Неужто для стека прям на порядок сложнее те же карты сделать?
C> И сразу же посыплются тонны приложений, где указатели не pin'ятся, но "всё работает" из-за того, что стек сканируется консервативно.
А нет никаких тонн приложений. Это самое хорошее тут.
C>У Mono сейчас та же проблема — они уже который год делают точный GC, но консервативный всё ещё работает быстрее.
В D, кстати, аналогично: добавление точности добавляет работы, и поскольку в 64-битном режиме нынешний сборщик работает вполне приемлемо, сильно никто не спешит к точному. Что могло бы дать сильное ускорение, и без чего Dивный GC ужасный тормоз, — это поколения. Но чтобы сделать нормальный GC с поколениями, нужно добавить write barrier везде-везде в коде, а вот это уже действительно проблемная задача и большой источник сопротивления.
Здравствуйте, D. Mon, Вы писали:
C>>Это совершенно другой уровень сложности. На порядок. DM>Он добавил карты указателей для кучи, которых раньше не было.
Это очень просто делается — достаточно рядом с объектом держать ссылку на его pointers bitmap.
DM>Неужто для стека прям на порядок сложнее те же карты сделать?
Да. Особенно для многопоточного GC.
C>> И сразу же посыплются тонны приложений, где указатели не pin'ятся, но "всё работает" из-за того, что стек сканируется консервативно. DM>А нет никаких тонн приложений. Это самое хорошее тут.
Ну вот и получается такой цугундер, который вечно в состоянии "вот буквально в следующем году завоююем мир".
За время развития D уже даже и C++ успел разогнаться до того, что Cairo в стандарт хотят включить.
C>>У Mono сейчас та же проблема — они уже который год делают точный GC, но консервативный всё ещё работает быстрее. DM>В D, кстати, аналогично: добавление точности добавляет работы, и поскольку в 64-битном режиме нынешний сборщик работает вполне приемлемо, сильно никто не спешит к точному. Что могло бы дать сильное ускорение, и без чего Dивный GC ужасный тормоз, — это поколения.
Хорошие барьеры и точный GC как раз имеют очень много пересечений.
Здравствуйте, D. Mon, Вы писали:
DM>Их нет в текущей версии компиляторов, но есть ли принципиальная проблема в том, чтобы добавить?
Принципиальная проблема D только одна – у него "все можно добавить и стабилизировать вот уже завтра", ну или послезавтра, ну или никогда ибо хз когда там Александреску наконец наиграется.
Здравствуйте, kaa.python, Вы писали:
KP>Принципиальная проблема D только одна – у него "все можно добавить и стабилизировать вот уже завтра", ну или послезавтра, ну или никогда ибо хз когда там Александреску наконец наиграется.
Есть такое. С другой стороны, он уже последние пару лет вполне юзабелен и довольно стабилен, а в расте то одно поменяют, то другое сломают.
Здравствуйте, Cyberax, Вы писали:
DM>>Он добавил карты указателей для кучи, которых раньше не было. C>Это очень просто делается — достаточно рядом с объектом держать ссылку на его pointers bitmap.
Неа, не все так просто. Подумай о массивах структур и их слайсах, например. Layout объектов и структур он не стал менять.
C>Ну вот и получается такой цугундер, который вечно в состоянии "вот буквально в следующем году завоююем мир". C>За время развития D уже даже и C++ успел разогнаться до того, что Cairo в стандарт хотят включить.
Когда над языком полтора человека работают, ничего удивительного. Посмотрел бы я, как ты со своим языком будешь С++ обгонять по росту.
Здравствуйте, D. Mon, Вы писали:
DM>Есть такое. С другой стороны, он уже последние пару лет вполне юзабелен и довольно стабилен, а в расте то одно поменяют, то другое сломают.
А ты ожидаешь стабильности от языка версии 0.8? Вот от языка версии 1.+, а уж тем более 2.+ хоть какой-то стабильности ожидать хотелось бы, но не моглось бы. Честно говоря, я когда-то большие надежды на D возлагал, но т.к. всегда работаю в больших компаних, такой нестабильности, какой отличается D никак позволить нельзя. Остается надеется на Rust
, ИМХО стоит написать об этом отдельную главу. 
Ждёмс, статью и видео.
Вот от языка версии 1.+, а уж тем более 2.+ хоть какой-то стабильности ожидать хотелось бы, но не моглось бы. Честно говоря, я когда-то большие надежды на D возлагал, но т.к. всегда работаю в больших компаних, такой нестабильности, какой отличается D никак позволить нельзя. Остается надеется на Rust 
