Проблема в том, что на 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 байт. Всё что больше — выделяется непрерывными кусками без особых заморочек. Как результат такой "сегрегации" — проще найти дырку под новый объект на месте удалённого.
Увы, я в курсе, что там куча комитетов.
Я хотел бы, чтобы велась разработка не стандарта, а референсного компилятора с участием всех заинтересованных сторон. Я так же в курсе, что "не судьбец".
То, что их добавление не задерживает принятие стандарта, не повод их в стандарт добавлять. Ещё 200 страниц к талмуду. Причём с пользой для очень узкого круга пользователей.
Это был горький сарказм если что. Про то, что в стандарт засунули то, что могло спокойно сидеть в tensorflow и дальше. Зато нет целой кучи базовых строительных блоков.
Зета-функция, полиномы Лежандра и т.п. безусловно важные и нужные штуки — но применяемые в довольно узкой области.
Проблема в том, что на 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 байт. Всё что больше — выделяется непрерывными кусками без особых заморочек. Как результат такой "сегрегации" — проще найти дырку под новый объект на месте удалённого.
Ладно, давайте закроем тему. Иначе сейчас будем спорить, у кого выборка репрезентативней.
Увы, я в курсе, что там куча комитетов.
Я хотел бы, чтобы велась разработка не стандарта, а референсного компилятора с участием всех заинтересованных сторон. Я так же в курсе, что "не судьбец".
То, что их добавление не задерживает принятие стандарта, не повод их в стандарт добавлять. Ещё 200 страниц к талмуду. Причём с пользой для очень узкого круга пользователей.
Это был горький сарказм если что. Про то, что в стандарт засунули то, что могло спокойно сидеть в tensorflow и дальше. Зато нет целой кучи базовых строительных блоков.
Зета-функция, полиномы Лежандра и т.п. безусловно важные и нужные штуки — но применяемые в довольно узкой области.