Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.145.47.253] |
|
Страницы: (16) [1] 2 3 ... 15 16 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Буэнос диас, амигос!
Бимбениву а ла гера санта ... Не буду из себя корчиить большого знатока С++, и, тем не менее - что знаю, то знаю. Сейчас, неспешно смакуя, читаю доку по Rust (книжка второй редакции). Понимаю, я еще далеко на пол-пути от понимания, но прочитанное и осознанное - это нечто! Раст: Поехали ... |
Сообщ.
#2
,
|
|
|
По большому счету у Rust, на мой взгляд, только два недостатка - убогий синтаксис(вкусовщина, но ничего не могу с этим сделать) и незрелость(быстрого взлета, как у Go, не получилось, но надежда еще есть).
Добавлено Цитата JoeUser @ Не задвигает ООП на вершину призеров по проектированию Ну C++ вроде тоже Цитата Хотя парадигмы ООП имеет возможность реализовать в полном объеме В виду отсутствия четкого определения и критериев ООП тут тяжело что-нибудь сказать. Наследование реализации отстутствует, например. Но да, противоречий с SOLID нет. Цитата Не парит мозги с возможными утечками памяти по невнимательности Требую подробностей Цитата Не вводит в обиход умные, хитрые и мудрые указатели А как же Box<T>, Rc<T>, Ref<T>, RefMut<T> и т.п.? Цитата Внесенное в состав языка понятия "типажей" (traits) - гораздо понятнее, значительно понятнее похожей концепции STL из С++ Скорее trait в rust ближе к концептам. STL traits немного о другом. Цитата Встроенные возможности юнит-тестирвания - это прекрасно! Ну на мой взгляд, это не принципиально. Тех же gtest или boost.test в плюсах вполне хватает. В остальном соглашусь |
Сообщ.
#3
,
|
|
|
Цитата D_KEY @ По большому счету у Rust, на мой взгляд, только два недостатка - убогий синтаксис(вкусовщина, но ничего не могу с этим сделать) и незрелость(быстрого взлета, как у Go, не получилось, но надежда еще есть). Синтаксис, мэй би убогий, но - логичный. Пример - определение ссылок на функции. Цитата D_KEY @ Цитата JoeUser @ Не задвигает ООП на вершину призеров по проектированию Ну C++ вроде тоже Oга-ога Цитата D_KEY @ Цитата Хотя парадигмы ООП имеет возможность реализовать в полном объеме В виду отсутствия четкого определения и критериев ООП тут тяжело что-нибудь сказать. Наследование реализации отстутствует, например. Но да, противоречий с SOLID нет. Быть должно! Помню - в плане ООП реализовано все. OpenGL,хелп! Цитата D_KEY @ Цитата Не парит мозги с возможными утечками памяти по невнимательности Требую подробностей Тут сложно объяснить в терминах С++. Если не дословно - компайлер Раст контролит каждую переменную в плане "рождения"-"смерти". А если не понимает - требует явного выставления "времени жизни". Цитата D_KEY @ Цитата Не вводит в обиход умные, хитрые и мудрые указатели А как же Box<T>, Rc<T>, Ref<T>, RefMut<T> и т.п.? Да, похоже я до этого еще де добрался в изучении ... Вычеркиваем! |
Сообщ.
#4
,
|
|
|
Цитата D_KEY @ На самом деле это НЕ недостатки, а вкусовщина. Самый большой недостаток на мой взгляд - избыточная жесткость. Пограммирование на Rust - суть борьба с компилятором. Наверное этот недостаток превращается в преимущество если ты пишешь какие-нибудь критические системы вроде ПО для самолетов. Кроме того у Rust дохлое метапрограммирование и дохлые макросы. По большому счету у Rust, на мой взгляд, только два недостатка - убогий синтаксис(вкусовщина, но ничего не могу с этим сделать) и незрелость(быстрого взлета, как у Go, не получилось, но надежда еще есть). |
Сообщ.
#5
,
|
|
|
Цитата applegame @ На самом деле это НЕ недостатки, а вкусовщина Это не взаимоисключающие вещи Я там в скобочках написал, что восприятие синтаксиса - вкусовщина. Но вот лично для меня это довольно существенное препятствие, поскольку ну не нравится мне писать на rust. Неприятно И судя по инету, я такой не один. Добавлено Цитата applegame @ Самый большой недостаток на мой взгляд - избыточная жесткость. Пограммирование на Rust - суть борьба с компилятором. Наверное этот недостаток превращается в преимущество если ты пишешь какие-нибудь критические системы вроде ПО для самолетов. А мне вот это нравится как раз А твои аргументы похоже на аргументацию против статической(и более менее строгой) типизации |
Сообщ.
#6
,
|
|
|
Цитата D_KEY @ Наследование реализации отстутствует, например. Были RCF-шки, которые вводили делегирование имплементации трейта какому-либо полю структуре. Но я за ними не следил - почему их не запилили (и будут ли запиливать вообще) - не в курсе. Цитата applegame @ Самый большой недостаток на мой взгляд - избыточная жесткость. Пограммирование на Rust - суть борьба с компилятором. А мне наоборот нравится - заставляет сперва продумать архитектуру. Клепать что-либо в нём костылями в стиле С++ говнокодера "а, этот объект и тут ещё нужен. Не беда - как-нибудь передам поинтер на него сюда" выйдет очень неудобно и долго. Цитата applegame @ Кроме того у Rust дохлое метапрограммирование и дохлые макросы. Ну метапрограммирование да, даже до плюсового не дотягивает. А макросы чем не угодили? |
Сообщ.
#7
,
|
|
|
Цитата D_KEY @ А мне вот это нравится как раз Да, в учебниках пишут - на первых порах это вынос мозга. Но потом, когда мышление изменяется, когда появляется привычка - то утверждают, что напряга совсем не чувствуется, а профит от большего контроля очевиден жиесть |
Сообщ.
#8
,
|
|
|
Цитата JoeUser @ Не парит мозги с возможными утечками памяти по невнимательности Ой да ладно. Один только mem::forget, не помеченный unsafe, чего стоит От утечек раст и не должен избавлять - в отличие от всяких use after free они не приводят к небезопасным ситуациям. |
Сообщ.
#9
,
|
|
|
Цитата JoeUser @ умные, хитрые и мудрые указатели Цитата JoeUser @ дочитаю доку - еще отпишусь |
Сообщ.
#10
,
|
|
|
Цитата D_KEY @ Твое право. Некоторые любят пожестче. А мне вот это нравится как раз Цитата D_KEY @ Да, похожи. А твои аргументы похоже на аргументацию против статической(и более менее строгой) типизации Добавлено Цитата OpenGL @ Не знаю, может в каком-то идеальном мире и можно все продумать заранее и это сработает, а в реальном мире действует следствие закона Мерфи: вероятность возникновения необходимого дополнения не вписывающегося в архитектуру ПО, прямо пропорциональна времени потраченному на проектирование этой архитектуры. А мне наоборот нравится - заставляет сперва продумать архитектуру. Клепать что-либо в нём костылями в стиле С++ говнокодера "а, этот объект и тут ещё нужен. Не беда - как-нибудь передам поинтер на него сюда" выйдет очень неудобно и долго. Ну и архитектура, на мой взгляд, это сущность более высокого уровня, на нее не влияют мелочи вроде контроля над временем жизни и прочие отличия Rust от C++. Языки с одного поля ягоды. Добавлено Синтаксис Rust меня особо не пугает, это дело привычки, проверено лично. Завезли в него уже конкурентность и параллелизм на уровне стандартной либы? Ну там всякие файберы/корутины плюс планировщик? |
Сообщ.
#11
,
|
|
|
Цитата applegame @ Ну и архитектура, на мой взгляд, это сущность более высокого уровня, на нее не влияют мелочи вроде контроля над временем жизни и прочие отличия Rust от C++. Языки с одного поля ягоды. Возможно, я не совсем к месту применил слово "архитектура". Допустим, я пишу библиотеку, эта библиотека выдаёт некие ссылки, куда может писать пользователь свои данные, и при этом библиотека устроена таким образом, что пользоваться ей можно только в один поток. Это требование в расте будет отражено в api этой библиотеки и, соответственно, сразу будут исключаться некорректные сценарии её использования, а это в свою очередь принуждает к более внимательному продумыванию того, как именно будет данная библиотека использоваться, и, соответственно, методология ХХивП в случае с растом не очень-то хорошо будет работать. Цитата applegame @ Завезли в него уже конкурентность и параллелизм на уровне стандартной либы? Ну там всякие файберы/корутины плюс планировщик? Нет, есть только сторонние. Но это не проблема совершенно из-за cargo. Добавлено Кстати, во многом из-за того, что привычные способы проектирования на расте плохо работают, на нём до сих пор нет хоть сколько-нибудь юзабельной gui библиотеки |
Сообщ.
#12
,
|
|
|
Цитата OpenGL @ Но это не проблема совершенно из-за cargo. В этом есть определённая проблема: наличие кучи различных способов обеспечить конкурентность и параллелизм, кто во что горазд, приводит к снижению сопровождаемости кода. |
Сообщ.
#13
,
|
|
|
Цитата korvin @ В этом есть определённая проблема: наличие кучи различных способов обеспечить конкурентность и параллелизм, кто во что горазд, приводит к снижению сопровождаемости кода. До прихода C++1x во всю пользовались бустом. Что сподвигло расширить/модернизировать Стандарт. Уверен, что и Раст пойдет по похожему пути. |
Сообщ.
#14
,
|
|
|
Цитата OpenGL @ На самом деле проблема. Сторонние библиотеки, в отличие от стандартной, иногда прекращают развиваться. А это базовые вещи, должны быть из коробки. По моему скромному.Нет, есть только сторонние. Но это не проблема совершенно из-за cargo. Цитата JoeUser @ Буст - это скорее исключение из правил. До прихода C++1x во всю пользовались бустом. Что сподвигло расширить/модернизировать Стандарт. Уверен, что и Раст пойдет по похожему пути. |
Сообщ.
#15
,
|
|
|
Цитата OpenGL @ Были RCF-шки, которые вводили делегирование имплементации трейта какому-либо полю структуре С возможностью переопределить часть методов, я надеюсь? В любом случае, прямо сейчас этого нет. Но я не уверен, что это плохо Я даже когда-то давно создавал холивар на тему Добавлено Цитата applegame @ Цитата D_KEY @ Твое право. Некоторые любят пожестче. А мне вот это нравится как раз На самом деле мне даже мало Больше статического анализа! |