Достаточно упаковать хорошо и резиночки повесить, в обычных приставках нет частей подвижных или сложных соединений. Температурные тесты и вибрации для критически важных компонентов требования, ТВ приставки транспортом не управляют.
Это обычные дестопные варианты Ubuntu, именно Embedded Linux гораздо надежнее, он обычно запечен в NAND образ и не обновляется и не убивается так легко. Работает единственное приложение полноэкранное без десктопного окружения и сервисов лишних.
Там где видно бсод, стоимость пк не такая высокая по сравнению с другими компонентами. Есть место куда запихнуть 10килограмовый пк и нанять администратора. Линукс выгодно на дешевых клиентских устройствах.
Выглядят как типичный маркетинг, чеклисты сравнения зеленые у вашей библиотеки, у других красные. Где и на каких данных производились замеры, не указывается.
Компилятор превращает мультиметоды в match под капотом даже в эрланге.
Имя однозначно идентифицирует функцию и не создает неопределенностей для передачи в ffi и инференса. Итак тяжело лайфтаймы расставить правильно, а если добавить перегрузку, вообще труба.
На плюсах у меня бы ушел на это год.
Преувеличение, плюсы не такие дряхлые. Обладатель черного пояса по ООП напишет за неделю.
Мне хватило 8 часов с нуля, чтобы написать довольно работоспособную библиотеку
Компилятор хорошо отполировали и примеров много, раньше новичков borrow checker булил. Есть места, где не влазит задача в идеоматичный rust, но их крайне мало и самое стремное в готовые крэйты завернули. Если не делать zero-copy/state-of-art, то особо нет проблем с проектированием.
Мультиметоды нарушат статический диспатчинг, там и без них неразбериха с dyn/impl.
Ссылки
Мне нравится что явно отличается move и ref. Иначе, изменение сигнатуры изменит поведение в месте вызова. Btw, до 2013 в расте были зеленые треды и сборка мусора, никаких умных указателей xD
метапрограммирование накостылено сбоку (что является, конечно, следствием отсутствия прямого доступа к AST) Почему нельзя было сделать по-человечески? Что с unquote — тоже неясно
Свечку не ждержал, но явно что-то не так пошло. Изначальная идея у них была здравая, взять syntax-rules из языка Scheme и адаптировать под себя. Там есть гигиена, шаблоны и репорт ошибок. Делал библиотеку макросов bitstring, которая реализует Erlang Bit Syntax, возможности там космические. Когда пытался портировать на Rust, ничего не получилось.
Вторая опция - процедурные макросы, должно было быть похоже на Defmacro/syntax-case с трансформацией из кода во время сборки. Их выбрали как основной способ написания макросов сложных. Раньше ими невозможно было пользоваться, время сборки на 10 умножалось.
Тесты, Документация
Приемлемая реализация, в 2014 это выглядело очень круто, сразу проект с тестами идет и документацией. Ну и cargo, пакеты из коробки, а самое главное интегрируются без боли. Это можно и к минусам отнести, как в Питоне, только один способ - делать как у всех.
Филосовия языка - надежность и скорость(не разработки xD). Никогда разработчики не утвеждали, что нашли серебрянную пулю, так говорят фанатики и у людей завышенные ожидания. Сейчас из Rust модно переходить на Zig.
Еще не придумали как одноцветные функуции сделать. Кто не придумал? Что значит, «сделать»?
Имеется ввиду function coloring. Нельзя подключить библиотеку которую написали в синхронном стиле и наоборот. Есть даже отдельная реализация стандартной библиотеки async-std. В Erlang нет такого разделения, просто пишешь линейный код и не заморачиваешься.
её [обработку ошибок] прям со старта планировать надо. Кому надо? Зачем надо?
Ну как пользователь свои типы ошибок прокинет, если разрешается использовать только ActorError, то окай.
интересно посмотреть, как может развиваться remote_actor Куда развиваться? Зачем ему развиваться? Вспоминается КВН: «—Слышал, Бузова развелась? — А она что, развивалась?»
1. Transport Layer
2. Serialization
3. Node Discovery
4. Location Transparency
5. Fault Tolerance
6. Performance Optimizations
Этож эпичекий обьем работы, целая экосистема, а не простой crate.
Не жалко занять всю имеющуюся память интерпретатором
Еще один миф, интерпретатор копактнее нативного кода. Есть техника token threading или еще "p-code" называется. Инструкции могут 4 бита занимать, вызов функции 8 или 12 бит. Нативный вызов минимум 8 на иснтрукцию + 8 адрес.
Итак, я написал библиотеку, которая позволит эрлангистам проще вкатываться в раст.
Так оно не страшно, самое неудобное это async. Обмазывать код Send/arc. Когда лайфтам инференсом не выводит - боль. Ну и библиотеки внешние должны быть с поддержкой async. Еще не придумали как одноцветные функуции сделать . Обработка ошибок отдельная тема, её прям со старта планировать надо.
Акторная модель притворяется краденой из эрланга, с примитивами GenServer и GenStatem, с деревьями супервизоров
Насколько понимаю, отбрабатывать panic/unwrap сейчас невозможно и сервер схлопывается. Интересно посмотреть, как может развиваться remote_actor. Rust/tokio склоняют делать один большой монолит.
Без технических подробностей скучно читать, нет драмы, не ясны даже причины текущих проблем.
Если честно, каждый раз жду что напишут:
№1 Неустойчивость фронт-систем при падениях бэка. №2 Бизнес-логика на стороне ядра системы, где у нас должна быть главная книга, должны быть проводки, но не бизнес-операция.
Мы переходим на Clojure/Datamic, чтобы избаваиться от проблемы масштабирования и размазывания логики.
№3 Дублирование бизнес-логики на стороне фронтов.
Переделываем часть фронта на ClojureScript для устранения дублирования.
И потом битва в коментах, что надо было Флютер Жава-Скала шардинг-посгресс-кликхаусс
Стэйблкоин это же доллар, его стоитмость не меняется. Меняется курс обмена в местную валюту и его устанавливает банк. Хотелось бы узнать, как на это повлиять, когда ставят не самый выгодный курс.
Токенизация делает возможным следующее: Глобальную торгуемость и ликвидность
Вроде, даже в TON, биржи это островки децентрализованные, с собственной ликвидностью. Глобально и без посредников - все договоряться использовать единый протокол и сеть? Это ведь означает равные права для всех участников в любой точке мира.
Это для энтерпрайз архитекторов, которые много делегируют и оторваны от реальности. В небольших компаниях совсем другие проблемы, там проектирование в условиях ограниченых ресурсов.
На таких встречах тайно договариваются, как сделать чтобы язык был максимально сложным. В стандарте С++36, добавят обязательное чтение мантры для успещного запуска программы, чтобы LLM не смогла писать код вместо человека. Смыслом жизни станет изучение и трактовка стандартов. Подготовку специалистов перенесут в закрытые монастыри.
Не понятно как работает матчинг, больше похоже на поиск кружка по интересам, а не деловых партнеров. Например, часто встречается ситуация, когда небольшой инвестор не может найти грамотных исполнителей и наоборот. Пересечение обших интересов у них очень небольшое.
жить в месте, и среди людей, с которыми не надо закрывать ни квартиру ни машину
Спорно по определению, если вы обладаете ресурсами, кто-то непременно захочет их перераспределить. Это может быть даже член семьи, а не посторонний человек.
Знаю только несколько примеров, где что-то подобное существует, они связаны с общинным укладом жизни аборигенов.
Удивительно, как вы делаете такие глубокие выводы, не обладая практическим опытом. Когда накапливается достаточно знаний и создаются инструменты, мы переходим на новый уровень абстракции. Больше не требуется писать ОС, прежде чем начать решать проблемы клиента. В современной разработке, более 60% проектов это однотипные решения, шаблоны и рутина. Лидеры отрасли и другие умные дяди, придумывают как сделать архитектуру, какие паттерны использовать. Фактически, кодеры уже операторы системы, дорогие и малоэффективные.
Сейчас мы накопили достаточно опыта, но инструменты очень примитивные. Должны появиться языки программирования LLM или более удобные способы задания промптинга. В этот момент переход завершиться, программирование в текущем виде, будет похоже на использование ассемблера. Потребуется решать задачи более высокого уровня.
LLM не обучают логическому мышлению, а только правдоподобной симуляции логического мышления.
Ну вот есть система Boolean satisfiability problem и есть правила, как конвертировать сложную логическую задачу к простым операциям над битами. Доказали что это NP-complete, т.е совершенно не гарантируется, что есть решение и вычисления не займут вечность. Теоретически, ничего не мешает LLM формировать запросы к такому движку, не обладая истиным логическим мышление. Это даже будет плюсом, можно будет остановить зависшее логическое вычисление и переформулировать вопрос или условия.
Достаточно упаковать хорошо и резиночки повесить, в обычных приставках нет частей подвижных или сложных соединений. Температурные тесты и вибрации для критически важных компонентов требования, ТВ приставки транспортом не управляют.
Это обычные дестопные варианты Ubuntu, именно Embedded Linux гораздо надежнее, он обычно запечен в NAND образ и не обновляется и не убивается так легко. Работает единственное приложение полноэкранное без десктопного окружения и сервисов лишних.
Там где видно бсод, стоимость пк не такая высокая по сравнению с другими компонентами. Есть место куда запихнуть 10килограмовый пк и нанять администратора. Линукс выгодно на дешевых клиентских устройствах.
Выглядят как типичный маркетинг, чеклисты сравнения зеленые у вашей библиотеки, у других красные. Где и на каких данных производились замеры, не указывается.
В сравнении нет примеров, какие данные упаковывались и какой бинарь получился.
Маленькие числа упаковывает в 1 байт. Поддержка bigint заявлена с 2021 года.
Добавьте web-playgorund, будет убедительнее тысячи скриншотов.
Имя однозначно идентифицирует функцию и не создает неопределенностей для передачи в ffi и инференса. Итак тяжело лайфтаймы расставить правильно, а если добавить перегрузку, вообще труба.
Преувеличение, плюсы не такие дряхлые. Обладатель черного пояса по ООП напишет за неделю.
Компилятор хорошо отполировали и примеров много, раньше новичков borrow checker булил. Есть места, где не влазит задача в идеоматичный rust, но их крайне мало и самое стремное в готовые крэйты завернули. Если не делать zero-copy/state-of-art, то особо нет проблем с проектированием.
Мультиметоды нарушат статический диспатчинг, там и без них неразбериха с dyn/impl.
Мне нравится что явно отличается move и ref. Иначе, изменение сигнатуры изменит поведение в месте вызова. Btw, до 2013 в расте были зеленые треды и сборка мусора, никаких умных указателей xD
Свечку не ждержал, но явно что-то не так пошло.
Изначальная идея у них была здравая, взять syntax-rules из языка Scheme и адаптировать под себя. Там есть гигиена, шаблоны и репорт ошибок. Делал библиотеку макросов bitstring, которая реализует Erlang Bit Syntax, возможности там космические. Когда пытался портировать на Rust, ничего не получилось.
Вторая опция - процедурные макросы, должно было быть похоже на Defmacro/syntax-case с трансформацией из кода во время сборки. Их выбрали как основной способ написания макросов сложных. Раньше ими невозможно было пользоваться, время сборки на 10 умножалось.
Приемлемая реализация, в 2014 это выглядело очень круто, сразу проект с тестами идет и документацией. Ну и cargo, пакеты из коробки, а самое главное интегрируются без боли. Это можно и к минусам отнести, как в Питоне, только один способ - делать как у всех.
Филосовия языка - надежность и скорость(не разработки xD). Никогда разработчики не утвеждали, что нашли серебрянную пулю, так говорят фанатики и у людей завышенные ожидания. Сейчас из Rust модно переходить на Zig.
:thumbup:
У меня устарешвая информация, catch_unwind уже стабилизировали. Cloudflare почему-то свои unwrap не ловят , наверное тоже не знают.
Имеется ввиду function coloring. Нельзя подключить библиотеку которую написали в синхронном стиле и наоборот. Есть даже отдельная реализация стандартной библиотеки async-std. В Erlang нет такого разделения, просто пишешь линейный код и не заморачиваешься.
Ну как пользователь свои типы ошибок прокинет, если разрешается использовать только ActorError, то окай.
1. Transport Layer
2. Serialization
3. Node Discovery
4. Location Transparency
5. Fault Tolerance
6. Performance Optimizations
Этож эпичекий обьем работы, целая экосистема, а не простой crate.
Еще один миф, интерпретатор копактнее нативного кода. Есть техника token threading или еще "p-code" называется. Инструкции могут 4 бита занимать, вызов функции 8 или 12 бит. Нативный вызов минимум 8 на иснтрукцию + 8 адрес.
Так оно не страшно, самое неудобное это async. Обмазывать код Send/arc. Когда лайфтам инференсом не выводит - боль. Ну и библиотеки внешние должны быть с поддержкой async. Еще не придумали как одноцветные функуции сделать .
Обработка ошибок отдельная тема, её прям со старта планировать надо.
Насколько понимаю, отбрабатывать panic/unwrap сейчас невозможно и сервер схлопывается. Интересно посмотреть, как может развиваться remote_actor. Rust/tokio склоняют делать один большой монолит.
Без технических подробностей скучно читать, нет драмы, не ясны даже причины текущих проблем.
Если честно, каждый раз жду что напишут:
Мы переходим на Clojure/Datamic, чтобы избаваиться от проблемы масштабирования и размазывания логики.
Переделываем часть фронта на ClojureScript для устранения дублирования.
И потом битва в коментах, что надо было Флютер Жава-Скала шардинг-посгресс-кликхаусс
Стэйблкоин это же доллар, его стоитмость не меняется. Меняется курс обмена в местную валюту и его устанавливает банк. Хотелось бы узнать, как на это повлиять, когда ставят не самый выгодный курс.
Вроде, даже в TON, биржи это островки децентрализованные, с собственной ликвидностью.
Глобально и без посредников - все договоряться использовать единый протокол и сеть? Это ведь означает равные права для всех участников в любой точке мира.
Это для энтерпрайз архитекторов, которые много делегируют и оторваны от реальности. В небольших компаниях совсем другие проблемы, там проектирование в условиях ограниченых ресурсов.
На таких встречах тайно договариваются, как сделать чтобы язык был максимально сложным. В стандарте С++36, добавят обязательное чтение мантры для успещного запуска программы, чтобы LLM не смогла писать код вместо человека. Смыслом жизни станет изучение и трактовка стандартов. Подготовку специалистов перенесут в закрытые монастыри.
Не понятно как работает матчинг, больше похоже на поиск кружка по интересам, а не деловых партнеров.
Например, часто встречается ситуация, когда небольшой инвестор не может найти грамотных исполнителей и наоборот. Пересечение обших интересов у них очень небольшое.
Спорно по определению, если вы обладаете ресурсами, кто-то непременно захочет их перераспределить. Это может быть даже член семьи, а не посторонний человек.
Знаю только несколько примеров, где что-то подобное существует, они связаны с общинным укладом жизни аборигенов.
Удивительно, как вы делаете такие глубокие выводы, не обладая практическим опытом. Когда накапливается достаточно знаний и создаются инструменты, мы переходим на новый уровень абстракции. Больше не требуется писать ОС, прежде чем начать решать проблемы клиента. В современной разработке, более 60% проектов это однотипные решения, шаблоны и рутина. Лидеры отрасли и другие умные дяди, придумывают как сделать архитектуру, какие паттерны использовать. Фактически, кодеры уже операторы системы, дорогие и малоэффективные.
Сейчас мы накопили достаточно опыта, но инструменты очень примитивные. Должны появиться языки программирования LLM или более удобные способы задания промптинга. В этот момент переход завершиться, программирование в текущем виде, будет похоже на использование ассемблера. Потребуется решать задачи более высокого уровня.
Ну вот есть система
Boolean satisfiability problemи есть правила, как конвертировать сложную логическую задачу к простым операциям над битами. Доказали что это NP-complete, т.е совершенно не гарантируется, что есть решение и вычисления не займут вечность. Теоретически, ничего не мешает LLM формировать запросы к такому движку, не обладая истиным логическим мышление. Это даже будет плюсом, можно будет остановить зависшее логическое вычисление и переформулировать вопрос или условия.