это очень сложный вопрос, думаю утром профессионалы с++ и js проснутся и ответят более точно но вообще, если вы не знаете ни с++, ни раста, то у с++ порог будет меньше, но раст будет выигрывать на дистанции

это в отрыве от wasm

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

это очень сложный вопрос, думаю утром профессионалы с++ и js проснутся и ответят более точно но вообще, если вы не знаете ни с++, ни раста, то у с++ порог будет меньше, но раст будет выигрывать на дистанции

я имею опыт с C++, правда сейчас конкретно на нём не работаю. с Rust'ом опыта нет ещё вообще, но, не смотря на убогость его синтаксиса, "compile-time гарантия отсутствия проблем с памятью, синхронизацией и т.д." звучит заманчиво учитывая сколько времени я убил на устранение багов связанных с неправильной работой с памятью

> убогость его синтаксиса а вы точно имеете опыт с с++?

это больше риторический вопрос

> убогость его синтаксиса а вы точно имеете опыт с с++?

имею опыт с C++11 давний, но сейчас работаю на Go и JS, в плане синтаксиса обожаю Go, C++ конечно далеко не сказка

имею опыт с C++11 давний, но сейчас работаю на Go и JS, в плане синтаксиса обожаю Go, C++ конечно далеко не сказка

сложно сказать. мне с с++03 было сложно переходить на раст больше не из-за синтаксиса, а из-за концепций

я имею опыт с C++, правда сейчас конкретно на нём не работаю. с Rust'ом опыта нет ещё вообще, но, не смотря на убогость его синтаксиса, "compile-time гарантия отсутствия проблем с памятью, синхронизацией и т.д." звучит заманчиво учитывая сколько времени я убил на устранение багов связанных с неправильной работой с памятью

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

Достаточно покопаться в нём неделю, чтобы понять, что оно да, решено, но не так, как создаётся впечатление, что решено и забыли, а немного другой ценой.

Достаточно покопаться в нём неделю, чтобы понять, что оно да, решено, но не так, как создаётся впечатление, что решено и забыли, а немного другой ценой.

чес гря не совсем понял)

ну в том, что это не C++, где просто всё проблемное магическим образом исчезло.

ну в том, что это не C++, где просто всё проблемное магическим образом исчезло.

и тут не понял))) о чём конкретно идёт речь?

ну в том, что это не C++, где просто всё проблемное магическим образом исчезло.

естественно, в языке с доступом к памяти "решено и забыли" не бывает

тем более кейс специфичный, > учитывая сколько времени я убил на устранение багов связанных с неправильной работой с памятью

и тут не понял))) о чём конкретно идёт речь?

о Расте же :)

о Расте же :)

если честно, тоже не очень понимаю

ну я так понял мы говорим о compile-time guarantees

@Romshark, а вы в васме тоже хотите работать с памятью?

@Romshark, а вы в васме тоже хотите работать с памятью?

как можно что-либо написать не работая с памятью?)

ну я так понял мы говорим о compile-time guarantees

насколько я понял, Александр пытается намекнуть, что compile time garantees достигаются путём того, что приходится делать разные вещи немного по-другому, нежели в с++

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

насколько я понял, Александр пытается намекнуть, что compile time garantees достигаются путём того, что приходится делать разные вещи немного по-другому, нежели в с++

это мне понятно, ибо в Rust'е у нас ownership and borrowing

как можно что-либо написать не работая с памятью?)

можно работать с памятью безопасно, и не натыкаться на проблемы, которые решает раст

можно работать с памятью безопасно, и не натыкаться на проблемы, которые решает раст

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

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

а как раст спасёт от "ночного кошмара большой кодовой" базы?

когда несколько потоков одновременно работают с shared state'ом и компилятор молча сиё дело пропускает то это дико опасно и дорого обойдётся

когда несколько потоков одновременно работают с shared state'ом и компилятор молча сиё дело пропускает то это дико опасно и дорого обойдётся

а васм умеет в несколько потоков? я просто не шарю

а как раст спасёт от "ночного кошмара большой кодовой" базы?

большей строгостью о том, где какая память откуда и когда пишется/читается, не?

а васм умеет в несколько потоков? я просто не шарю

пока ещё нет, но думаю это вопрос времени

я думаю это вопрос бесконечного потенциала

я думаю это вопрос бесконечного потенциала

всмсл?

большей строгостью о том, где какая память откуда и когда пишется/читается, не?

зависит от того, что вы вкладываете в "ночной кошмар" если это работа с шаред стейтом, то да, раст зафорсит вас писать везде lock() и прочее

всмсл?

а подскажите ещё (тоже не шарю), wasm исполняется отдельным рантаймом? или тем же JS-овским?

зависит от того, что вы вкладываете в "ночной кошмар" если это работа с шаред стейтом, то да, раст зафорсит вас писать везде lock() и прочее

об этом я и говорю да. В основном shared state является причиной всех самых страшных багов

если второе, то это нужно идти к js-никам и спрашивать, когда им завезут многопоточность

(ставлю на то, что через несколько лет) (моё авторитетное мнение никому не сдалось)

а подскажите ещё (тоже не шарю), wasm исполняется отдельным рантаймом? или тем же JS-овским?

WASM исполняется внутри JS движка браузера, это по сути виртуальный CPU, со своим instruction set'ом. Т.е. это обеспечивает безопасность и представляет собой compile target который очень близок к CPU

если второе, то это нужно идти к js-никам и спрашивать, когда им завезут многопоточность

им уже давно завезли многопоточность к качестве WebWorker'ов, правда shared state'а у них, естественно, нет. Только asynchronous message passing

Я что-то бенчил wasm от нечего делать, и что-то даже не близко к cpu было. Просто для коммента.

им уже давно завезли многопоточность к качестве WebWorker'ов, правда shared state'а у них, естественно, нет. Только asynchronous message passing

как раз об этом читал вчера

в общем, мне кажется вы решаете несуществующую проблему

Я что-то бенчил wasm от нечего делать, и что-то даже не близко к cpu было. Просто для коммента.

может дело в бенчмарке а не в WASM'е?)

но, если решите присоединиться к рустовому сообществу, будем рады помочь и разобравться в концепциях

в общем, мне кажется вы решаете несуществующую проблему

проблема существует и называется она JavaScript. garbage collection, dynamic typing.... всё это может и подходит для сайтиков, но вот для систем и приложений уже не совсем.

я бы сказал "для систем и приложений не нужно использовать wasm/js", но сдержусь

я бы сказал "для систем и приложений не нужно использовать wasm/js", но сдержусь

+1. К тому же не пойму про dyn-types каким они боком к типу приложения.

Си со слабой типизацией не сильно лучше динамического языка, однако системный.

я бы сказал "для систем и приложений не нужно использовать wasm/js", но сдержусь

я изначально пришёл из мира C++ Qt, где есть просто великолепный фреймворк Qt Quick со своим языком написания UI - QML. Когда я перешёл на веб HTML/CSS/JS оказался катастрофой. Веб сам по себе это более 50% рынка и за ним будущее, он убьёт app store'ы, в браузеры переместится весь софт, включая 3Д игры и подобное, с лишь небольшими исключениями, но вот HTML/CSS для написания современных динамичных приложений совершенно не годится, но это отдельная тема. Поэтому я задался вопросом, лично для себя, попробовать написать небольшой SceneGraph на WASM и WebGL, простенький тупенький MVP. WASM по той причине что JS для этого абсолютно не годится, это не systems programming language и он слишком прожорлив чтоб писать на нём рендеринг движок. Просто составить граф мета объектов со свойствами и биндингами и вывести их на экран.

и тут буквально на днях я услышал, что мол одних из самых популярных языков для WASM'а сейчас это Rust, глянул несколько детальных презентаций и заинтересовался, хотя изначально хотел писать всё это на C++

Go, на котором я сейчас реализую GraphQL API'шки, т.е. бэкэнд приложений, для этого к сожалению тоже не подходит, даже не смотря на то что компилятор Go в скором сможет компилить WASM. Garbage collection и graphics engine просто не подружатся

Сложно сказать, у меня нет опыта на wasm, поэтому не могу сказать точнее Если вы интересуетесь именно производительностью кода rust vs c++, то она сравнимая (читай: одинаковая) нужно дождаться пока проснуться те, кто бенчмаркал wasm код, и скажут более подробно Ну и насчет самой идеи, можете считать меня ретроградом, но по моему (никому не нужному) мнению игры не уйдут в веб, по крайней мере пока все js программисты не перейдут на что-то адаптированное для (хотя бы) многопоточных вычислений

Тем не менее, если очень хочется wasm, раст должен неплохо себя показать как замена c++ Кривая входа конечно будет покруче, но все изучаемо

Сложно сказать, у меня нет опыта на wasm, поэтому не могу сказать точнее Если вы интересуетесь именно производительностью кода rust vs c++, то она сравнимая (читай: одинаковая) нужно дождаться пока проснуться те, кто бенчмаркал wasm код, и скажут более подробно Ну и насчет самой идеи, можете считать меня ретроградом, но по моему (никому не нужному) мнению игры не уйдут в веб, по крайней мере пока все js программисты не перейдут на что-то адаптированное для (хотя бы) многопоточных вычислений

никто не будет писать 3д игры на JS, это нонсенс, для этого и появился WASM, это среда напоминающая виртуальный процессор, без garbage collection, с (как обещают разработчики браузеров) 5% overhead'ом по сравнению с кодом, компилированным на x86 5% это вполне приемлимо, учитывая уровень безопасности который мы получаем от sandbox'а браузера. В будущем приложения не будут устанавливаться из app store'ов, достаточно будет зайти на URL, подождать загрузки приложения в cache если загружаем первый раз и вуаля..

это впервые позволит писать абсолютно cross platform'енные приложения с идеалогией "write once - run everywhere", которые по производительности сопостовимы с нативными. пишешь 1 приложения, пользуешься на абсолютно любом стационарном или мобильном девайсе

https://caniuse.com/#search=WASM уже поддерживается в основных браузерах таких как Edge, Chrome, Firefox, Safari

та ну, какие 5%, wasm не везде даже js обгоняет

та ну, какие 5%, wasm не везде даже js обгоняет

Тут главное иметь самые актуальные данные, тк ускоряется он довольно быстро

+ GC не помеха UI. если электрон приехал на десктопы уже

> В будущем приложения не будут устанавливаться из app store'ов, достаточно будет зайти на URL, подождать загрузки приложения в cache если загружаем первый раз и вуаля.. такое себе будущее, этакая смесь киберпанка с "навозными веками" =)

та ну, какие 5%, wasm не везде даже js обгоняет

технология молодая, поживём - увидим. Ещё даже потоки не завезли, но вроде как обещают. Однако тот факт что основные браузеры сию инициативу подхватили уже обо многом говорит.

write once - run everywhereгде-то мы это уже слышали... точно! в прошлый раз они назвали это "Java"

> В будущем приложения не будут устанавливаться из app store'ов, достаточно будет зайти на URL, подождать загрузки приложения в cache если загружаем первый раз и вуаля.. такое себе будущее, этакая смесь киберпанка с "навозными веками" =)

На самом деле уже лет 5 обещают подобное будущее, электрон конеш пинает натив, но какими средствами

write once - run everywhereгде-то мы это уже слышали... точно! в прошлый раз они назвали это "Java"

Руст вроде тоже пытается придерживаться этого слогана

+ GC не помеха UI. если электрон приехал на десктопы уже

мы говорим не про логику UI, а про graphics & layout engine, а тут GC stop-the-world может отрицательно сказаться на UX. Даже малейшие паузы могут привести к микро-лагам и потерянным кадрам, а это некрасиво особенно в 2018 году.

Руст вроде тоже пытается придерживаться этого слогана

Но тут про ffi в первую очередь конеш https://blog.rust-lang.org/2015/04/24/Rust-Once-Run-Everywhere.html

> В будущем приложения не будут устанавливаться из app store'ов, достаточно будет зайти на URL, подождать загрузки приложения в cache если загружаем первый раз и вуаля.. такое себе будущее, этакая смесь киберпанка с "навозными веками" =)

ну, таким вижу его лично я. И тенденция говорит сама за себя, 50% рынка - веб, потому-что порог установления приложения - выше, чем порог посещения URL

мы говорим не про логику UI, а про graphics & layout engine, а тут GC stop-the-world может отрицательно сказаться на UX. Даже малейшие паузы могут привести к микро-лагам и потерянным кадрам, а это некрасиво особенно в 2018 году.

В веб based приложениях к этому давно привыкли

50% рынка - веб - очень смелое утверждение

"веб" - это самая верхушечка айсберга

write once - run everywhereгде-то мы это уже слышали... точно! в прошлый раз они назвали это "Java"

Да, вот только в браузере Java не запустится (без плагинов разумеется). Qt тоже прекрасная вещь, но в браузере она не работает. Но именно браузер сейчас является самый главной платформой.

под водой у неё тонны системного софта, тонны железа, очень сложная инфраструктура

Да, вот только в браузере Java не запустится (без плагинов разумеется). Qt тоже прекрасная вещь, но в браузере она не работает. Но именно браузер сейчас является самый главной платформой.

> не запустится Важно: теперь не запустится Запускалась же раньше)

мы говорим не про логику UI, а про graphics & layout engine, а тут GC stop-the-world может отрицательно сказаться на UX. Даже малейшие паузы могут привести к микро-лагам и потерянным кадрам, а это некрасиво особенно в 2018 году.

а на андроиде это как решается? имхо никак и не мешает.

Да, вот только в браузере Java не запустится (без плагинов разумеется). Qt тоже прекрасная вещь, но в браузере она не работает. Но именно браузер сейчас является самый главной платформой.

это от того, что плагины похоронили

а ещё был, прости хоспаде, ActiveX

ну и Silverlight

а флеш даже ещё шевелится местами

в общем не в первый раз у нас впереди светлое (нет) будущее с переносом всего в веб

На самом деле уже лет 5 обещают подобное будущее, электрон конеш пинает натив, но какими средствами

Пока мы не перейдём с HTML/CSS/JS на что-то более подходящее, для написания приложений - ситуация не изменится. HTML/CSS изначально создавался как язык описания статичных документов. То что его сейчас используют для динамики, просто извращение, я сам сейчас этим занимаюсь но никакого удовольствия это не приносит, одни боли. Следственно, если веб как среда улучшится, а к этому всё и идёт - больше приложений будут переходить в браузер по причине меньшего порога доступа к клиенту.

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