Смотрю неплохой ЯП сделали.
Практичный?
Приятно удивил иммутабельностью "вглубь" как в Ди.
Вообщем, такой функциональный без ВМ и ГЦ.
Еще приятно что обязательны скобы на всех выражениях.
П,С, вопрос мучает уже несколько дней.
В лиспах нет нужды сравнивать nil с сылкой и это естественным кажется сейчас
(if nil 0 1)
не понятно почему стали
сравнивать так if(x == null)
Органичения парсеров/компиляторов или еще чего-то?
Правильно говорят, раст вырос. вышел в народ.
Смущает только кривая и названия библиотек : тибериус, токио.
еще интнересно, в тибериусе например, тисипи отдельно от собственно эскюэля.
В чем прикол непонятно.
Интересно, а можно ли на нем си-либу статическую скомпилить.
А то я в шоке, ngate client от крипто про. а они известные сишники.
так вот подключения хранятся в реестре. и рядом с конэкшинами параметр сайз!!!, патаму шта наверно си не знает размера массивов?
Здравствуйте, varenikAA, Вы писали:
AA>Смотрю неплохой ЯП сделали.
Согласен! "Осталось покрасить и выбросить!" (ц)
AA>не понятно почему стали сравнивать так if(x == null)
Возможно, для более точного выражения мыслей. if (bzbz) — вот что это? класс и сравнение на null? А если срефакторят код и в будущем это будет string? У стринга есть null, "" и "что-то значимое". Что брать — null или ""? И то ли задумывал автор?
Здравствуйте, varenikAA, Вы писали:
AA>Смотрю неплохой ЯП сделали. AA>Практичный?
Практичный, интересный, потенциально полезный. Если не знаешь C++ — стоит смотреть. Если знаешь C++ Если уровень знания C++ достаточен для коммерческого применения — не стоит смотреть.
Здравствуйте, varenikAA, Вы писали:
AA>В лиспах нет нужды сравнивать nil с сылкой и это естественным кажется сейчас AA>(if nil 0 1) AA>не понятно почему стали AA>сравнивать так if(x == null)
Очеидным образом потому, что лиспе свой синтаксис, а в других языках — свой.
object y;
var x = GetValue( y = GetOtherValue(), out var z );
if( null ){
// а что null-то?
}
TB> Переписать ллвм на раст? Делать вообще нехрен?
Это тест на практичность. Был бы язык практичным — переписать было бы практично.
А если переписывать сложно, долго, неудобно, никому не нужно, то язык непрактичный.
Здравствуйте, kaa.python, Вы писали:
KP>Практичный, интересный, потенциально полезный. Если не знаешь C++ — стоит смотреть. Если знаешь C++ — не стоит смотреть.
Здравствуйте, kaa.python, Вы писали:
KP>Практичный, интересный, потенциально полезный. Если не знаешь C++ — стоит смотреть. Если знаешь C++ — не стоит смотреть.
Так как C++ даже Страуструп (сам в каком-то интервью признавался) и Александреску (убежал на D) до конца не знают, то ответ очевидный смотреть стоит
Здравствуйте, Эйнсток Файр, Вы писали:
TB>> Переписать ллвм на раст? Делать вообще нехрен?
ЭФ>Это тест на практичность. Был бы язык практичным — переписать было бы практично. ЭФ>А если переписывать сложно, долго, неудобно, никому не нужно, то язык непрактичный.
Ты объём кодобазы видел? Или потроллить пришёл? Давай ещё всё мировое ПО перепишем на Раст, потому что некий онаним из интернетика решил, что это должно доказать практичность.
AA>Практичный?
За весь 2020-й писал на расте "для продакшена" только пару месяцев, и честное слово, исключительно из-за денег
Моё мнение:
1) Пока нормальных исключений не завезут — к индустриальной разработке не годен. Сейчас исключений как-бы нет, но они немножко есть на донышке. В плане надёжности получилось худшее из двух миров, кмк.
2) Когда показывают примеры как в rust'е всё круто — это обычно код который на любом языке очень просто пишется и ошибок там не сделаешь. Но вот когда дело доходит до кода который на любом языке сложный — раст вместо того чтобы помогать начинает мне мешать. Нужно продумать логику до мелочей, но вместо этого держишь в голове как что передано, и отвлекаешься на то чтобы ублажить компилятор выписывая закорючки и AsRef<>, AsMut<>, Cell<> ...
3) Когда пишу на расте очень часто появляется ощущение, словно программируешь на ассемблере, мартышкин труд. Например: если уж создатели компилятора решили что в языке нет исключений, зачем заставлять меня писать у каждой функции Result<i32, Error>? Дайте написать просто i32, и пусть компилятор его завернёт в result. И такого дохрена.
4) До сих пор самый быстрый путь отладки мелких ошибок у меня был — запустить всю прогу/проблемный тест, под отладичком, вызвать ошибку, отладчик сам брякается там где ошибка случилась, и можно не отходя от кассы починить. В IntelliJ Rust у меня так не вышло. И судя по SO и GitHub'у Rust не только у меня.
5) Если смотреть глазами ПМ-а — то я вообще не вижу ниши для rust. Язык требует нормальный такой скилл. Человек с таким скилом будет жрать бабки в три горла. Садить такого писать код, где логики с треть кода в строчке будет не моей логики а на радость компилятору? Как-то невыгодно.
Как наверное можно почувствовать, раст мне не особо зашёл даже для пет-проектов.
Здравствуйте, FR, Вы писали:
FR>Так как C++ даже Страуструп (сам в каком-то интервью признавался) и Александреску (убежал на D) до конца не знают, то ответ очевидный смотреть стоит
Здравствуйте, hi_octane, Вы писали:
RW>>А если сомневаешься? _>Хаскель!
Вот кстатит да, для себя (да и потенциально продать навык) это куда разумнее учить, особенно если C++ уже знаешь на достаточном уровне для коммерческой разработки.
Здравствуйте, hi_octane, Вы писали:
_>1) Пока нормальных исключений не завезут — к индустриальной разработке не годен. Сейчас исключений как-бы нет, но они немножко есть на донышке. В плане надёжности получилось худшее из двух миров, кмк.
По остальному в целом согласен, но тут-то что не так?
Здравствуйте, hi_octane, Вы писали:
_>1) Пока нормальных исключений не завезут — к индустриальной разработке не годен. Сейчас исключений как-бы нет, но они немножко есть на донышке. В плане надёжности получилось худшее из двух миров, кмк.
а можно немного больше аргументации? Мне наоборот кажется, что от исключений надо уходить. Сейчас часто фикшу код, который или слишком много исключений бросает (их не обрабатывают), либо слишком мало (где-то выше по стеку словили и умолчали ошибку).
