Мало кто учил тот же Си, начав с Ассемблера, чтобы потоптаться по граблям Ассемблера, и понять, ради чего это всё. Проблема в том, что у опытного программиста возникают вопросы к выразительности Rust. Точно так же, как у программистов на Ассесблере возникли вопросы к Си. А новичок воспримет это всё как данность.
До Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.
Модель памяти Linux описана в терминах работы железа. Не очень понятно, что именно в этом описании "странно".
Ну, и, наконец, рендеринг шрифтов 144 раза в секунду на OpenGL от языка не зависит: шейдеры будут с одинаковой сокростью работать. От языка зависит сложность составлерия и загрузки этих шейдеров. Но, вроде, на Python это не сложно сделать. Не уверен, что сложнее, чем в Rust.
Ваша реплика читается так: если человек не способен учиться на своих ошибках (иначе, откуда многочисленные самострелы?), то Rust легко попадёт ему в подсознание. Странное утверждение, мне кажется.
Мне кажется, наоборот, Rust надо учить одним из первых языков, пока человек не освоил алгоритмы. Иначе Rust вызывает недоумение, потому что не позволяет писать привычные алгоритмы без unsafe. Это лично для меня источник постоянного дискофорта. Никак не привыкну к идее, что простейшая биномиальная куча - это небезопасная структура данных.
Раз уж говорим об RK3588, нужно добавить Mekotronics R58 и R58X. По тестам в интернетах - отличные железяки. Ну, и Radxa ROCK 5b когда-нибудь выйдет. RK3588, похоже, весьма удачный чип, вполне может заменять офисные ПК.
Хотел бы ещё высказаться о Pine64. Неудачные у них платы, аппаратных багов много. Я б не посоветовал.
Не, его часто вспоминают словами о том, какое же это Го..., а вот Rust - золото. Совершенно, кстати, не понятно, чего Rust-овцы недолюбливают так сильно именно Go. Типа, одна из граней противостояния Google и Mozilla, начавшегося с браузеров?
Что все люди разные. И у всех разные подходы к решению задач, и это нормально. Но вот почему-то type-driven сообщество этого не признаёт этого, и пытается всем доказать, что есть только единственно верный путь в программировании.
Это ошибки, которые были обнаружены в последующих коммитах
В смысле? Исследователи брали код в версии до правки бага, переписывали его на TS и Flow, и смотрели, вылезет ли ошибка компиляции. То есть, баг был обнаружен и исправлен.
Так если это важно, тогда какие вообще вопросы? Кто-то получает удовольствие от Си, кто-то - от Раста, кто-то - от Лиспа, кто-то - от Го. Вопрос закрыт простым ответом: что вам нравится, то и используйте. Нет?
Не факт. Вы не учитываете усложнение алгоритма вывода типов. БОльшая часть правил вывода в том же Haskell, процентов 90, - она про ограничения и generic-и (конструкторы типов) как раз. А работает проверка и вывод типов всегда. И там сложность, минимум, квадратичная.
А какие ограничения решение должно учитывать? Самое простое - сделать две разные реализации интрфейса "под задачи", а чтобы не писать каждый раз длинные if-then-else в реализациях Less для сравнений по ключам сделать функцию-композиции сравнений.
На многих sbc на основе RK35xx разведён M.2. Цена около $100. Вряд ли Broadcom будет продавать значительно дороже.
Мало кто учил тот же Си, начав с Ассемблера, чтобы потоптаться по граблям Ассемблера, и понять, ради чего это всё. Проблема в том, что у опытного программиста возникают вопросы к выразительности Rust. Точно так же, как у программистов на Ассесблере возникли вопросы к Си. А новичок воспримет это всё как данность.
То есть, если unsafe спрятать внутрь, то как бы и не считается?
Не знаю ??♂️: внутри у неё unsafe.
В той реализации, которую я знаю, использован
replaceДо Rust были языки, спроектированные "по науке". Поэтому высказывание "наконец-то" выглядит странным. Примеры: Haskell, ML, Scheme, Oberon, Algol и так далее.
Модель памяти Linux описана в терминах работы железа. Не очень понятно, что именно в этом описании "странно".
Ну, и, наконец, рендеринг шрифтов 144 раза в секунду на OpenGL от языка не зависит: шейдеры будут с одинаковой сокростью работать. От языка зависит сложность составлерия и загрузки этих шейдеров. Но, вроде, на Python это не сложно сделать. Не уверен, что сложнее, чем в Rust.
Ваша реплика читается так: если человек не способен учиться на своих ошибках (иначе, откуда многочисленные самострелы?), то Rust легко попадёт ему в подсознание. Странное утверждение, мне кажется.
Мне кажется, наоборот, Rust надо учить одним из первых языков, пока человек не освоил алгоритмы. Иначе Rust вызывает недоумение, потому что не позволяет писать привычные алгоритмы без unsafe. Это лично для меня источник постоянного дискофорта. Никак не привыкну к идее, что простейшая биномиальная куча - это небезопасная структура данных.
А в чём проблема? Armbian, вроде как, поддерживает всё это
Раз уж говорим об RK3588, нужно добавить Mekotronics R58 и R58X. По тестам в интернетах - отличные железяки. Ну, и Radxa ROCK 5b когда-нибудь выйдет. RK3588, похоже, весьма удачный чип, вполне может заменять офисные ПК.
Хотел бы ещё высказаться о Pine64. Неудачные у них платы, аппаратных багов много. Я б не посоветовал.
Некоторые в некоторых ревизиях имеют, надо внимательно смотреть спецификации. Там обычно делают отдельный разъём для подключения батарейки.
Мы обсуждаем конкретное исследование. Там был использован такой метод анализа эффективности типизации.
Так я же про упоминание Go в тех каналах, которые я читаю.
Так явное указание требует вывода и проверки ограничений, всё равно.
Не, его часто вспоминают словами о том, какое же это Го..., а вот Rust - золото. Совершенно, кстати, не понятно, чего Rust-овцы недолюбливают так сильно именно Go. Типа, одна из граней противостояния Google и Mozilla, начавшегося с браузеров?
Так необходимо вывести instance.
Что все люди разные. И у всех разные подходы к решению задач, и это нормально. Но вот почему-то type-driven сообщество этого не признаёт этого, и пытается всем доказать, что есть только единственно верный путь в программировании.
В смысле? Исследователи брали код в версии до правки бага, переписывали его на TS и Flow, и смотрели, вылезет ли ошибка компиляции. То есть, баг был обнаружен и исправлен.
Ну... Социальные пузыри у всех разные. К сожалению. Я живу в каналах дизайна ЯП и компиляторов. А что, в Вашем пузыре реально пиарят Go изо всех сил?
Так если это важно, тогда какие вообще вопросы? Кто-то получает удовольствие от Си, кто-то - от Раста, кто-то - от Лиспа, кто-то - от Го. Вопрос закрыт простым ответом: что вам нравится, то и используйте. Нет?
Не факт. Вы не учитываете усложнение алгоритма вывода типов. БОльшая часть правил вывода в том же Haskell, процентов 90, - она про ограничения и generic-и (конструкторы типов) как раз. А работает проверка и вывод типов всегда. И там сложность, минимум, квадратичная.
А какие ограничения решение должно учитывать? Самое простое - сделать две разные реализации интрфейса "под задачи", а чтобы не писать каждый раз длинные if-then-else в реализациях Less для сравнений по ключам сделать функцию-композиции сравнений.