для написания на нём чего либо... double-free, data race, segfault это всё жуть жутчайщая дебажить которую я даже врагу не желаю (дабы потом украсть его код разумеется 😁) когда ты знаешь что если скомпилилось то эдаких проблем нет - это сильно упрощает разработку

поговаривают, что в раст завезут async/await, тогда заживём

ну камон, под раст портируют низкоуровневые либы для написания гуёв, тот же gtk3. И можно пилить графические аппликухи

тот факт что для Go нет библиотек и фреймворков для написания гуев - не делает Rust идеологически более пригодным для application programming. JavaScript больше application prog. чем C++, но на C++ есть Qt, однако даже там завезли QML (superset of JavaScript/ECMA) однако JavaScript убог для более сложных аппликух, но увы, Go пока-что не про Gui, хотя вполне мог бы быть

application programming = software for users systems programming = software for software applications prog. = ttm (time-to-market), features, security systems programming = performance, resource-usage, safety Rust = systems programming Go = application programming

Внезапно большинство десктопных приложений пишутся именно на языках "системного программирования", ибо микролаги из-за GC

легаси. Идеологически C++ и подобные ничерта не потеряли в applc. prog.

чуваки, какую книжку посоветуете для быстрого освоения go? я из плюсов припёрся)

Тоже эту тему иногда просматриваю. Как думаешь, почему так? Просто руки ещё не дошли?

Я знаю только одно нормальное десктопное приложение написанное на языке с GC, это эмулятор терминала Tilix написанный на D.

а как жи IDEA ???!!!!

Проблема в том, что не легаси работает так плохо, что аж терпеть невозможно.

Внезапно большинство десктопных приложений пишутся именно на языках "системного программирования", ибо микролаги из-за GC

GUI renderer = systems programming GUI application = application programming я не говорю что на Go нужно рендерить, нет, ни в коем случае! (мы об этом уже здесь говорили почему писать рендер на Go это очень плохая идея) а вот для самой логики приложения, для работы с сетью, для работы с файловой системой, с базами данных, с поверхностным number crunchung'ом и т.д. Go довольно хорош в идеале у нас рендер на Rust вызывающий Go код. Никаких микролагов, стабильные 60 фпс, но и относительно простое написание логики приложения. https://github.com/therecipe/qt это как-раз про C++/Qt рендер с Go логикой

Проблема в том, что не легаси работает так плохо, что аж терпеть невозможно.

проблема веб-аппликух обёрнутых в аппликухи типа Electron в устаревшем DOM'е (HTML/CSS это вообще про статические документы, а не динамические приложения) QML это как раз замена HTML/CSS/DOM, но пока-что только в C++/Qt

То есть при вводе текста лагов в такой схеме не будет замечено? Сомневаюсь.

Проблема в том, что надо не только рисовать быстро, но и обрабатывать пользовательский ввод без задержек

а как думаете, чем плох swift по сравнению с go для бэкэнда?

ты пойми, рендер и логика/данные должны оперировать в разных потоках независимо друг от друга. Единственно лаги могут возникать когда рендер не может отрисовать картинку из-за того что логика его блокирует, но этого можно и нужно избегать

а как думаете, чем плох swift по сравнению с go для бэкэнда?

а как думаете, чем плох swift по сравнению с go для бэкэнда?

Ну вот допустим у нас текстовый редактор. Там, чтобы символ появился на экране рендер должен отдать событие апликэйшн части, а апп должен рассказать рендеру что рисовать. Как в такой схеме избежать лагов? Только переписывать логику на языке без GC

shared memory. рендер в отдельном потоке работает с повышенным приоритетом грубо говоря 60 раз в секунду наблюдая за изменениями в data model которая в shared memory. application logic может пропустить пару кадров например из-за GC, но не заблокирует этим render. Когда AL завершит свою обработку данных он просто разлочит новую модель и рендер среагирует на это читая новую модель

Ну вот ты описал сценарий, где инпут лаг 2 кадра. Ну и нахера такие приложения нужны?

Скорее десктопные приложения нужно писать с архитектурой frontend-backend, где на бэкенде вся медленная бизнес логика, а на фронте быстрые обработчики событий.

А это много? 🤔

Ну вот ты описал сценарий, где инпут лаг 2 кадра. Ну и нахера такие приложения нужны?

сам Пайк об этом трубил во все стороны, хотя это конечно бред)

в C++ разве умные указатели не решают проблем хотя бы частично?

Умные указатели - это вообще ортогональная тема.

почему? вроде про new\delete имелось в виду про опасности?

Это единственная проблема, которую умные указатели решают, и то, если не забываешь их мувать при передаче кому-нибудь (unique_ptr).

вроде умные указатели решают проблемы с утечкой памяти+проблемы с concurrency?

Они решают только проблему своевременного удаления объектов. О каких проблемах с concurrency вы говорите?

гонки по данным?

Не решают.

зачем тогда нужен shared_ptr и unique_ptr?

shared_ptr решает проблему своевременного очищения "общих" объектов, unique_ptr решает проблему своевременного очищения объектов, на которые есть одна уникальная ссылка. При этом unique_ptr никак не гарантирует, что на объект есть только одна ссылка.

тогда странно, что unique_ptr назван так

нужно быть фантастически смелым человеком, чтобы утверждать, что Пайк не знает, что он делает, да.

Владение и заимствование же решают эти проблемы фундаментально.

вроде умные указатели решают проблемы с утечкой памяти+проблемы с concurrency?

гонки по данным?

shared_ptr решает проблему своевременного очищения "общих" объектов, unique_ptr решает проблему своевременного очищения объектов, на которые есть одна уникальная ссылка. При этом unique_ptr никак не гарантирует, что на объект есть только одна ссылка.

смотря что понимать под systems programming

Вот вам не лень...

application programming = software for users systems programming = software for software applications prog. = ttm (time-to-market), features, security systems programming = performance, resource-usage, safety Rust = systems programming Go = application programming

@aadz69