Здравствуйте, Dair, Вы писали:
D>Ну вот мне привычно было до недавнего времени использовать С++ как язык, общий для бизнес-логики мобильных приложений, а это iOS с Swift и ObjC, куда С++ компилируется нативно, и Андроид с его Джава-машиной и чудовищным (но работающим) JNI.
JNI у вас работает? А как вы deal with exceptions?
Здравствуйте, gyraboo, Вы писали:
G>Елки-палки, да скажите уже однозначно и обоснованно, стоит ли изучать Rust и начинать на нём новые системные проекты, или это очередной пшик, и лучше Лазаря, усиленного ординарной сишкой, пока ничего не придумали? Сколько можно философствовать? Требую истину, в готовом и удобоваримом виде!
Ну, что это не очередной пшик, уже можно точно сказать. Язык вполне себе взлетел (хоть и не высоко), у него есть свое сообщество фанатов, на нем вполне себе есть и опенсорсные и коммерческие проекты, и даже можно найти вакансии.
Другое дело, что некоторые пророчат ему стать убийцей С++, и конечно же всех остальных языков, в этом у меня большие сомнения, по крайней мере в обозримом будущем.
Стоит ли учить Раст, однозначно тебе никто сейчас не скажет.
С одной стороны, язык вроде вполне набирает популярность, и есть вероятность, что в будущем он может стать одним из мейнстрим языков.
С другой стороны, это не точно... Популярность хоть и растет, но как-то медленно. Несмотря на большое количество фанатов, в коммерческой разработке его как-то совсем немного. Совершенно не факт, что не через год не появится новый молодежный "убийца С++" и все эти фанаты забудут про Раст.
На язык однозначно стоит взглянуть, там есть несколько довольно интересных концепций, которых не увидишь в основных популярных языках. Далее, если вдруг возникло ощущение, что это лучший язык программирования в мире, то поздравляю, ты один из фанатов Раст, в этом случае все вопросы снимаются, ты сам всем будешь предлагать все писать на Расте.
Если же такого ощущения не возникло, то ИМХО с детальным изучением Раста лучше повременить.Все таки он еще не стал мейнстрим языком, и не факт что станет.
Здравствуйте, Dair, Вы писали:
D>>>А этот Руст бинарно совместим с С++-библиотеками? F>>1. Зачем?
D>Ну вот мне привычно было до недавнего времени использовать С++ как язык, общий для бизнес-логики мобильных приложений, а это iOS с Swift и ObjC, куда С++ компилируется нативно, и Андроид с его Джава-машиной и чудовищным (но работающим) JNI. Будет Раст работать через JNI?
Здравствуйте, ksandro, Вы писали:
K>С другой стороны, это не точно... Популярность хоть и растет, но как-то медленно. Несмотря на большое количество фанатов, в коммерческой разработке его как-то совсем немного. Совершенно не факт, что не через год не появится новый молодежный "убийца С++" и все эти фанаты забудут про Раст.
В линуксе 6.1 официальная поддержка раста. Между прочим С++ в ядро Линус так и не позволил затащить.
Здравствуйте, so5team, Вы писали:
BFE>>Из мотивации никак не следует, что \n следует добавлять, и уж никак не обосновано, что \n следует добавить таким противоестественным способом. Ну зачем?!
S>Может вы думаете, что вот эти две строчки эквивалентны друг другу? S>
Здравствуйте, vsb, Вы писали:
vsb>Прислушайтесь!
К чему? К тому, что уровень подготовки программистов упал и они не могут справиться с С++? Слишком сложно? Индусы не справляются? Изнеженные выпускники не могут писать и осваивать или Руссиновч закончил пару проектов после чего решил что Rust это серебряная пуля?
Т.е. про разницу в выводе без flush-а и с flush-ем вы в курсе. OK еще раз.
Тогда следующий вопрос: правильно ли я понимаю, что ваш нормальный стиль вот такой:
print("\nThe result is: {}", result);
std::cout.flush();
Здравствуйте, Dair, Вы писали:
D>Ну вот мне привычно было до недавнего времени использовать С++ как язык, общий для бизнес-логики мобильных приложений, а это iOS с Swift и ObjC, куда С++ компилируется нативно, и Андроид с его Джава-машиной и чудовищным (но работающим) JNI. Будет Раст работать через JNI?
JNI это extern "C". Естественно, все языки, умеющие в C ABI, будут работать сJNI.
Тогда уже надо вспомнить старофортрановский стиль стандартного вывода ("carriage control ASA codes"), где каждая операция вывода должна была начинаться с одиночного символа:
Control character Effect Possible implementation
----------------- ---------------- -----------------------
Space Normal behaviour CR/LF/printing
0 Double spacing CR/LF/LF/printing
+ Overwrite mode CR/printing
1 Next page m*LF/CR/LF/n*LF/printing/CR/LF
или его современный эквивалент:
write(*, fmt="(1x,a,i0)", advance="no") "loop #", i
BFE>и да, я в курсе, что косный unix стиль, всё больше проникает всюду мешая прогрессу. Вот, уже до С++ добрались.
Говоря о языках, пора прекратить начинать любые новые проекты на C/C++ и использовать Rust для тех сценариев, где требуется язык, отличный от GC. Ради безопасности и надежности. отрасль должна объявить эти языки устаревшими.
vsb>Прислушайтесь!
Я не знаю кто такой Руссинович, он для меня не авторитет. Авторитеты для меня это Ричард Столлман, Бьерн Страуструп, Мартин Фаулер и далее по списку.
А так в идеале любые проекты нужно начинать на C/C++, вот моё мнение. Более того, раньше раздавались робкие голоса в пользу C/C++, потому что самые крутые проекты сделаны на них.
Но в тоже время котировались языки одной компании, такие как C#, в некотором смысле даже Java и многие другие. Теперь санкции против России наглядно показывают, что не стоит гнаться за технологиями, которые могут забанить.
Дело уже не просто в техническом превосходстве C/C++, это вопрос выживания. Причём именно кроссплатформенные программы на C/C++ имеют наибольшие шансы прожить десятки лет чтобы там не мутили it-гиганты.
Здравствуйте, gyraboo, Вы писали:
D>>Ну вот мне привычно было до недавнего времени использовать С++ как язык, общий для бизнес-логики мобильных приложений, а это iOS с Swift и ObjC, куда С++ компилируется нативно, и Андроид с его Джава-машиной и чудовищным (но работающим) JNI. G>JNI у вас работает?
Работало, чего б не работать. Впрочем, я последний андроид-проект сдал и закрыл в 2019 году.
G> А как вы deal with exceptions?
Здравствуйте, so5team, Вы писали:
S>Вы не знаете, что в вашей программе уже выведено? Ну, OK.
Откуда это можно знать в многопоточной программе?
И почему только в одной программе? На терминал можно выводить из нескольких...
S>Тогда следующий вопрос: правильно ли я понимаю, что ваш нормальный стиль вот такой: S>
S>print("\nThe result is: {}", result);
S>std::cout.flush();
S>
S>?
Нет. Во-первых: использование форматированной строки имеет смысл, если предполагается перевод вывода на другие естественные языки, что из кода никак не следует. Во-вторых: форматирование вывода и сам вывод — это две разные операции, поэтому имеет смысл их разнести. (std::formatter — правильный шаг в данном направлении). В-третьих: смешивать потоки с вызовами функций ввода-вывода — так себе идея.
Здравствуйте, netch80, Вы писали:
BFE>>Я думаю, что так вообще не стоит писать, так как не известно, что уже выведено в строку. N>Известно, ждём что-то с новой строки.
Смелое допущение. Откуда это известно?
echo -n "asdf" > c.txt
cat c.txt
BFE>>и да, я в курсе, что косный unix стиль, всё больше проникает всюду мешая прогрессу. Вот, уже до С++ добрались. N>Что сразу unix-то?
А вот я не знаю, чего оттуда всё в язык тащат: сначала примитивы синхронизации (не удобные для прикладных уровней), потом вот — перевод строки в конце вывода (см. определение линии в POSIX)
Здравствуйте, B0FEE664, Вы писали:
S>>Вы не знаете, что в вашей программе уже выведено? Ну, OK. BFE>Откуда это можно знать в многопоточной программе? BFE>И почему только в одной программе? На терминал можно выводить из нескольких...
Если вы думаете, что в многопоточной программе (не говоря уже о ситуации, когда в консоль может писать сразу несколько приложений) вот эта вот перестраховка:
вас от чего-то защищает или что-то вам гарантирует, то у меня для вас плохие новости...
S>>Тогда следующий вопрос: правильно ли я понимаю, что ваш нормальный стиль вот такой: S>>
S>>print("\nThe result is: {}", result);
S>>std::cout.flush();
S>>
S>>? BFE>Нет. Во-первых: использование форматированной строки имеет смысл, если предполагается перевод вывода на другие естественные языки, что из кода никак не следует.
Во-первых, это минимальный пример, из которого не следует делать далеко идущие выводы.
BFE>Во-вторых: форматирование вывода и сам вывод — это две разные операции, поэтому имеет смысл их разнести. (std::formatter — правильный шаг в данном направлении).
А могли бы вы переписать показанный мной минималистичный пример так, как вас бы это устроило?
BFE>В-третьих: смешивать потоки с вызовами функций ввода-вывода — так себе идея.
Здравствуйте, Dair, Вы писали:
vsb>>JNI это сишный интероп, а не С++.
D>Окей, а мячик сбросьте так раст работать будет?
Будет, конечно, уж у языка, претендующего на системный, с сишным интеропом-то всё хорошо. Тут вопрос в качестве обёрток, для JNI есть официальные С и С++ хедеры с макросами и всяким, которые призваны немного упрощать всё это дело. Для Rust от сообщества тоже что-то гуглится, но про качество — хз. Но если самому не в ломы написать нужные декларации, проблем точно не будет. Да там в принципе этих обёрток немного, если память не изменяет, буквально несколько десятков функций. Не, я бы на Rust для JNI писал бы без беспокойства, тут проблем не ожидается.
