Комментарии 21
А для программирования микроконтроллеров годятся оба языка?
Тут один чертяга недавно писал ядро ОС на Go… Но ты подумай, у Go хоть и классный, но сборщик мусора.
Может и «годятся», но так-то и Nim «годится». Заставить работать можно, только это ничего не даёт — во-первых, нужна память для среды исполнения, во-вторых, гарантии безопасности Rust статические — во время исполнения это ничего не стоит.
То есть Rust годится для микроконтроллеров, а Go нет?
Если так, то, имхо, это одно из решающих отличий.
Если так, то, имхо, это одно из решающих отличий.
Да, всё так.
На Rust удобно написать программу для микроконтроллера гораздо проще, чем на Go.
На Rust удобно написать программу для микроконтроллера гораздо проще, чем на Go.
НЛО прилетело и опубликовало эту надпись здесь
На Rust писать без рантайма проще, чем на Go. Для поддержки всех фич Go нужен рантайм. Каналы, встроенные типы данных, горутины — всё это без рантайма работать не будет, а без этих фич Go — это крайне неудобный C. В Rust практически весь язык доступен вообще без какого-либо внешнего кода, и, кроме того, он «модульный», если это так можно сформулировать. Например, вы хотите написать программу для Pebble. Там свои скрипты сборки, своя архитектура и своя сишная библиотека, сильно урезанная по сравнению, например, с glibc. Не проблема — отключаете std, подключаете то, что можно, например, liballoc (и, как следствие, станет возможно взять libcollections и ещё кучу всего), который можно подключить, обернув сишный malloc/free, компилируете свою программу как статическую библиотеку и скармливаете её нативным для Pebble скриптам сборки — и всё будет работать.
В Rust писать низкоуровневый код, например, работу с сырыми указателями, гораздо проще. Goшный unsafe.Pointer очень неудобен по сравнению с его обычными указателями. В Go нет inline assembly, в Rust есть, и есть планы по его улучшению.
В Rust писать низкоуровневый код, например, работу с сырыми указателями, гораздо проще. Goшный unsafe.Pointer очень неудобен по сравнению с его обычными указателями. В Go нет inline assembly, в Rust есть, и есть планы по его улучшению.
НЛО прилетело и опубликовало эту надпись здесь
Тут речь о том, что так как у Rust бэкенд это LLVM, то можно библиотеки на Rust, линковать к другим приложениям.
Тут говорят о том, что у Rust практически отсутствует среда исполнения, поэтому его можно легко встраивать в языки с runtime. В официальной книге есть пример вызова Rust из Ruby.
Есть куча характеристик, показатели которых можно измерять для Rust и Go. И в этом смысле определять соперничество.
То, что они предназначены для разных областей, не значит что они не являются соперниками. Просто один другому однозначно проигрывает в популярности, в зависимости от сферы применения.
То, что они предназначены для разных областей, не значит что они не являются соперниками. Просто один другому однозначно проигрывает в популярности, в зависимости от сферы применения.
Недавно решил взглянуть на оба языка. Как-то с первых же глав их документаций ощущается, что Rust метит в нишу безопасного системного ПО С/С++, а Go больше по прикладному на замену Java/Python/Perl/Nodejs
Go больше по прикладному на замену Java/Python/Perl/Nodejs
Спорное утверждение, как альтернативу еще может быть, но чтобы прям замену… Да и к тому же даже у этих казалось бы чаще применимых на бэкэндах языков отчасти разные ниши. Не будете же Вы для банков ПО писать на NodeJS. А если сравнить Python и Go в разрезе разработки сферического веб-сайта в вакууме, то победитель тоже очевиден.
Ну понятно, что это очень грубая оценка. Объединил я эти средства по большей части в контексте веб-приложений, где сейчас у Go наблюдается наверное наибольшая популярность. Perl/Python скорее в контексте написания различных скриптов. В общем посыл в том, что может работать на низком уровне, но сами же слабо позиционируют себя в этом направлении
Ну вот я знаю один очень большой банк (международный) в котором сделали огромный фрэймворк на Питоне (под капотом много всего, но бизнес логика именно на Питоне) и сейчас мигрируют Java и .NET приложения на него. Сделано всё довольно круто. Так что теоретически наверное и на NodeJS можно.
Хм, достаточно интересно. Но в принципе ничего удивительно, зная то насколько Python хорошо подходит для data mining и т.д., можно с легкостью предположить, что и для финансовых операций он отлично подойдет. Не в курсе как у него с транзакциями и т.д., но думаю что язык вполне подходящий под эту нишу.
Не будете же Вы для банков ПО писать на NodeJS.PayPal в 2013 году начал переход с Java на Node.js.
There’s been a lot of talk on PayPal moving to node.js for an application platform. I’m happy to say that the rumors are true and our web applications are moving away from Java and onto JavaScript and node.js.
Если вчитаться, то можно увидеть, что они его юзают именно для веба. Речь то шла совсем о другом. Если гугл себе состряпает сайт для одного из сотни своих сервисов на Node.js, то не будем же мы говорить, что гугл на Node.js написан… Пока мы не увидим реально большие вещи на Node.js(например как инфраструктура Amazon'а), то даже и обсуждать нечего. Ничего не имею против Node.js(даже напротив очень рад что появилась такая быстрорастущая платформа), но надо понимать, что у него совсем другая ниша.
Что Rust, что Go — оба считаются безопасными (по части управления памятью). В то время, как это утверждение абсолютно правдиво, оба языка не поощряют использование unsafe кода; что более важно, сегодня мир просто не примет язык без подобных гарантий надежности. Просто так получилось, что Go и Rust — это первые языки, которым удалось доказать, спустя десятилетия доказательств, что в реальности программисты просто не могут безопасно обращаться с памятью вручную.
Если вам не сложно, не можете, пожалуйста, подсказать, чем именно они доказали это?
Вон в Java и C# уже давно были сборщики мусора и они вроде оба безопасные по памяти.
Или я что-то не понимаю?
(Также существование C++ вот уже много лет доказывает, что вполне себе могут)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему Go и Rust не соперники