Имхо, явное, в данном случае, лучше неявного.
Отличить типаж от типа, не закапываясь в "где же он определён" бывает достаточно сложно — далеко не всегда исходники доводится читать в IDE.
И в целом очень удобно явно видеть, что "здесь у нас trait-object" (на который кроме вышеупомянутых "штрафов" скорости, действует ещё целый ряд ограничений).
Пример был лишь конкретным ответом на вброс. Вы с этим ответом очевидно не согласны, но углубляться в детали чего-то более объективного не стремитесь. Ну ок.
Т.е. притащить либу это ни о чем, а импорт целая катастрофа. Это я ёрничаю над объективностью оценки.
Нападка была на многословность и именно она оценивалась, не что-то другое. При этом "притащить целую либу" — тоже было оценено: в случае Java эта "целая либа" — уже притащена в комплекте стандартной, а в случае Rust, хоть и оформлена отдельной либой, но по статусу близка к стандартной.
Точно так же упоминался и особый стиль работы Rust с ошибками. Но ок, пример с io тоже хорош.
Про коммуникацию не буду обсуждать, у вас своя волна каких-то теплых человеческих чувств к машине.
Вам не кажется, что отрицать существование коммуникации "человек-машина", в качестве аргумента используя при этом язвительные эмоциональные ярлыки — несколько… гм… неконструктивно?
Ок, давайте о комментаторе подробней, комментатор не против ;-)
Комментатор говорит за лаконичность кода и для примера используют внешнюю либу в своем примере.
Комментатор пытает честно сравнить объём кода, который потребовался для решения задачи на двух разных языках. Объём кода растёт из всего, в том числе и из подключения внешних модулей, и необходимости создавать служебные объекты, и из необходимости обрабатывать ошибки, что мы и видим на примере Regex.
При этом использованная внешняя либа — находится в так называемом "nursery", который отделён от стандартной либы очень тонкой (сходящей на нет) гранью. Это сравнивается с тем, что в Java аналогичная функциональность закопана в stdlib.
println! и иже с ним всякие write!, format! в Rust доступны программисту без дополнительных телодвижений (если он не делает странного), в Java аналогичные вещи нужно либо импортировать, либо вызывать полностью прописав весь путь к соответствующим классам и это тоже видно на примере кода.
И вот всплывают действительные различия на уровне семантики языков, а комментатор бодро их игнорит в примере.
Эмм, мы можем развить эту тему, наверняка Вы знаете экстремальные примеры, где обработка ошибок — это бессмысленно, больно и много кода? На синтетическом примере с wordcount — здесь негде развернуться.
О чем это вообще? Вроде ни акторы ни каналы не присутствовали в контексте.
То есть, на самом деле Вы просто не поняли о чём речь и из этого преждевременно сделали вывод, что комментатор говорил без конкретики, вместо того, чтобы прямо сообщить комментатору, что он как-то непонятно выразился?
Язык программирования — это таки язык — средство коммуникации, в данном случае человека с машиной. Акторы и каналы здесь ни при чём. Язык должен позволять человеку описывать то, что он хочет получить от машины.
в 2-3 раза больше кода, чем на многих других языках
Возможно Вы про какой-то другой Rust говорите? Если мы будем сравнивать с языками, созданными специально для обработки текста, то наверняка с задачей обработки текста они справятся лучше. Но с ними проиграют вообще большинство современных популярных и универсальных языков.
public static void main (String[] args) {
System.out.println("Simple Java Word Count Program");
String str1 = "Today is Holdiay Day";
String[] wordArray = str1.trim().split("\\s+");
int wordCount = wordArray.length;
System.out.println("Word count is = " + wordCount);
}
extern crate regex;
fn main() {
println!("Simple Rust Word Count Program");
let str1 = "Today is Holdiay Day";
let spaces = regex::Regex::new(r"\s+").expect("Can't compile regex");
let word_count = spaces.split(str1.trim()).count();
println!("Word count is = {}", word_count);
}
Что мы здесь видим? Когда что-то внесено в стандартную библиотеку да ещё и автоматически импортируется, с этим бывает проще работать. В примерах выше у Rust таким лаконичным оказывается ввод-вывод, у Java — регулярные выражения, принимаемые как строковой аргумент.
В остальном… Rust принуждает обрабатывать ошибки — если мы пишем качественный код, им придётся уделять внимание в любом случае, но с Rust — все ошибки явные и их обработка входит в привычку. Java же кидает исключения, которые далеко не так удобно обрабатывать на каждом шагу и всегда есть соблазн отложить их обработку на потом.
Вышеприведённый код на Java честно украден со StackOverflow, вероятно его можно ещё чуточку упростить, использовав аналогичным образом итератор?
В одном из альтернативных ответов предлагают использовать StringTokenizer API, что позволяет, наверно, надёжней считать слова: new StringTokenizer(str1).countTokens() однако не выглядит лаконичней, чем приведённый код. Такому сценарию можно сопоставить использование какой-нибудь библиотеки по работе с текстом и мне сложно представить, что её API для тех же задач будет сложнее.
Если посмотреть на другие варианты ответов — умение писать компактный код на Java — далеко не такой распространённый навык, как можно было бы ожидать.
Ну и последний момент — Rust создан для точного управления тем, что происходит в программе. Коммуникация — часть процесса управления. Иногда приходится сообщать больше, чтобы не было разночтений, и возможность что-то сообщить — упрощает написание качественного и согласованного кода. Компилятор может ловить достаточно сложные ошибки, за которыми в других языках пришлось бы бегать с отладчиком по всему проекту и молиться на QA, которые их заметят до релиза.
С другой стороны — в Rust реализован впоне здоровый компромис между детальностью описания и "догадливостью" компилятора. Нет необходимости уточнять вот прям всё-всё-всё — Rust умеет выводить типы, библиотеки предоставляют инструменты для конвертации типов. И есть неплохая система кодогенерации, позволяющая сокращать количество пользовательского кода на порядок, чем популярные библиотеки (и упомянутый в статье Exonum) достаточно часто пользуются.
Обычно за несколько часов радикальных изменений курса не происходит. А вложить "все свои деньги" — всё-таки плохая идея даже с самыми надёжными и стабильными валютами.
Из 5 примеров ни в одном нет ссылки на домашнюю страницу.
Определённо это не проблема ICO, а проблема данной статьи ;-)
Из 5 проектов, кажется, ни один до продукта и стабильной выручки не дошёл. Ну то есть так чтобы это не было чем-то "пирамидообразным", чтобы были стабильные кастомеры и т.п.
Это мало чем отличается от вложений в стартапы в сфере IT или венчурных инвестиций в целом, что не мешает им быть достаточно популярными, хоть и с высоким риском.
остальные почти чисто производные от "криптовалютной" темы
Eos и Tezos — платформы для универсальных смарт-контрактов, так же как и уже всем известный Ethereum.
"Криптовалютная" тема — сама по себе произвольная от темы автоматического и децентрализованного управления собственностью, так что тут всё наоборот.
Bancor — частный случай применения смарт-контрактов — протокол автоматического обмена этой самой собственностью с подстройкой стоимости в зависимости от спроса. В данном случае он "перпендикулярен" "криптовалютной" теме.
Применение децентрализованных систем управления правами, неподконтрольных государству, в любом случае предмет риска регуляции со стороны различных юрисдикций. Но в ряде уважаемых юрисдикций оно уже узаконено.
ICO, существующее в рамках этих систем очевидно подвергается всем их рискам. Однако, в случае, когда исходный код смарт-контрактов доступен к изучению, исходный код проектов и их концепция подробно описаны, разработчики обладают хорошей репутацией и успешно запускали перед этим другие проекты — объявлять все ICO под одну гребёнку "похожими на развод" — так же странно, как объявлять разводом государства только потому, что некоторые из них заканчивали своё существование включённым на полную мощность печатным станком, рекордами гиперинфляции и коллапсом экономики. ICO в этом плане куда более прозрачная и понятная штука, чем среднестатистическое государство на нашей планете.
Рано или поздно в протоколах или их реализациях обнаруживаются баги. Открытая среда позволяет незаметно наблюдать и собирать статистику, а также вмешаться, «не нарушая территорию» и вполне возможно, что издалека.
Позже возникнут конфликты разнообразного оборудования и прошивок.
Кроме того тут ниже упоминают, что погодные условия тоже интересным образом влияют на качество функционирования и в этом вопросе у наземных каналов имеется традиционное преимущество.
Всё это неизбежно и старо — единственное, что здесь не так, это попытка продать радиоканал вместо наземного как нечто уникальное. Да, мобильность это неплохо и имеет свои достоинства, так что рынок несколько перераспределиться со временем в пользу мобильного интернета, но это произойдёт независимо от конкретной компании и её брендированной технологии — это объективный и уже давно идущий процесс.
Сам язык с пользовательской точки зрения — вряд ли сложнее.
А сравнивать сложность "договориться со строгим компилятором" и "договориться с отладикой, тестированием и фазой луны" — достаточно тяжело сравнивать.
Прошу прощения, изначально я "промахнулся" с контекстом и поспешил ответить ))
Как выше написали, буквально str — это тип. Тип, который невозможно (без unsafe) получить с "неправильными" данными. Но сами данные — в этом случае придётся держать за указателем — либо с контролируемым временем жизни за ссылкой &str, либо за владеющей ссылкой Box<str>, Rc<str> etc, либо за сырым указателем *const/mut str. str — тип неизвестного на этапе компиляции размера, поэтому простого способа использовать его как обычную переменную, лежащую на стеке, нет (да и нужно ли?).
Если у нас есть нечто типа str, значит под капотом — набор байт, являющийся корректной utf-8 строкой. И с этим типом ассоциирован ряд функций, которые умеют с этим utf-8 корректно работать.
Rust позволяет программисту с помощью типов выразить некоторую логику состояния, описать логику переходов между состояниями и дать определённые гарантии в связи со всем этим. Тут была неплохая статья на тему конечных автоматов, которая раскрывает идеи такого подхода.
Если типы не прошли проверку — это не скомпилируется, а функции, принимающие на вход другой тип — не будут работать не со своими данными, что снимает ряд недоразумений и позволяет большой ряд ошибок ловить на этапе компиляции и не путать тёплое с быстрым.
Если же мы займёмся произвольным приведением указателей — плакали наши гарантии, пользы от Rust будет сильно меньше, чем от C (учитывая его полувековую историю). Но Rust как и C не запрещает работать с указателями, в некоторых ситуациях это неизбежно (это и фундамент низкоуровневых библиотек, и всевозможный FFI). Всё, что для этого требуется — чётко обозначенное условие потери гарантий (или точнее — взятие на себя ответственности) — unsafe.
В Грузии с начала этого года запущен первый госреестр (если не ошибаюсь, недвижимого имущества) на блокчейне. Аналогичный проект сейчас тестируется и запускается в Украине. Записи в блокчейн-реестрах медленно но уверенно обретают юридическую силу. Впереди — решение вопросов интеграции между блокчейнами.
Получится. Для этого необходима поддержка технологии на государственном уровне.
Например, в Украине ведётся соответствующая разработка электронной гривны
Майнинг — это не эмиссия.
Майнинг — это внесение новых записей в распределённый реестр.
В случае биткойна и ряда его клонов на начальном этапе с малым движением в сети он вознаграждается эмиссией, поэтапно вознаграждение переносится на комиссию.
Майнинг с точки зрения криптовалюты — это такая же материальная услуга, как и обычный денежный перевод в каком-нибудь банке или условном "вестернюнионе". Но в дополнение к этому — он быстрее, дешевле, надёжней, гибче и фактически независим. Не будут нужны дешёвые и быстрые международные переводы, не будет нужен и майнинг, не будут нужны и различные "койны".
Но пока что мы наблюдаем обратное и причин, по которым основные койны могли бы "исчезнуть" — не просматривается.
За саму возможность майнить "драка" идёт, оборудование раскупают "с колёс" опоздавшие, а умные — сразу с завода, какое же тут "исчезнуть"? Место исчезнувшего с удовольствием занимают оставшиеся и новоприбывшие — сложность сети подстраивается под количество участников — если кто-то выбывает из игры по причине нерентабельности, сложность падает и для оставшихся — рентабельность растёт.
Добавьте к этому, что ряд уважаемых юрисдикций уже легализовали блокчейн либо как платёжное средство, либо как иные виды активов, при этом местами — даже освободив от налогов, а значительная часть уважаемых юрисдикций — не считают необходимым вмешиваться.
Конечно, где-то и запрещают, примеры есть, так же как где-то и интернет запрещают. Но какое дело локомотиву прогресса до тех, кто остался на обочине? Процесс уже необратим, блокчейн как платформа обладает высокой ценностью за счёт своих свойств, а теперь уже и благодаря сетевым эффектам планетарного масштаба.
Имхо, явное, в данном случае, лучше неявного.
Отличить типаж от типа, не закапываясь в "где же он определён" бывает достаточно сложно — далеко не всегда исходники доводится читать в IDE.
И в целом очень удобно явно видеть, что "здесь у нас trait-object" (на который кроме вышеупомянутых "штрафов" скорости, действует ещё целый ряд ограничений).
Пример был лишь конкретным ответом на вброс. Вы с этим ответом очевидно не согласны, но углубляться в детали чего-то более объективного не стремитесь. Ну ок.
Нападка была на многословность и именно она оценивалась, не что-то другое. При этом "притащить целую либу" — тоже было оценено: в случае Java эта "целая либа" — уже притащена в комплекте стандартной, а в случае Rust, хоть и оформлена отдельной либой, но по статусу близка к стандартной.
Точно так же упоминался и особый стиль работы Rust с ошибками. Но ок, пример с io тоже хорош.
Вам не кажется, что отрицать существование коммуникации "человек-машина", в качестве аргумента используя при этом язвительные эмоциональные ярлыки — несколько… гм… неконструктивно?
Ок, давайте о комментаторе подробней, комментатор не против ;-)
Комментатор пытает честно сравнить объём кода, который потребовался для решения задачи на двух разных языках. Объём кода растёт из всего, в том числе и из подключения внешних модулей, и необходимости создавать служебные объекты, и из необходимости обрабатывать ошибки, что мы и видим на примере Regex.
При этом использованная внешняя либа — находится в так называемом "nursery", который отделён от стандартной либы очень тонкой (сходящей на нет) гранью. Это сравнивается с тем, что в Java аналогичная функциональность закопана в stdlib.
println!и иже с ним всякиеwrite!,format!в Rust доступны программисту без дополнительных телодвижений (если он не делает странного), в Java аналогичные вещи нужно либо импортировать, либо вызывать полностью прописав весь путь к соответствующим классам и это тоже видно на примере кода.Эмм, мы можем развить эту тему, наверняка Вы знаете экстремальные примеры, где обработка ошибок — это бессмысленно, больно и много кода? На синтетическом примере с wordcount — здесь негде развернуться.
То есть, на самом деле Вы просто не поняли о чём речь и из этого преждевременно сделали вывод, что комментатор говорил без конкретики, вместо того, чтобы прямо сообщить комментатору, что он как-то непонятно выразился?
Язык программирования — это таки язык — средство коммуникации, в данном случае человека с машиной. Акторы и каналы здесь ни при чём. Язык должен позволять человеку описывать то, что он хочет получить от машины.
Предлагайте более актуальные примеры, мы с удовольствием их обсудим и, возможно, это станет началом улучшения языка. Rust — развивается не в последнюю очередь в ответ на потребности сообщества. Я же лишь ответил на конкретный комментарий выше, с утверждением "реализации на Rust требуют в 2-3 раза больше кода, чем на других языках", что "несколько преувеличено" ©.
Возможно Вы про какой-то другой Rust говорите? Если мы будем сравнивать с языками, созданными специально для обработки текста, то наверняка с задачей обработки текста они справятся лучше. Но с ними проиграют вообще большинство современных популярных и универсальных языков.
Что мы здесь видим? Когда что-то внесено в стандартную библиотеку да ещё и автоматически импортируется, с этим бывает проще работать. В примерах выше у Rust таким лаконичным оказывается ввод-вывод, у Java — регулярные выражения, принимаемые как строковой аргумент.
В остальном… Rust принуждает обрабатывать ошибки — если мы пишем качественный код, им придётся уделять внимание в любом случае, но с Rust — все ошибки явные и их обработка входит в привычку. Java же кидает исключения, которые далеко не так удобно обрабатывать на каждом шагу и всегда есть соблазн отложить их обработку на потом.
Вышеприведённый код на Java честно украден со StackOverflow, вероятно его можно ещё чуточку упростить, использовав аналогичным образом итератор?
В одном из альтернативных ответов предлагают использовать StringTokenizer API, что позволяет, наверно, надёжней считать слова:
new StringTokenizer(str1).countTokens()однако не выглядит лаконичней, чем приведённый код. Такому сценарию можно сопоставить использование какой-нибудь библиотеки по работе с текстом и мне сложно представить, что её API для тех же задач будет сложнее.Если посмотреть на другие варианты ответов — умение писать компактный код на Java — далеко не такой распространённый навык, как можно было бы ожидать.
Ну и последний момент — Rust создан для точного управления тем, что происходит в программе. Коммуникация — часть процесса управления. Иногда приходится сообщать больше, чтобы не было разночтений, и возможность что-то сообщить — упрощает написание качественного и согласованного кода. Компилятор может ловить достаточно сложные ошибки, за которыми в других языках пришлось бы бегать с отладчиком по всему проекту и молиться на QA, которые их заметят до релиза.
С другой стороны — в Rust реализован впоне здоровый компромис между детальностью описания и "догадливостью" компилятора. Нет необходимости уточнять вот прям всё-всё-всё — Rust умеет выводить типы, библиотеки предоставляют инструменты для конвертации типов. И есть неплохая система кодогенерации, позволяющая сокращать количество пользовательского кода на порядок, чем популярные библиотеки (и упомянутый в статье Exonum) достаточно часто пользуются.
Обычно за несколько часов радикальных изменений курса не происходит. А вложить "все свои деньги" — всё-таки плохая идея даже с самыми надёжными и стабильными валютами.
Да ну, Вы прям скажете, "не взлетели"
Определённо это не проблема ICO, а проблема данной статьи ;-)
Это мало чем отличается от вложений в стартапы в сфере IT или венчурных инвестиций в целом, что не мешает им быть достаточно популярными, хоть и с высоким риском.
Eos и Tezos — платформы для универсальных смарт-контрактов, так же как и уже всем известный Ethereum.
"Криптовалютная" тема — сама по себе произвольная от темы автоматического и децентрализованного управления собственностью, так что тут всё наоборот.
Bancor — частный случай применения смарт-контрактов — протокол автоматического обмена этой самой собственностью с подстройкой стоимости в зависимости от спроса. В данном случае он "перпендикулярен" "криптовалютной" теме.
Применение децентрализованных систем управления правами, неподконтрольных государству, в любом случае предмет риска регуляции со стороны различных юрисдикций. Но в ряде уважаемых юрисдикций оно уже узаконено.
ICO, существующее в рамках этих систем очевидно подвергается всем их рискам. Однако, в случае, когда исходный код смарт-контрактов доступен к изучению, исходный код проектов и их концепция подробно описаны, разработчики обладают хорошей репутацией и успешно запускали перед этим другие проекты — объявлять все ICO под одну гребёнку "похожими на развод" — так же странно, как объявлять разводом государства только потому, что некоторые из них заканчивали своё существование включённым на полную мощность печатным станком, рекордами гиперинфляции и коллапсом экономики. ICO в этом плане куда более прозрачная и понятная штука, чем среднестатистическое государство на нашей планете.
Позже возникнут конфликты разнообразного оборудования и прошивок.
Кроме того тут ниже упоминают, что погодные условия тоже интересным образом влияют на качество функционирования и в этом вопросе у наземных каналов имеется традиционное преимущество.
Всё это неизбежно и старо — единственное, что здесь не так, это попытка продать радиоканал вместо наземного как нечто уникальное. Да, мобильность это неплохо и имеет свои достоинства, так что рынок несколько перераспределиться со временем в пользу мобильного интернета, но это произойдёт независимо от конкретной компании и её брендированной технологии — это объективный и уже давно идущий процесс.
Firefox → Firefox Quantum — уже в бете.
Для этого придумали виртуалки )
Сам язык с пользовательской точки зрения — вряд ли сложнее.
А сравнивать сложность "договориться со строгим компилятором" и "договориться с отладикой, тестированием и фазой луны" — достаточно тяжело сравнивать.
Прошу прощения, изначально я "промахнулся" с контекстом и поспешил ответить ))
Как выше написали, буквально
str— это тип. Тип, который невозможно (безunsafe) получить с "неправильными" данными. Но сами данные — в этом случае придётся держать за указателем — либо с контролируемым временем жизни за ссылкой&str, либо за владеющей ссылкойBox<str>,Rc<str>etc, либо за сырым указателем*const/mut str.str— тип неизвестного на этапе компиляции размера, поэтому простого способа использовать его как обычную переменную, лежащую на стеке, нет (да и нужно ли?).Если у нас есть нечто типа
str, значит под капотом — набор байт, являющийся корректной utf-8 строкой. И с этим типом ассоциирован ряд функций, которые умеют с этим utf-8 корректно работать.Rust позволяет программисту с помощью типов выразить некоторую логику состояния, описать логику переходов между состояниями и дать определённые гарантии в связи со всем этим. Тут была неплохая статья на тему конечных автоматов, которая раскрывает идеи такого подхода.
Если типы не прошли проверку — это не скомпилируется, а функции, принимающие на вход другой тип — не будут работать не со своими данными, что снимает ряд недоразумений и позволяет большой ряд ошибок ловить на этапе компиляции и не путать тёплое с быстрым.
Если же мы займёмся произвольным приведением указателей — плакали наши гарантии, пользы от Rust будет сильно меньше, чем от C (учитывая его полувековую историю). Но Rust как и C не запрещает работать с указателями, в некоторых ситуациях это неизбежно (это и фундамент низкоуровневых библиотек, и всевозможный FFI). Всё, что для этого требуется — чётко обозначенное условие потери гарантий (или точнее — взятие на себя ответственности) —
unsafe.удалено
Как бы это ни было смешно, но буквально "из коробки", как и всё, что на crates.io :-)
Что лишний раз подтверждает, что статья, хоть и с картинками и благими намерениями, но в общем — так себе статья.
Раздел про монады — это ж самые, что ни на есть, паттерны. Далеко не все, конечно, статья бедновата даже по меркам введения.
Получится. Для этого необходима поддержка технологии на государственном уровне.
Например, в Украине ведётся соответствующая разработка электронной гривны
Майнинг — это не эмиссия.
Майнинг — это внесение новых записей в распределённый реестр.
В случае биткойна и ряда его клонов на начальном этапе с малым движением в сети он вознаграждается эмиссией, поэтапно вознаграждение переносится на комиссию.
Майнинг с точки зрения криптовалюты — это такая же материальная услуга, как и обычный денежный перевод в каком-нибудь банке или условном "вестернюнионе". Но в дополнение к этому — он быстрее, дешевле, надёжней, гибче и фактически независим. Не будут нужны дешёвые и быстрые международные переводы, не будет нужен и майнинг, не будут нужны и различные "койны".
Но пока что мы наблюдаем обратное и причин, по которым основные койны могли бы "исчезнуть" — не просматривается.
За саму возможность майнить "драка" идёт, оборудование раскупают "с колёс" опоздавшие, а умные — сразу с завода, какое же тут "исчезнуть"? Место исчезнувшего с удовольствием занимают оставшиеся и новоприбывшие — сложность сети подстраивается под количество участников — если кто-то выбывает из игры по причине нерентабельности, сложность падает и для оставшихся — рентабельность растёт.
Добавьте к этому, что ряд уважаемых юрисдикций уже легализовали блокчейн либо как платёжное средство, либо как иные виды активов, при этом местами — даже освободив от налогов, а значительная часть уважаемых юрисдикций — не считают необходимым вмешиваться.
Конечно, где-то и запрещают, примеры есть, так же как где-то и интернет запрещают. Но какое дело локомотиву прогресса до тех, кто остался на обочине? Процесс уже необратим, блокчейн как платформа обладает высокой ценностью за счёт своих свойств, а теперь уже и благодаря сетевым эффектам планетарного масштаба.