Майнинг — это не эмиссия.
Майнинг — это внесение новых записей в распределённый реестр.
В случае биткойна и ряда его клонов на начальном этапе с малым движением в сети он вознаграждается эмиссией, поэтапно вознаграждение переносится на комиссию.
Майнинг с точки зрения криптовалюты — это такая же материальная услуга, как и обычный денежный перевод в каком-нибудь банке или условном "вестернюнионе". Но в дополнение к этому — он быстрее, дешевле, надёжней, гибче и фактически независим. Не будут нужны дешёвые и быстрые международные переводы, не будет нужен и майнинг, не будут нужны и различные "койны".
Но пока что мы наблюдаем обратное и причин, по которым основные койны могли бы "исчезнуть" — не просматривается.
За саму возможность майнить "драка" идёт, оборудование раскупают "с колёс" опоздавшие, а умные — сразу с завода, какое же тут "исчезнуть"? Место исчезнувшего с удовольствием занимают оставшиеся и новоприбывшие — сложность сети подстраивается под количество участников — если кто-то выбывает из игры по причине нерентабельности, сложность падает и для оставшихся — рентабельность растёт.
Добавьте к этому, что ряд уважаемых юрисдикций уже легализовали блокчейн либо как платёжное средство, либо как иные виды активов, при этом местами — даже освободив от налогов, а значительная часть уважаемых юрисдикций — не считают необходимым вмешиваться.
Конечно, где-то и запрещают, примеры есть, так же как где-то и интернет запрещают. Но какое дело локомотиву прогресса до тех, кто остался на обочине? Процесс уже необратим, блокчейн как платформа обладает высокой ценностью за счёт своих свойств, а теперь уже и благодаря сетевым эффектам планетарного масштаба.
До хорошего состояния Windows тоже ещё нужно довести.
Просто ваш опыт с Windows (сколько лет вы с ним живёте?) позволяет Вам чувствовать себя в нём комфортно — все привычные инструменты уже изучены, установлены и под рукой.
С Linux всё точно так же — за годы он изучается вдоль и впоперек, нужные инструменты находятся и устанавливаются, выкапываются все нужные настройки.
Linux радует ещё тем, что не препятствует изучать и настраивать себя.
Но с другой стороны не радуют некоторые разработчики ПО, которые избегают поддержки линукса на десктопе.
P.S. Вы точно уверены, что дяди из Microsoft сделали именно "халяву"? :-)
На самом деле уточню, что для ошибок в случае try! / ? — вызов .into() происходит «под капотом», что сильно упрощает жизнь, да и в целом, макросы немного нивелируют принцип явности.
Да, и чем дальше в лес, чем крупнее проект, тем это качество всё важнее.
При этом попутно происходит ещё и обучение — почему так или иначе делать нельзя или просто плохо в других языках, у которых нет такого строгого контроля.
А с опытом эта «борьба» с компилятором проходит, начинаешь чётко представлять как всё будет работать, и эти ошибки из-за непонимания перестают отнимать время.
Кстати, очень рекомендовал бы сразу изучить вдоль и впоперек стандартную библиотеку — она минималистична и это не отнимет много времени, зато многие "тупиковые" вопросы, когда непонятно что делать, будут сняты.
Rust — это не тот язык, который запрещает стрелять себе в ногу.
Rust — это тот язык, который даёт инструменты, позволяющие не стрелять (в дополенние к имеющимся в других языках).
Использовать их или нет — это отдельный вопрос, не сводящийся к одному только желанию.
Очевидно, что они в определённых случаях сложнее в использовании и имеют естественные ограничения, происходящие из их природы. Поэтому они — не серебряная пуля.
В Rust — тоже есть инструменты с run-time проверками и прочие источники неожиданностей, к которым нужно относиться соответствующим образом.
«Может ли быть удалена кнопка», которая «сейчас рассылает» (длительный процесс?) и «случайно» ли это произойдёт — это вопрос архитектуры системы. Вопрос в том, чего хочет её разработчик: иметь возможность удалить в произвольный момент времени или держать до последнего, заблокировав обновление интерфейса для других частей системы, пока кто-то ждёт ответа по сети или работает с диском.
из типизированного массива, а он о строках ничего не знает.
Вы хотите сказать, что проблему создаст сам JS, выполняя некоторую бессмысленную работу? Тогда согласен, тут всё будет сложнее, нужно подробней изучать, как всё устроено, в том числе как получается этот типизированный массив и обртно строки из него.
Со стороны Rust подобных проблем не будет, поскольку он может прозрачно "трансмутировать" тип значений в массиве.
Но вообще, линейная трансформация строки, имхо, менее затратная операция, чем масса аллокаций в процессе обработки шаблона. Но тут уже решающее слово за бенчмарками.
Строка в представлении JS — и есть массив значений. Технически какой-нибудь аналог Vec<u16> или Vec<Utf16Char>. Преобразования не требуется, (разве что чисто номинальное, чтобы получить в Rust необходимый тип), данные уже являются набором байт (как и вообще всё в памяти машины).
Операции элементарные, но дорогостоящие, особенно склейка
В том и суть, что Rust позволяет делать склейку дёшево — в едином буфере, что многократ эффективней, чем создание множества промежуточных строк, как это делается в JS. Точно так же Rust может склеивать и байты и массивы произвольных типов, "наливая" их последовательно сразу в конечный массив. В результате на выходе мы имеем уже готовую строку, которую только и остаётся передать в JS.
Именно поэтому я и предположил, что вынесение в Rust задачи шаблонизации, позволит достичь существенной экономии. Всё-таки этот язык создавался в том числе и для скорости, что достигается за счёт низкоуровневых операций, обычно недоступных в высокоуровневых языках.
Да, я про само представление строк в JS не подумал, там таки UTF-16.
Ну, никто не заставляет преобразовывать их в utf-8. Если у нас на входе будут корректные массивы байт с UTF-16 строками в шаблонах и значениях, то они же будут и на выходе. Хотя соответствующие примитивы для парсинга шаблонов в Rust придётся "завелосипедить".
прийдется каждый символ строки превращать в число, потом передавать в васм и там с ним работать и потом возвращать обратно и снова превращать в символ и клеить из этого набора символов большую строку
Не совсем понимаю суть операции. Строки в Rust — это массивы байт, которым гарантируется, что они являются корректным utf-8. Их не требуется дополнительно преобразовывать в "символы".
Кроме того, сами шаблоны вполне могут работать в режиме байтовых массивов, им не требуется быть полноценной строкой.
В целом — я согласен, что WAsm достаточно близок к asm.js. Тут не о чем особо спорить: первый — развитие идеи второго и логическое его завершение. Просто не могли в конечном итоге не придти к представлению в виде байткода, поскольку это самое удобное и компактное представление, уже подвергнутое предварительной оптимизации, и не могли не сделать его максимально близким к низкоуровневой платформе.
Тогда, возможно, мы просто говорили о разных вещах, ок.
JS не позволяет избежать динамичности в силу того, что у него просто нет соответствующих инструментов. И JIT, каким бы он ни был умным, не сможет из ничего сделать статическую проверку и оптимизацию. Речь ведь не только про конкретные типы переменных, речь про сам алгоритм.
В Rust мы можем выполнить проверку варианта с перечислением через match — компилятор будет точно знать, что значение не может содержать ничего лишнего, "проверка" сведётся лишь к проверке значения дискриминанта и в соответствии с этим значением будет выбрана конкретная ветвь. Компилятор может статически проанализировать ход исполнения и убедиться, что какие-то ветви вообще не будут задействованы и просто исключить их. Компилятор может заранее вычислить все статические преобразования и убрать их из кода, заменив на вычисленные значения. Таким же способом он может вооще исключить вызовы функций, либо заинлайнив их код, либо в процессе упрощения выражений вообще сократив, как ненужные (что проблема для JS, который должен свериться с виртуальными таблицами методов у объектов). Много таких оптимизаций, которые возможны благодаря заранее и однозначно размеченному коду. Сюда же свобода от сборщика мусора — память управляется однозначно и предсказуемо, а большое количество типов не требуют отдельного выделения памяти в куче.
Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя. Сам же JIT — тоже требует времени на компиляцию, которая в случае компилируемых языков происходит заранее. Причём оптимизация может занимать времени в разы больше, чем сама компиляция (в случае с Rust это легко может достигать показателя "на порядок дольше") — в каком-то смысле это роскошь для JIT, хотя у него есть и свои, недоступные обычным компиляторам возможности.
Asm.js я здесь не рассматриваю, поскольку не знаю случаев, чтобы он напрямую использовался в разработке, а не как цель компиляции из других языков. Возможно, где-то, в особых случаях такое происходит, но это всё-таки скорее исключения, чем норма, и было бы интересно услышать опыт тех, кто этим занимался.
code/decode между строками и буфером будет довольно дорогим
Почему? Что сделает его дорогим? Строка по сути и есть буфер. В любом случае одно преобразование — это значительно дешевле, чем масса промежуточных аллокаций на каждый объект JS. Тут уже нужно закапываться в устройство React и детально изучать возможности, поскольку сложно что-то утверждать на основе догадок и предположений. Посмотрим, если у "энтузиастов" получится то, что они задумали — это будет хорошим знаком и примером, который будет стоить изучить всем. Хотя они вполне могли и ошибиться, неверно оценив задачу.
от dll никуда не убежишь нельзя же все монолитом собирать
Тут немного не то. Сами библиотеки могут подключаться динамически, но таки их интерфейс быть статическим, соответственно код остаётся статически анализируемым и оптимизируемым.
Но динамическое связывание вполне может быть и в монолитном бинарнике. Всё, что ведёт к определению типа в рантайме, проверкам в рантайме — всё это бьёт по производительности и надёжности.
WAsm позволяет избежать именно этого вида динамичности и достигнуть пределов возможного — полной отдачи от процессора. Но это не означает, что саму динамичность он исключает, нет — он даёт выбор, который был крайне беден в JS и появилось хоть что-то с asm.js.
Эволюция самого JS — тоже достаточно радующий факт. Возможно через несколько лет мы получим стандарт достаточно продуктивного языка. Но наследие со всеми странностями, нелогичностями и проблемами — ещё долго будет тянуться. Хотя, какой-нибудь очередной strict mode и транспилеры могут решить эту проблему.
более крутом динамическом связывании через таблицы
Опять же, динамическое связывание — это противоположность того, что необходимо для достижения высокой производительности. Но эта тема уже выходит за пределы парадигмы языка, созданного быть динамическим, так что требовать от JS прыгнуть выше головы — нет смысла.
Поэтому, собственно, и появился WAsm, — для заполнения этой лакуны, способный генерировать код близкий по производительности к нативному, в том числе благодаря возможности статически всё прописать и оптимизировать.
Я, конечно, не исключаю, что оптимизатор JS может проанализировать код и убедиться, что тип не должен поменяться — в такой ситуации можно выбросить проверку и это как раз хорошо скажется на производительности. В конце концов, за счёт чего-то таки потрясающих результатов таки добиваются.
Майнинг — это не эмиссия.
Майнинг — это внесение новых записей в распределённый реестр.
В случае биткойна и ряда его клонов на начальном этапе с малым движением в сети он вознаграждается эмиссией, поэтапно вознаграждение переносится на комиссию.
Майнинг с точки зрения криптовалюты — это такая же материальная услуга, как и обычный денежный перевод в каком-нибудь банке или условном "вестернюнионе". Но в дополнение к этому — он быстрее, дешевле, надёжней, гибче и фактически независим. Не будут нужны дешёвые и быстрые международные переводы, не будет нужен и майнинг, не будут нужны и различные "койны".
Но пока что мы наблюдаем обратное и причин, по которым основные койны могли бы "исчезнуть" — не просматривается.
За саму возможность майнить "драка" идёт, оборудование раскупают "с колёс" опоздавшие, а умные — сразу с завода, какое же тут "исчезнуть"? Место исчезнувшего с удовольствием занимают оставшиеся и новоприбывшие — сложность сети подстраивается под количество участников — если кто-то выбывает из игры по причине нерентабельности, сложность падает и для оставшихся — рентабельность растёт.
Добавьте к этому, что ряд уважаемых юрисдикций уже легализовали блокчейн либо как платёжное средство, либо как иные виды активов, при этом местами — даже освободив от налогов, а значительная часть уважаемых юрисдикций — не считают необходимым вмешиваться.
Конечно, где-то и запрещают, примеры есть, так же как где-то и интернет запрещают. Но какое дело локомотиву прогресса до тех, кто остался на обочине? Процесс уже необратим, блокчейн как платформа обладает высокой ценностью за счёт своих свойств, а теперь уже и благодаря сетевым эффектам планетарного масштаба.
До хорошего состояния Windows тоже ещё нужно довести.
Просто ваш опыт с Windows (сколько лет вы с ним живёте?) позволяет Вам чувствовать себя в нём комфортно — все привычные инструменты уже изучены, установлены и под рукой.
С Linux всё точно так же — за годы он изучается вдоль и впоперек, нужные инструменты находятся и устанавливаются, выкапываются все нужные настройки.
Linux радует ещё тем, что не препятствует изучать и настраивать себя.
Но с другой стороны не радуют некоторые разработчики ПО, которые избегают поддержки линукса на десктопе.
P.S. Вы точно уверены, что дяди из Microsoft сделали именно "халяву"? :-)
На самом деле уточню, что для ошибок в случае
try!/?— вызов .into() происходит «под капотом», что сильно упрощает жизнь, да и в целом, макросы немного нивелируют принцип явности.Да, и
чем дальше в лес,чем крупнее проект, тем это качество всё важнее.При этом попутно происходит ещё и обучение — почему так или иначе делать нельзя или просто плохо в других языках, у которых нет такого строгого контроля.
А с опытом эта «борьба» с компилятором проходит, начинаешь чётко представлять как всё будет работать, и эти ошибки из-за непонимания перестают отнимать время.
Кстати, очень рекомендовал бы сразу изучить вдоль и впоперек стандартную библиотеку — она минималистична и это не отнимет много времени, зато многие "тупиковые" вопросы, когда непонятно что делать, будут сняты.
Именно поэтому нет смысла закрывать квартиру/автомобиль/сейф на замок и все именно так и поступают, оставляя двери открытыми? :-)
Rust — это не тот язык, который запрещает стрелять себе в ногу.
Rust — это тот язык, который даёт инструменты, позволяющие не стрелять (в дополенние к имеющимся в других языках).
Использовать их или нет — это отдельный вопрос, не сводящийся к одному только желанию.
Очевидно, что они в определённых случаях сложнее в использовании и имеют естественные ограничения, происходящие из их природы. Поэтому они — не серебряная пуля.
В Rust — тоже есть инструменты с run-time проверками и прочие источники неожиданностей, к которым нужно относиться соответствующим образом.
«Может ли быть удалена кнопка», которая «сейчас рассылает» (длительный процесс?) и «случайно» ли это произойдёт — это вопрос архитектуры системы. Вопрос в том, чего хочет её разработчик: иметь возможность удалить в произвольный момент времени или держать до последнего, заблокировав обновление интерфейса для других частей системы, пока кто-то ждёт ответа по сети или работает с диском.
Но эта тема пока открыта и ждёт своих героев :-)
Что ж, надеюсь под давлением насущной потребности это случится достаточно быстро.
Вы хотите сказать, что проблему создаст сам JS, выполняя некоторую бессмысленную работу? Тогда согласен, тут всё будет сложнее, нужно подробней изучать, как всё устроено, в том числе как получается этот типизированный массив и обртно строки из него.
Со стороны Rust подобных проблем не будет, поскольку он может прозрачно "трансмутировать" тип значений в массиве.
Но вообще, линейная трансформация строки, имхо, менее затратная операция, чем масса аллокаций в процессе обработки шаблона. Но тут уже решающее слово за бенчмарками.
Строка в представлении JS — и есть массив значений. Технически какой-нибудь аналог
Vec<u16>илиVec<Utf16Char>. Преобразования не требуется, (разве что чисто номинальное, чтобы получить в Rust необходимый тип), данные уже являются набором байт (как и вообще всё в памяти машины).В том и суть, что Rust позволяет делать склейку дёшево — в едином буфере, что многократ эффективней, чем создание множества промежуточных строк, как это делается в JS. Точно так же Rust может склеивать и байты и массивы произвольных типов, "наливая" их последовательно сразу в конечный массив. В результате на выходе мы имеем уже готовую строку, которую только и остаётся передать в JS.
Именно поэтому я и предположил, что вынесение в Rust задачи шаблонизации, позволит достичь существенной экономии. Всё-таки этот язык создавался в том числе и для скорости, что достигается за счёт низкоуровневых операций, обычно недоступных в высокоуровневых языках.
А может даже и велосипедить не придётся, всё-таки Rust создавался с мыслью о создании браузера.
Да, я про само представление строк в JS не подумал, там таки UTF-16.
Ну, никто не заставляет преобразовывать их в utf-8. Если у нас на входе будут корректные массивы байт с UTF-16 строками в шаблонах и значениях, то они же будут и на выходе. Хотя соответствующие примитивы для парсинга шаблонов в Rust придётся "завелосипедить".
Не совсем понимаю суть операции. Строки в Rust — это массивы байт, которым гарантируется, что они являются корректным utf-8. Их не требуется дополнительно преобразовывать в "символы".
Кроме того, сами шаблоны вполне могут работать в режиме байтовых массивов, им не требуется быть полноценной строкой.
В целом — я согласен, что WAsm достаточно близок к asm.js. Тут не о чем особо спорить: первый — развитие идеи второго и логическое его завершение. Просто не могли в конечном итоге не придти к представлению в виде байткода, поскольку это самое удобное и компактное представление, уже подвергнутое предварительной оптимизации, и не могли не сделать его максимально близким к низкоуровневой платформе.
Тогда, возможно, мы просто говорили о разных вещах, ок.
JS не позволяет избежать динамичности в силу того, что у него просто нет соответствующих инструментов. И JIT, каким бы он ни был умным, не сможет из ничего сделать статическую проверку и оптимизацию. Речь ведь не только про конкретные типы переменных, речь про сам алгоритм.
В Rust мы можем выполнить проверку варианта с перечислением через
match— компилятор будет точно знать, что значение не может содержать ничего лишнего, "проверка" сведётся лишь к проверке значения дискриминанта и в соответствии с этим значением будет выбрана конкретная ветвь. Компилятор может статически проанализировать ход исполнения и убедиться, что какие-то ветви вообще не будут задействованы и просто исключить их. Компилятор может заранее вычислить все статические преобразования и убрать их из кода, заменив на вычисленные значения. Таким же способом он может вооще исключить вызовы функций, либо заинлайнив их код, либо в процессе упрощения выражений вообще сократив, как ненужные (что проблема для JS, который должен свериться с виртуальными таблицами методов у объектов). Много таких оптимизаций, которые возможны благодаря заранее и однозначно размеченному коду. Сюда же свобода от сборщика мусора — память управляется однозначно и предсказуемо, а большое количество типов не требуют отдельного выделения памяти в куче.Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя. Сам же JIT — тоже требует времени на компиляцию, которая в случае компилируемых языков происходит заранее. Причём оптимизация может занимать времени в разы больше, чем сама компиляция (в случае с Rust это легко может достигать показателя "на порядок дольше") — в каком-то смысле это роскошь для JIT, хотя у него есть и свои, недоступные обычным компиляторам возможности.
Asm.js я здесь не рассматриваю, поскольку не знаю случаев, чтобы он напрямую использовался в разработке, а не как цель компиляции из других языков. Возможно, где-то, в особых случаях такое происходит, но это всё-таки скорее исключения, чем норма, и было бы интересно услышать опыт тех, кто этим занимался.
Почему? Что сделает его дорогим? Строка по сути и есть буфер. В любом случае одно преобразование — это значительно дешевле, чем масса промежуточных аллокаций на каждый объект JS. Тут уже нужно закапываться в устройство
Reactи детально изучать возможности, поскольку сложно что-то утверждать на основе догадок и предположений. Посмотрим, если у "энтузиастов" получится то, что они задумали — это будет хорошим знаком и примером, который будет стоить изучить всем. Хотя они вполне могли и ошибиться, неверно оценив задачу.Тут немного не то. Сами библиотеки могут подключаться динамически, но таки их интерфейс быть статическим, соответственно код остаётся статически анализируемым и оптимизируемым.
Но динамическое связывание вполне может быть и в монолитном бинарнике. Всё, что ведёт к определению типа в рантайме, проверкам в рантайме — всё это бьёт по производительности и надёжности.
WAsm позволяет избежать именно этого вида динамичности и достигнуть пределов возможного — полной отдачи от процессора. Но это не означает, что саму динамичность он исключает, нет — он даёт выбор, который был крайне беден в JS и появилось хоть что-то с asm.js.
Эволюция самого JS — тоже достаточно радующий факт. Возможно через несколько лет мы получим стандарт достаточно продуктивного языка. Но наследие со всеми странностями, нелогичностями и проблемами — ещё долго будет тянуться. Хотя, какой-нибудь очередной
strict modeи транспилеры могут решить эту проблему.Опять же, динамическое связывание — это противоположность того, что необходимо для достижения высокой производительности. Но эта тема уже выходит за пределы парадигмы языка, созданного быть динамическим, так что требовать от JS прыгнуть выше головы — нет смысла.
Поэтому, собственно, и появился WAsm, — для заполнения этой лакуны, способный генерировать код близкий по производительности к нативному, в том числе благодаря возможности статически всё прописать и оптимизировать.
А кто сказал, что оно одиночное? Если мы в цикле складываем элементы массива — ок, тут простая ситуация. Но обычно не это называют "математикой".
Я, конечно, не исключаю, что оптимизатор JS может проанализировать код и убедиться, что тип не должен поменяться — в такой ситуации можно выбросить проверку и это как раз хорошо скажется на производительности. В конце концов, за счёт чего-то таки потрясающих результатов таки добиваются.
"нет ветвлений" и "проверка" — это взаимоисключающие параграфы.