Это очень спорно. Скорее всего вся сложность - именно в ломке сознания и уже освоенных паттернов!
В ANSI С++ 98 работать с памятью очень просто - там основныхоператоров раз два и обчёлся! А вот эффективно и надёжно работать с памятью даже в ANSI С++ 98 очень непросто! И если бред на Rust либо не скомпилируется либо просто сразу не заработает как надо. То бред на C++ может проявить себя спустя годы успешной работы! Не говоря уже о мелки недочётах. И выливающихся в гигантские отложенные затраты! Впрочем, и без бреда, чтобы код на С++ скомпилировался - это тоже надо будет очень постараться, даже после незначительных изменений!
А уж последние стандарты C++ столько в него внесли - что чтобы это всё эффективно и надёжно применяться нужно очень сильно мозг напрягать!
И в C++ очень много пережитков прошлого и очень много разных библиотек и паттернов - всё это тоже не добавляет простоты кодирования и отладки!
А уж какую головную боль там обеспечивают шаблоны - что применяются налево и направо!
Но итог тут такой:
Профессионал C++ не будет иметь больших сложностей в кодировании - он 1001 собаку уже съел и знает большую часть тонкостей и нюансов!
Аналогично про Rust профессионала - только тонкостей и тут на порядок меньше, если не на два порядка!
А вот переходить между этими ЯП будет очень больно - это так же больно как переходить, скажем между чисто функциональным и чисто императивным ЯП, и даже убери тут слово "чисто" - по сути ничего не изменится!
На Rust тяжело переходить. Особенно, как ни странно, именно с ЯП с нативным управлением памятью.
Но Rust даёт высокую надёжность при практической такой же производительности!
Я не говорю - что Rust - идеальный ЯП - он просто первый в своём роде - со статическим управлением памятью! Он просто брутальный революционер, обративший на себя взгляды большой части IT-аудитории!
А вот C++ просто ужасный ЯП - учить его для повседневного применения врагу не пожелаешь! Да - у него есть своя и позитивная репутация - и она даёт хлеб тем, кто на нём программирует, и для ряда задач у него, по сути, нет альтернатив (связываться с Rust пока боятся чуть ли не так же как с С++, да и с компиляторами там всё не густо для различных платформ). И альтернатив тут почти нет
Тут скорее другие задачи. Вот есть ЯП Python - он сейчас очень популярен и имеет кучу библиотек, вот только местами тормознут... и тормознут там - где как раз очень максимальная производительность - не критично, но "время-деньги". Да - безусловно - кто-то сразу решает такие задачи на других ЯП, но есть уже не мало тех, кто терпит и остаётся верен Python - с его плюшками! Вот ради них и затеяли сугубо локальную Mojo-революцию! Просто она пока не увенчалась даже призрачной победой, пока только планы строят по захвату мостов и телеграфов! Ну а как удастся - вот тогда и с других ЯП начнут переманивать...
А глобальные революции - оставьте другим, экспериментальным ЯП, как Rust
Выглядит слишком хорошо, чтобы быть правдой! Да и дата публикация явно намекает...
России нынче не до то таких изделий - не ну рисовать красивые картинки и делать громкие лозунги-то - всегда ПОЖАЛУЙСТА - но фактически ни проектировать ни производить ни получать комплектующие ни финансирование ни инженеров - попросту не от куда! Но маркетологи в стране ещё пока есть....
Маркетплейсы сами успешно торговали поставками из-за рубежа.
При лимите в $200 теперь там имеет смысл покупать только всякую безделицу - типа чехольчиков и шнурочков. Остальное всё будет слишком дорого - оно и так было не дёшево (на фоне гигантских объёмов серого импорта).
Но... государству нужны деньги, а не счастливые не бедствующие граждане или развивающийся бизнес с высоким уровнем переработки!
А почему именно трансляция на Си (ЯП которому, то уже тоже читай полтинник лет) , а не на что-то более современное - Kotlin например, который и Native есть (ну на Rust было бы очень сложно) или Python (Mojo).
ИМХО, тут бы конечно лучше выбирать систему с управляемой памятью, а-ля Java (и да в статье и про этот проект тоже пара строчек есть), но всё-таки лучше выбрать современный ЯП (XXI века), а не устаревающие нишевые ЯП. Но тут уже надо глубже понимать среду выполнения - может ли она тянуть доп CLR исполнитель или нужен чистый машинный код?
Вот, приведённый мной вариант с Kotlin - вполне себе может и так и эдак.
Python (с Mojo) тоже вроде как, условно, может в любой среде исполняться
Вообще тут по сути достаточно в IR в модели LLVM компилировать - и далее уже под любое железо и среду исполнения бакэнд-комплятор сделать не проблема!
Даже C# сейчас учится в rutime компилироваться - так что выбор его, мне кажется, тоже более перспективным чем ЯП Си
Или я что-то не понимаю?
Жаль не показали содержательный пример такой трансляции!
Кстати, интересно, насколько COBOL актуален в России?
Ничего не фантазировал и уж тем более никаких претензий не предъявлял. Просто искал смысл
Ну а ради одного пиара только идиоты так бабки закапывают.... вернее сбрасывают с неба на льдину! А в остальном - обычно всегда есть другие цели в т.ч. и скрытый смысл
Ну как минимум профит тут в отработке технологии размещения серверов вне чей-либо юрисдикции - что в уже ближайшем будущем будет очень полезно! Пусть, пока Барнео - это и российская юрисдикция - но ведь это пока лишь "пробная ласточка".
Кстати, в Арктике ещё холодно круглый год - меньше проблем с охлаждением ЦОД. И обслуживание, наверное, проще чем подводой и уж тем более, чем на орбите.
Тогда смысл так и остался не ясен. Ну разве что самопиар и продолжение тестирование возможности разместиться там где не достанут "плохие дядьки" с какой бы стороны они не лезли. Впрочем.... история с "Северным потоком" показала - если местоположение известно - то "плохие дядьки" достанут где угодно - вопрос только сочетания сложности этого процесса и фактической выгоды.
Но, вот, если на Марсе размещать.... то там пока только США хоть как-то достать может.... у остальных пока всё в грунт уходит.... обычно не долетев даже... и пока денег на большее не предвидится!
Тут скорее проблема в другом. Не все ездят часто, кто-то зимой вообще не ездит. И даже если аккум внезапно не сядет в ноль - то в ряде случаев имеет смысл снять и зарядить его - ну а без него машину и вовсе не закрыть, если нет физической личинки хотя бы на водительской двери. Понятно, что премики сами это делать не будут и поедут в автосервис к дилеру; но это далеко не все потребители современных авто - и многие из них будут заряжать самостоятельно, с полным съёмом аккума!
Другое дело то, что в современных автомобилях очень много эоектроники, и она всё чаще глючит, в т.ч. и системы безопасности. Вот сам так попадал - когда заглючил штатный иммобилайзер - но да - это не повлияло на вход в салон, а только двиг не заводился, но если бы это была сингалка с центральным замком - то в салон без ключа уже так же не удалось бы войти. Вопрос зачем - коли и так в сервис на буксире везти? Ну мало ли... вдруг что-то ценное в салоне. Или ни дай бог кто живой... в т.ч. и Вы сами там можете оказаться - вот закроется машина с водителем внутри (а такие случаи, кстати были) - и всё - не выйти - только стёкла выдавливать (ну это кто сообразит)! Впрочем, если водитель внутри машину снаружи не откроет - просто если замок механический - то он и изнутри механически открывается... хотя сейчас везде скрытая блокировка дверей - руками не открыть - если они заблокируются, то тогда, наверное, только стёкла давить!
Это очень спорно. Скорее всего вся сложность - именно в ломке сознания и уже освоенных паттернов!
В ANSI С++ 98 работать с памятью очень просто - там основныхоператоров раз два и обчёлся! А вот эффективно и надёжно работать с памятью даже в ANSI С++ 98 очень непросто! И если бред на Rust либо не скомпилируется либо просто сразу не заработает как надо. То бред на C++ может проявить себя спустя годы успешной работы! Не говоря уже о мелки недочётах. И выливающихся в гигантские отложенные затраты!
Впрочем, и без бреда, чтобы код на С++ скомпилировался - это тоже надо будет очень постараться, даже после незначительных изменений!
А уж последние стандарты C++ столько в него внесли - что чтобы это всё эффективно и надёжно применяться нужно очень сильно мозг напрягать!
И в C++ очень много пережитков прошлого и очень много разных библиотек и паттернов - всё это тоже не добавляет простоты кодирования и отладки!
А уж какую головную боль там обеспечивают шаблоны - что применяются налево и направо!
Но итог тут такой:
Профессионал C++ не будет иметь больших сложностей в кодировании - он 1001 собаку уже съел и знает большую часть тонкостей и нюансов!
Аналогично про Rust профессионала - только тонкостей и тут на порядок меньше, если не на два порядка!
А вот переходить между этими ЯП будет очень больно - это так же больно как переходить, скажем между чисто функциональным и чисто императивным ЯП, и даже убери тут слово "чисто" - по сути ничего не изменится!
Начать с Kotlin как раз проще, чем с Java не имея практики ООП.
Вот, с С++ безусловно проще на Java перейти, но ещё лучше - перейти на C# - а потом уже, по необходимости, на Kotlin
На Rust тяжело переходить. Особенно, как ни странно, именно с ЯП с нативным управлением памятью.
Но Rust даёт высокую надёжность при практической такой же производительности!
Я не говорю - что Rust - идеальный ЯП - он просто первый в своём роде - со статическим управлением памятью! Он просто брутальный революционер, обративший на себя взгляды большой части IT-аудитории!
А вот C++ просто ужасный ЯП - учить его для повседневного применения врагу не пожелаешь! Да - у него есть своя и позитивная репутация - и она даёт хлеб тем, кто на нём программирует, и для ряда задач у него, по сути, нет альтернатив (связываться с Rust пока боятся чуть ли не так же как с С++, да и с компиляторами там всё не густо для различных платформ).
И альтернатив тут почти нет
Тут скорее другие задачи. Вот есть ЯП Python - он сейчас очень популярен и имеет кучу библиотек, вот только местами тормознут... и тормознут там - где как раз очень максимальная производительность - не критично, но "время-деньги". Да - безусловно - кто-то сразу решает такие задачи на других ЯП, но есть уже не мало тех, кто терпит и остаётся верен Python - с его плюшками! Вот ради них и затеяли сугубо локальную Mojo-революцию! Просто она пока не увенчалась даже призрачной победой, пока только планы строят по захвату мостов и телеграфов! Ну а как удастся - вот тогда и с других ЯП начнут переманивать...
А глобальные революции - оставьте другим, экспериментальным ЯП, как Rust
Выглядит слишком хорошо, чтобы быть правдой! Да и дата публикация явно намекает...
России нынче не до то таких изделий - не ну рисовать красивые картинки и делать громкие лозунги-то - всегда ПОЖАЛУЙСТА - но фактически ни проектировать ни производить ни получать комплектующие ни финансирование ни инженеров - попросту не от куда! Но маркетологи в стране ещё пока есть....
а что такое MV3?
Маркетплейсы сами успешно торговали поставками из-за рубежа.
При лимите в $200 теперь там имеет смысл покупать только всякую безделицу - типа чехольчиков и шнурочков. Остальное всё будет слишком дорого - оно и так было не дёшево (на фоне гигантских объёмов серого импорта).
Но... государству нужны деньги, а не счастливые не бедствующие граждане или развивающийся бизнес с высоким уровнем переработки!
М-да, значит сделать такой проект по задаче (тестовая), чуть большего объёма, за чуть менее месяц, не имея большого опыта, просто нереально...
Интересный материал. Вот вопрос - сколько по времени заняла разработка вышеприведённых схем от момент первичной постановки задачи?
А почему именно трансляция на Си (ЯП которому, то уже тоже читай полтинник лет) , а не на что-то более современное - Kotlin например, который и Native есть (ну на Rust было бы очень сложно) или Python (Mojo).
ИМХО, тут бы конечно лучше выбирать систему с управляемой памятью, а-ля Java (и да в статье и про этот проект тоже пара строчек есть), но всё-таки лучше выбрать современный ЯП (XXI века), а не устаревающие нишевые ЯП. Но тут уже надо глубже понимать среду выполнения - может ли она тянуть доп CLR исполнитель или нужен чистый машинный код?
Вот, приведённый мной вариант с Kotlin - вполне себе может и так и эдак.
Python (с Mojo) тоже вроде как, условно, может в любой среде исполняться
Вообще тут по сути достаточно в IR в модели LLVM компилировать - и далее уже под любое железо и среду исполнения бакэнд-комплятор сделать не проблема!
Даже C# сейчас учится в rutime компилироваться - так что выбор его, мне кажется, тоже более перспективным чем ЯП Си
Или я что-то не понимаю?
Жаль не показали содержательный пример такой трансляции!
Кстати, интересно, насколько COBOL актуален в России?
Ничего не фантазировал и уж тем более никаких претензий не предъявлял. Просто искал смысл
Ну а ради одного пиара только идиоты так бабки закапывают.... вернее сбрасывают с неба на льдину! А в остальном - обычно всегда есть другие цели в т.ч. и скрытый смысл
Причём в прямом смысле - с неба
Ну как минимум профит тут в отработке технологии размещения серверов вне чей-либо юрисдикции - что в уже ближайшем будущем будет очень полезно! Пусть, пока Барнео - это и российская юрисдикция - но ведь это пока лишь "пробная ласточка".
Кстати, в Арктике ещё холодно круглый год - меньше проблем с охлаждением ЦОД. И обслуживание, наверное, проще чем подводой и уж тем более, чем на орбите.
Главное с электроэнергией вопросы решить
Тогда смысл так и остался не ясен. Ну разве что самопиар и продолжение тестирование возможности разместиться там где не достанут "плохие дядьки" с какой бы стороны они не лезли. Впрочем.... история с "Северным потоком" показала - если местоположение известно - то "плохие дядьки" достанут где угодно - вопрос только сочетания сложности этого процесса и фактической выгоды.
Но, вот, если на Марсе размещать.... то там пока только США хоть как-то достать может.... у остальных пока всё в грунт уходит.... обычно не долетев даже... и пока денег на большее не предвидится!
del
Так сегодня или с 1-го апреля?
А из своих продуктов OneDrive тоже уберут - что бы не мешался, а то уже достал - лезет из всех щелей...
А юрисдикция то чья будет? Ради чего всё это затевалось?
М-да - был когда-то неплохой банк... и началось (два года назад) - теперь рулит лозунг: Помойки РФ - объединяйтесь!
А странно что они сами на себя ещё в суд не подали!
Тут скорее проблема в другом. Не все ездят часто, кто-то зимой вообще не ездит. И даже если аккум внезапно не сядет в ноль - то в ряде случаев имеет смысл снять и зарядить его - ну а без него машину и вовсе не закрыть, если нет физической личинки хотя бы на водительской двери. Понятно, что премики сами это делать не будут и поедут в автосервис к дилеру; но это далеко не все потребители современных авто - и многие из них будут заряжать самостоятельно, с полным съёмом аккума!
Другое дело то, что в современных автомобилях очень много эоектроники, и она всё чаще глючит, в т.ч. и системы безопасности. Вот сам так попадал - когда заглючил штатный иммобилайзер - но да - это не повлияло на вход в салон, а только двиг не заводился, но если бы это была сингалка с центральным замком - то в салон без ключа уже так же не удалось бы войти. Вопрос зачем - коли и так в сервис на буксире везти? Ну мало ли... вдруг что-то ценное в салоне. Или ни дай бог кто живой... в т.ч. и Вы сами там можете оказаться - вот закроется машина с водителем внутри (а такие случаи, кстати были) - и всё - не выйти - только стёкла выдавливать (ну это кто сообразит)! Впрочем, если водитель внутри машину снаружи не откроет - просто если замок механический - то он и изнутри механически открывается... хотя сейчас везде скрытая блокировка дверей - руками не открыть - если они заблокируются, то тогда, наверное, только стёкла давить!