Нет смысла сравнивать Rust с Хаскелем, потому что это совершенно разные языки. Rust вдохновлялся идеями из Haskell, например, трейты очень похожи на многопараметрические классы типов (пока это их сильно урезанная версия, но в будущем это может быть исправлено), а внутри функций действует вывод типов по Хиндли-Милнеру, но в целом Rust гораздо ближе к императивным языкам. И это естественно, потому что системный функциональный язык сделать очень трудно, и даже если такое сделать, получится что-то, неудобоваримое для использования.
Спасибо за статью, очень здорово видеть русскоязычных людей в коммьюнити Rust :)
С другой стороны есть Haskell, этакий язык-крепость (по принципу «раз оно компилируется, значит работает»), хоть и не могущий похвастаться скоростью.
Это не так, Haskell очень даже может похвастаться скоростью. Здесь Haskell стабильно держит места вплоть за Java и C/C++. Кстати, Java — это как раз один из наиболее быстрых языков.
Однако Rust и в самом деле стремится занять нишу C/C++, и, как мне кажется, когда он станет стабильным, у него есть все шансы это сделать.
Не очень корректно сравнивать Rust с Go. Go никогда не представлялся как язык для системного программирования и он не может им быть — в Go неотключаемый GC, от которого очень многое зависит. В Rust с этой точки зрения упор именно на безопасное управление памятью без оверхеда от GC и прочих автоматических систем (но если сборщик мусора очень нужен, всегда можно взять его из библиотеки). Rust — это именно язык для системного программирования, замена C/C++. Go же позиционировался как такая быстрая компилируемая статическая замена языкам вроде Python/Ruby, т.е. в основном для веб-программирования.
Rust более низкоуровневый и гибкий и не позиционирует себя как «правильный C++», в отличие от D. Философия языков очень различается, как и наборы предоставляемых инструментов. D в этом плане очень похож на C++; в Rust абстракции, с которыми приходится работать, другие.
то в BIOS будем выбирать, грузить «linux-3.14.efi» или «bootmgfw.efi»
В EFI к этому всё идёт, но пока что у меня лично на одной машине получилось так сделать, а на другой — нет. Когда версии EFI будут более унифицированы, нужна в загрузчиках отпадёт, ИМХО.
На самом деле, Дайсон изначально предлагал не сферу в смысле сплошной оболочки, а множество независимых элементов, обращающихся вокруг звезды. См. здесь:
In fictional accounts, the Dyson-sphere concept is often interpreted as an artificial hollow sphere of matter around a star. This perception is based on a literal interpretation of Dyson's original short paper introducing the concept. In response to letters prompted by this paper, Dyson replied, «A solid shell or ring surrounding a star is mechanically impossible. The form of 'biosphere' which I envisaged consists of a loose collection or swarm of objects traveling on independent orbits around the star.»
Не думаю, что это так. Конечно, это anecdotal evidence, что называется, но у меня в библиотеке стима около сотни игр, и ни в одну я в мультиплеере не играю. Для меня стим в первую очередь — это удобный магазин.
Боюсь, я не смогу вам помочь :( выглядит как проблема с git под windows. Я всё манипуляции проводил под Linux, и у меня проблем не было. Может быть, гит просит пароль; попробуйте использовать не https:// для developerConnection, а git@github.com:MY_LOGIN/MY_PROJECT_NAME.git, но это требует правильной настройки ssh.
Согласен. Может быть, я не в тех разделах там сижу, но никогда не видел никакой агрессии, даже когда вопросы закрывают и при этом ведётся дискуссия с его автором в комментариях. Наоборот, всё даже чересчур цивильно, даже удивительно :)
Это ни грамма не микроволновка. Кроме того, я не вижу точных подробностей, но как мне кажется, это даже не излучатель ЭМ-волн, передача энергии идёт только через магнитное поле. Даже если и не так, то частоты совершенно другие, 12 кГц против единиц-десятков ГГц.
Не могу сказать ничего про Wiki-разметку, но вот буквально месяц назад я делал парсер XML на Rust. И могу с абсолютной уверенностью утверждать, что и мой парсер, и парсеры других языков на Rust (например, TOML) вообще не используют индексацию внутри строк и вырезание подстрок.
Вот пожалуйста только не говорите, что индексация в строке — это самая частая операция. Это абсолютная неправда. А других «проблем» с производительностью UTF-8 не имеет.
enca — это детектор кодировки, а конвертер — это enconv. Но ваш пример не пройдёт, потому что терминал в UTF-8, а двойное преобразование (как в вашем примере с iconv) оно не сделает — ведь это вполне себе валидный юникод. enconv по умолчанию будет стараться преобразовать из любой кодировки в кодировку текущей локали.
Да, я в курсе что такое Yaml, я его использую в проектах :) просто не очень было понятно, причём он здесь, когда описываемый формат XML-like. Спасибо за разъяснение.
В тексте указывается, что YML — это XML. И по ссылке на определение его тоже так сказано. Но в конце статьи два раза даётся ссылка на онлайн-парсер Yaml. Это же разные вещи, нет?
Тип Map<T, Boolean> изоморфен типу Set<T> (и, например, в Java множество HashSet построено как тонкая обёртка над HashMap). В языках, где нет эффективной поддержки дженериков, множества частно эмулируются через ассоциативные массивы непосредственно. Например, общепринятым в Go способом создания множества (упоминается даже в официальной документации) является использование map[<something>]bool.
Это не так, Haskell очень даже может похвастаться скоростью. Здесь Haskell стабильно держит места вплоть за Java и C/C++. Кстати, Java — это как раз один из наиболее быстрых языков.
Однако Rust и в самом деле стремится занять нишу C/C++, и, как мне кажется, когда он станет стабильным, у него есть все шансы это сделать.
В EFI к этому всё идёт, но пока что у меня лично на одной машине получилось так сделать, а на другой — нет. Когда версии EFI будут более унифицированы, нужна в загрузчиках отпадёт, ИМХО.
write — wrote — written
read [ri:d] — read [red] — read [red]
utf8everywhere.org/
enca— это детектор кодировки, а конвертер — этоenconv. Но ваш пример не пройдёт, потому что терминал в UTF-8, а двойное преобразование (как в вашем примере с iconv) оно не сделает — ведь это вполне себе валидный юникод.enconvпо умолчанию будет стараться преобразовать из любой кодировки в кодировку текущей локали.В тексте указывается, что YML — это XML. И по ссылке на определение его тоже так сказано. Но в конце статьи два раза даётся ссылка на онлайн-парсер Yaml. Это же разные вещи, нет?
Тип
Map<T, Boolean>изоморфен типуSet<T>(и, например, в Java множествоHashSetпостроено как тонкая обёртка надHashMap). В языках, где нет эффективной поддержки дженериков, множества частно эмулируются через ассоциативные массивы непосредственно. Например, общепринятым в Go способом создания множества (упоминается даже в официальной документации) является использованиеmap[<something>]bool.