Эх, 301 Pro до сих пор пользуюсь, хоть аккумулятор уже от старости выдохся, и корпус весь исцарапанный. А всё почему? А всё потому что поддержка кучи форматов, в т.ч. fb2. Не потеряйте это преимущество.
Когда я "искал себе жену" (примем такую формулировку), мне никто не пытался рекламировать невест на выданье. Впрочем, зная нынешних рекламщиков, мне бы скорее предлагали проституток по месту жительства.
Ваш пример с автомобилями неверен. Красивость тоже своего рода ТТХ — но я не буду покупать какую-нибудь Эдамскую косметичку" чтобы возить картошку с дачи — даже если она красивая.
По поводу нужности рекламы спорить не буду. Я даже наверное согласен что она нужна — в какой-то форме. Но блин не так что мне её, фигурально выражаясь, пытаются из катапульты в окно закидывать мешками по пол-центнера.
Проблема в том, что на 1-2 таких полезных объявления приходится несколько тысяч (и более) бесполезных и просто мусорных.
Примерно половина будет просто нерелевантной рекламой (новый гэлэкси, новые прокладки, средство от какого-нибудь цистита и т.п.).
Вторая примерно половина — откровенный шлак, псевдо-новости про знаменитостей, пророков и т.п. Теперь бульварный трэш пытается пролезть мне в мозги и таким способом.
Вводим дурацкое сообщение при пуше "делать пулл-реквест тут!". Неотключаемое. Потребовалось 8 месяцев чтобы Атлассианы соизволили добавить кнопку чтобы его отключить
Добавить трекинг переименования и перемещения файлов. Запрос висел несколько лет. В это время Атлассиан доблестно добавлял интеграцию с пейстбином, как пример. Потом эти чудики добавили бета-поддержку — на уровне репозиториев. Почему нельзя было на уровне пользователей — загадка.
Несколько топовых запросов висят по несколько лет в их трекере без ответа.
Теперь будет как и с битбакетом — вводим сомнительные фичи по желанию левой пятки и игнорируем топовые просьбы пользователей на нами же созданном трекере.
За других не буду конечно расписываться.
Я например, когда мне что-то нужно, сначала прикидываю примерный список ТТХ, потом иду на сайт вроде Я.Маркета и смотрю что есть подходящее под эти ТТХ, потом возможно лажу по форумам и читаю отзывы.
Реклама в моей цепочке покупки отсутствует как класс — так как не способна дать нужной мне информации, в нужной мне форме.
Суммируя — ваше предложение не достигнет меня через рекламу, никак. Более того, даже если я случайно вижу в рекламном объявлении то, что мне нужно в данный момент — всё равно игнорирую. По причине из предыдущего абзаца.
Не сочтите за "наезд", просто обрисовываю ситуацию.
Вы видимо никогда случайно не добавляли элементы в вектор, по которому в это время итерировались. И не забывали инициализировать unique_ptr. И не делали случайное обращение к шареному ресурсу без синхронизации.
Break Blade
Редкий зверёк про меха без ОЯШ, психозных самозаглублений главгероя и окружающих. «Художественных допущений» конечно тоже хватает, но они хоть не режут глаз как в тех же гандамах.
Насколько я знаю, нет возможности превратить строковой литерал в параметр типа чтобы распарсить и проверить его в компайл-тайме. Точнее, вроде как можно — но на практике оказывается что нельзя.
Не совсем. ЕМНИП Матсакис писал, что компилятор тоже будет отдавать поток токенов — но будет libmacro которая будет делать юзабельный АСТ и всякие ништяки. Я так понял, своего рода forward compatibility.
Работа над теми же non-scoped lifetimes ведётся. Не всё сразу. В конце концов, здесь есть возможность ослабить ограничения. Сильно подозреваю что и вывод типов на уровне модуля со временем завезут.
И вот касательно Rust. Возникает тогда вопрос: а зачем разработчику прописывать все эти ограничения на переменные, если, всё равно, придёт мощный оптимизатор и сам всё это посчитает вместе с сотней других важных параметров?
Я бы сказал — для самого разработчика. Это может не играть роли для монолитного бинарника. Но ох как важно для библиотечного кода. В том числе позволяет оптимизатору делить работу на куски поменьше. Без аннотаций придётся каждый раз делать анализ всего графа программы.
Но как он отработает на "обычном" JavaScript с пачками интроспекции, манкипатчингом и другой динамикой? Как он будет жить на библиотечном коде? Проблема в динамической от природы и, скажем прямо, кривой от рождения семантике JavaScript. Даже самый умный оптимизатор будет вынужден будет думать о ситуации когда в некое под-дерево функций передадут совершенно не то, что ожидали.
В целом же не вижу особой "перегруженности". Да, OCaml значительно короче — но это объясняется просто другими решениями при дизайне языка. В частности, module-wide type inference. В Rust сознательно ограничили вывод типов телом функции. Ну и по мелочи различия — например в OCaml версии нет вектора как отдельного типа, а в Rust — есть.
Я в курсе. Как по мне, это костыль.
Два недостатка:
Менеджмент ручками. Ответственность за удаление перекладывается с автора кода ресурса на пользователя. Забыли юзинг — ресурс освободится неизвестно когда, если вообще освободится.
Как только ресурс живёт дольше области видимости одной функции — using блок становится бесполезен
Мне кажется, вы сравниваете с конкретно Generational GC — у которого тоже есть свои проблемы. Но не будем, тут действительно нужно писать бенчмарки — и притом не тривиальную сумму миллиона чисел в массиве.
Лично для меня преимущество у не-GC языков в большей управляемости и, что важнее, едином в меру удобном механизме работы с любыми ресурсами — не только памятью. В управляемой среде нетривиальный сценарий работы с тем же файлом, критической секцией, COM-объектом или кустом реестра превращается в мороку. В С++ и Расте компилятор хоть деструкторы сгенерит.
Это скорее результат старого проверенного подхода "всё есть ресурс в т.ч. память". Кстати, это одна из проблем языков со сборкой мусора — работа с временем жизни неуправляемых ресурсов превращается в редкий геморрой вне самых простых сценариев.
Насколько я помню, применяется метод нескольких пулов страниц по размеру. Допустим, менеджер памяти откусывает страницы по 4 килобайта. Мы создаём несколько пулов объектов — 32, 64, 128, 256, 512, 1024, 2048 байт. Всё что больше — выделяется непрерывными кусками без особых заморочек. Как результат такой "сегрегации" — проще найти дырку под новый объект на месте удалённого.
То, что вы описали — JSDD == Job Safety Driven Development :)
Когда я "искал себе жену" (примем такую формулировку), мне никто не пытался рекламировать невест на выданье. Впрочем, зная нынешних рекламщиков, мне бы скорее предлагали проституток по месту жительства.
Ваш пример с автомобилями неверен. Красивость тоже своего рода ТТХ — но я не буду покупать какую-нибудь Эдамскую косметичку" чтобы возить картошку с дачи — даже если она красивая.
По поводу нужности рекламы спорить не буду. Я даже наверное согласен что она нужна — в какой-то форме. Но блин не так что мне её, фигурально выражаясь, пытаются из катапульты в окно закидывать мешками по пол-центнера.
Проблема в том, что на 1-2 таких полезных объявления приходится несколько тысяч (и более) бесполезных и просто мусорных.
Примерно половина будет просто нерелевантной рекламой (новый гэлэкси, новые прокладки, средство от какого-нибудь цистита и т.п.).
Вторая примерно половина — откровенный шлак, псевдо-новости про знаменитостей, пророков и т.п. Теперь бульварный трэш пытается пролезть мне в мозги и таким способом.
Свежие примеры
Если чего ещё вспомню — напишу.
Теперь будет как и с битбакетом — вводим сомнительные фичи по желанию левой пятки и игнорируем топовые просьбы пользователей на нами же созданном трекере.
За других не буду конечно расписываться.
Я например, когда мне что-то нужно, сначала прикидываю примерный список ТТХ, потом иду на сайт вроде Я.Маркета и смотрю что есть подходящее под эти ТТХ, потом возможно лажу по форумам и читаю отзывы.
Реклама в моей цепочке покупки отсутствует как класс — так как не способна дать нужной мне информации, в нужной мне форме.
Суммируя — ваше предложение не достигнет меня через рекламу, никак. Более того, даже если я случайно вижу в рекламном объявлении то, что мне нужно в данный момент — всё равно игнорирую. По причине из предыдущего абзаца.
Не сочтите за "наезд", просто обрисовываю ситуацию.
Вы видимо никогда случайно не добавляли элементы в вектор, по которому в это время итерировались. И не забывали инициализировать unique_ptr. И не делали случайное обращение к шареному ресурсу без синхронизации.
Редкий зверёк про меха без ОЯШ, психозных самозаглублений главгероя и окружающих. «Художественных допущений» конечно тоже хватает, но они хоть не режут глаз как в тех же гандамах.
Насколько я знаю, нет возможности превратить строковой литерал в параметр типа чтобы распарсить и проверить его в компайл-тайме. Точнее, вроде как можно — но на практике оказывается что нельзя.
Не совсем. ЕМНИП Матсакис писал, что компилятор тоже будет отдавать поток токенов — но будет libmacro которая будет делать юзабельный АСТ и всякие ништяки. Я так понял, своего рода forward compatibility.
Работа над теми же non-scoped lifetimes ведётся. Не всё сразу. В конце концов, здесь есть возможность ослабить ограничения. Сильно подозреваю что и вывод типов на уровне модуля со временем завезут.
Я бы сказал — для самого разработчика. Это может не играть роли для монолитного бинарника. Но ох как важно для библиотечного кода. В том числе позволяет оптимизатору делить работу на куски поменьше. Без аннотаций придётся каждый раз делать анализ всего графа программы.
Это крайне интересный проект, без шуток.
Но как он отработает на "обычном" JavaScript с пачками интроспекции, манкипатчингом и другой динамикой? Как он будет жить на библиотечном коде? Проблема в динамической от природы и, скажем прямо, кривой от рождения семантике JavaScript. Даже самый умный оптимизатор будет вынужден будет думать о ситуации когда в некое под-дерево функций передадут совершенно не то, что ожидали.
В целом же не вижу особой "перегруженности". Да, OCaml значительно короче — но это объясняется просто другими решениями при дизайне языка. В частности, module-wide type inference. В Rust сознательно ограничили вывод типов телом функции. Ну и по мелочи различия — например в OCaml версии нет вектора как отдельного типа, а в Rust — есть.
Я бы сказал что код на Rust процентов на 50 не-идиоматичный. Чего только стоит клон списка тел при подсчёте попарных разниц.
Ответил в соседней подветке
Я в курсе. Как по мне, это костыль.
Два недостатка:
Мне кажется, вы сравниваете с конкретно Generational GC — у которого тоже есть свои проблемы. Но не будем, тут действительно нужно писать бенчмарки — и притом не тривиальную сумму миллиона чисел в массиве.
Лично для меня преимущество у не-GC языков в большей управляемости и, что важнее, едином в меру удобном механизме работы с любыми ресурсами — не только памятью. В управляемой среде нетривиальный сценарий работы с тем же файлом, критической секцией, COM-объектом или кустом реестра превращается в мороку. В С++ и Расте компилятор хоть деструкторы сгенерит.
Это скорее результат старого проверенного подхода "всё есть ресурс в т.ч. память". Кстати, это одна из проблем языков со сборкой мусора — работа с временем жизни неуправляемых ресурсов превращается в редкий геморрой вне самых простых сценариев.
Насколько я помню, применяется метод нескольких пулов страниц по размеру. Допустим, менеджер памяти откусывает страницы по 4 килобайта. Мы создаём несколько пулов объектов — 32, 64, 128, 256, 512, 1024, 2048 байт. Всё что больше — выделяется непрерывными кусками без особых заморочек. Как результат такой "сегрегации" — проще найти дырку под новый объект на месте удалённого.