Аннотация:
Краткое описание ключевых возможностей нового языка программирования Rust. Основной акцент делается на особенностях Rust, которых не хватает многим системным и сетевым разработчикам в других языках программирования.
Здравствуйте, alex_public, Вы писали:
_>Сама статья интересная и к ней в общем то претензий нет. Но хотелось бы (просто здесь или в рамках продолжения статьи) прояснения одного вопроса. Если некоторые преимущества Rust'a по отношению скажем к C++ можно здесь увидеть, то вот при сравнение его с D получается картинка скорее наоборот...
D намертво прикручен к тупому консервативному garbage collector'у. И в нём нет ничего нового для многопоточной работы. У Rust инновации в обоих областях:
1) Вполне реально можно обходиться без GC для достаточно сложных программ.
2) Отсутствие разделяемой памяти и семантика работы с заимстованными указателями — уникальна среди языков, которые хотят стать mainstream'ом.
3) D уж слишком заинжинерен и непонятно куда идёт.
Здравствуйте, alex_public, Вы писали:
_>Сама статья интересная и к ней в общем то претензий нет. Но хотелось бы (просто здесь или в рамках продолжения статьи) прояснения одного вопроса. Если некоторые преимущества Rust'a по отношению скажем к C++ можно здесь увидеть, то вот при сравнение его с D получается картинка скорее наоборот...
Единственное "наоборот" со стороны D — это наличие бОльшего количества библиотек чем имеется в Rust на данный момент, но это вполне ожидаемо. При этом, в D нет ни проверки валидносит указателей на этапе компиляции, ни разделение памяти на шаренную и локальную. Собственно говоря, я вообще не вижу ни одной причины почему программист может выбрать D вместо C++, не говоря уже о сравнении с Rust Дабы не описывать почему не D, вот тут почитай, очень верно все написано.
Здравствуйте, Cyberax, Вы писали:
C>Прикручен. Для точного GC нужны stackmap'ы и механизмы быстрой остановки потоков. Ничего этого нет.
Их нет в текущей версии компиляторов, но есть ли принципиальная проблема в том, чтобы добавить? Т.е. это проблема текущей реализации или самого языка? Когда Rainer'у Schuetze недоставало какой-то информации о типах для реализации более точного GC в D, он просто добавил недостающее в компилятор, на языке это не отразилось.
Если я правильно понял, то вот тут нeбольшая опечатка:
Для этого, как и для схемы «один-читатель-один-писатель», необходимо создать серверный (2) и клиентский (3) потоки и запустить серверную задачу (3). Логика серверной задачи предельно проста: считать (5)
Здравствуйте, DarkEld3r, Вы писали:
DE>И ещё один момент интересен: DE>
DE>#[auto_encode] // (1)
DE>#[auto_decode] // (2)
DE>Неужели необходимость обьявлять только сериализуемые или десериализуемые структуры часто возникает?
Я вообще не понимаю, зачем нужен отдельно серриализатор и отдельно десерриализатор. Насколько я помню, по началу и то и то объявлялось разом, потом разнесли зачем-то.
Сама статья интересная и к ней в общем то претензий нет. Но хотелось бы (просто здесь или в рамках продолжения статьи) прояснения одного вопроса. Если некоторые преимущества Rust'a по отношению скажем к C++ можно здесь увидеть, то вот при сравнение его с D получается картинка скорее наоборот... Т.е. пока, если говорить исключительно о технической стороне, то совсем непонятно, с чего программист может выбрать Rust, а не D в качестве замены C++. Вот не технический аргумент я вижу: поддержка языка одной из мегакорпораций обещает ему потенциально более светлое будущее. А технических что-то не видно...
Здравствуйте, Cyberax, Вы писали:
C>D намертво прикручен к тупому консервативному garbage collector'у.
Не совсем. Например, в VisualD используется другой GC, существенно менее консервативный.
Плюс, вот такая штука зреет: http://erdani.com/d/phobos-prerelease/std_allocator.html
C> И в нём нет ничего нового для многопоточной работы. C>2) Отсутствие разделяемой памяти и семантика работы с заимстованными указателями — уникальна среди языков, которые хотят стать mainstream'ом.
+файберы
Плюс система типов таки дает определенную изоляцию потоков: все глобальные переменные по-умолчанию thread-local, а посылать в сообщениях между потоками можно либо immutable либо explicitly shared. К сожалению, с т.з. GC куча у потоков общая, тут в Rust намного лучше сделано.
Здравствуйте, Cyberax, Вы писали:
C>D намертво прикручен к тупому консервативному garbage collector'у.
Вообще то надо понимать место GC в D... К примеру у меня бывает что код вообще его ни разу не использует. Причём не благодаря каким-то хитрым извращениям, а просто привычная (из C++) работа в основном со стековыми переменными...
C>И в нём нет ничего нового для многопоточной работы.
Ха, как раз в смысле многопоточности в D ситуация побогаче. В нём есть как полноценная архитектура акторов (и кстати похоже поудобнее чем в Rust'e, т.к. там реализовано некое подобие сопоставления с образцом из Эрланга), так и ещё несколько более классических моделей параллелизма.
C>У Rust инновации в обоих областях: C>1) Вполне реально можно обходиться без GC для достаточно сложных программ.
Как и в D. ) Собственно в D можно писать на 3-мя разными стилями (и спокойно смешивать их). Можно извращаться с голыми указателями в стиле C. Можно работать в рамках RAII (и соответственно упор на метафору объект-значение) как в C++. А можно работать через GC (и соответственно использовать метафору объект-ссылка), как в Java.
C>2) Отсутствие разделяемой памяти и семантика работы с заимстованными указателями — уникальна среди языков, которые хотят стать mainstream'ом.
Да есть это всё в D. )))
C>3) D уж слишком заинжинерен и непонятно куда идёт.
Не очень понятны претензии. Единственно что у D пока нет поддержки ни одной из мегакорпорации. Это да, существенный недостаток. Хотя там какие-то намёки на Facebook были в последнее время, но я бы предпочёл кого-то посерьёзнее, а не этот мыльный пузырь. )))
Здравствуйте, kaa.python, Вы писали:
KP>Собственно говоря, я вообще не вижу ни одной причины почему программист может выбрать D вместо C++, не говоря уже о сравнении с Rust
Нет, вообще то сравнение у нас как раз D с Rust, а C++ стоит в сторонке как бы, т.к. он и так текущий лидер, которого пытаются заменить данные новички.
Ну и сразу небольшое отступление: я с Rust'ом практически не знаком, максимум знаю в рамках этой статьи и ещё подобных же кратких обзоров. Так что буду высказываться именно в рамках эти знаний — если окажется что какие-то функции есть в языке, а просто не попали в обзоры, то поправляйте меня естественно.
Так вот, смотря на все эти обзоры Rust'a я совсем не вижу метапрограммирования. Т.е. даже хотя бы такого как в C++ (в D оно ещё намного сильнее чем в плюсах). А это очень существенная часть языка, причём отлично сочетающаяся и нужная как раз в системных языках, т.к. она позволяет вносить в язык очень высокий абстракции при этом не добавляя ни капли оверхеда в рантайм. Возможно эту тему (а так же вопросы гибкости языка, такие как переопределение операторов, макросы и т.п.) просто не затрагивали в обзорах. Но если этого действительно нет в языке, то тогда Rust может претендовать максимум на замену C, но никак не на замену C++...
KP>Дабы не описывать почему не D, вот тут почитай, очень верно все написано.
Да, довольно справедливое описание расклада сил C++ vs D. Фокус в том, что если мы напишем аналогичный текст про C++ vs Rust, то получим буквально тоже самое, только в ещё большей степени (т.к. язык ещё более молодой и неустановившийся).
_>Нет, вообще то сравнение у нас как раз D с Rust, а C++ стоит в сторонке как бы, т.к. он и так текущий лидер, которого пытаются заменить данные новички.
Еще раз. Главных фич в Rust которых нет и не может быть в D и C++ на релиз 0.8 две. Причем эти фичи настолько прекрасны, что за их наличие системный разработчик, например я, многое языку простит:
1. Проверка валидносит указателей на момент компиляции.
2. Модель памяти великолепно подходящая для многопоточных приложений.
Ну а мелкие радости типа метапрограммирования, конечно есть, просто они много где есть для того, что бы на них внимание заострять.
Здравствуйте, kaa.python, Вы писали:
Интересная статья. Спасибо.
Набудущее: KP>1. Проверка валидносит указателей на момент компиляции.
Хотелось бы больше узнать об этом.
А так-же о поддержке WinAPI, и сторонних библиотек.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Интересная статья. Спасибо.
Рад что понравилась, очень старался
KP>>1. Проверка валидносит указателей на момент компиляции. CAB>Хотелось бы больше узнать об этом.
Об этом немного есть в статье, просто размазанно по тексту. Информацию на английском можно прочитать тут.
CAB>А так-же о поддержке WinAPI, и сторонних библиотек.
О какой конкретно поддержке идет речь? В составе стандартной библиотки есть различные IO функции, ну и любая функция из WinAPI может быть экспортирована через FFI и использована.
Здравствуйте, alex_public, Вы писали:
_>Да, довольно справедливое описание расклада сил C++ vs D. Фокус в том, что если мы напишем аналогичный текст про C++ vs Rust, то получим буквально тоже самое, только в ещё большей степени (т.к. язык ещё более молодой и неустановившийся).
Не получим, т.к. один язык фактически который никак не закопают, а второй даже до версии 1.0 не дошел
KP>>>1. Проверка валидносит указателей на момент компиляции. CAB>>Хотелось бы больше узнать об этом. KP>Об этом немного есть в статье, просто размазанно по тексту. Информацию на английском можно прочитать тут.
Компилтайм валидация указателей — интересная проблема, некогда и я пытался её решить , ИМХО стоит написать об этом отдельную главу.
CAB>>А так-же о поддержке WinAPI, и сторонних библиотек. KP>О какой конкретно поддержке идет речь? В составе стандартной библиотки есть различные IO функции, ну и любая функция из WinAPI может быть экспортирована через FFI и использована.
О том есть ли готовые бинденги и если нету как их можно сделать. Вообще я бы хотел тутореал "для самых маленьких" с примерами и картинками. Начиная у установки и настройки среды, далее где-то в средине "...а вот так мы можем показать MessageBox...", и где-то под конец "...ну а вод таким, хитрым способом мы можем распараллелить обработку оконных сообщений...".
PS: Это моё ИМХО: "что бы я хотел узнать" из будущих твоих статей, если таковые будут.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, kaa.python, Вы писали:
KP>1. Проверка валидносит указателей на момент компиляции.
Про это в статье практически ничего не увидел.
KP>2. Модель памяти великолепно подходящая для многопоточных приложений.
Про саму модель памяти в статье очень подробно написано, но вот преимущества по сравнению с другими системами не особо видны.
KP>Ну а мелкие радости типа метапрограммирования, конечно есть, просто они много где есть для того, что бы на них внимание заострять.
Не так уж и много где среди основных языков, а тем более системных.
Здравствуйте, kaa.python, Вы писали:
KP>Не получим, т.к. один язык фактически который никак не закопают, а второй даже до версии 1.0 не дошел
Никак не закопают? ) Как раз в указанной статье был хороший тезис, что C++11 нанёс приличный урон по D своим появлением. На мой взгляд этот же самый факт касается и Rust'a... )
Ну и D в последнее время достаточно стабильный стал, особенно после окончания разборок между стандартными библиотеками. )))
Здравствуйте, alex_public, Вы писали:
_>Фокус в том, что если мы напишем аналогичный текст про C++ vs Rust, то получим буквально тоже самое, только в ещё большей степени (т.к. язык ещё более молодой и неустановившийся).
Всё-таки нет. Автор ведь упирает на то, что "время упущено" — то есть потенциал был, но им своевременно не воспользовались.
А раст появился позже и (ещё) не успел ничего упустить. (:
Впрочем, именно этот аргумент мне кажется так себе.
Здравствуйте, DarkEld3r, Вы писали:
DE>Всё-таки нет. Автор ведь упирает на то, что "время упущено" — то есть потенциал был, но им своевременно не воспользовались. DE>А раст появился позже и (ещё) не успел ничего упустить. (:
Там в основном речь шла о появление C++11... А этот факт точно так же влияет на Rust, как и на D. Причём C++ только пошёл сейчас в активное развитие (даже MS сейчас вернулась к активной разработке его, вместо впаривания всем .net'a), так что дальше будет только хуже. Т.е. я как бы даже согласен с аргументами той статьи, но они создают одинаковое печальное состояние и для D и для Rust. Конечно оба последних языка (если конечно в Rust'е действительно есть метапрограммирование) лучше чем C++, но уже не настолько как было в сравнение с C++03. И подобный переход для очень многих уже не стоит потери кучи плюшек C++, происходящих из супер развитой инфраструктуры языка.
Здравствуйте, alex_public, Вы писали:
KP>>2. Модель памяти великолепно подходящая для многопоточных приложений. _>Про саму модель памяти в статье очень подробно написано, но вот преимущества по сравнению с другими системами не особо видны.
ПРедполагается, что програмисты, особенно системные, привыкли думать самостоятельно
KP>>Ну а мелкие радости типа метапрограммирования, конечно есть, просто они много где есть для того, что бы на них внимание заострять. _>Не так уж и много где среди основных языков, а тем более системных.
Здравствуйте, 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'ы и механизмы быстрой остановки потоков. Ничего этого нет.
Здравствуйте, 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
Здравствуйте, D. Mon, Вы писали:
C>>Это очень просто делается — достаточно рядом с объектом держать ссылку на его pointers bitmap. DM>Неа, не все так просто. Подумай о массивах структур и их слайсах, например. Layout объектов и структур он не стал менять.
Если у структур с указателями есть ссылка на их тип (можно в виде vtbl), то не проблема.
C>>За время развития D уже даже и C++ успел разогнаться до того, что Cairo в стандарт хотят включить. DM>Когда над языком полтора человека работают, ничего удивительного. Посмотрел бы я, как ты со своим языком будешь С++ обгонять по росту.
Так в том и вопрос — почему за 15 лет всего два человека язык используют? Это уже явный признак фэйла.
Здравствуйте, Cyberax, Вы писали:
C>>>Это очень просто делается — достаточно рядом с объектом держать ссылку на его pointers bitmap. DM>>Неа, не все так просто. Подумай о массивах структур и их слайсах, например. Layout объектов и структур он не стал менять. C>Если у структур с указателями есть ссылка на их тип (можно в виде vtbl), то не проблема.
Фишка как раз в том, что такой ссылки там нет, структуры там бинарно совместимы с Си. Иначе это действительно просто было бы.
Здравствуйте, D. Mon, Вы писали:
DM>>>Неа, не все так просто. Подумай о массивах структур и их слайсах, например. Layout объектов и структур он не стал менять. C>>Если у структур с указателями есть ссылка на их тип (можно в виде vtbl), то не проблема. DM>Фишка как раз в том, что такой ссылки там нет, структуры там бинарно совместимы с Си. Иначе это действительно просто было бы.
Тогда нужен тип у массива или какие-то другие дополнительные runtime-метки.
Здравствуйте, Cyberax, Вы писали:
DM>>Фишка как раз в том, что такой ссылки там нет, структуры там бинарно совместимы с Си. Иначе это действительно просто было бы. C>Тогда нужен тип у массива или какие-то другие дополнительные runtime-метки.
Ага, а теперь передадим один из элементов массива структур по ссылке куда-нибудь. Передавать еще ссылку на массив? Менять всю кодогенерацию вызовов и передавать с указателями ссылку на тип? В общем, не настолько там все тривиально, как кажется.
Дабы не описывать почему не D, вот тут почитай, очень верно все написано.
Ждёмс, статью и видео.
Вот от языка версии 1.+, а уж тем более 2.+ хоть какой-то стабильности ожидать хотелось бы, но не моглось бы. Честно говоря, я когда-то большие надежды на D возлагал, но т.к. всегда работаю в больших компаних, такой нестабильности, какой отличается D никак позволить нельзя. Остается надеется на Rust 
