Rust 1.34

Что творят окаянные! Вместо await expression будем писать expression.await

https://boats.gitlab.io/blog/post/await-decision/

Так php же уже давно даже не мелкой сапой как и js обэнтерпрайзилось и вполне уже похоже на маленьких уродливых братишек java.

Спасибо за ответы. Хотя по ссылке ниже товарищ аноним утверждает обратное, как бы вы могли это прокомментировать?

Rust 1.34 (комментарий)

Плохо то, что по-прежнему можно писать по-старому и многие продолжат так делать.

А код-ревью на что?

Но такие случае в меньшинстве

Большинство давно пишет на 11, многие на 14. На 17 вот не все перешли еще, да.

в любом случае это небольшие проекты

Может хватит повторять этот бред как мантру?

Это больше смущать должно производителей компиляторов. Тебя, как программиста это затронет раз в год и то если ты библиотеки пишешь, а не продукты/системы.

А чего не пошли по пути Котлин, где одного ключевого слова хватило и не надо везде await вставлять?

В этом и есть главная проблема переходов пусть даже на новые и перспективные языки, проще наныть чтобы похожий подход нового языка добавили в старый через костылестроительство, чем создавать экосистему для нового с кучей библиотек (при самых радужных перспективах, на это нужны миллионы человекочасов работы, кто этим будет заниматься - непонятно), и уж простите, но это действительно лучший подход даже несмотря на костыли. Поэтому имеем что имеем, тут уже заводился разговор почему С тянется уже пол века грязным смрадным шлейфом за нами, вот именно поэтому и тянется как и любое другое легаси. А еще обычно именно поэтому любой маломальский серьезный проект это жутчайшая солянка из технологий и языков слепленных на уровне форматов вызовов или на уровне скриптовых сопельных прослоек для передачи данных их одной части в другую. Уж лучше пусть плюсы и дальше пухнут, нежели эти мириады языков в каждый из которых тоже приходится вникать, т.к. переключения контекста с одного языка на другой никогда ничем хорошим не заканчивается.

Пых все профукал. Там то ли с 5 то ли с 6 версии все встало колом и кучу раз откладывали большие фичи типа нормальной поддержки юникода. В итоге народ посваливал на питоны-руби-ноды, и когда пых наконец-то просрался, обратно уже никто не захотел. Теперь его только в ынтырпрайзах и юзают, из-за легаси.

Дык если б модули были, лично я бы и не дергался так резко. Но их нет. И как долго это все будет раскатываться до реальных проектов будет - фик знает.

Тоже самое говорят и про другие языки что они все профукали, тем не менее плюсы живы, питон который активно хейтится в пользу голанда жив и не собирается уходить. И с php будет все точно также. Пакетных менеджеров уже налабали, добавили классическое плюсоподобное ооп, в жс завезли хоть и убогое но подобие распараллеливание... в общем будет жить что то, что это. А учитывая как плотно тот же веб сидит на жс в виде клиенсткого кода и никто не думает даже впилить хоть какую-то альтернативу в современные браузеры, или выкатить механизм биндинга твоего любимого язычка для этих целей. В общем... ну вы поняли.

А учитывая как плотно тот же веб сидит на жс в виде клиенсткого кода и никто не думает даже впилить хоть какую-то альтернативу в современные браузеры, или выкатить механизм биндинга твоего любимого язычка для этих целей.

WASM же.

Уже есть С++ с модулями, это языки на jvm или на .net. Хотя и в плюсах скорее всего завезут, просто это будет опять же какой-то адок уродский, по типу прибивания тех же лямбд что в плюсах, что в какой-нибудь java. Но лучше так, чем перепись языка с потерей совместимости или еще более глупая идея - запиливание очередного языка который решит все проблемы своих предшественником (спойлер - не решит, но создаст новые) :3

он уже перестал использовать asm.js и вообще js для того чтобы функционировать?

Доля рынка пыха сейчас и раньше - не сопоставимы. Раньше фактически была монополия. Я не про «полную и окончательную смерть», а про популярность и перетекание людей куда-то еще. Пример пыха, который на несколько лет перестал развиваться, очень показателен. Просрать монополию - это не каждый день случается :)

В плюсах как-то вот сильно увлеклись академическими вещами, позабыв про реальную жизнь. Но я им зла не желаю. Успеют не растерять преимущество - ну ок.

Давно уже.

https://github.com/fontello/wawoff2 - пересобранный woff2 от гугла. Прикольно. Ничего не ломается с выходом новый версий ноды.

Для мелких эмбедов их нет, поэтому для меня подобные рассуждения не имеют смысла.

Это шутка такая? Я вижу там кругом js и упоминание ноды. Я же имею в виду биндинг любого языка к браузеру без необходимости писать хоть строчку кода на жс или использовать его под капотом.

While there are future plans to allow WebAssembly modules to be loaded just like ES6 modules (using <script type='module'>), WebAssembly must currently be loaded and compiled by JavaScript.

Всё будет, короче.

Вот же https://github.com/fontello/wawoff2/tree/master/build/woff2
. wasm - бинарники. На жыэс только загрузка и внешние интерфейсы (в данном конкретном случае это ведь под внешние программы на JS).

Это давно делалось, я не вникал как стало сейчас. Clang поддерживает wasm бакенд. Не знаю про какие «любые другие языки» вы говорили, но все что соберете clang-ом - ваше.

Ваш вопрос был

и *на этапе выполнения* каков оверхед

А он пишет

прочекать *во время компиляции* не в состоянии

Все верно. Во время компиляции никто не может прочекать границы. Кажется, это следствие проблемы остановки, то есть фундаментальное ограничения для Тюринг полных языков. Возможно когда-то у нас будут неполные языки где такой проблемы не будет.

Ну да, для этого им надо впилить свою vm с байткодом во все популярные браузеры, тогда действительно может что-то получиться. Ждемс. Ну и да, желательно чтобы эта vm была реализованная не на js, а была полноценным модулем основного кода браузера.

У меня для вас хорошие новости. 2 года назад разработчики браузеров собрали машину времени, слетали вперед, прочитали ваш пост и потом сделали точно как вы хотите.

Хочу делать на lua выпадающие менюшки и прочие интерактивные элементы страницы в любом браузере с отключенным js или в браузере где js вообще нет, это возможно сейчас если использовать wasm? Будут ли они работать?

Так было бы, если программисты были бы бессмертны и новые не приходили.

Во время компиляции никто не может прочекать границы

Там ниже был пример на креслах, когда компилятор в некоторых случаях может.

Кажется, это следствие проблемы остановки

Произвольный код нельзя будет проверить, да. Но кажется можно проверить простейшие случаи. Так же можно проверить, есть ли проверка. Статические анализаторы часто неплохо проверяют, но не знаю, насколько их проверки полны.

Ну я лишь хотел сказать что не вижу особой проблемы в распухании, это на мой личный взгляд лучше, чем солянка из языков и технологий.

Там ниже был пример на креслах, когда компилятор в некоторых случаях может.

В таких и rust может.

Кажется вы забыли добавить «а еще чтобы wasm тоже был отключен, а самого браузера не было или хотя бы сразу закрывался» :)

Доступа к видеокарте из wasm нет. Луа - не вижу причин почему ему бы не собраться и не погонять луаскрипты.

То есть все же без js оно не работает, правильно? Я просто в этом и вижу проблему что js превращается в некий С для веба, хотя по сути для этого особо нет каких-то предпосылок и оправдания.

Видимо никого кроме вас эта филосовская проблема не взволновала.

Люди хотели дешево и сердито компилять текущие исходники под браузер, и они своего добились.

С этим никто не спорит, что так все и работает. Просто wasm дали как решение, но он не решение, а присыпание сахарной пудрой. Посмотрим во что превратится этот проект.

Идея-фикс плюсистов.

В действительности, и правда основная проблема плюсов - это модули.

Интересно правда, как будут решать проблему шаблонов и модулей одновременно.

По-моему вы единственный, кто еще не посмотрел :)

https://littlevgl.com/live-demo - вот пример, где люди выгладувают демку GUI от ембедов. Вполне прикладная задача. Сами они на жыэси ничего точно не делали.

В плюсах как-то вот сильно увлеклись академическими вещами

Это какими?

Интересно правда, как будут решать проблему шаблонов и модулей одновременно.

В D шаблоны (https://dlang.org/spec/template.html) ничем ни хуже чем в C++ и без проблем сочетаются с модулями.

Надо будет почитать. Начинал когда-то изучать D, но так и не собрался домучить.

Современный C++ не защищает, например, от вот таких граблей:

А можно пояснить, что тут не так?

~~@~~

Его покусали раст-сектанты, либо он забыл передать строку по-значению.

А можно пояснить, что тут не так?

Вот в этом случае у вас получится повисшая ссылка, если get_or вернет значение параметра default_value:

const std::string & v = get_or("some_key", "some_default_value");

Этой проблеме, например, подвержен std::max и std::min. И эта проблема существует в C++ уже лет 30.

отключите js в браузере и ожидаемо ничего не работает. Пока технология неспособна жить без js. За них просто все сделали, тем не менее факт остается фактом.

а почему не expression.await()?

Я уже говорил, что мне не интересно обсуждение шарообразных фактов в вакууме. Не надо мне ничего доказывать про wasm, я знаю как он устроен.

а почему не expression.await()?

Потому что это не вызов метода, а «dot operator», как они это назвали. Блин, по ссылке доступно же разжевано, не надо быть настолько Ъ.

Во время компиляции никто не может прочекать границы

Наверняка с этим справились бы зависимые типы.

Еще можно прикрутить контракты и статически проверить, что в коде выполнены все предусловия.

Мне больше по душе идея программировать на Тюринг неполном языке вместо этого. Такое только императивное бы.

Раст суров. Необычно выглядит, но вроде отторжения не вызывает.

Там был аргумент сделать match тоже dot выражением. Было бы временами прикольно.

как там руби поживает?

хотя, в отличие от руби, не нужно на каждую конструкцию лямбду городить

Вызывает шок. Сложон больно если в голове нет C++ бэкграунда :)

В действительности, и правда основная проблема плюсов - это модули.

Почему?