К тому же проблемы сырости фронтенда никуда не денутся и ещё несколько лет компилятор rust будет генерировать не самый хороший код просто потому что недоделан до оптимальной реализации.
Во-первых оптимизация упирается в основном в бэкенд, а там LLVM. Во-вторых, это проблема курицы и яйца. Никто не пишет потому что не супероптимально потому что никто не пишет. Сколько человековеков вбухано в GCC/CLang?
Если посмотреть на код в репе Mozilla там виден ещё один косяк rust-а в языке по умолчанию использовали не C-style calling convention (соглашение о вызовах) по непонятной причине и этот calling convention создаёт большие накладные расходы. Это тоже имхо следует поправить в будущем.
Я не в курсе, какой конкретно у них calling convention. Но CDecl тоже не идеал. Хорош для интеропа, да. ЕМНИП тот же Itanium ABI требует несколько первых аргументов и результат класть в регистры, что явно будет быстрее чем снимать их со стека.
Собственно, нередко для нетривиальных фич бывают временные резолюции вида «давайте реализуем это в clang и посмотрим, что получится» или подкрепления пропозалов вида «я это запилил в clang на таком-то бранче, получилось прикольно».
ИМХО одна из фундаментальных проблем в том, что такой процесс применяется от случая к случаю. По-хорошему надо бы чтобы каждый пропозал проходил через стадию реализации на референсном компиляторе под future gate, с каким-то временем обкатки in the wild.
Нет, не про это. То ли байка, то ли правда. Появляется на стэковерфлоу вопрос "Как сложить на JS два числа?".
Куча ответов в стиле "Напиши плагин для JQuery" с примерами кода как написать этот плагин а потом использовать.
А самый простой ответ "a + b" оказывается самым заминусованным.
Они будут это позволять только для generic кода? Тогда посыпется консистентность с dynamic dispatch. Просто если в Rust есть Sized, в Golang можно правильно сделанные методы дёргать на nil instance, а Haskell по-моему вообще пофиг, то как это будет в C#?
Я думаю, под static method имелся ввиду метод, не зависящий от instance, но при этом перегружаемый. Идея в том, что интерфейс определяет не просто полиморфное поведение инстанса, но контракт всего типа. Например, добавляет сигнатуру метода-фабрики сразу в интерфейс. Такие фокусы возможны в языках, где вместо интерфейсов живут трейты или тайпклассы. Haskell, Rust. Golang позволяет подобный фокус неявно т.к. использует fat pointers и не требует self-pointer != null.
PsyHaSTe Я подозреваю, в Java/C# такое невозможно по чисто идеологическим причинам. Там для таких фокусов применяются инстансы фабрик.
Вообще я в таких случаях пишу две перегрузки, ElemType const& и ElemType&&. А сложную логику, независимую от метода форварда, кладу в приватный метод. Чуть больше бойлерплэйта, но гораздо понятней.
Классная штука, я оценил недавно. Особенно когда завезут компоненты в полный рост. Проблема в укуренных скриптах сборки, которые надо как-то с ним состыковать. Даже диалектов CMake выходит несколько штук.
Хотел написать здесь длиннющую стену текста с собственным нытьём, но не буду пожалуй. Просто скажу, что, начав очередной проект на С++, понял, что меня просто-таки задолбало тратить неделю на сведение и настройку сборки нескольких разношёрстных зависимостей. Тратить день на наладку тонкого патчинга одной из них, чтобы она блин поддерживала хотя бы utf-8 пути для файлов.
Я банально не хочу заниматься в 500й раз этой рутиной. Я хочу решать задачу. Такие дела.
Я немного не о человекочитаемости. Я о том, что все абстракции в исходном коде проекта 1:1 попадают в браузер, который вынужден их переваривать. Хотя можно бы пройтись транспилятором и выкинуть мусор, оставив только голую низкоуровневую логику.
С одной стороны, нативный мир живёт с этим уже десятки лет, и ничего. Агрессивная оптимизация может изменить ассемблерный выхлоп до неузнаваемости, при этом выкинув 9/10-х исходной логики за ненадобностью. С другой стороны, я иногда смотрю на результаты всяких там DI или Service Locator и понимаю, что отлаживать это практически невозможно из-за адового количества подкапотной магии. Так что я до сих пор не совсем понимаю, почему во фронтэнде не прижился подход с JS-as-assembly.
Как многие уже написали, опрос будет страдать ошибкой выжившего. Я к примеру без особой надежды жду от МС когда они возьмутся за качество своих продуктов и перестанут держать пользователей за имбецилов. Но варианта "Чего ждёте" — "Больше внимания качеству ПО" просто нет. Уважаемые представители МС, вы реально проводите опрос или лишь бы вышестоящий менеджер по голове погладил?
Я не жду ни бесплатного, ни открытого Windows. Это ваш продукт, имеете право. Но блин у меня на ноутбуке старый Mint 18 работает в разы быстрее и стабильней чем ваша хвалёная 10ка, которая всё никак не наобновляется. Сделайте наконец-то чтобы она соответствовала званию качественного платного продукта, а не была на уровне любительской свалки свистоперделок.
А через 10 лет вы будете говорить, что по сравнению с 40 годами стабильности С++… Ну вы поняли.
Во-первых оптимизация упирается в основном в бэкенд, а там LLVM. Во-вторых, это проблема курицы и яйца. Никто не пишет потому что не супероптимально потому что никто не пишет. Сколько человековеков вбухано в GCC/CLang?
Я не в курсе, какой конкретно у них calling convention. Но CDecl тоже не идеал. Хорош для интеропа, да. ЕМНИП тот же Itanium ABI требует несколько первых аргументов и результат класть в регистры, что явно будет быстрее чем снимать их со стека.
ИМХО одна из фундаментальных проблем в том, что такой процесс применяется от случая к случаю. По-хорошему надо бы чтобы каждый пропозал проходил через стадию реализации на референсном компиляторе под future gate, с каким-то временем обкатки in the wild.
В Rust можно использовать unchecked методы, и будет точно так же без проверок. Вопрос в поведении по умолчанию.
Правильно верится с трудом. Как только
std::initializer_list, так сразу проблемы.Нет, не про это. То ли байка, то ли правда. Появляется на стэковерфлоу вопрос "Как сложить на JS два числа?".
Куча ответов в стиле "Напиши плагин для JQuery" с примерами кода как написать этот плагин а потом использовать.
А самый простой ответ "a + b" оказывается самым заминусованным.
Они будут это позволять только для generic кода? Тогда посыпется консистентность с dynamic dispatch. Просто если в Rust есть Sized, в Golang можно правильно сделанные методы дёргать на nil instance, а Haskell по-моему вообще пофиг, то как это будет в C#?
Это уже к автору вопроса.
Чисто субъективно — потому что они реально сделаны через *опу. В Lua к примеру тоже прототипное ООП, но при этом простое и понятное.
Я думаю, под static method имелся ввиду метод, не зависящий от instance, но при этом перегружаемый. Идея в том, что интерфейс определяет не просто полиморфное поведение инстанса, но контракт всего типа. Например, добавляет сигнатуру метода-фабрики сразу в интерфейс. Такие фокусы возможны в языках, где вместо интерфейсов живут трейты или тайпклассы. Haskell, Rust. Golang позволяет подобный фокус неявно т.к. использует fat pointers и не требует self-pointer != null.
PsyHaSTe Я подозреваю, в Java/C# такое невозможно по чисто идеологическим причинам. Там для таких фокусов применяются инстансы фабрик.
Аргументируй.
Вообще я в таких случаях пишу две перегрузки,
ElemType const&иElemType&&. А сложную логику, независимую от метода форварда, кладу в приватный метод. Чуть больше бойлерплэйта, но гораздо понятней.С одной стороны де-факто стандарт это хорошо, с другой стороны я бы хотел что-то поприличней.
Классная штука, я оценил недавно. Особенно когда завезут компоненты в полный рост. Проблема в укуренных скриптах сборки, которые надо как-то с ним состыковать. Даже диалектов CMake выходит несколько штук.
Как говорится, I feel your pain bro.
Хотел написать здесь длиннющую стену текста с собственным нытьём, но не буду пожалуй. Просто скажу, что, начав очередной проект на С++, понял, что меня просто-таки задолбало тратить неделю на сведение и настройку сборки нескольких разношёрстных зависимостей. Тратить день на наладку тонкого патчинга одной из них, чтобы она блин поддерживала хотя бы utf-8 пути для файлов.
Я банально не хочу заниматься в 500й раз этой рутиной. Я хочу решать задачу. Такие дела.
Я немного не о человекочитаемости. Я о том, что все абстракции в исходном коде проекта 1:1 попадают в браузер, который вынужден их переваривать. Хотя можно бы пройтись транспилятором и выкинуть мусор, оставив только голую низкоуровневую логику.
Т.е. импортируют пакет ради проверки is-a? Напоминает старую шутку про jQuery a+b.
С одной стороны, нативный мир живёт с этим уже десятки лет, и ничего. Агрессивная оптимизация может изменить ассемблерный выхлоп до неузнаваемости, при этом выкинув 9/10-х исходной логики за ненадобностью. С другой стороны, я иногда смотрю на результаты всяких там DI или Service Locator и понимаю, что отлаживать это практически невозможно из-за адового количества подкапотной магии. Так что я до сих пор не совсем понимаю, почему во фронтэнде не прижился подход с JS-as-assembly.
Как многие уже написали, опрос будет страдать ошибкой выжившего. Я к примеру без особой надежды жду от МС когда они возьмутся за качество своих продуктов и перестанут держать пользователей за имбецилов. Но варианта "Чего ждёте" — "Больше внимания качеству ПО" просто нет. Уважаемые представители МС, вы реально проводите опрос или лишь бы вышестоящий менеджер по голове погладил?
Я не жду ни бесплатного, ни открытого Windows. Это ваш продукт, имеете право. Но блин у меня на ноутбуке старый Mint 18 работает в разы быстрее и стабильней чем ваша хвалёная 10ка, которая всё никак не наобновляется. Сделайте наконец-то чтобы она соответствовала званию качественного платного продукта, а не была на уровне любительской свалки свистоперделок.
Т.е. реальная новость "Мы положили на стандарты и заложились на недокументированное поведение одной конкретной реализации".
Они хотят сказать что другие браузеры не хранят данные в кеше?