Этого треда уже нет.
Это копия, сохраненная 31 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Rust — невероятно быстрый язык для системного программирования без segfault'ов и с гарантиями потокобезопасности.
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и
программирования в целом, поможем вкатывающимся, подскажем что
выбрать для веба, игр или спасибо абу блокчейна.
https://www.rust-lang.org
https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Читать
Оф. книга, она же растбук
https://doc.rust-lang.org/book/
https://rustbyexample.com/
Очень хорошая книга, отлично зайдет после растбука:
http://shop.oreilly.com/product/0636920040385.do
Упражнения
https://exercism.io/tracks/rust
https://github.com/crazymykl/rust-koans
Писать
IDE
https://areweideyet.com/
Вебня
http://www.arewewebyet.org/
Игры
http://arewegameyet.com/
Etc
https://wiki.mozilla.org/Areweyet
Список интересных проектов
https://github.com/rust-unofficial/awesome-rust
Новости
Компиляция всего, что произошло за неделю
Иногда постят вакансии
https://this-week-in-rust.org/
Сколько вешать в лайках
https://github.com/trending/rust
Оп рекомендует:
https://www.amethyst.rs/
ИТТ мы можем объяснить базовые и продвинутые концепции языка, и
программирования в целом, поможем вкатывающимся, подскажем что
выбрать для веба, игр или спасибо абу блокчейна.
https://www.rust-lang.org
> Пачиму helloworld весит как моя мамка?!1й
https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
Читать
Оф. книга, она же растбук
https://doc.rust-lang.org/book/
https://rustbyexample.com/
Очень хорошая книга, отлично зайдет после растбука:
http://shop.oreilly.com/product/0636920040385.do
Упражнения
https://exercism.io/tracks/rust
https://github.com/crazymykl/rust-koans
Писать
IDE
https://areweideyet.com/
Вебня
http://www.arewewebyet.org/
Игры
http://arewegameyet.com/
Etc
https://wiki.mozilla.org/Areweyet
Список интересных проектов
https://github.com/rust-unofficial/awesome-rust
Новости
Компиляция всего, что произошло за неделю
Иногда постят вакансии
https://this-week-in-rust.org/
Сколько вешать в лайках
https://github.com/trending/rust
Оп рекомендует:
https://www.amethyst.rs/
>>299618 (OP)
Лул, второй пик такой маняпик. Ведь если ты пишешь что то больше чем хеллоу ворлд, то весь код надо в ансейф оборачивать.
Лул, второй пик такой маняпик. Ведь если ты пишешь что то больше чем хеллоу ворлд, то весь код надо в ансейф оборачивать.
>>299703
Фантазер. Так делают только те кто пришли из с++ и по другому просто уже не могут.
Фантазер. Так делают только те кто пришли из с++ и по другому просто уже не могут.
>>299707
В С++ можно обходится без сырых указателей, new и delete. Где твой бох теперь?
А ещё там есть лямбды, темплейты, автоматический вывод типов, сементика перемещения, треды, компилторЫ, отладчикИ, IDE с автокомплитом, а самое главное ООП.
В С++ можно обходится без сырых указателей, new и delete. Где твой бох теперь?
А ещё там есть лямбды, темплейты, автоматический вывод типов, сементика перемещения, треды, компилторЫ, отладчикИ, IDE с автокомплитом, а самое главное ООП.
Проиграл с этого флешмоба.
>>299787
Ну дык а хуле тогда в этом решете постоянно дыры находят?
Ну дык а хуле тогда в этом решете постоянно дыры находят?
>>299618 (OP)
650 kilobytes for helloworld - это днище полное.
650 kilobytes for helloworld - это днище полное.
>>299787
Когда сделают С++ хотя бы сильнотипизированным, тогда и приходите. А пока это всё костыли, усложняющие синтаксис и семантику. Пожалуй самые годные вещи в С++ - темплейты и перегрузка, они худо-бедно обеспечивают параметрический и адхок полиморфизм.
Но слабая типизация с этими вашими кастованиями все портит. Кроме того, вещи типа мув семантики, лямбд, умных указателей не избавляют от утечек памяти, а наоборот, делают их еще более не очевидными и усложняют отладку. При этом читаемость кода нихуя не улучшилась.
Язык-костыль, язык-выстрели-себе-в-ногу, язык-хуй-поймешь.
Когда сделают С++ хотя бы сильнотипизированным, тогда и приходите. А пока это всё костыли, усложняющие синтаксис и семантику. Пожалуй самые годные вещи в С++ - темплейты и перегрузка, они худо-бедно обеспечивают параметрический и адхок полиморфизм.
Но слабая типизация с этими вашими кастованиями все портит. Кроме того, вещи типа мув семантики, лямбд, умных указателей не избавляют от утечек памяти, а наоборот, делают их еще более не очевидными и усложняют отладку. При этом читаемость кода нихуя не улучшилась.
Язык-костыль, язык-выстрели-себе-в-ногу, язык-хуй-поймешь.
>>299810
ох блять, откуда вылезите то?
Просто прекрати уже тут серить и съеби.
ох блять, откуда вылезите то?
> https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html
> This strips yet more bits off the binary and weighs 5072 bytes after strip.
Просто прекрати уже тут серить и съеби.
>>299878
Хуже.
Хуже.
>>299618 (OP)
Лучшего языка тред!
Лучшего языка тред!
Шота я не понял, ткнул на рандомный туториал в растбуке, а там
И в таком духе.
И как позвольте им пользоваться тогда, м?
Алсо языку 8 лет, так то. Пора уже быть пёрфект.
> Unfortunately, the Rust compiler isn’t perfect yet
> Rust is still a work in progress
> compiler could be improved, but in the future
И в таком духе.
И как позвольте им пользоваться тогда, м?
Алсо языку 8 лет, так то. Пора уже быть пёрфект.
>>300103
Потому что это правда. Например nll который завезут в декабре сделает борроу-чекер намного приятней в использовании. Сделает ли это язык пёрфект? Конечно нет.
Компилятор крестов и сам язык пилят уже хер знает сколько десятков лет, а он все еще ни капли не пёрфект.
Потому что это правда. Например nll который завезут в декабре сделает борроу-чекер намного приятней в использовании. Сделает ли это язык пёрфект? Конечно нет.
Компилятор крестов и сам язык пилят уже хер знает сколько десятков лет, а он все еще ни капли не пёрфект.
>>300107
Еще точно не скоро. Я сам юзаю обычные Future и мне в целом норм. Но боли было очень много пока я осилил.
Плюс есть https://github.com/alexcrichton/futures-await
Еще точно не скоро. Я сам юзаю обычные Future и мне в целом норм. Но боли было очень много пока я осилил.
Плюс есть https://github.com/alexcrichton/futures-await
>>299813
-Werror -Wpedantic
Вот и не соберется без явного преобразования.
А как реализовать адхок полиморфизм без преобразований типов? Кароч отсутсвие возможности что то сделать фича раста.
-Werror -Wpedantic
Вот и не соберется без явного преобразования.
А как реализовать адхок полиморфизм без преобразований типов? Кароч отсутсвие возможности что то сделать фича раста.
>>299813
это значило бы отказаться от совместимости с си, те отказаться от нетипизированного указателя и неявных преобразований в си-стиле
но в современном с++ это и не используют
потому что в тех случаях когда нужен был нетипизированный указатель (например, для adt) используются шаблоны, а для задания преобразований для типов есть масса способов, начиная хотя бы с задания явного оператора преобразования к типу в классе и конструкторов преобразования
>Когда сделают С++ хотя бы сильнотипизированным
это значило бы отказаться от совместимости с си, те отказаться от нетипизированного указателя и неявных преобразований в си-стиле
но в современном с++ это и не используют
потому что в тех случаях когда нужен был нетипизированный указатель (например, для adt) используются шаблоны, а для задания преобразований для типов есть масса способов, начиная хотя бы с задания явного оператора преобразования к типу в классе и конструкторов преобразования
>Компилятор крестов и сам язык пилят уже хер знает сколько десятков лет, а он все еще ни капли не пёрфект.
>Компилятор крестов
какой из?
>>300237
А с (void*) соберется?
Перегрузка методов же. Зачем какие-то преобразования?
>>300252
Темплейты - это параметрический.
>>300257
с++ и так вобщем-то отказался от совместимости с си: как на уровне исходников - си не является подмножеством с++, так и на уровне бинарников - настандартизированный name mangling этому способствует.
>Вот и не соберется без явного преобразования.
А с (void*) соберется?
>А как реализовать адхок полиморфизм без преобразований типов?
Перегрузка методов же. Зачем какие-то преобразования?
>>300252
Темплейты - это параметрический.
>>300257
>это значило бы отказаться от совместимости с си
с++ и так вобщем-то отказался от совместимости с си: как на уровне исходников - си не является подмножеством с++, так и на уровне бинарников - настандартизированный name mangling этому способствует.
>>300237
Там есть динамик диспатч с явным преобразованием.
>А как реализовать адхок полиморфизм без преобразований типов? Кароч отсутсвие возможности что то сделать фича раста.
>
Там есть динамик диспатч с явным преобразованием.
>>300252
А это в рантайме работает? Например у меня есть интерфес для объекта, в рантайме можно выбрать квадрат или круг. Интрфейсу все равно что выбрано у всех объетов есть метод draw().
Как это сделать в расте?
А это в рантайме работает? Например у меня есть интерфес для объекта, в рантайме можно выбрать квадрат или круг. Интрфейсу все равно что выбрано у всех объетов есть метод draw().
Как это сделать в расте?
>>300444
Нагляднее вот так:
foo(if rand::random() { &Square{side: 42} } else { &Circle{radius: 13} });
На шёл статейку:
https://alschwalm.com/blog/static/2017/03/07/exploring-dynamic-dispatch-in-rust/
Дискас?
Нагляднее вот так:
foo(if rand::random() { &Square{side: 42} } else { &Circle{radius: 13} });
На шёл статейку:
https://alschwalm.com/blog/static/2017/03/07/exploring-dynamic-dispatch-in-rust/
Дискас?
>>300478
https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=4f3fb2236fcbd67c64d0fbde88157170
Не очень понимаю че автор хотел.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=4f3fb2236fcbd67c64d0fbde88157170
Не очень понимаю че автор хотел.
https://www.reddit.com/r/rust/comments/9zuk09/rust_in_aaa_game_engine/
> C++
> On the last game we shipped, in my team about 75% of the last year was spent on issues that Rust promises to prevent. Double free, Dangling pointers, out of bound access, threading issues, non initalized variable, null pointer, etc.
>>300577
Камикадзе, проснись, ты обосрался.
Камикадзе, проснись, ты обосрался.
Почему среди обилия великолепных языков программирования вы выбрали именно раст? Чего вам не хватало-то?
>>300773
0) Статическая типизация
1) Дженерики
2) Лямбды
3) Отсутсвие ГЦ
4) Производительность
5) Нет главных проблем крестов: Double free, Dangling pointers, out of bound access, threading issues, non initalized variable, null pointer, etc.
5) Компиляция в бинарник
Лично я жду когда игровые движки допилят до вменяемого состояния.
0) Статическая типизация
1) Дженерики
2) Лямбды
3) Отсутсвие ГЦ
4) Производительность
5) Нет главных проблем крестов: Double free, Dangling pointers, out of bound access, threading issues, non initalized variable, null pointer, etc.
5) Компиляция в бинарник
Лично я жду когда игровые движки допилят до вменяемого состояния.
727 Кб, 900x563>>300773
>>обилия великолепных языков программирования
>тонны легаси-говна почти в каждом языке, которое не вычищают ради обратной совместимости. вплоть до шизы вроде поддержки обратной совместимости с багами, как в C#
>широко используемых языка без GC вообще только 2
>>обилия великолепных языков программирования
>>300870
Для индексирования — насколько я знаю нет.
Альтернативы (для вектора):
v.get(index) -> Option<T>
unsafe {
v.get_uncheked(index) -> T
}
Для индексирования — насколько я знаю нет.
Альтернативы (для вектора):
v.get(index) -> Option<T>
unsafe {
v.get_uncheked(index) -> T
}
>>300875
Мань, хаскель конечно хорош, но у нас тут язык для системного программирования с минимальным оверхедом и без гц.
Мань, хаскель конечно хорош, но у нас тут язык для системного программирования с минимальным оверхедом и без гц.
>>300883
Нет, братишка, я занимаюсь геймдевом, и знаю что такое требования к производительности не по наслышке.
Нет, братишка, я занимаюсь геймдевом, и знаю что такое требования к производительности не по наслышке.
>>300867
Чем D лучше Rust?
Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано. Вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО. Исключение где Rust может быть реально полезен могут составлять только Embedded и hard real-time системы. Однако это капля в море разрабатываемого софта. На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным. Так же стоит отметить очень свобразный апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода. D в этом отношении гораздо проще и универсальнее. К тому же в D есть режим `betterC` позволяющий использовать ручное управление памятью и сводящий 80% преимуществ Rust к нулю.
http://dlang.ru/faq
Чем D лучше Rust?
Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано. Вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО. Исключение где Rust может быть реально полезен могут составлять только Embedded и hard real-time системы. Однако это капля в море разрабатываемого софта. На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным. Так же стоит отметить очень свобразный апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода. D в этом отношении гораздо проще и универсальнее. К тому же в D есть режим `betterC` позволяющий использовать ручное управление памятью и сводящий 80% преимуществ Rust к нулю.
http://dlang.ru/faq
>>300888
Сто раз уже обсуждали.
1) Без ГЦ D не нужен
2) У нас на 10к строк растокода лайфтаймы есть в основном в определнии структур с реферансами (тривиально), либо в редким хитровыебаных трейтах, которые пишутся один раз.
3) Для того чтобы писать на си/++ точно так же нужно понимать lifetime & ownership, с той разницей что компилятор тебе не поможет.
Сто раз уже обсуждали.
1) Без ГЦ D не нужен
2) У нас на 10к строк растокода лайфтаймы есть в основном в определнии структур с реферансами (тривиально), либо в редким хитровыебаных трейтах, которые пишутся один раз.
3) Для того чтобы писать на си/++ точно так же нужно понимать lifetime & ownership, с той разницей что компилятор тебе не поможет.
>>300888
Вообще такое то говно там написано. Большая часть заявлений это просто пук без какой-либо аргументации, например
Вот я пишу энтерпрайз на расте, и вроде как пока не разорилась контора. И чо?
Это про что вообще?
Охуеть, чтобы писать код, нужно знать язык и используемые в нем концепции.
Вообще пушка. КОД НЕ КАК В МОЕМ ЛЮБИМОМ %ЯЗЫК_НЕЙМ% ВЫГЛЯДИТ, ЗНАЧИТ ГОВНО
Там есть борроу чекер, лайфтаймы, овнершим и иммутабельность по умолчанию? Если да, то тогда это можно зачесть за аргумент.
ясно-понятно
Вообще такое то говно там написано. Большая часть заявлений это просто пук без какой-либо аргументации, например
> Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано
Вот я пишу энтерпрайз на расте, и вроде как пока не разорилась контора. И чо?
> указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО
Это про что вообще?
> На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership.
Охуеть, чтобы писать код, нужно знать язык и используемые в нем концепции.
> апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода
Вообще пушка. КОД НЕ КАК В МОЕМ ЛЮБИМОМ %ЯЗЫК_НЕЙМ% ВЫГЛЯДИТ, ЗНАЧИТ ГОВНО
> в D есть режим `betterC` позволяющий использовать ручное управление памятью
Там есть борроу чекер, лайфтаймы, овнершим и иммутабельность по умолчанию? Если да, то тогда это можно зачесть за аргумент.
> сводящий 80% преимуществ Rust к нулю
ясно-понятно
99% раст треды - жуткий срач. Хотя, даже мне, крестофилу, видны достоинства раста.
Пора комикс запилить.
Пора комикс запилить.
>>300908
99% любых языко-тредов это срач, разве нет?
99% любых языко-тредов это срач, разве нет?
Посоны, учитывая бурное развитие языка, через сколько лет он обрастёт легаси-говном ради обратной совместимости?
>>300915
RFC процесс довольно неплохо позволяет не пихать в язык говно, которое потенциально принесет проблемы.
Так что пока что можно не бояться.
RFC процесс довольно неплохо позволяет не пихать в язык говно, которое потенциально принесет проблемы.
Так что пока что можно не бояться.
ИЩЕШЬ В КАКОЙ БЫ СИСТЕМНЫЙ ЯЗЫК ВКАТИТЬСЯ
@
ПРОБУЕШЬ НЯШНУЮ - УЧИШЬСЯ НЕ ПРОГАНЬЮ, А КАК НЕ СТУПИТЬ В ДРЕВНЕЕ ДЕРЬМО ДИДОВ
@
СМОТРИШЬ В СТОРОНУ КРЕСТОВ - ТО ЖЕ САМОЕ, ТОЛЬКО КОНЦА И КРАЯ ДЕРЬМУ НЕ ВИДАТЬ
@
ПЫТАЕШЬСЯ ОБМАЗАТЬСЯ РЖАВЧИНОЙ - СЛОЖНО ППЦ, СЛОВНО НЕ ДЛЯ ЛЮДЕЙ ПРИДУМЫВАЛИ
@
НАКОНЕЦ НАХОДИШЬ АДЕКВАТНЫЙ ЯЗЫК - ДВИЖУХА НА НЕМ МАЛЕНЬКАЯ, ВАКАНСИЙ С ГУЛЬКИН НОС
@
СИДИШЬ НЕДОВОЛЬНО УРЧИШЬ
@
ПРОБУЕШЬ НЯШНУЮ - УЧИШЬСЯ НЕ ПРОГАНЬЮ, А КАК НЕ СТУПИТЬ В ДРЕВНЕЕ ДЕРЬМО ДИДОВ
@
СМОТРИШЬ В СТОРОНУ КРЕСТОВ - ТО ЖЕ САМОЕ, ТОЛЬКО КОНЦА И КРАЯ ДЕРЬМУ НЕ ВИДАТЬ
@
ПЫТАЕШЬСЯ ОБМАЗАТЬСЯ РЖАВЧИНОЙ - СЛОЖНО ППЦ, СЛОВНО НЕ ДЛЯ ЛЮДЕЙ ПРИДУМЫВАЛИ
@
НАКОНЕЦ НАХОДИШЬ АДЕКВАТНЫЙ ЯЗЫК - ДВИЖУХА НА НЕМ МАЛЕНЬКАЯ, ВАКАНСИЙ С ГУЛЬКИН НОС
@
СИДИШЬ НЕДОВОЛЬНО УРЧИШЬ
>>300961
Ты про дэ что ли?
>НАКОНЕЦ НАХОДИШЬ АДЕКВАТНЫЙ ЯЗЫК - ДВИЖУХА НА НЕМ МАЛЕНЬКАЯ, ВАКАНСИЙ С ГУЛЬКИН НОС
Ты про дэ что ли?
>>300961
Может хоть кто-нибудь внятно объяснить, что там такого сложного и не для людей?
> ПЫТАЕШЬСЯ ОБМАЗАТЬСЯ РЖАВЧИНОЙ - СЛОЖНО ППЦ, СЛОВНО НЕ ДЛЯ ЛЮДЕЙ ПРИДУМЫВАЛИ
Может хоть кто-нибудь внятно объяснить, что там такого сложного и не для людей?
>>300966
Да нет ничего сложного. кроме futures, которые тоже не сложные, просто ебать какие неэргономичные. Просто неосиляторы привыкли не до конца понятый код запускать в прод.
Да нет ничего сложного. кроме futures, которые тоже не сложные, просто ебать какие неэргономичные. Просто неосиляторы привыкли не до конца понятый код запускать в прод.
>>300964
Писал на нем. Не очень, если честно.
Писал на нем. Не очень, если честно.
>>300964
На сишке компилятор надо еще сделать.
На сишке компилятор надо еще сделать.
>>300888
кстати, а где нормальные бенчмарки дишки глянуть для сравнения с растом?
тут почему-то нет https://benchmarksgame-team.pages.debian.net/benchmarksgame/
>Чем D лучше Rust?
кстати, а где нормальные бенчмарки дишки глянуть для сравнения с растом?
тут почему-то нет https://benchmarksgame-team.pages.debian.net/benchmarksgame/
>>301362
Не густо для языка который появился в 2001
Не густо для языка который появился в 2001
>>300967
Я сам их не осилил, как бы не было стыдно. Вообще не вдупляю всю эту асинхронщину ебаную. Один раз пришлось потрогать actix-web (там как раз тиоже вроде эта поебень используется), так было прям больно.
Может есть какие материалы, чтобы вкатиться в асинхронщину? Или хоть идея, чтобы разобраться в этой хуйне?
> кроме futures, которые тоже не сложные, просто ебать какие неэргономичные
Я сам их не осилил, как бы не было стыдно. Вообще не вдупляю всю эту асинхронщину ебаную. Один раз пришлось потрогать actix-web (там как раз тиоже вроде эта поебень используется), так было прям больно.
Может есть какие материалы, чтобы вкатиться в асинхронщину? Или хоть идея, чтобы разобраться в этой хуйне?
>>301575
Ну мне помогло понимае как промизы в жс-дристне работают.
Ну мне помогло понимае как промизы в жс-дристне работают.
>>299618 (OP)
Напомните-ка мне, почему раст параша и не взлетел?
Напомните-ка мне, почему раст параша и не взлетел?
>>301722
Смешное название потому что, кто хочет быть программистом на педерасте?
>раст параша и не взлетел?
Смешное название потому что, кто хочет быть программистом на педерасте?
>>301722
потому что хомячкам проще говнокодить в плюсах
потому что хомячкам проще говнокодить в плюсах
>>301722
А в чём магия на первой пикче? Всё понятно же вроде.
А в чём магия на первой пикче? Всё понятно же вроде.
>>301722
зато не обосрешься с lifetime-ами объектов
охуенная идея, аж стало любопытно раст потыкать
эксперты, вопрос: насколько эффективно проверка на borrow совмещается с многопоточностью?
>magic
зато не обосрешься с lifetime-ами объектов
охуенная идея, аж стало любопытно раст потыкать
эксперты, вопрос: насколько эффективно проверка на borrow совмещается с многопоточностью?
>>301930
Охуено сочетается. Компилятор не даст тебе отправить в соседний тред значение если оно не Send/Sync.
То есть компилято заставить тебя завернуть свое говно в Arc/Mutex
Охуено сочетается. Компилятор не даст тебе отправить в соседний тред значение если оно не Send/Sync.
То есть компилято заставить тебя завернуть свое говно в Arc/Mutex
>>300964
поздровляю вы изобрели мозготрах
поздровляю вы изобрели мозготрах
207 Кб, 745x555Принес вам немножко новостей.
Результаты третьего ежегодного опроса:
https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
https://github.com/firecracker-microvm/firecracker
Результаты третьего ежегодного опроса:
https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
> Secure and fast microVMs for serverless computing.
https://github.com/firecracker-microvm/firecracker
Анончик, я тут еду на конфу и взял себе билет по которому вы можете пройти нахаляву. Кому интересно — https://rustrush.ru
>>304863
Зато он решает некоторое говно: https://blog.rust-lang.org/2018/11/29/a-new-look-for-rust-lang-org.html
Зато он решает некоторое говно: https://blog.rust-lang.org/2018/11/29/a-new-look-for-rust-lang-org.html
>>305242
у меня слишком подгорает, поэтому все таки высру свое охуенно важное мнение
Не понимаю, какое говно он решает.
Как раз объясняет. Я сразу вижу фичи, которые выделают язык. И понимаю, почему мне нужно выбрать его, на не, например, джаву.
Новый слоган:
А, то есть язык тупо для ОС и микроконтроллеров, ясно-понятно, пойду на го писать микросервисы. Нет, серьезно, язык отличный для написания чего угодно, но нет, СИСТЕМНЫЙ ПРОГРАММИСТ.
Вон из профессии таких программистов (ну или обратно на первый курс).
Ну и тащемта то, чего не хватало на старой версии: ссылок на различны ресурсы экосистемы раста: crates.io, play.rust-lang.org (даже песочницу убрали, суки). Какой-нибудь This Week in Rust. Но нееееет, давайте сделаем ебучий лендинг с маркетинговой хуйней для даунов и кучей пустого места, блять.
Вон D (https://dlang.org/) имеет очень хороший, как по мне, сайт. Может не такой "красивый", но сразу можно и код увидеть, и что и нахуя надо, все ссылочки в верхней панели красиво есть (и выпадающие списки, Карл). Годнота.
у меня слишком подгорает, поэтому все таки высру свое охуенно важное мнение
Не понимаю, какое говно он решает.
> In other words, this list:
> zero-cost abstractions
> move semantics
> ...
> doesn’t explain what you can do with Rust
Как раз объясняет. Я сразу вижу фичи, которые выделают язык. И понимаю, почему мне нужно выбрать его, на не, например, джаву.
Новый слоган:
> Rust: The programming language that empowers everyone to become a systems programmer.
А, то есть язык тупо для ОС и микроконтроллеров, ясно-понятно, пойду на го писать микросервисы. Нет, серьезно, язык отличный для написания чего угодно, но нет, СИСТЕМНЫЙ ПРОГРАММИСТ.
>Even if people have different ideas about what “systems programming” means, they at least have some idea. “guarantees thread safety,” not so much.
Вон из профессии таких программистов (ну или обратно на первый курс).
Ну и тащемта то, чего не хватало на старой версии: ссылок на различны ресурсы экосистемы раста: crates.io, play.rust-lang.org (даже песочницу убрали, суки). Какой-нибудь This Week in Rust. Но нееееет, давайте сделаем ебучий лендинг с маркетинговой хуйней для даунов и кучей пустого места, блять.
Вон D (https://dlang.org/) имеет очень хороший, как по мне, сайт. Может не такой "красивый", но сразу можно и код увидеть, и что и нахуя надо, все ссылочки в верхней панели красиво есть (и выпадающие списки, Карл). Годнота.
>>305890
Ну а ты не думал о том, что сайт нужен как раз чтобы продавать продукт даунам? Остальные и так разберутся. Может поэтому этот ваш Д такой мертвый?
Ну а ты не думал о том, что сайт нужен как раз чтобы продавать продукт даунам? Остальные и так разберутся. Может поэтому этот ваш Д такой мертвый?
>>305926
Не думаю. Вкатываться в программирование ты почти гарантированно будешь через что-то более мейнстримовое. Расту до этого ОЧЕНЬ ДАЛЕКО (я вживую не видел людей, у которых раст был первым языком). А вот тех кто перекатился видел (целый, блять, офис). И этот сайт вообще никак этому не способствует.
Хз, я на нем не пишу.
Короче на само деле это вкусовщина, каждому свое, но жаль, что убрали песочницу, это действительно прикольная штука, и есть почти везде. Сразу дает минимальное представление о том, что же за язык.
> Ну а ты не думал о том, что сайт нужен как раз чтобы продавать продукт даунам?
Не думаю. Вкатываться в программирование ты почти гарантированно будешь через что-то более мейнстримовое. Расту до этого ОЧЕНЬ ДАЛЕКО (я вживую не видел людей, у которых раст был первым языком). А вот тех кто перекатился видел (целый, блять, офис). И этот сайт вообще никак этому не способствует.
> Может поэтому этот ваш Д такой мертвый?
Хз, я на нем не пишу.
Короче на само деле это вкусовщина, каждому свое, но жаль, что убрали песочницу, это действительно прикольная штука, и есть почти везде. Сразу дает минимальное представление о том, что же за язык.
>>301777
Что не так?
Что не так?
>>299618 (OP)
Можете пояснить, где в играх можно применить раст? Директ икс же написан на крестах. Опенжл на сишке. То есть вся графика с использованием аппаратного ускорения работает на сях. При этом большинство игровых движков так или иначе работают так же на сях. Край энжин - кресты. Анрил - кресты. Юнити - сисярп.
Или это все планируется в будущем? Насколько далеком? Вы точно уверены, что нвидия и мелкософт уволит своих индусов-крестоебов и наймет заместо них школьников-растоебов, чтобы переписать весь прилагающийся к работе с графикой софт?
Можете пояснить, где в играх можно применить раст? Директ икс же написан на крестах. Опенжл на сишке. То есть вся графика с использованием аппаратного ускорения работает на сях. При этом большинство игровых движков так или иначе работают так же на сях. Край энжин - кресты. Анрил - кресты. Юнити - сисярп.
Или это все планируется в будущем? Насколько далеком? Вы точно уверены, что нвидия и мелкософт уволит своих индусов-крестоебов и наймет заместо них школьников-растоебов, чтобы переписать весь прилагающийся к работе с графикой софт?
>>306761
Повторюсь, все что расту осталось для успеха - это отдрочка компилятора до уровня Clang/GCC.
Повторюсь, все что расту осталось для успеха - это отдрочка компилятора до уровня Clang/GCC.
>>306761
Тащемта ничего тебе не мешает писать код, использующий OpenGL, на любом удобном тебе языке. Уверен, что и DirectX также. А сишный интерфейс это хорошо, легко интегрируется с любым языком.
Я думаю, что в большом геймдеве есть следующая проблема: консоли. И вот хрен знает, можно ли под них вообще сейчас хоть как-то писать на расте. А почти все игры это кроссплатформа. Надо чтобы кто-то запилил весь инструментарий, тогда взлетит. А мало кто захочет тратить свои кровные на эту хуйню, ведь и так работает, чо трогать то.
>>306794
Что значит отдрочка до уровня Clang/GCC? По каким параметрам сравнивать? Типа скорость компиляции или чего? Ну и да, там даже Clang сосет у GCC все еще.
> Опенжл на сишке
Тащемта ничего тебе не мешает писать код, использующий OpenGL, на любом удобном тебе языке. Уверен, что и DirectX также. А сишный интерфейс это хорошо, легко интегрируется с любым языком.
Я думаю, что в большом геймдеве есть следующая проблема: консоли. И вот хрен знает, можно ли под них вообще сейчас хоть как-то писать на расте. А почти все игры это кроссплатформа. Надо чтобы кто-то запилил весь инструментарий, тогда взлетит. А мало кто захочет тратить свои кровные на эту хуйню, ведь и так работает, чо трогать то.
>>306794
Что значит отдрочка до уровня Clang/GCC? По каким параметрам сравнивать? Типа скорость компиляции или чего? Ну и да, там даже Clang сосет у GCC все еще.
>>306862
Оптимизация кода.
>Что значит отдрочка до уровня Clang/GCC? По каким параметрам сравнивать? Типа скорость компиляции или чего? Ну и да, там даже Clang сосет у GCC все еще.
Оптимизация кода.
>>306875
Раст и Clang используют один и тот же LLVM, только при максимальной оптимизации не включают некоторые опасные модификации кода.
Раст и Clang используют один и тот же LLVM, только при максимальной оптимизации не включают некоторые опасные модификации кода.
>>303677
а тем временем из goвна и палок запилили posix-совместимое ядро https://www.linux.org.ru/news/opensource/14653611/
а тем временем из goвна и палок запилили posix-совместимое ядро https://www.linux.org.ru/news/opensource/14653611/
>>303677
Ferris is the unofficial mascot of the Rust Community. Many Rust programmers call themselves “Rustaceans,” a play on the word “crustacean.” We refer to Ferris with the pronouns “they,” “them,” etc., rather than with gendered pronouns.
Ferris is the unofficial mascot of the Rust Community. Many Rust programmers call themselves “Rustaceans,” a play on the word “crustacean.” We refer to Ferris with the pronouns “they,” “them,” etc., rather than with gendered pronouns.
>people often assume that Ferris is a boy and use (he/him), but Ferris is non binary
>>306875
А как их сравнивать? То есть как понять что вот один код оптимизирован лучше другого?
А как их сравнивать? То есть как понять что вот один код оптимизирован лучше другого?
>>307000
Ferris это ж вроде мужское имя.
Ferris это ж вроде мужское имя.
>>307037
ого, круто! прогрессивные модные девчонки в команде раста, которые открыты для самых смелых предложенийгусары, молчать!, не то что заскорузлые комитетчики от древних языков программирования! всё, решено - после си буду учить раст!
ого, круто! прогрессивные модные девчонки в команде раста, которые открыты для самых смелых предложенийгусары, молчать!, не то что заскорузлые комитетчики от древних языков программирования! всё, решено - после си буду учить раст!
Я правильно понял, что в расте нельзя безопасно заанрапить, не создавая скоуп иф лета? Что-то типа
guard let Some(n) = s else {
return
}
println!("{}", n)
Выходит вложенность скобочек будет все больше и больше с каждой проверкой опшионалов?
guard let Some(n) = s else {
return
}
println!("{}", n)
Выходит вложенность скобочек будет все больше и больше с каждой проверкой опшионалов?
>>307518
Почему?
>>307533
Что за муть ты написал? Смотри методы тут: https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or
Почему?
>>307533
Что за муть ты написал? Смотри методы тут: https://doc.rust-lang.org/std/option/enum.Option.html#method.unwrap_or
>>307565
Ashley Williams (ныне член Rust core team, Wasm WG и одна из ответственных за новый сайт) ранее состояла в совете директоров Node.js Foundation, но покинула его из-за обвинений в "поощрении насилия в отношения мужчин".
https://theoutline.com/post/2206/the-node-js-code-of-conduct-diversity-tech
Ashley Williams (ныне член Rust core team, Wasm WG и одна из ответственных за новый сайт) ранее состояла в совете директоров Node.js Foundation, но покинула его из-за обвинений в "поощрении насилия в отношения мужчин".
https://theoutline.com/post/2206/the-node-js-code-of-conduct-diversity-tech
>>307797
Лол, мы же нормальные люди, а не какие то рад-фемки чтобы решать проблемы насилием.
Лол, мы же нормальные люди, а не какие то рад-фемки чтобы решать проблемы насилием.
>>307804
Выебать?
Выебать?
>>307795
то есть это какой-то анонимус с реддита напел, крутой источник, чо
>из-за обвинений в "поощрении насилия в отношения мужчин"
>according to an anonymous Reddit post
то есть это какой-то анонимус с реддита напел, крутой источник, чо
АХахахахахах. У вас даже сайт говно стал.
Я вообще поражаюсь, как здесь с серьезным лицом можно что-то делать. Мертвый язык. Даже рельсы живее говнораста.
Я вообще поражаюсь, как здесь с серьезным лицом можно что-то делать. Мертвый язык. Даже рельсы живее говнораста.
>>308097
Математику и какой-нить фреймворк для рисования. От ебли с шейдерами до канваса в браузере.
Математику и какой-нить фреймворк для рисования. От ебли с шейдерами до канваса в браузере.
Ржавчина или Питон?
Было бы не плохо вкатиться в системку, т.к иногда NodeJS не выезжает Хотел 10MB wav через марковскую цепь пропустить, а он вылетает
Было бы не плохо вкатиться в системку, т.к иногда NodeJS не выезжает Хотел 10MB wav через марковскую цепь пропустить, а он вылетает
>>308235
Ничего из этого. В первом и втором педерастия. Бери пхп или руби на рельсах.
Ничего из этого. В первом и втором педерастия. Бери пхп или руби на рельсах.
>>300468
Как же я блядь не выношу этих ебанных англоговорящих дикторов.
Как же я блядь не выношу этих ебанных англоговорящих дикторов.
Посоны в расте можно сделать чтобы распараллеливались вычисления в виде описаном ниже?
Например есть масcив из 1000 элементов координат точек x и y;
Mass vector2D = new Mass();
vector2D.add(X, Y); и так 1000 раз
И нужно что бы для отрисовки этих точек использовался не один процессор а 4.
Paralleling.Draw(vector2D.pos(0, 249))
Paralleling.Draw(vector2D.pos(250, 449))
Paralleling.Draw(vector2D.pos(500, 749))
Paralleling.Draw(vector2D.pos(750, 999))
Тогда на экране в 4 раза быстрее отрисуются точки нежели с одним процессором.
В расте такое возможно?
Например есть масcив из 1000 элементов координат точек x и y;
Mass vector2D = new Mass();
vector2D.add(X, Y); и так 1000 раз
И нужно что бы для отрисовки этих точек использовался не один процессор а 4.
Paralleling.Draw(vector2D.pos(0, 249))
Paralleling.Draw(vector2D.pos(250, 449))
Paralleling.Draw(vector2D.pos(500, 749))
Paralleling.Draw(vector2D.pos(750, 999))
Тогда на экране в 4 раза быстрее отрисуются точки нежели с одним процессором.
В расте такое возможно?
>>308525
Чот мне кажется отрисовка всегда из одного треда идет и твое распараллеливание не будет иметь смысла.
Чот мне кажется отрисовка всегда из одного треда идет и твое распараллеливание не будет иметь смысла.
206 Кб, 506x1024>>308525
Раст, какой бы хуйнёй без задач он ни был, тут ни при чём. За рисование отвечает видеодрайвер. Твой Draw() где-то внутри вызовет функцию графического апи, которая вызовет видеодрайвер. Драйвер же собирает вызовы в списки команд и в некие моменты шлёт списки на исполнение в GPU. Ну или в CPU через софтверный рендерер, если GPU не завезли, но на него всё равно никак не повлиять. Так вот, поскольку обычно GPU только один, то подумай, насколько вырастет производительность при вызове Draw из нескольких потоков по сравнению с одним потоком. Ни насколько, даже упадёт из-за оверхеда при переключении сначала контекста треда, а потом, что хуже, контекста графического api. Но даже если бы в системе стояло три 1080 в SLI, это бы не сильно помогло: драйвер назначит одну из карт мастером, и этот мастер будет выдавать остальным карточкам некоторые наивно распараллеливающиеся последовательности команд в очереди выполнения. То есть прирост специфичен для некоторых операций, а стоимость ожидания ответа от слэйвов может и превысить профит. Специально для решения проблем мультипоточности придумали Vulkan, в котором можно руками сабмитить списки команд в очереди выполнения драйвера, а самим очередям добавили простые примитивы синхронизации, чтобы можно было управлять порядком выполнения.
Но конкретно для того, чтобы рисовать точки с максимальной скоростью, не нужны ни многопоточность, ни вулкан, достаточно базового знания графического апи. Просто почитай про hardware instancing для своего любимого апи. Например, в ogl это засунуть все точки в один VBO и отрисовать его через glDrawArrays(GL_POINTS...)
Раст, какой бы хуйнёй без задач он ни был, тут ни при чём. За рисование отвечает видеодрайвер. Твой Draw() где-то внутри вызовет функцию графического апи, которая вызовет видеодрайвер. Драйвер же собирает вызовы в списки команд и в некие моменты шлёт списки на исполнение в GPU. Ну или в CPU через софтверный рендерер, если GPU не завезли, но на него всё равно никак не повлиять. Так вот, поскольку обычно GPU только один, то подумай, насколько вырастет производительность при вызове Draw из нескольких потоков по сравнению с одним потоком. Ни насколько, даже упадёт из-за оверхеда при переключении сначала контекста треда, а потом, что хуже, контекста графического api. Но даже если бы в системе стояло три 1080 в SLI, это бы не сильно помогло: драйвер назначит одну из карт мастером, и этот мастер будет выдавать остальным карточкам некоторые наивно распараллеливающиеся последовательности команд в очереди выполнения. То есть прирост специфичен для некоторых операций, а стоимость ожидания ответа от слэйвов может и превысить профит. Специально для решения проблем мультипоточности придумали Vulkan, в котором можно руками сабмитить списки команд в очереди выполнения драйвера, а самим очередям добавили простые примитивы синхронизации, чтобы можно было управлять порядком выполнения.
Но конкретно для того, чтобы рисовать точки с максимальной скоростью, не нужны ни многопоточность, ни вулкан, достаточно базового знания графического апи. Просто почитай про hardware instancing для своего любимого апи. Например, в ogl это засунуть все точки в один VBO и отрисовать его через glDrawArrays(GL_POINTS...)
>>308785
Получается что все игровые движки так или иначе работают с api Direx, Vulkan, OpenGL, а сам по себе язык не может через видяху все это отрисовать кроме как через CPU.
Получается что все игровые движки так или иначе работают с api Direx, Vulkan, OpenGL, а сам по себе язык не может через видяху все это отрисовать кроме как через CPU.
>>308818
Тогда используй опенжл, дх, вулканы итд.
Тогда используй опенжл, дх, вулканы итд.
>>308800
Даже этого не может, потому что даже в ДОСе, где вывод на экран делался через запись по какому-то адресу, нужна была отдельная железка для отправки изображения на монитор.
>а сам по себе язык не может через видяху все это отрисовать кроме как через CPU.
Даже этого не может, потому что даже в ДОСе, где вывод на экран делался через запись по какому-то адресу, нужна была отдельная железка для отправки изображения на монитор.
>>299618 (OP)
Поясните пару моментов:
1) Почему раст не взлетел?
2) Быстрее ли раст чем си++?
3) Что надо сделать, чтобы раст был популярен?
Поясните пару моментов:
1) Почему раст не взлетел?
2) Быстрее ли раст чем си++?
3) Что надо сделать, чтобы раст был популярен?
>>309315
1) Кто сказал что он не взлетел?
2) Смотря кто, как и что измеряет
3) Что по твоему популярность? Вот это: https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted показатель популярности?
1) Кто сказал что он не взлетел?
2) Смотря кто, как и что измеряет
3) Что по твоему популярность? Вот это: https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted показатель популярности?
>>309324
1) Статистика
https://insights.stackoverflow.com/survey/2018/#technology
2) Мне надо быть уверенным, что аналогичный код переписанный с c++ на раст будет быстрее.
3) Популярность, как правило, это количество работ и потребность в разработчиках для бизнеса.
1) Статистика
https://insights.stackoverflow.com/survey/2018/#technology
2) Мне надо быть уверенным, что аналогичный код переписанный с c++ на раст будет быстрее.
3) Популярность, как правило, это количество работ и потребность в разработчиках для бизнеса.
>>309334
Раст взлетел. Хочешь работу? Учи жабу[скрипт]. Хочешь чтобы было быстро, больно и дешманскую работу, учи кресты. Чтобы раст был популярен нужно чтобы люди начали думать о том, как типы помогают решать проблемы.
Раст взлетел. Хочешь работу? Учи жабу[скрипт]. Хочешь чтобы было быстро, больно и дешманскую работу, учи кресты. Чтобы раст был популярен нужно чтобы люди начали думать о том, как типы помогают решать проблемы.
>>309346
Вот руби взлетел, да, вроде и ебанутый язык.
По твоей логике и D взлетел.
Значит раст таки еще один высер без задач?
Зачем же он нужен такой медленный?
>Раст взлетел.
Вот руби взлетел, да, вроде и ебанутый язык.
По твоей логике и D взлетел.
>Хочешь чтобы было быстро
Значит раст таки еще один высер без задач?
Зачем же он нужен такой медленный?
>>309346
Чот крикнул с помощи типов в языке где система типа по выразительности находится на уровне Java
Чот крикнул с помощи типов в языке где система типа по выразительности находится на уровне Java
>>309315
Потому что он лезет туда где не привыкли прыгать и всё переписывать на каждую новую модную хуйню. Потихоньку растёт популярность и хорошо.
Чудес не бывает. Скорость на уровне цпп это уже очень заебись. Сокращение времени на написание и отладку кода тоже очень хорошо.
Он и так достаточно популярен.
> 1) Почему раст не взлетел?
Потому что он лезет туда где не привыкли прыгать и всё переписывать на каждую новую модную хуйню. Потихоньку растёт популярность и хорошо.
> 2) Быстрее ли раст чем си++?
Чудес не бывает. Скорость на уровне цпп это уже очень заебись. Сокращение времени на написание и отладку кода тоже очень хорошо.
> 3) Что надо сделать, чтобы раст был популярен?
Он и так достаточно популярен.
>>309351
на раст переходят с питона, руби, перла, хацкеля, сишарпа, жабы, жабоскрипта и прочих медленных языков программирования
вот в этом и есть великая польза раста!
>Значит раст таки еще один высер без задач?
>Зачем же он нужен такой медленный?
на раст переходят с питона, руби, перла, хацкеля, сишарпа, жабы, жабоскрипта и прочих медленных языков программирования
вот в этом и есть великая польза раста!
![[react]15414305293970.png](https://2ch.hk//pr/src/1299618/15445064263120.png)
>>309333
Потому что в названии нет жабы.
Потому что в названии нет жабы.
>>309315
Да вроде взлетел. Хотя я хз, че ты вкладываешь в это понятие. Язык развивается, новые вакансии появляются. Да, не пщ с котлином, но там за языками стоят серьезные конторы.
Сложно сказать. Быстрее ли C чем C++? Мне кажется, что раст, в теории, побыстрее, ибо все таки там меньше рантайма, чем в плюсах. Но тащемта можно и на C++, и на расте забить на классы/трейты и писать как на C, тогда вообще its all the same shit.
3) Что надо сделать, чтобы раст был популярен?
Да тащемта ничего. Он и так потихноьку становится все более популярным.
> 1) Почему раст не взлетел?
Да вроде взлетел. Хотя я хз, че ты вкладываешь в это понятие. Язык развивается, новые вакансии появляются. Да, не пщ с котлином, но там за языками стоят серьезные конторы.
> 2) Быстрее ли раст чем си++?
Сложно сказать. Быстрее ли C чем C++? Мне кажется, что раст, в теории, побыстрее, ибо все таки там меньше рантайма, чем в плюсах. Но тащемта можно и на C++, и на расте забить на классы/трейты и писать как на C, тогда вообще its all the same shit.
3) Что надо сделать, чтобы раст был популярен?
Да тащемта ничего. Он и так потихноьку становится все более популярным.
>>309894
Забухать. Ты в отеле будешь или ты местный?
Забухать. Ты в отеле будешь или ты местный?
>>310035
Все в сравнении познается. У каких языков с равной или большей популярностью система типов по выразительности такая же или лучше? Haskell и Swift, больше нихуя нет.
Все в сравнении познается. У каких языков с равной или большей популярностью система типов по выразительности такая же или лучше? Haskell и Swift, больше нихуя нет.
>>310037
Мне например трейты раста нравятся. И то как генерики с ними работают.
Ради интереса в тот же Хаскель заглядывал, тайп классы - это какой то duck typing, если в типе функции есть с нужными названиями, то он автоматом становится членом тайпкласса (или я ебу дал и несу хуйню).
Мне например трейты раста нравятся. И то как генерики с ними работают.
Ради интереса в тот же Хаскель заглядывал, тайп классы - это какой то duck typing, если в типе функции есть с нужными названиями, то он автоматом становится членом тайпкласса (или я ебу дал и несу хуйню).
>>310096
Это ты с го путаешь. В хаскеле тоже нужно имплементить тайпкласс для типа непосредственно.
Это ты с го путаешь. В хаскеле тоже нужно имплементить тайпкласс для типа непосредственно.
>>309315
Чтобы "взлететь" в современном мире нужно быть жаваскриптом или goвном похуже. Это как с соцсетями и техникой — все пользуются техническими испражнениями вроде инсты/фб/айфонов/итд просто потому что ПРОСТА.
Токой же.
Почаще срать в этом треде, и держать его в топа. Своеобразный местный смм.
>1) Почему раст не взлетел?
Чтобы "взлететь" в современном мире нужно быть жаваскриптом или goвном похуже. Это как с соцсетями и техникой — все пользуются техническими испражнениями вроде инсты/фб/айфонов/итд просто потому что ПРОСТА.
>2) Быстрее ли раст чем си++?
Токой же.
>3) Что надо сделать, чтобы раст был популярен?
Почаще срать в этом треде, и держать его в топа. Своеобразный местный смм.
Пиздец конечно. Примеров кода на главной больше нет. Линка на плейграунд тоже днем с огнем не сыщешь. Выебать их надо за такой апдейт.
>>299618 (OP)
Есть ли имплементация в/под уеч? Планируется ли? Опенсорс все-таки, исходники на гитхабе, бери и пили.
Есть ли имплементация в/под уеч? Планируется ли? Опенсорс все-таки, исходники на гитхабе, бери и пили.
>>310299
Он самый. Четвертый.
Вообще есть ли имплементация хоть в какой-нибудь актуальный нынче движок? Кроме нахуй уже никому не нужного сорца.
Он самый. Четвертый.
Вообще есть ли имплементация хоть в какой-нибудь актуальный нынче движок? Кроме нахуй уже никому не нужного сорца.
>>310037
Очевидная Scala ещё.
Очевидная Scala ещё.
>>310298
У уе имплементация одна единственная на плюсах, в переводчик вбей как слово-то переводится.
У уе имплементация одна единственная на плюсах, в переводчик вбей как слово-то переводится.
195 Кб, 1130x550Предлагаю запилить небольшой проект по запросу местных анонов, чтобы наглядно показать раст в деле.
>>310325
Запили ядро на расте и чтобы было быстро как в си, и показаны главные достоинства языка.
Алсо, я вкатываюсь в раст и все думаю, зачем я учу ебанутый синтаксис и эту экосистему, если есть кресты, которые куда интуитивнее и где хотя бы инкремкнь с декрементом есть.
Запили ядро на расте и чтобы было быстро как в си, и показаны главные достоинства языка.
Алсо, я вкатываюсь в раст и все думаю, зачем я учу ебанутый синтаксис и эту экосистему, если есть кресты, которые куда интуитивнее и где хотя бы инкремкнь с декрементом есть.
>>310328
Чтобы не быть ограниченным мудаком с ЛОРа и выучить новые концепты, до которых ты не додумался бы самостоятельно, а потом применять их на практике и в других языках.
Чтобы не быть ограниченным мудаком с ЛОРа и выучить новые концепты, до которых ты не додумался бы самостоятельно, а потом применять их на практике и в других языках.
>>310330
И какие например раст привносит принципиально новые концепты? Иммутабельность? Очень смешно.
И какие например раст привносит принципиально новые концепты? Иммутабельность? Очень смешно.
>>310332
Например, я раньше думал, что за шаблоны в прикладном коде нужно пиздить палками, но раст мне показал, что дженерики на каждый чих - это вполне легитимный и удобный способ писать код.
Например, я раньше думал, что за шаблоны в прикладном коде нужно пиздить палками, но раст мне показал, что дженерики на каждый чих - это вполне легитимный и удобный способ писать код.
>>310332
Главная фича раста — борроу-чекер и зеро-кост абстракции построенные вокруг него. Так ьы получаешь безопасное и быстрое управление паматью и безопасный многопоточный код с функциональным вкусом.
Главная фича раста — борроу-чекер и зеро-кост абстракции построенные вокруг него. Так ьы получаешь безопасное и быстрое управление паматью и безопасный многопоточный код с функциональным вкусом.
>>310337
Это потому, что ты нихуя не знаешь про параметрический полиморфизм.
>я раньше думал, что за шаблоны в прикладном коде нужно пиздить палками
Это потому, что ты нихуя не знаешь про параметрический полиморфизм.
>>310330
Програмач вчера:
Програмач сегодня
Програмач завтра
Програмач вчера:
> Иди учи хацкель и поменяй полученные откровения в других языках
Програмач сегодня
> Иди учи раст, чтобы не быть как долбоебы с лора)0
Програмач завтра
> Ну бля, черепашка вперёд потом налево)00Ы Пагади бля, направо) соре
>>310366
Первый любитель черепашьей графики сгорел, несите следующего
Первый любитель черепашьей графики сгорел, несите следующего
>>310378
Можешь, начинай.
Можешь, начинай.
>>310378
В смысле конкретную либу для шарпов или похожий MVVM-тулкит, который рендерит XAML? Первое вряд ли получится сделать эргономично, а второе почему нет? Биндинги для SDL, OpenGL и Cairo уже есть, херачь.
В смысле конкретную либу для шарпов или похожий MVVM-тулкит, который рендерит XAML? Первое вряд ли получится сделать эргономично, а второе почему нет? Биндинги для SDL, OpenGL и Cairo уже есть, херачь.
>>310599
Возьму что-нибудь вроде этого
https://rust-lang-nursery.github.io/cli-wg/tutorial/
и запилю простеньку утилиту для просмотра этого итт треда.
Возьму что-нибудь вроде этого
https://rust-lang-nursery.github.io/cli-wg/tutorial/
и запилю простеньку утилиту для просмотра этого итт треда.
Какой вариант вам нравится больше и почему?
https://gist.github.com/rust-
play/528b607acd5d1831d0e48c6717eb461c
https://gist.github.com/rust-
play/528b607acd5d1831d0e48c6717eb461c
255 Кб, 1288x1368>>310641
Как-то так.
Как-то так.
>>310701
А то смотрю ник знакомый, помню как у тебя стримы по лиспу были и mmo в gd пилил (несколько лет туда не заглядывал).
А то смотрю ник знакомый, помню как у тебя стримы по лиспу были и mmo в gd пилил (несколько лет туда не заглядывал).
>>310702
Было дело, ага. Забавно что именно общелисп дал мне работу на расте в другой стране.
Было дело, ага. Забавно что именно общелисп дал мне работу на расте в другой стране.
124 Кб, 1600x615Ладно, какой-то дичи под конец запилил. Ну и размазал все немножко по модулям.
Напомню что можно смотреть отдельные коммиты. Я старался добавлять фичи понемногу и комментить по мере возможности.
Напомню что можно смотреть отдельные коммиты. Я старался добавлять фичи понемногу и комментить по мере возможности.
Уже 2019 год на подходе.
Сколько лет должно пройти после выхода первой версии языка программирования, чтобы можно было делать вывод о его востребованности? Ну чтобы отмазки типа "язык мало времени существует, поэтому ещё ничего крупного на нём не написано" не прокатывали?
Сколько лет должно пройти после выхода первой версии языка программирования, чтобы можно было делать вывод о его востребованности? Ну чтобы отмазки типа "язык мало времени существует, поэтому ещё ничего крупного на нём не написано" не прокатывали?
>>311067
Язык востребован, когда за него платят деньги. Вакансий на данный момент мало и, в основном, криптопараша, но тем не менее, они существуют.
Назови несколько крупных проектов, которые написали за последние несколько лет на на плюсах, на джаве, на шарпах. Т.е. именно написали с нуля, я не про поддержку легаси говна. Рынок проприетарного софта поделен, опенсорцу тоже не особо нужен ни второй блендер, ни второй nginx. Ну вот недавно выходцы из дайсов объявили, что будут пилить свой движок на Расте. Если взлетит, это сделает его востребованным в твоих глазах?
Язык востребован, когда за него платят деньги. Вакансий на данный момент мало и, в основном, криптопараша, но тем не менее, они существуют.
>ничего крупного на нём не написано
Назови несколько крупных проектов, которые написали за последние несколько лет на на плюсах, на джаве, на шарпах. Т.е. именно написали с нуля, я не про поддержку легаси говна. Рынок проприетарного софта поделен, опенсорцу тоже не особо нужен ни второй блендер, ни второй nginx. Ну вот недавно выходцы из дайсов объявили, что будут пилить свой движок на Расте. Если взлетит, это сделает его востребованным в твоих глазах?
>>311097
На крестах это боль потому что. В расте хоть рефлекшн есть и тулзы для AST. Не надо свои метаклассы лепить из говна и палок как в Qt и анриле.
>что будут пилить свой движок на Расте
На крестах это боль потому что. В расте хоть рефлекшн есть и тулзы для AST. Не надо свои метаклассы лепить из говна и палок как в Qt и анриле.
>>311178
И не только, в крестах легко проебатся с памятью и указателями, в статьях на хабре посвященной теме PVS-Studio, там и показываются те трудно уловимые ошибки.
И не только, в крестах легко проебатся с памятью и указателями, в статьях на хабре посвященной теме PVS-Studio, там и показываются те трудно уловимые ошибки.
>>311197
Это редко бывает, сейчас тулзы хорошие, валгринд все вылавливает, да и с голыми указателями нечасто работаешь. Для десктопных программ это не слишком критично опять же.
>в крестах легко проебатся с памятью и указателями
Это редко бывает, сейчас тулзы хорошие, валгринд все вылавливает, да и с голыми указателями нечасто работаешь. Для десктопных программ это не слишком критично опять же.
У меня есть желания на расте попробовать написать игровой движок, но как толь задумаюсь сколько миллионов строк кода нужно написать и нужно будет ебатся с математикой сразу желание отпадает.
>>311211
Движок писать - самое бесполезное занятие. Лучше сразу игру пиши. То есть реализуй необходимый минимум, который нужен вот прямо сейчас, и не больше. Граф сцены, например, можно сразу выкинуть, он реально не нужен для игр, там сложной иерархии не встречается обычно.
Какая там математика? Либ для векторов-матриц-кватернионов полно, бери любую.
Движок писать - самое бесполезное занятие. Лучше сразу игру пиши. То есть реализуй необходимый минимум, который нужен вот прямо сейчас, и не больше. Граф сцены, например, можно сразу выкинуть, он реально не нужен для игр, там сложной иерархии не встречается обычно.
>нужно будет ебатся с математикой
Какая там математика? Либ для векторов-матриц-кватернионов полно, бери любую.
Подскажите, wasm он только для фронта нужен? Где посмотреть и поконтрибьють в него можно? Насколько он нестабилен сейчас, чтобы на нем писать веб-приложения? Алсо, возможно ли сейчас или в будущем писать SPA, как на реакте?
Вот четыре вопроса. Ответьте на каждый плис, ребята поопытнее.
Вот четыре вопроса. Ответьте на каждый плис, ребята поопытнее.
>>311255
В wasm сейчас нет полноценного доступа к DOM и очень куцый интероп с js. Можешь накодить свой движок для рендера и лейаута через webgl, и на нем рисовать гуй.
В wasm сейчас нет полноценного доступа к DOM и очень куцый интероп с js. Можешь накодить свой движок для рендера и лейаута через webgl, и на нем рисовать гуй.
479 Кб, 2490x1067>>311273
По-моему уже фреймворк yew для этого
https://github.com/DenisKolodin/yew
И кстати говоря самый медленный из всех.
По-моему уже фреймворк yew для этого
https://github.com/DenisKolodin/yew
И кстати говоря самый медленный из всех.
>>311077
Нет, я ее с собой взял.
Нет, я ее с собой взял.
>>311291
Грустно. Неужели ваниллужс так сложно обогнать с этим вашим васм? Посмотреть бы исходники последнего.
Грустно. Неужели ваниллужс так сложно обогнать с этим вашим васм? Посмотреть бы исходники последнего.
>>311293
Так все манипуляции с DOM через JS.
Так все манипуляции с DOM через JS.
>>311224
Ну почему же? Движок это разные программные компоненты для удобного создания игры, создания анимаций, игровых событий, всяких эффектов и т.д. без этого нужно будет писать много кода, а так все это инкапсулируешь и работаешь через удобные интерфейсы.
Физика столкновений, работа с тенями, работа с отображением материалов и многое другое.
>Движок писать - самое бесполезное занятие.
Ну почему же? Движок это разные программные компоненты для удобного создания игры, создания анимаций, игровых событий, всяких эффектов и т.д. без этого нужно будет писать много кода, а так все это инкапсулируешь и работаешь через удобные интерфейсы.
>Какая там математика?
Физика столкновений, работа с тенями, работа с отображением материалов и многое другое.
>>311255
https://github.com/mozilla/gecko-dev/tree/master/js/src/wasm
>Где посмотреть и поконтрибьють в него можно?
https://github.com/mozilla/gecko-dev/tree/master/js/src/wasm
>>311302
С webgl ты js гораздо реже будешь дергать, чем при работе с DOM. Вся производительность от нативного кода сожрется оверхедом на вызов js из wasm.
С webgl ты js гораздо реже будешь дергать, чем при работе с DOM. Вся производительность от нативного кода сожрется оверхедом на вызов js из wasm.
>>311306
Пока ты игру не напишешь, ты не узнаешь, какие компоненты удобные, а какие-нет. Поэтому и глупо их писать заранее, если у тебя опыта нет.
Обычно все это даже с готовым движком приходится писать в каком-то виде, особенно материалы. Или по крайней мере очень хорошо представлять, как оно работает внутри. Базовый колижен, кстати, во всех физических движках искаропки, если ты еще и физику не собираешься сам писать.
> Движок это разные программные компоненты для удобного создания игры, создания анимаций, игровых событий, всяких эффектов
Пока ты игру не напишешь, ты не узнаешь, какие компоненты удобные, а какие-нет. Поэтому и глупо их писать заранее, если у тебя опыта нет.
>Физика столкновений, работа с тенями, работа с отображением материалов и многое другое.
Обычно все это даже с готовым движком приходится писать в каком-то виде, особенно материалы. Или по крайней мере очень хорошо представлять, как оно работает внутри. Базовый колижен, кстати, во всех физических движках искаропки, если ты еще и физику не собираешься сам писать.
>>311321
Да. Только надо будет рисовать не кубик, а всю страницу с текстом и графикой. То есть писать свой браузерный движок.
Да. Только надо будет рисовать не кубик, а всю страницу с текстом и графикой. То есть писать свой браузерный движок.
Ананасы, рискую быть посланным нахуй, но всё же
Хочу вкатиться в раст и пилю всякие hello world'ы. Но вопрос не об этом. В качестве IDE использую vscode, но из неё не получается собрать проект, валится ошибка
Compiling some_project v0.1.0 (C:\rust\some_project)
error: linking with `link.exe` failed: exit code: 1181
= note: LINK : fatal error LNK1181: cannot open input file 'advapi32.lib'
Нагуглить ответ не получилось, поэтому запускаю сборку из x64 Native Tools Command Prompt for VS 2017, но это не очень удобно. Может кто-нить подсказать, как наладить сборку из vscode?
Хочу вкатиться в раст и пилю всякие hello world'ы. Но вопрос не об этом. В качестве IDE использую vscode, но из неё не получается собрать проект, валится ошибка
Compiling some_project v0.1.0 (C:\rust\some_project)
error: linking with `link.exe` failed: exit code: 1181
= note: LINK : fatal error LNK1181: cannot open input file 'advapi32.lib'
Нагуглить ответ не получилось, поэтому запускаю сборку из x64 Native Tools Command Prompt for VS 2017, но это не очень удобно. Может кто-нить подсказать, как наладить сборку из vscode?
>>311656
Если ты даже это не можешь сделать, то ты не станешь растом.
Тем более раст изначально рожден мертвым.
Если ты даже это не можешь сделать, то ты не станешь растом.
Тем более раст изначально рожден мертвым.
>>311656
Сорян, братиш. Помог бы, но винду юзать для разработки это добровольный мазохизм. Вкати себе прыщи на виртуалку для экспериментов, поймешь как там все удобно сделано для разработки.
Сорян, братиш. Помог бы, но винду юзать для разработки это добровольный мазохизм. Вкати себе прыщи на виртуалку для экспериментов, поймешь как там все удобно сделано для разработки.
Когда уже в раст завезут нормальные асинхронные функции? А то после языков с ними даже элементарные многопоточные задачи превращаются в мучение. Например нужно сделать поллинг функции в отдельном потоке, при этом поток в любой момент можно остановить. В расте приходится городить свою структуру контекста, откуда вызывать функцию сна (у меня оно реализовано через мютекс с булеаном внутри, означающим завершить тред или нет + условная переменная).
>>311873
Чем тебя futures не устраивают? Если хочется сахара, ставь niglty, там новая версия в стандартной либе.
https://github.com/withoutboats/romio
Чем тебя futures не устраивают? Если хочется сахара, ставь niglty, там новая версия в стандартной либе.
https://github.com/withoutboats/romio
Так, доны-аноны, настало время провести заседание по вопросу rust + wasm.
Контекст.
Из wasm кода не доступно браузерное апи. Единственное решение -- использовать биндинг к js. Группой энтузиастов разрабатывается и поддерживается stdweb (https://github.com/koute/stdweb) как такой вот биндинг, и cargo web (https://github.com/koute/cargo-web) как основная тулзовина, автоматизирующая разработку/сборку.
На прошлых выходных в Москве состоялась конференция RustRush, на которой Ashley Williams, одна из основных контрибьюторов wasm working groupe, пришедшая в rust из nodejs, презентовала, по сути, wasm-bindgen (https://github.com/rustwasm/wasm-bindgen) как биндинг и wasm-pack (https://github.com/rustwasm/wasm-pack) как основной инструмент автоматизации процесса разработки. Среди прочего хорошего, как новый легковесный аллокатор, следует особо отметить, что wasm-pack сильно завязан на инфраструктуру nodejs/npm.
Вопросы.
1. Как оцениваете такой шаг, когда вместо улучшения существующего решения, создают новое с почти тем же функционалом?
2. Как вам такая жесткая привязка к nodejs/npm в разработке rust + wasm приложений?
3. Как считаете есть ли теперь будущее у stdweb и cargo web?
4. Почему такое маленькое сообщество у такого крутого языка? (риторический вопрос)
Мнение.
С учетом того, насколько маленькое сообщество у rust, мне бы хотелось видеть как люди объединяются вокруг уже существующих решений, а не пилят такиеже, но свои. И, как сторонник разумного минимальзма во всем, я совершенно не понимаю зачем мне зависимости (nodejs/npm/WebPack), без которых я явно смог бы обойтись, разрабатывая что-то на rust + wasm. Это ещё и с учетом того, что я не являюсь хейтером js стека, писал под nodejs и среда эта для меня родная. Просто не понимаю, зачем всё в кучу смешивать.
Дискас.
Контекст.
Из wasm кода не доступно браузерное апи. Единственное решение -- использовать биндинг к js. Группой энтузиастов разрабатывается и поддерживается stdweb (https://github.com/koute/stdweb) как такой вот биндинг, и cargo web (https://github.com/koute/cargo-web) как основная тулзовина, автоматизирующая разработку/сборку.
На прошлых выходных в Москве состоялась конференция RustRush, на которой Ashley Williams, одна из основных контрибьюторов wasm working groupe, пришедшая в rust из nodejs, презентовала, по сути, wasm-bindgen (https://github.com/rustwasm/wasm-bindgen) как биндинг и wasm-pack (https://github.com/rustwasm/wasm-pack) как основной инструмент автоматизации процесса разработки. Среди прочего хорошего, как новый легковесный аллокатор, следует особо отметить, что wasm-pack сильно завязан на инфраструктуру nodejs/npm.
Вопросы.
1. Как оцениваете такой шаг, когда вместо улучшения существующего решения, создают новое с почти тем же функционалом?
2. Как вам такая жесткая привязка к nodejs/npm в разработке rust + wasm приложений?
3. Как считаете есть ли теперь будущее у stdweb и cargo web?
4. Почему такое маленькое сообщество у такого крутого языка? (риторический вопрос)
Мнение.
С учетом того, насколько маленькое сообщество у rust, мне бы хотелось видеть как люди объединяются вокруг уже существующих решений, а не пилят такиеже, но свои. И, как сторонник разумного минимальзма во всем, я совершенно не понимаю зачем мне зависимости (nodejs/npm/WebPack), без которых я явно смог бы обойтись, разрабатывая что-то на rust + wasm. Это ещё и с учетом того, что я не являюсь хейтером js стека, писал под nodejs и среда эта для меня родная. Просто не понимаю, зачем всё в кучу смешивать.
Дискас.
>>312535
Пытаются облегчить перекот для жс-макак.
В стиле элма. У тебя есть приложение которое явно повязано на нпм. Ты хочешь оптимизировать вот этот кусок, и для этого юзаешь раст. И для тебя это выглядит как подключение обычной либы из npm. Как по мне, звучит логично. Эшли похожа на продавщицу из овощного.
Пытаются облегчить перекот для жс-макак.
В стиле элма. У тебя есть приложение которое явно повязано на нпм. Ты хочешь оптимизировать вот этот кусок, и для этого юзаешь раст. И для тебя это выглядит как подключение обычной либы из npm. Как по мне, звучит логично. Эшли похожа на продавщицу из овощного.
>>312550
В таком подходе выглядит логично, но что делать тем, кто не повязан на npm и хочет в стиле этого https://github.com/DenisKolodin/yew что-то писать? Получается нужно писать с использованием их инструментов и и шаблоны, потому что это же core team и их подход дефолтный и правильный.
В таком подходе выглядит логично, но что делать тем, кто не повязан на npm и хочет в стиле этого https://github.com/DenisKolodin/yew что-то писать? Получается нужно писать с использованием их инструментов и и шаблоны, потому что это же core team и их подход дефолтный и правильный.
>>312535
Быстрее работает на тех же принципах (нпм/ноджес говна) благодаря бороу чекеру и зиро-кост абстракциям (плюс)
Полная хуйня, к сожалению
Возможно.
Вот был бы rustscript, быстрее ваших жсов в тыщу раз, то было бы круто.
Синтаксис ебанутый, ну и еще надо все в ансейф оборачивать, чтобы быструю программу написать.
>Вопросы.
>1. Как оцениваете такой шаг
Быстрее работает на тех же принципах (нпм/ноджес говна) благодаря бороу чекеру и зиро-кост абстракциям (плюс)
>2. Как вам такая жесткая привязка к nodejs/npm в разработке rust + wasm приложений?
Полная хуйня, к сожалению
>3. Как считаете есть ли теперь будущее у stdweb и cargo web?
Возможно.
Вот был бы rustscript, быстрее ваших жсов в тыщу раз, то было бы круто.
>4. Почему такое маленькое сообщество у такого крутого языка?
Синтаксис ебанутый, ну и еще надо все в ансейф оборачивать, чтобы быструю программу написать.
>>312553
stdweb никто не отменял. Не вижу ничего плохого в том, чтобы иметь несколько конкурирующих подходов. Либо один из них со временем отомрет, либо место найдется для обоих.
stdweb никто не отменял. Не вижу ничего плохого в том, чтобы иметь несколько конкурирующих подходов. Либо один из них со временем отомрет, либо место найдется для обоих.
>>312555
Имел ввиду сравнение stdweb и wasm-bindgen, а не rust и nodejs.
Это как раз очень плохая практика. Чуваки из Baido рассказывали, что нашли 2 уязвимости в стандартной библиотеке раста.
В стандартной библиотеке раста! Чувствуете иронию? А появились они там как раз из-за таких вот подходов и ошибочных представлений. Почти везде, где используется unsafe, можно и нужно обойтись без него!
Но это отдельная тема.
>Быстрее работает на тех же принципах (нпм/ноджес говна)
Имел ввиду сравнение stdweb и wasm-bindgen, а не rust и nodejs.
>надо все в ансейф оборачивать
Это как раз очень плохая практика. Чуваки из Baido рассказывали, что нашли 2 уязвимости в стандартной библиотеке раста.
В стандартной библиотеке раста! Чувствуете иронию? А появились они там как раз из-за таких вот подходов и ошибочных представлений. Почти везде, где используется unsafe, можно и нужно обойтись без него!
Но это отдельная тема.
>>312567
Нет, уязвимости были как раз потому, что unsafe использовался там, где в нем нет необходимости.
Нет, уязвимости были как раз потому, что unsafe использовался там, где в нем нет необходимости.
>>312567
Что ты несешь? Уязвимости были из-за неверного использования unsafe. Разница в том, что в расте unsafe изолирован и явно виден, а в крестах, например, у тебя все приложение unsafe.
Интересно, что баг был не в unsafe блоке, а в коде, который этот unsafe использовал.
Что ты несешь? Уязвимости были из-за неверного использования unsafe. Разница в том, что в расте unsafe изолирован и явно виден, а в крестах, например, у тебя все приложение unsafe.
Интересно, что баг был не в unsafe блоке, а в коде, который этот unsafe использовал.
>>312557
Было бы не плохо, если бы stdweb и дальше жил, и новые разработчики знали бы, что есть альтернатива стандартному подходу.
Было бы не плохо, если бы stdweb и дальше жил, и новые разработчики знали бы, что есть альтернатива стандартному подходу.
>>312535
cargo-web + stdweb значительно медленнее чем wasm-bindgen + web-sys + js-sys.
В первом случае ты просто все вызовы в js!() макрос оборачиваешь и пишешь на джаваскрипте, а втором случае у тебя готовые типобезопасные биндинги ко всему API js и DOM.
Плюс wasm-bindgen автоматом будет поддерживать работу с DOM в обход js, когда добавят такую возможность в стандарт и браузеры.
cargo-web + stdweb значительно медленнее чем wasm-bindgen + web-sys + js-sys.
В первом случае ты просто все вызовы в js!() макрос оборачиваешь и пишешь на джаваскрипте, а втором случае у тебя готовые типобезопасные биндинги ко всему API js и DOM.
Плюс wasm-bindgen автоматом будет поддерживать работу с DOM в обход js, когда добавят такую возможность в стандарт и браузеры.
Так че, какой лучший способ писать СПА на расте+васме? В плане наименьшей ресурсозатратности и наибольшей производительности.
>>312761
Разумные аргументы! Меня смущает только попытки определить стандартный workflow с использованием излишних зависимостей. В гайде по wasm-bindgen в разделе Basic Usage (https://rustwasm.github.io/wasm-bindgen/whirlwind-tour/basic-usage.html) сразу про webpack и npm пишут. Может я зря парюсь и так оно и должно быть всё, если по нормальному делать.
Разумные аргументы! Меня смущает только попытки определить стандартный workflow с использованием излишних зависимостей. В гайде по wasm-bindgen в разделе Basic Usage (https://rustwasm.github.io/wasm-bindgen/whirlwind-tour/basic-usage.html) сразу про webpack и npm пишут. Может я зря парюсь и так оно и должно быть всё, если по нормальному делать.
>>312784
Я на draco начал пилить, правда там всего один разраб который пропадает постоянно. Но там все что от него нужно это реализация VirtualDOM, а дальше хоть форкай и пили сам что хочешь.
Есть еще несколько разных реализаций VDOM на wasm-bindgen, но они все как и draco делаются в половину человека, поэтому пофиг что брать, только производительность VDOM волновать должна.
Я вообще свой синаксис шаблонов поверх написал чтобы можно было на другой фреймворк съебать безболезненно.
Я на draco начал пилить, правда там всего один разраб который пропадает постоянно. Но там все что от него нужно это реализация VirtualDOM, а дальше хоть форкай и пили сам что хочешь.
Есть еще несколько разных реализаций VDOM на wasm-bindgen, но они все как и draco делаются в половину человека, поэтому пофиг что брать, только производительность VDOM волновать должна.
Я вообще свой синаксис шаблонов поверх написал чтобы можно было на другой фреймворк съебать безболезненно.
Ахуеть, гайз. Этот тред проклят, или что?
Раньше тут ошивался шизик и общался сам с собой, теперь его затопили ебланы, тащащие раст в фронтенд. Ладно если был бы в этом смысл, но ведь переусложнённый и баганный вариант работает ещё медленнее жса потому что это просто ебаная прослойка над ним.
В хаскель тред вырождаемся, ей богу.
Раньше тут ошивался шизик и общался сам с собой, теперь его затопили ебланы, тащащие раст в фронтенд. Ладно если был бы в этом смысл, но ведь переусложнённый и баганный вариант работает ещё медленнее жса потому что это просто ебаная прослойка над ним.
В хаскель тред вырождаемся, ей богу.
>>313166
Шта? WASM это не прослойка, он через специальный AOT+JIT работает напрямую с железом. Для доступа к DOM и прочим WebAPI да, нужна прослойка для JS. Но например для WebGL уже можно писать безжаваскрипта вообще.
> просто ебаная прослойка над ним.
Шта? WASM это не прослойка, он через специальный AOT+JIT работает напрямую с железом. Для доступа к DOM и прочим WebAPI да, нужна прослойка для JS. Но например для WebGL уже можно писать безжаваскрипта вообще.
>>313182
Там тоже через js сейчас все вызывается. А значит за кадр не больше нескольких тысяч вызовов gl-функций. Это примерно как в 2001 году, когда DirectX на каждый чих сискол делал. Очень небыстро.
>Но например для WebGL уже можно писать безжаваскрипта вообще.
Там тоже через js сейчас все вызывается. А значит за кадр не больше нескольких тысяч вызовов gl-функций. Это примерно как в 2001 году, когда DirectX на каждый чих сискол делал. Очень небыстро.
>>313182
>>313226
Да на текущий момент однохуйственно слишком дорого рисовать в браузере что-то кроме анимаций в плане ресурсов, ещё лет 5 хотя бы надо поперетаскивать людей со старых железок, и уже думать о браузерных ммо и прочей дрочильне.
>для WebGL
>в треде только и обсуждается работа с DOM, веб-фреймворки и прочий фронтендный вебмакакинг
>>313226
Да на текущий момент однохуйственно слишком дорого рисовать в браузере что-то кроме анимаций в плане ресурсов, ещё лет 5 хотя бы надо поперетаскивать людей со старых железок, и уже думать о браузерных ммо и прочей дрочильне.
>>313166
Ты чё, пёс, wasm это киллерфича раста. Во всех остальных направлениях уже есть устоявшиеся стеки, а здесь у раста реальный шанс взлететь. Осталось только апи нормольное дождаться.
Ты чё, пёс, wasm это киллерфича раста. Во всех остальных направлениях уже есть устоявшиеся стеки, а здесь у раста реальный шанс взлететь. Осталось только апи нормольное дождаться.
>>313226
В firefox например уже оптимизаций вызова js функций из api браузера завезли, у меня в нём ре-рендер фронта на расте в 2 раза быстрее чем в хроме. Как это заевезут так быстрее JS работать будет - https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md
В firefox например уже оптимизаций вызова js функций из api браузера завезли, у меня в нём ре-рендер фронта на расте в 2 раза быстрее чем в хроме. Как это заевезут так быстрее JS работать будет - https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md
>>313265
Фронт и бэк на одном языке, можно суб-крейты шарить с общей логикой.
Нормальная система типов с которой не страшно рефакторить.
Скорость компиляции c wasm-pack незначительно отличается от скорости траспиляции всяких webpackов c babelом.
Фронт и бэк на одном языке, можно суб-крейты шарить с общей логикой.
Нормальная система типов с которой не страшно рефакторить.
Скорость компиляции c wasm-pack незначительно отличается от скорости траспиляции всяких webpackов c babelом.
>>313267
Быстрее дробит цифры ты хотел сказать. Только вот в вебе это нахуй не нужно, рисовать интерфейс так — слишком оверкилл по всем параметрам. Когда полноценные игори начнут переезжать в бровсер можешь высрать этот аргумент, а сейчас иди пукай в другом месте. Или иди покажи как рокетсаенс в браузере мутить.
>>313271
Хорошо, нахуя тащить его что на бек что на фронт? По времени и деньгам, это как дворников/маршрутчиков/строителей-джамшутов пытаться заменить роботами — никогда не окупится.
Система типов для гуйни, где нужна возможность прототипировать и смотреть выхлоп на лету — это, конечно, нечто. Сидишь такой, анимируешь кнопку, а тебя борроу-чекер в гц окружении (которое там так или иначе будет) ставит раком.
Быстрее дробит цифры ты хотел сказать. Только вот в вебе это нахуй не нужно, рисовать интерфейс так — слишком оверкилл по всем параметрам. Когда полноценные игори начнут переезжать в бровсер можешь высрать этот аргумент, а сейчас иди пукай в другом месте. Или иди покажи как рокетсаенс в браузере мутить.
>>313271
Хорошо, нахуя тащить его что на бек что на фронт? По времени и деньгам, это как дворников/маршрутчиков/строителей-джамшутов пытаться заменить роботами — никогда не окупится.
Система типов для гуйни, где нужна возможность прототипировать и смотреть выхлоп на лету — это, конечно, нечто. Сидишь такой, анимируешь кнопку, а тебя борроу-чекер в гц окружении (которое там так или иначе будет) ставит раком.
>>313309
Ты видимо ничего сложнее домашней странички не делал, если не понимаешь зачем нужен нормальный ЯП в вэбе.
Ты видимо ничего сложнее домашней странички не делал, если не понимаешь зачем нужен нормальный ЯП в вэбе.
21 Кб, 474x266>>313309
Можно скомпилировать фаерфокс в васм и потом запустить лису в лисе в лисе в лисе в лисе в лисе в лисе в лисе.
Можно скомпилировать фаерфокс в васм и потом запустить лису в лисе в лисе в лисе в лисе в лисе в лисе в лисе.
67 Кб, 678x401> webgl
> ui
> wasm
Покажите скриншот что ли, чего вы там такое мутите.
>>313358
Без таких выебонов как у тебя на пике. Тупо формочки можно будет лепить без еботни с HTML, плюс десктопные проги переносить в веб. Хоть автокад, хоть 3дмакс.
Без таких выебонов как у тебя на пике. Тупо формочки можно будет лепить без еботни с HTML, плюс десктопные проги переносить в веб. Хоть автокад, хоть 3дмакс.
>>313309
С чего ты взял? На Qt формочки лепить в разы проще, чем пердолиться с заебонами CSS+HTML.
>слишком оверкилл по всем параметрам
С чего ты взял? На Qt формочки лепить в разы проще, чем пердолиться с заебонами CSS+HTML.
>>313374
Разве что это, да. И еще в виде обычного приложения высрать хуйню на электроне. Ну и браузерки.
Как-то это всё ощущается так, как будто надо не дать производителям железа отдохнуть. 2025 год, фотошоп перестал тормозить? Следующую версию сделаем в браузере хули.
Not bad.
>>313375
Тоже неплохо.
> десктопные проги переносить в веб
Разве что это, да. И еще в виде обычного приложения высрать хуйню на электроне. Ну и браузерки.
Как-то это всё ощущается так, как будто надо не дать производителям железа отдохнуть. 2025 год, фотошоп перестал тормозить? Следующую версию сделаем в браузере хули.
> Тупо формочки можно будет лепить
Not bad.
>>313375
> формочки лепить
Тоже неплохо.
>>313378
Почему ты думаешь, что раз в браузере, то будет тормозить? Идея как раз в том, что с wasm+webgl будет производительность и потребление ресурсов близкие к нативу.
>фотошоп перестал тормозить? Следующую версию сделаем в браузере хули.
Почему ты думаешь, что раз в браузере, то будет тормозить? Идея как раз в том, что с wasm+webgl будет производительность и потребление ресурсов близкие к нативу.
>>313381
Местами.
Оче побольше.
Чудес, к сожалению, не бывает.
> производительность
Местами.
> потребление ресурсов
Оче побольше.
Чудес, к сожалению, не бывает.
>>299618 (OP)
Итак напомните-ка еще раз, зачем раст высрали?
1. Зачем нужен раст, когда уже давно есть рельсы, жаба, котлин?
2. Раст, как язык с сахаром. На самом деле тебе придется ебаться с с++, чтобы по-настоящему оценить это говно.
3. А зачем ебаться с с++, чтобы потом ебаться с растом, если можно стать жабой-меном и получать свои 200 ?
4. А лучше вообще становится гошником и получать 300 ?
5. По своей сути - раст - это высер, который только усложняет код своим "безопасным" подходом. Трудночитабелен, и не понимаем. Требует бекграунда определенного, для новичка - самый кал.
6. Ну и что за ебанутый 4 пикрил? Фриендс оф раст? Какие-то мелкобуквенные компании.
7. И вообще, сейчас низшее программирование неблагодарное занятие.
Итак напомните-ка еще раз, зачем раст высрали?
1. Зачем нужен раст, когда уже давно есть рельсы, жаба, котлин?
2. Раст, как язык с сахаром. На самом деле тебе придется ебаться с с++, чтобы по-настоящему оценить это говно.
3. А зачем ебаться с с++, чтобы потом ебаться с растом, если можно стать жабой-меном и получать свои 200 ?
4. А лучше вообще становится гошником и получать 300 ?
5. По своей сути - раст - это высер, который только усложняет код своим "безопасным" подходом. Трудночитабелен, и не понимаем. Требует бекграунда определенного, для новичка - самый кал.
6. Ну и что за ебанутый 4 пикрил? Фриендс оф раст? Какие-то мелкобуквенные компании.
7. И вообще, сейчас низшее программирование неблагодарное занятие.
>>313566
Слушай, ну че ты. Ну есть же пхп, в конце-то концов. Все остальное вообще не нужно.
Слушай, ну че ты. Ну есть же пхп, в конце-то концов. Все остальное вообще не нужно.
>>313415
При чем тут чудеса вообще? Там никакой магии нет. Нативный код и ручное управление памятью быстрее и тратят меньше ресурсов. Это факт.
>Чудес, к сожалению, не бывает.
При чем тут чудеса вообще? Там никакой магии нет. Нативный код и ручное управление памятью быстрее и тратят меньше ресурсов. Это факт.
>>313602
В вебе нет настолько тяжелых скриптов, чтобы была заметна разница в скорости выполнения. Большая часть вычислений - это DOM, но его Раст не ускорит.
В вебе нет настолько тяжелых скриптов, чтобы была заметна разница в скорости выполнения. Большая часть вычислений - это DOM, но его Раст не ускорит.
>>313566
Это язык, в первую очередь, для компиляции в васм.
> Итак напомните-ка еще раз, зачем раст высрали?
Это язык, в первую очередь, для компиляции в васм.
>>313695
Я и говорил о том, чтобы DOM выкинуть, и рисовать интерфейс вручную, через webgl.
Я и говорил о том, чтобы DOM выкинуть, и рисовать интерфейс вручную, через webgl.
>>313814
Смысл, если есть нормальный стандарт для веба, есть html, который прост и удобен.
Смысл, если есть нормальный стандарт для веба, есть html, который прост и удобен.
>>313814
Вот этот господин уже высрал сценарий такого будующего >>313338. Гуд лах хэв йор перформанс.
>>313375
Угу, для десктопа. Причём на Qt нет софта, который не выглядел бы везде одинаково ущербно. А ещё до Qml там кастомизация была на уровне изменения цвета кнопок.
А теперь давай перенесёмся в реалии веба, где сайты открывают с хуйлиарда типов устройств, от компуктеров с экранами 21:9 с разрешением 5к до ебучих смартчасов c 272x340. Под каждый тип экрана свой интерфейс будешь делать по каждому пуку дизайнеров?
Короче, к чему это я — веб со своими жсами/хтмлми/итд это конечно кривая жопная хуйня, но она такая из-за рынка, и это её оптимальное состояние.
>>313602
Это факт, но ещё есть другие факты:
1) Это ебать как дорого;
2) Это ебать как долго;
3) Код всё равно работает в вм;
4) Ты конечно убежишь от гц, но он там рано или поздно появится (см пропозалы), и большинство кода в окружении будут его юзать если это не твой код на расте, лол (будет ситуация как с языком D).
Собственно, если нет нужды на это никто не пойдёт. Дропбоксов в мире очень мало, видишь ли.
>все коллы к вебгл к через жс
>жс крутится в отдельной вм, и коллы извне это дорого как с жавой
>весь код энивэй будет работать в вм
>а эта браузерная вм работает в осевой вм
>сама ос тоже своего рода вм
>а ещё следующее поколение процессоров сделают с изолированной вм на уровне микрокода
Вот этот господин уже высрал сценарий такого будующего >>313338. Гуд лах хэв йор перформанс.
>>313375
Угу, для десктопа. Причём на Qt нет софта, который не выглядел бы везде одинаково ущербно. А ещё до Qml там кастомизация была на уровне изменения цвета кнопок.
А теперь давай перенесёмся в реалии веба, где сайты открывают с хуйлиарда типов устройств, от компуктеров с экранами 21:9 с разрешением 5к до ебучих смартчасов c 272x340. Под каждый тип экрана свой интерфейс будешь делать по каждому пуку дизайнеров?
Короче, к чему это я — веб со своими жсами/хтмлми/итд это конечно кривая жопная хуйня, но она такая из-за рынка, и это её оптимальное состояние.
>>313602
>Нативный код и ручное управление памятью быстрее и тратят меньше ресурсов.
Это факт, но ещё есть другие факты:
1) Это ебать как дорого;
2) Это ебать как долго;
3) Код всё равно работает в вм;
4) Ты конечно убежишь от гц, но он там рано или поздно появится (см пропозалы), и большинство кода в окружении будут его юзать если это не твой код на расте, лол (будет ситуация как с языком D).
Собственно, если нет нужды на это никто не пойдёт. Дропбоксов в мире очень мало, видишь ли.
>>313833
Они обещают нативные вызовы.
Читай, как webasm работает. Там нет ВМ. Байткод компилируется в натив после статической проверки на безопасность. Производительность хуже, чем у оффлайн-компиляторов, но достаточно высокая.
>все коллы к вебгл к через жс
Они обещают нативные вызовы.
>вмвмвм
Читай, как webasm работает. Там нет ВМ. Байткод компилируется в натив после статической проверки на безопасность. Производительность хуже, чем у оффлайн-компиляторов, но достаточно высокая.
>>313833
Да похуй как он выглядит. Тот же 3дмакс далеко не шедевр дизайна, люди его не за это покупают. Главное функционал, который на жабоскрипте ты никогда реализовать не сможешь.
Это и так приходится делать для сайтов. Некоторые еще и мобильную приложуху делают. Я говорю о софте, а не о сайтах. Автокадом на часах никто пользоваться не будет.
>Причём на Qt нет софта, который не выглядел бы везде одинаково ущербно
Да похуй как он выглядит. Тот же 3дмакс далеко не шедевр дизайна, люди его не за это покупают. Главное функционал, который на жабоскрипте ты никогда реализовать не сможешь.
>Под каждый тип экрана свой интерфейс будешь делать по каждому пуку дизайнеров?
Это и так приходится делать для сайтов. Некоторые еще и мобильную приложуху делают. Я говорю о софте, а не о сайтах. Автокадом на часах никто пользоваться не будет.
>>313566
Хуйню спизданул по почти каждому пункту:
Разные сегменты как бы. Тащемта вполне даже в рамках одного проекта могут сосуществовать раст и, например, джава (сам на таком сижу).
Ну хз. В чем то ты прав (сам писал на C++, и тут сразу прям зашло), но при этом знаю людей, которые перекатились с других языков (джава, скала), и им тоже заебись.
Не понял, при чем тут С++. А вот про джаву: не всем нравится говнокодить энтерпрайз (внезапно). Есть еще и другие задачи. И иногда и за больше деньги.
Сейм щит: не для всех задач подходит.
Ну такой трейдофф: ты получаешь безопасный язык с zero-cost абстракциями, офк появится некоторая сложность. Но немного попишешь, перестроишь мышление), и уже будешь так же легко, как раньше, писать код.
Ты явно новенький в ИТ. Куча хороших контор, которые делают супер годные продуткы.
Очередной смузихлеб поравлся, несите следующего.
Итог: разъеб по всем пунктам. Оправдывайся.
Хуйню спизданул по почти каждому пункту:
> 1. Зачем нужен раст, когда уже давно есть рельсы, жаба, котлин?
Разные сегменты как бы. Тащемта вполне даже в рамках одного проекта могут сосуществовать раст и, например, джава (сам на таком сижу).
> 2. Раст, как язык с сахаром. На самом деле тебе придется ебаться с с++, чтобы по-настоящему оценить это говно.
Ну хз. В чем то ты прав (сам писал на C++, и тут сразу прям зашло), но при этом знаю людей, которые перекатились с других языков (джава, скала), и им тоже заебись.
> 3. А зачем ебаться с с++, чтобы потом ебаться с растом, если можно стать жабой-меном и получать свои 200 ?
Не понял, при чем тут С++. А вот про джаву: не всем нравится говнокодить энтерпрайз (внезапно). Есть еще и другие задачи. И иногда и за больше деньги.
> 4. А лучше вообще становится гошником и получать 300 ?
Сейм щит: не для всех задач подходит.
> 5. По своей сути - раст - это высер, который только усложняет код своим "безопасным" подходом. Трудночитабелен, и не понимаем. Требует бекграунда определенного, для новичка - самый кал.
Ну такой трейдофф: ты получаешь безопасный язык с zero-cost абстракциями, офк появится некоторая сложность. Но немного попишешь, перестроишь мышление), и уже будешь так же легко, как раньше, писать код.
> 6. Ну и что за ебанутый 4 пикрил? Фриендс оф раст? Какие-то мелкобуквенные компании.
Ты явно новенький в ИТ. Куча хороших контор, которые делают супер годные продуткы.
> 7. И вообще, сейчас низшее программирование неблагодарное занятие.
Очередной смузихлеб поравлся, несите следующего.
Итог: разъеб по всем пунктам. Оправдывайся.
>>313844
Реализовать-то что угодно можно, только работать будет лет через 15-20.
Вот вообще нет.
На сайтах тоже. По факту сайты это самые обычные гуй-приложульки. Весь чертёжный 2д функционал автокада (и как минимум статичную проекцию такого добра хотя бы под парой углов) можно реализовать уже сейчас (см. приложения вроде Figma), остаётся вопрос — а нахуя? Прогреть процессор чуть сильнее? Ведь всё равно для работы таких приложений тем более нужны полноценные компутеры, с планшетика не поработаешь в дороге, а на любом пк, тем более на ноутбуке, банально быстрее будет нативный софт, ведь даже самое оптимистичное отставание в 10-20% (которое будет обязательно) превратит работу даже в фш в полный пиздец.
Короче, пока высирал свою "войну и мир" до меня дошёл смысл вебасма — эту движуху гугл затеял чтобы всех анально привязать к софту, который нельзя спиратить. Это пока что единственный логичный кейс, без выдавливания обоснований нужности из неоткуда.
>Главное функционал, который на жабоскрипте ты никогда реализовать не сможешь.
Реализовать-то что угодно можно, только работать будет лет через 15-20.
>Это и так приходится делать для сайтов.
Вот вообще нет.
> Я говорю о софте, а не о сайтах. Автокадом на часах никто пользоваться не будет.
На сайтах тоже. По факту сайты это самые обычные гуй-приложульки. Весь чертёжный 2д функционал автокада (и как минимум статичную проекцию такого добра хотя бы под парой углов) можно реализовать уже сейчас (см. приложения вроде Figma), остаётся вопрос — а нахуя? Прогреть процессор чуть сильнее? Ведь всё равно для работы таких приложений тем более нужны полноценные компутеры, с планшетика не поработаешь в дороге, а на любом пк, тем более на ноутбуке, банально быстрее будет нативный софт, ведь даже самое оптимистичное отставание в 10-20% (которое будет обязательно) превратит работу даже в фш в полный пиздец.
Короче, пока высирал свою "войну и мир" до меня дошёл смысл вебасма — эту движуху гугл затеял чтобы всех анально привязать к софту, который нельзя спиратить. Это пока что единственный логичный кейс, без выдавливания обоснований нужности из неоткуда.
>>313566
Если тебе это сложно и не идёт, а борроу чекер тебя просто пиздец доебал, то в цпп ты творил бы полностью корявую, лагающую, дырявую херню.
> усложняет код своим "безопасным" подходом
Если тебе это сложно и не идёт, а борроу чекер тебя просто пиздец доебал, то в цпп ты творил бы полностью корявую, лагающую, дырявую херню.
62 Кб, 1080x1080>The variable name is highlighted in transgender pride flag colors.
>str::replace() swaps in "E" for "T"; the program prints out "Hello, E!"
>"E", as in estrogen.
>>313863
В теории можно будет так же васм данные пропачить и запускать офлайн сохраненный файл.
>>313844
https://clara.io хоть я и все равно считаю идиотизмом вынесение такого в браузер.
> спиратить
В теории можно будет так же васм данные пропачить и запускать офлайн сохраненный файл.
>>313844
> функционал, который на жабоскрипте ты никогда реализовать не сможешь
https://clara.io хоть я и все равно считаю идиотизмом вынесение такого в браузер.
>>313182
JS, внезапно, уже овер 10 с хуем лет работает точно так же что в пихле что в макаке.
И wasm точно так же как и обычный жс транслируется во внутреннее представление пихла/макаки, после чего точно так же жит-компилируется.
>Шта? WASM это не прослойка, он через специальный AOT+JIT работает напрямую с железом
JS, внезапно, уже овер 10 с хуем лет работает точно так же что в пихле что в макаке.
И wasm точно так же как и обычный жс транслируется во внутреннее представление пихла/макаки, после чего точно так же жит-компилируется.
>>314016
Я в курсе, но в WASM (1) байт-код может быть гораздо более оптимизированным (хотя это зависит от конпелятора язык_нейм в байткод) и (2) там идёт AOT компиляция, что в js можно делать очень ограниченно из-за того что язык динамический, а все современные движки AOT не делают вообще и более того даже минимально парсят неиспользуемый код, чтоб страницы с несколькими сотнями килобайтов (если не мегабайтов) жс-говнокода быстрее загружались.
> JS, внезапно, уже овер 10 с хуем лет работает точно так же что в пихле что в макаке.
Я в курсе, но в WASM (1) байт-код может быть гораздо более оптимизированным (хотя это зависит от конпелятора язык_нейм в байткод) и (2) там идёт AOT компиляция, что в js можно делать очень ограниченно из-за того что язык динамический, а все современные движки AOT не делают вообще и более того даже минимально парсят неиспользуемый код, чтоб страницы с несколькими сотнями килобайтов (если не мегабайтов) жс-говнокода быстрее загружались.
>>313936
Ты не понимаешь концепции. В той же фигме у тебя все данные банально болтаются на сервере, спирачивание каждой версии будет необходимо начинать с эмуляции сервера со всем апи, который будет постоянно меняться, и это без учёта шифрования и банальной большей защищённости от патчинга и дебагинга кода налету ввиду изоляции в браузере (ну разве что кто-то будет ради этого форкать движки браузеров и выпускать свои, лол).
Короче, пиратить-то будет можно, но с такими затратами что это нахуй никому не будет нужно.
>В теории можно будет так же васм данные пропачить и запускать офлайн сохраненный файл.
Ты не понимаешь концепции. В той же фигме у тебя все данные банально болтаются на сервере, спирачивание каждой версии будет необходимо начинать с эмуляции сервера со всем апи, который будет постоянно меняться, и это без учёта шифрования и банальной большей защищённости от патчинга и дебагинга кода налету ввиду изоляции в браузере (ну разве что кто-то будет ради этого форкать движки браузеров и выпускать свои, лол).
Короче, пиратить-то будет можно, но с такими затратами что это нахуй никому не будет нужно.
>>314057
Ок, и к чему это? Ну загрузится скомпилированный код на пару секунд быстрее, дальше что? Он будет работать в тех же условиях что жс, и всё, кроме числодробления там будет работать с той же скоростью.
Ок, и к чему это? Ну загрузится скомпилированный код на пару секунд быстрее, дальше что? Он будет работать в тех же условиях что жс, и всё, кроме числодробления там будет работать с той же скоростью.
>>314069
Кроме числодробления там еще есть ебаная динамическая типизация жабоскрипта и его же объектная система, которые с любым джитом будут тормозить.
>и всё, кроме числодробления там будет работать с той же скоростью.
Кроме числодробления там еще есть ебаная динамическая типизация жабоскрипта и его же объектная система, которые с любым джитом будут тормозить.
https://ferrous-systems.com/blog/rust-analyzer-2019/
https://github.com/rust-analyzer/rust-analyzer
Довольно интересный проект, ибо шо Racer, шо RLS не очень. Надеюсь автор не ленивая жопа и доведет до конца проект.
https://github.com/rust-analyzer/rust-analyzer
Довольно интересный проект, ибо шо Racer, шо RLS не очень. Надеюсь автор не ленивая жопа и доведет до конца проект.
>>314222
Вась, а рендерить и работать ты где будешь? Такое даже для гугла дорого.
Суть вебаппов в том, что движуха в плане нагрузки-то твоя пека берёт на себя, но ты привязан жопой к дилде гугла под эгидой "безопасности и удобства".
Вась, а рендерить и работать ты где будешь? Такое даже для гугла дорого.
Суть вебаппов в том, что движуха в плане нагрузки-то твоя пека берёт на себя, но ты привязан жопой к дилде гугла под эгидой "безопасности и удобства".
>>314190
Прям как местные со своим васмом. Только в терминальной стадии, местные ещё в начальной.
>челы сначала запилили полностью свой парсер и анализатор для ИДЕИ на котлине
>потом челы додумались что МЕДЛЕННА и решили сделать всё готовыми нативными средствами
Прям как местные со своим васмом. Только в терминальной стадии, местные ещё в начальной.
>>314246
Так а причем тут ИДЕЯ то? Ты сравниваешь инструмент, которым можно пользоваться везде, с плагином для исключительно своей хуеты.
Все таки инструмент скорее замена Racer и RLS, у которых действительно есть некоторое количество критичных недостатков.
Вот тут бы как раз поспорил, ИДЕЯ с растом работает вполне прилично, особых тормозов не видел. Другое дело, что не все пользуются ей. Жаль, что jetbrains вместо помощи сообществу пилит свою хуету.
Так а причем тут ИДЕЯ то? Ты сравниваешь инструмент, которым можно пользоваться везде, с плагином для исключительно своей хуеты.
Все таки инструмент скорее замена Racer и RLS, у которых действительно есть некоторое количество критичных недостатков.
>потом челы додумались что МЕДЛЕННА
Вот тут бы как раз поспорил, ИДЕЯ с растом работает вполне прилично, особых тормозов не видел. Другое дело, что не все пользуются ей. Жаль, что jetbrains вместо помощи сообществу пилит свою хуету.
>>314296
У idea неплохой плагин, работает заебись. Че вы кудахчете
У idea неплохой плагин, работает заебись. Че вы кудахчете
>>314124
Если ты сам не станешь передавать при каждом вызове параметры с рандомными или динамически запиленными типами, то после пары прогонов жит прогреется и на динамическую и объектную систему ему станет похуй. Не похуй ему будет, если ты в очередной раз внезапно вместо числа передашь строку тут то он и охуеет и откатится в интерпретацию.
>Кроме числодробления там еще есть ебаная динамическая типизация жабоскрипта и его же объектная система, которые с любым джитом будут тормозить.
Если ты сам не станешь передавать при каждом вызове параметры с рандомными или динамически запиленными типами, то после пары прогонов жит прогреется и на динамическую и объектную систему ему станет похуй. Не похуй ему будет, если ты в очередной раз внезапно вместо числа передашь строку тут то он и охуеет и откатится в интерпретацию.
>>314404
Ты слишком всё упрощаешь. Во-первых не пары, а несколько десятков раз (зачастую JIT делаются уровневыми и максимальный уровень оптимизаций достигается только после сотен итераций циклов или вызовов). Во-вторых это будет справедливо, только если особенным образом писать код на JS. Например те же итераторы сделаны так, что оптимизировать из чрезвычайно сложно. Так что если хочешь быстрый код, придётся отказаться от кучи сахарка со времён ES6, но этого, разумеется, никто делать не будет.
> то после пары прогонов жит прогреется и на динамическую и объектную систему ему станет похуй
Ты слишком всё упрощаешь. Во-первых не пары, а несколько десятков раз (зачастую JIT делаются уровневыми и максимальный уровень оптимизаций достигается только после сотен итераций циклов или вызовов). Во-вторых это будет справедливо, только если особенным образом писать код на JS. Например те же итераторы сделаны так, что оптимизировать из чрезвычайно сложно. Так что если хочешь быстрый код, придётся отказаться от кучи сахарка со времён ES6, но этого, разумеется, никто делать не будет.
>>314411
И да, добавлю, что именно поэтому раст мне нравится. В JS если вместо for(;;) будешь использовать for(of) то можешь сразу попрощаться с пирформансом (для того чтобы оптимизировать итераторы, которые использует for of, нужны очень мощные оптимизации вроде escape analysis чтоб убрать все аллокации при создании кучи побочных объектов, которая оффициальная спецификация ECMA требует создавать в реализации). В расте же все эти итераторы изначально делаются zero-cost и могут занять больше времени разве что при конпеляции.
И да, добавлю, что именно поэтому раст мне нравится. В JS если вместо for(;;) будешь использовать for(of) то можешь сразу попрощаться с пирформансом (для того чтобы оптимизировать итераторы, которые использует for of, нужны очень мощные оптимизации вроде escape analysis чтоб убрать все аллокации при создании кучи побочных объектов, которая оффициальная спецификация ECMA требует создавать в реализации). В расте же все эти итераторы изначально делаются zero-cost и могут занять больше времени разве что при конпеляции.
42 Кб, 742x855Растаманы, лишился тут своего ноута на время и придется работать за старым компом , на котором только под шиндой. Что там вообще можно устроить , чтобы с ржавчиной работать? Решил попробовать на эмаксе , но racer работает через жопу , плодя процессы и блокируя буффер на каждом дополнении. Vs code просто говно, на котором постоянно что-то отваливается. Idea накатить нет возможности , ибо 32 бит. На чем вообще тогда писать остаётся ?
>>314734
В блокноте открыв доку. Имакс на шинд, блядь. Ты понимаешь что ты поехавший?
В блокноте открыв доку. Имакс на шинд, блядь. Ты понимаешь что ты поехавший?
>>314734
На сколько старый комп? Если древний проц и нет ssd, то время компиляции становится болью.
На сколько старый комп? Если древний проц и нет ssd, то время компиляции становится болью.
Растобамп. https://github.com/trending/rust
Растопидоры снова соснули. Замерил вывод хелловорда и он оказался в 70 раз медленнее крестов. Оправдывайтесь.
37 Кб, 460x604Биндинги curses тут кто-нибудь пердолил?
Я ньюфаг и в Расте и в Проклятиях, если что.
Т.к. у меня винда выбрал вот эту либу: https://github.com/ihalila/pancurses/
Не могу понять чем различаются функции addstr и printw. У них в Расте одинаковая сигнатура, просто принимают строку которую выведут. В примерах зачем-то используются обе функции, хотя делают они одно и то же.
В сишке сигнатура разная, addstr принимает просто строку, а у printw сигнатура и предназначение как у классического printf - си-стайл форматирование.
В расте понятное дело этот функционал обрублен, переменного числа аргумента у printw нет. Но если в строке будет какое-нибудь "%s" - выводит рандомный мусор.
Короч я не понял зачем было в биндингах оставлять такую ущербную версию printw, ещё и в примерах его использовать в перемешку с addstr.
Я ньюфаг и в Расте и в Проклятиях, если что.
Т.к. у меня винда выбрал вот эту либу: https://github.com/ihalila/pancurses/
Не могу понять чем различаются функции addstr и printw. У них в Расте одинаковая сигнатура, просто принимают строку которую выведут. В примерах зачем-то используются обе функции, хотя делают они одно и то же.
В сишке сигнатура разная, addstr принимает просто строку, а у printw сигнатура и предназначение как у классического printf - си-стайл форматирование.
В расте понятное дело этот функционал обрублен, переменного числа аргумента у printw нет. Но если в строке будет какое-нибудь "%s" - выводит рандомный мусор.
Короч я не понял зачем было в биндингах оставлять такую ущербную версию printw, ещё и в примерах его использовать в перемешку с addstr.
>>317322
Хз, возьми просто нативную либу:
https://github.com/gyscos/Cursive
https://github.com/fdehau/tui-rs
Хз, возьми просто нативную либу:
https://github.com/gyscos/Cursive
https://github.com/fdehau/tui-rs
>>317345
Не, мы не отрицаем факт того, что ты дебил ибо свой прошлый высер про "в 70 раз медленнее крестов" ты как-то ничем не подтвердил, да покормил зеленого
Не, мы не отрицаем факт того, что ты дебил ибо свой прошлый высер про "в 70 раз медленнее крестов" ты как-то ничем не подтвердил, да покормил зеленого
>>317682
Сам проверь, напиши пару строк и увидишь насколько быстр твой "системный" говноязык.
Сам проверь, напиши пару строк и увидишь насколько быстр твой "системный" говноязык.
>>317682
https://gist.github.com/rust-play/37f48b637b98652ed4a82498335c7533
Что теперь скажешь расто-петушок?
> ничем не подтвердил
https://gist.github.com/rust-play/37f48b637b98652ed4a82498335c7533
Что теперь скажешь расто-петушок?
Фу, посмотрите, всего три элементарные строки кода, а растокод НЕ ВЫДЕРЖАЛ и сегфолтнулся. Оправдывайтесь, растоманьки.
https://gist.github.com/rust-play/88508199a3f0d46342e1d8d76cf7dffa
https://gist.github.com/rust-play/88508199a3f0d46342e1d8d76cf7dffa
>>317709
То что ты можешь вставить себе черенок от лопаты в жопу, не значит что другие люди будут это делать.
То что ты можешь вставить себе черенок от лопаты в жопу, не значит что другие люди будут это делать.
>>317709
Ты же понимаешь, что большая часть кода пишется на нормальном Rust, не unsafe?
Так что теперь давай сегфолт без unsafe, умник.
imbeCile'ы могут не стрелять себе в ногу вообще?
Ты же понимаешь, что большая часть кода пишется на нормальном Rust, не unsafe?
Так что теперь давай сегфолт без unsafe, умник.
imbeCile'ы могут не стрелять себе в ногу вообще?
>>317891
Так сойдёт? https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=10bd396c4227228530bc123f5b6f67d4
Эпичный баг на самом деле, хоть и не раста, а LLVM. https://github.com/rust-lang/rust/issues/28728
> Так что теперь давай сегфолт без unsafe, умник.
Так сойдёт? https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=10bd396c4227228530bc123f5b6f67d4
Эпичный баг на самом деле, хоть и не раста, а LLVM. https://github.com/rust-lang/rust/issues/28728
>>317901
Хотя вот так с рекурсией выглядит даже эпичней: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=a02aa321d93de50a42feb8715d4e6393
Хотя вот так с рекурсией выглядит даже эпичней: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=a02aa321d93de50a42feb8715d4e6393
>>317901
Нет, не сойдет.
Прикольно, но все таки баг старый, и, например, у меня оно не упало. Тащемта и на playground же умирает по таймауту.
Кажется как раз в последних версиях запилили workaround: https://github.com/rust-embedded/cortex-m-quickstart/pull/59
Нет, не сойдет.
Прикольно, но все таки баг старый, и, например, у меня оно не упало. Тащемта и на playground же умирает по таймауту.
Кажется как раз в последних версиях запилили workaround: https://github.com/rust-embedded/cortex-m-quickstart/pull/59
>>317905
Да, да мы поняли. Если код нихуя не делает и LLVM его нахуй выпиливает, случается падение. Неприятно, но не смертельно.
Да, да мы поняли. Если код нихуя не делает и LLVM его нахуй выпиливает, случается падение. Неприятно, но не смертельно.
>>317905
Потому что компилируешь в debug режиме. Баг работает только в release.
Это не для компилятора, а для библиотеки. Компилятор всё выдаёт неправильный код.
> у меня оно не упало
Потому что компилируешь в debug режиме. Баг работает только в release.
> Кажется как раз в последних версиях запилили workaround
Это не для компилятора, а для библиотеки. Компилятор всё выдаёт неправильный код.
>>317909
Да, ты прав. Я таки в дебаге скомпилил. С opt-level=3 упало.
В любом случае, это таки: а) баг компилятора (и даже не Rust, как ты сам и заметил), а не языка, и б) баг при оптимизации. Это совсем не то же самое, что стрелять себе в ногу, долбясь в unsafe к нулевому указателю.
Да, ты прав. Я таки в дебаге скомпилил. С opt-level=3 упало.
В любом случае, это таки: а) баг компилятора (и даже не Rust, как ты сам и заметил), а не языка, и б) баг при оптимизации. Это совсем не то же самое, что стрелять себе в ногу, долбясь в unsafe к нулевому указателю.
Котоны. У меня есть enum варианты которого имплементят Display. Как мне сделать без бойлерплейта реализацию Display для самого енума, который будет просто передавать вызов конкретному варианту?
>>317925
Вот сегфолт из-за бага конкретно языка: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=af0b0292bc6abdde0fcc7ca1aa625b59
И решение до сих пор не придумали, хоть компилятор и предупреждает, что так делать не надо. https://github.com/rust-lang/rust/issues/51443
Вот сегфолт из-за бага конкретно языка: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=af0b0292bc6abdde0fcc7ca1aa625b59
И решение до сих пор не придумали, хоть компилятор и предупреждает, что так делать не надо. https://github.com/rust-lang/rust/issues/51443
>>317928
Ну сорт оф решение будет в будущем: запретить такое нахуй, как написано в ворнинге. Хотя пока пример валидный. (блять, какой норкоман писал этот код)
>>317930
Не согласен. Мне кажется, что ворнинг это как раз то, что можно проигнорировать и оно продолжит работать (может медленнее, или код будет менее красивый). А если ты (компилятор) уверен, что это некорректный код и все сломается, то стоит запретить.
Ну сорт оф решение будет в будущем: запретить такое нахуй, как написано в ворнинге. Хотя пока пример валидный. (блять, какой норкоман писал этот код)
>>317930
Не согласен. Мне кажется, что ворнинг это как раз то, что можно проигнорировать и оно продолжит работать (может медленнее, или код будет менее красивый). А если ты (компилятор) уверен, что это некорректный код и все сломается, то стоит запретить.
>>317951
Там же черным по белому написано, что это депрекейтед говно, которое пока что для обратной совместимости принимается, а скоро будет ошибкой.
Там же черным по белому написано, что это депрекейтед говно, которое пока что для обратной совместимости принимается, а скоро будет ошибкой.
>>317956
Так, падажжи, я ж это и сказал:
Так, падажжи, я ж это и сказал:
> Ну сорт оф решение будет в будущем: запретить такое нахуй, как написано в ворнинге.
>>317987
Че там в двух словах? Не похоже на то, что стоит прочитать.
Че там в двух словах? Не похоже на то, что стоит прочитать.
>>299618 (OP)
Ребята привет! Напомните-ка, почему раст такой ущербный? Даже в соседних тредах людей сюда заманивают. Он уже настолько плох? Алсо, еще и плохочитаемый. Как вы вообще дышите здесь?
Ребята привет! Напомните-ка, почему раст такой ущербный? Даже в соседних тредах людей сюда заманивают. Он уже настолько плох? Алсо, еще и плохочитаемый. Как вы вообще дышите здесь?
А расскажите мне про раст-ембедед, что там да как вообще. Там есть нормальная отладка? Что-то сложнее консоли и светодиода можно написать при этом чтобы не требовалось внешнюю оперативу и флешку для бинарника?
>>318099
Отладка стандартная GDB (или LLDB) + OpenOCD. Интеграция с IDE это уже другой вопрос, я не пробовал.
Начиная с 1.31 версии (последняя на данный момент) можно писать no_std бинари (в которых нет встроенного аллокатора) без включения экспериментальных фич и почти без пердолинга (лютый пердолинг начнётся если захочешь сделать библиотеку, особенно универсальную).
Странный запрос. Обычно программы на слабеньких bare-metal мк внешнюю (т.е. в виде отдельных компонентов) оперативную память и не требуют.
А это уже решается линкером, а не компилятором. Насколько я знаю в расте можно указывать в виде атрибутов куда линкеру размещать определённые куски данных, но возможно придётся попердолиться.
Я пробовал писать программы для Cortex-M3 на RTFM [1] и работало всё норм. Кстати, асинхронные функции (они же корутины) изначально делаются так, чтоб работать без аллокаций, так что в no_std (а значит и в embedded) они тоже будут работать. Интересно будет испробовать когда их закончат.
Пока что напрягают две вещи: неполноценные константные функции и отсутствие констант в генериках. Частично можно решить шаманством с макросами и абсолютно ебанутым шаманством с трейтами [2] уровня шаблонов C++98, но выглядит некрасиво и непонятно.
[1]: https://github.com/japaric/cortex-m-rtfm
[2]: https://github.com/paholg/typenum/blob/master/src/int.rs
> Там есть нормальная отладка?
Отладка стандартная GDB (или LLDB) + OpenOCD. Интеграция с IDE это уже другой вопрос, я не пробовал.
> А расскажите мне про раст-ембедед
Начиная с 1.31 версии (последняя на данный момент) можно писать no_std бинари (в которых нет встроенного аллокатора) без включения экспериментальных фич и почти без пердолинга (лютый пердолинг начнётся если захочешь сделать библиотеку, особенно универсальную).
> не требовалось внешнюю оперативу
Странный запрос. Обычно программы на слабеньких bare-metal мк внешнюю (т.е. в виде отдельных компонентов) оперативную память и не требуют.
> и флешку для бинарника
А это уже решается линкером, а не компилятором. Насколько я знаю в расте можно указывать в виде атрибутов куда линкеру размещать определённые куски данных, но возможно придётся попердолиться.
Я пробовал писать программы для Cortex-M3 на RTFM [1] и работало всё норм. Кстати, асинхронные функции (они же корутины) изначально делаются так, чтоб работать без аллокаций, так что в no_std (а значит и в embedded) они тоже будут работать. Интересно будет испробовать когда их закончат.
Пока что напрягают две вещи: неполноценные константные функции и отсутствие констант в генериках. Частично можно решить шаманством с макросами и абсолютно ебанутым шаманством с трейтами [2] уровня шаблонов C++98, но выглядит некрасиво и непонятно.
[1]: https://github.com/japaric/cortex-m-rtfm
[2]: https://github.com/paholg/typenum/blob/master/src/int.rs
81 Кб, 800x533>>318004
Неудобный вопрос:
Как вы их гарантировать собрались? Нарушить теорему Гёделя? Или расписаться в неполноте языка? Нахуй вы вообще такие вещи на первую страницу вешаете, ваш язык рассчитан на полных дебилов, которые в элементарную логику не могут? Если так, что хорошего в языке с коммьюнити, состоящим из дебилов?
Неудобный вопрос:
>с гарантиями потокобезопасности
Как вы их гарантировать собрались? Нарушить теорему Гёделя? Или расписаться в неполноте языка? Нахуй вы вообще такие вещи на первую страницу вешаете, ваш язык рассчитан на полных дебилов, которые в элементарную логику не могут? Если так, что хорошего в языке с коммьюнити, состоящим из дебилов?
>>318166
Супер, меня устроит. Интеграция с ide не так важна, если есть gdb. По моему опыту зачастую gdb бывает удобнее некоторых дерьмовых ide (не знаю, какая для раста там есть).
Встроенный не умеет нормально с мк работать? А сторонних понаписали уже? Впрочем, на небольших мк без операционки или с какой-нибудь rtos обычно на моей практике все старались не выделять память динамически.
Универсальную в смысле для разных архитектур или о чем вообще речь?
Ну я преувеличил, конечно, но вообще к тому, что в newlibc из arm-none-eabi тулчейна, которым я пользовался последнее время, некоторые инструменты из libc жрали очень много стека (например форматирование строк), и оказалось, что для мелких мк хорошей практикой является подмена printf на что-то попроще.
Это хорошо, но меня размер бинарника интересовал. При одинаковой функциональности программы сильно ли отличаться будет размер от того же самого, написанного на C.
Под мк корутины? Интересно поглядеть. как это всё будет работать.
А это проект энтузиастов или это прямо разработчики раста пилят? Я так-то за раст пока не решился взяться, но прям читаю про него и держу кулачки, чтобы когда-нибудь в ближайшее время он стал достойной заменой C/C++ для встраиваемых (особенно bare-metal) систем. Было бы здорово.
Спасибо за развернутый ответ.
> Отладка стандартная GDB
Супер, меня устроит. Интеграция с ide не так важна, если есть gdb. По моему опыту зачастую gdb бывает удобнее некоторых дерьмовых ide (не знаю, какая для раста там есть).
> в которых нет встроенного аллокатора
Встроенный не умеет нормально с мк работать? А сторонних понаписали уже? Впрочем, на небольших мк без операционки или с какой-нибудь rtos обычно на моей практике все старались не выделять память динамически.
> лютый пердолинг начнётся если захочешь сделать библиотеку, особенно универсальную
Универсальную в смысле для разных архитектур или о чем вообще речь?
> Обычно программы на слабеньких bare-metal мк внешнюю (т.е. в виде отдельных компонентов) оперативную память и не требуют
Ну я преувеличил, конечно, но вообще к тому, что в newlibc из arm-none-eabi тулчейна, которым я пользовался последнее время, некоторые инструменты из libc жрали очень много стека (например форматирование строк), и оказалось, что для мелких мк хорошей практикой является подмена printf на что-то попроще.
> можно указывать в виде атрибутов куда линкеру размещать определённые куски данных
Это хорошо, но меня размер бинарника интересовал. При одинаковой функциональности программы сильно ли отличаться будет размер от того же самого, написанного на C.
> асинхронные функции
Под мк корутины? Интересно поглядеть. как это всё будет работать.
А это проект энтузиастов или это прямо разработчики раста пилят? Я так-то за раст пока не решился взяться, но прям читаю про него и держу кулачки, чтобы когда-нибудь в ближайшее время он стал достойной заменой C/C++ для встраиваемых (особенно bare-metal) систем. Было бы здорово.
Спасибо за развернутый ответ.
>>318172
Раст очень мощный язык. Пост анона за написаный по наитию за 30 секунд, конечно опровергат все талмуды CS и труды учёных, которые разрабатывали язык.
Раст очень мощный язык. Пост анона за написаный по наитию за 30 секунд, конечно опровергат все талмуды CS и труды учёных, которые разрабатывали язык.
>>318276
С этим пока всё плохо. В no_std аллокатора нет, а std для bare-metal не подходит. Есть API для аллокаторов (так что запросто можешь написать свой, там 2 функции: аллокация, деаллокация), но в no_std нет коллекций и объектов, которые могли бы его использовать. Сейчас хотят вынести все коллекции и объекты, требующие динамические аллокации из std в отдельный крейт [1], который будет работать в no_std и где будет возможно использование любого аллокатора + свой собственный обработчик OOM [2] (где например ты сможешь перезагрузить мк). Но сейчас тишина.
Ну да. Для условной компиляции придётся использовать флаги карго и в отличии от #ifdef из Си нельзя использовать целочисленные значения, только булевы.
С размером всё норм. Причиной большого размер растопрограмм, на который некоторые жалуются, являются две вещи: (1) стандартная библиотека и (2) статически скомпилированные несколько версий одной зависимости. (1) для no_std не является проблемой, а вот (2) вполне себе может всплыть. Например ты используешь крейт XXX версии 1.1 и крейт YYY. В свою очередь крейт YYY использует крейт XXX версии 1.0 и указано, что только эту версию и никакую другую. Из-за этого в бинарник слинкуются обе версии пакета XXX, что увеличит размер. Для тех кто программирует на С/С++ это будет в новизну, поскольку в си эта проблема решалась отсутствием пакетного менеджера и полностью ручным управлением зависимостями.
Ну и ещё может всплыть размер debug-версии программы. Хоть раст и использует zero-cost абстракции, в debug-версии они далеко не zero-cost и могут быть как медленней, так и занимать больше места. Иногда в разы. Особенно весело выглядит когда в debug-версии, чтобы подёргать пин дополнительно пишутся пара ветвлений и вызовов функций.
Угу. Их изначально пилят без динамических аллокаций.
Автор japaric является разработчиком раста и вносит в язык/компилятор изменения для улучшения работы в embedded. Но конкретно RTFM это не официальный проект, да. Официальные проекты все находятся здесь [3]
А вообще там куча хотелок для embedded-разработки [4]. Учитывая как круто всё продвинулось в 2018 году, думаю скоро допилят недостающие части.
[1]: https://github.com/rust-lang/rfcs/pull/2480
[2]: https://github.com/rust-lang/rust/issues/51540
[3]: https://github.com/rust-embedded
[4]: https://github.com/rust-embedded/wg/issues/256
> Встроенный не умеет нормально с мк работать? А сторонних понаписали уже?
С этим пока всё плохо. В no_std аллокатора нет, а std для bare-metal не подходит. Есть API для аллокаторов (так что запросто можешь написать свой, там 2 функции: аллокация, деаллокация), но в no_std нет коллекций и объектов, которые могли бы его использовать. Сейчас хотят вынести все коллекции и объекты, требующие динамические аллокации из std в отдельный крейт [1], который будет работать в no_std и где будет возможно использование любого аллокатора + свой собственный обработчик OOM [2] (где например ты сможешь перезагрузить мк). Но сейчас тишина.
> Универсальную в смысле для разных архитектур или о чем вообще речь?
Ну да. Для условной компиляции придётся использовать флаги карго и в отличии от #ifdef из Си нельзя использовать целочисленные значения, только булевы.
> размер бинарника интересовал
С размером всё норм. Причиной большого размер растопрограмм, на который некоторые жалуются, являются две вещи: (1) стандартная библиотека и (2) статически скомпилированные несколько версий одной зависимости. (1) для no_std не является проблемой, а вот (2) вполне себе может всплыть. Например ты используешь крейт XXX версии 1.1 и крейт YYY. В свою очередь крейт YYY использует крейт XXX версии 1.0 и указано, что только эту версию и никакую другую. Из-за этого в бинарник слинкуются обе версии пакета XXX, что увеличит размер. Для тех кто программирует на С/С++ это будет в новизну, поскольку в си эта проблема решалась отсутствием пакетного менеджера и полностью ручным управлением зависимостями.
Ну и ещё может всплыть размер debug-версии программы. Хоть раст и использует zero-cost абстракции, в debug-версии они далеко не zero-cost и могут быть как медленней, так и занимать больше места. Иногда в разы. Особенно весело выглядит когда в debug-версии, чтобы подёргать пин дополнительно пишутся пара ветвлений и вызовов функций.
> Под мк корутины?
Угу. Их изначально пилят без динамических аллокаций.
> А это проект энтузиастов или это прямо разработчики раста пилят?
Автор japaric является разработчиком раста и вносит в язык/компилятор изменения для улучшения работы в embedded. Но конкретно RTFM это не официальный проект, да. Официальные проекты все находятся здесь [3]
А вообще там куча хотелок для embedded-разработки [4]. Учитывая как круто всё продвинулось в 2018 году, думаю скоро допилят недостающие части.
[1]: https://github.com/rust-lang/rfcs/pull/2480
[2]: https://github.com/rust-lang/rust/issues/51540
[3]: https://github.com/rust-embedded
[4]: https://github.com/rust-embedded/wg/issues/256
>>318276
С этим пока всё плохо. В no_std аллокатора нет, а std для bare-metal не подходит. Есть API для аллокаторов (так что запросто можешь написать свой, там 2 функции: аллокация, деаллокация), но в no_std нет коллекций и объектов, которые могли бы его использовать. Сейчас хотят вынести все коллекции и объекты, требующие динамические аллокации из std в отдельный крейт [1], который будет работать в no_std и где будет возможно использование любого аллокатора + свой собственный обработчик OOM [2] (где например ты сможешь перезагрузить мк). Но сейчас тишина.
Ну да. Для условной компиляции придётся использовать флаги карго и в отличии от #ifdef из Си нельзя использовать целочисленные значения, только булевы.
С размером всё норм. Причиной большого размер растопрограмм, на который некоторые жалуются, являются две вещи: (1) стандартная библиотека и (2) статически скомпилированные несколько версий одной зависимости. (1) для no_std не является проблемой, а вот (2) вполне себе может всплыть. Например ты используешь крейт XXX версии 1.1 и крейт YYY. В свою очередь крейт YYY использует крейт XXX версии 1.0 и указано, что только эту версию и никакую другую. Из-за этого в бинарник слинкуются обе версии пакета XXX, что увеличит размер. Для тех кто программирует на С/С++ это будет в новизну, поскольку в си эта проблема решалась отсутствием пакетного менеджера и полностью ручным управлением зависимостями.
Ну и ещё может всплыть размер debug-версии программы. Хоть раст и использует zero-cost абстракции, в debug-версии они далеко не zero-cost и могут быть как медленней, так и занимать больше места. Иногда в разы. Особенно весело выглядит когда в debug-версии, чтобы подёргать пин дополнительно пишутся пара ветвлений и вызовов функций.
Угу. Их изначально пилят без динамических аллокаций.
Автор japaric является разработчиком раста и вносит в язык/компилятор изменения для улучшения работы в embedded. Но конкретно RTFM это не официальный проект, да. Официальные проекты все находятся здесь [3]
А вообще там куча хотелок для embedded-разработки [4]. Учитывая как круто всё продвинулось в 2018 году, думаю скоро допилят недостающие части.
[1]: https://github.com/rust-lang/rfcs/pull/2480
[2]: https://github.com/rust-lang/rust/issues/51540
[3]: https://github.com/rust-embedded
[4]: https://github.com/rust-embedded/wg/issues/256
> Встроенный не умеет нормально с мк работать? А сторонних понаписали уже?
С этим пока всё плохо. В no_std аллокатора нет, а std для bare-metal не подходит. Есть API для аллокаторов (так что запросто можешь написать свой, там 2 функции: аллокация, деаллокация), но в no_std нет коллекций и объектов, которые могли бы его использовать. Сейчас хотят вынести все коллекции и объекты, требующие динамические аллокации из std в отдельный крейт [1], который будет работать в no_std и где будет возможно использование любого аллокатора + свой собственный обработчик OOM [2] (где например ты сможешь перезагрузить мк). Но сейчас тишина.
> Универсальную в смысле для разных архитектур или о чем вообще речь?
Ну да. Для условной компиляции придётся использовать флаги карго и в отличии от #ifdef из Си нельзя использовать целочисленные значения, только булевы.
> размер бинарника интересовал
С размером всё норм. Причиной большого размер растопрограмм, на который некоторые жалуются, являются две вещи: (1) стандартная библиотека и (2) статически скомпилированные несколько версий одной зависимости. (1) для no_std не является проблемой, а вот (2) вполне себе может всплыть. Например ты используешь крейт XXX версии 1.1 и крейт YYY. В свою очередь крейт YYY использует крейт XXX версии 1.0 и указано, что только эту версию и никакую другую. Из-за этого в бинарник слинкуются обе версии пакета XXX, что увеличит размер. Для тех кто программирует на С/С++ это будет в новизну, поскольку в си эта проблема решалась отсутствием пакетного менеджера и полностью ручным управлением зависимостями.
Ну и ещё может всплыть размер debug-версии программы. Хоть раст и использует zero-cost абстракции, в debug-версии они далеко не zero-cost и могут быть как медленней, так и занимать больше места. Иногда в разы. Особенно весело выглядит когда в debug-версии, чтобы подёргать пин дополнительно пишутся пара ветвлений и вызовов функций.
> Под мк корутины?
Угу. Их изначально пилят без динамических аллокаций.
> А это проект энтузиастов или это прямо разработчики раста пилят?
Автор japaric является разработчиком раста и вносит в язык/компилятор изменения для улучшения работы в embedded. Но конкретно RTFM это не официальный проект, да. Официальные проекты все находятся здесь [3]
А вообще там куча хотелок для embedded-разработки [4]. Учитывая как круто всё продвинулось в 2018 году, думаю скоро допилят недостающие части.
[1]: https://github.com/rust-lang/rfcs/pull/2480
[2]: https://github.com/rust-lang/rust/issues/51540
[3]: https://github.com/rust-embedded
[4]: https://github.com/rust-embedded/wg/issues/256
>>318309
Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так? То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C?
А управление зависимостями вручную возможно вообще как-то? То есть, описанная тобой проблема разных версий она вообще как-то хоть решаема на данный момент?
Алсо, а что с поддержкой конкретных МК и их периферии? Кто-то пилит либы или обходятся биндингами на libopencm3?
Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так? То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C?
А управление зависимостями вручную возможно вообще как-то? То есть, описанная тобой проблема разных версий она вообще как-то хоть решаема на данный момент?
Алсо, а что с поддержкой конкретных МК и их периферии? Кто-то пилит либы или обходятся биндингами на libopencm3?
>>318335
*раст видел?
*раст видел?
>>318335
Насобирали худшие практики из разных языков и реализовали в нечитабельный медленный "системный" язык.
Насобирали худшие практики из разных языков и реализовали в нечитабельный медленный "системный" язык.
>>318314
Встроенных - да. Я использовал в своём проекте библиотеку heapless [1]. Мне оттуда всего хватало.
Сложно сказать
Можно. Просто скачиваешь нужную версию крейта, проводишь необходимые изменения и в качестве источника указываешь каталог с крейтом [2]. Теперь вместо crates.io будет использоваться локальный каталог и обновлять зависимость сможешь только вручную. Можно даже сделать так, что при любом запросе этого конкретного крейта (даже если остальные берутся с crates.io) карго всегда отдавала локальную версию [3].
Тут ответ нужно разбить на две части. (1) - поддежржка архитектуры и (2) поддержка периферии. Первое касается компилятора и пакетного менеджера, второе - библиотек.
1) Если твоя архитектура оффициально поддерживается [4], поздравляю, никаких проблем не будет. Учитывая, что боддерживаются Cortex-M[0-7][F] то скорее всего с этим особых проблем не будет. Иначе придётся пердолиться и самомму компилиовать libcore под свою архитектуру. И это если сам llvm эту архитектуру поддерживат. Если llvm не поддерживает, то есть два варианта - транслировать раст в Си, а потом компилировать уже сишный код [5], самому пердолиться с llvm и добавлять возможно компиляции на свою архитектуру, как делают с AVR [6].
2) Тут вопрос библиотек. Для работы с периферией используются специальный раст-файлы сгенерированные из SVD при помощи утилиты svd2rust [7]. Там генерируются относительно безопасные абстракции для работы с периферией. Для некоторых мк есть уже готовые [8]. Плюс пилится универсальный hal [9], работающий поверх этих файлов, сгенерированных из SVD. Для некоторых мк также есть уже готовые реализации [10].
[1]: https://github.com/japaric/heapless
[2]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies
[3]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
[4]: https://forge.rust-lang.org/platform-support.html
[5]: https://github.com/thepowersgang/mrustc/
[6]: https://github.com/avr-rust/rust
[7]: https://github.com/rust-embedded/svd2rust
[8]: https://github.com/rust-embedded/awesome-embedded-rust#device-crates
[9]: https://github.com/rust-embedded/embedded-hal
[10]: https://github.com/rust-embedded/awesome-embedded-rust#hal-implementation-crates
> Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так?
Встроенных - да. Я использовал в своём проекте библиотеку heapless [1]. Мне оттуда всего хватало.
> То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C?
Сложно сказать
> А управление зависимостями вручную возможно вообще как-то?
Можно. Просто скачиваешь нужную версию крейта, проводишь необходимые изменения и в качестве источника указываешь каталог с крейтом [2]. Теперь вместо crates.io будет использоваться локальный каталог и обновлять зависимость сможешь только вручную. Можно даже сделать так, что при любом запросе этого конкретного крейта (даже если остальные берутся с crates.io) карго всегда отдавала локальную версию [3].
> Алсо, а что с поддержкой конкретных МК и их периферии?
Тут ответ нужно разбить на две части. (1) - поддежржка архитектуры и (2) поддержка периферии. Первое касается компилятора и пакетного менеджера, второе - библиотек.
1) Если твоя архитектура оффициально поддерживается [4], поздравляю, никаких проблем не будет. Учитывая, что боддерживаются Cortex-M[0-7][F] то скорее всего с этим особых проблем не будет. Иначе придётся пердолиться и самомму компилиовать libcore под свою архитектуру. И это если сам llvm эту архитектуру поддерживат. Если llvm не поддерживает, то есть два варианта - транслировать раст в Си, а потом компилировать уже сишный код [5], самому пердолиться с llvm и добавлять возможно компиляции на свою архитектуру, как делают с AVR [6].
2) Тут вопрос библиотек. Для работы с периферией используются специальный раст-файлы сгенерированные из SVD при помощи утилиты svd2rust [7]. Там генерируются относительно безопасные абстракции для работы с периферией. Для некоторых мк есть уже готовые [8]. Плюс пилится универсальный hal [9], работающий поверх этих файлов, сгенерированных из SVD. Для некоторых мк также есть уже готовые реализации [10].
[1]: https://github.com/japaric/heapless
[2]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies
[3]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
[4]: https://forge.rust-lang.org/platform-support.html
[5]: https://github.com/thepowersgang/mrustc/
[6]: https://github.com/avr-rust/rust
[7]: https://github.com/rust-embedded/svd2rust
[8]: https://github.com/rust-embedded/awesome-embedded-rust#device-crates
[9]: https://github.com/rust-embedded/embedded-hal
[10]: https://github.com/rust-embedded/awesome-embedded-rust#hal-implementation-crates
>>318314
Встроенных - да. Я использовал в своём проекте библиотеку heapless [1]. Мне оттуда всего хватало.
Сложно сказать
Можно. Просто скачиваешь нужную версию крейта, проводишь необходимые изменения и в качестве источника указываешь каталог с крейтом [2]. Теперь вместо crates.io будет использоваться локальный каталог и обновлять зависимость сможешь только вручную. Можно даже сделать так, что при любом запросе этого конкретного крейта (даже если остальные берутся с crates.io) карго всегда отдавала локальную версию [3].
Тут ответ нужно разбить на две части. (1) - поддежржка архитектуры и (2) поддержка периферии. Первое касается компилятора и пакетного менеджера, второе - библиотек.
1) Если твоя архитектура оффициально поддерживается [4], поздравляю, никаких проблем не будет. Учитывая, что боддерживаются Cortex-M[0-7][F] то скорее всего с этим особых проблем не будет. Иначе придётся пердолиться и самомму компилиовать libcore под свою архитектуру. И это если сам llvm эту архитектуру поддерживат. Если llvm не поддерживает, то есть два варианта - транслировать раст в Си, а потом компилировать уже сишный код [5], самому пердолиться с llvm и добавлять возможно компиляции на свою архитектуру, как делают с AVR [6].
2) Тут вопрос библиотек. Для работы с периферией используются специальный раст-файлы сгенерированные из SVD при помощи утилиты svd2rust [7]. Там генерируются относительно безопасные абстракции для работы с периферией. Для некоторых мк есть уже готовые [8]. Плюс пилится универсальный hal [9], работающий поверх этих файлов, сгенерированных из SVD. Для некоторых мк также есть уже готовые реализации [10].
[1]: https://github.com/japaric/heapless
[2]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies
[3]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
[4]: https://forge.rust-lang.org/platform-support.html
[5]: https://github.com/thepowersgang/mrustc/
[6]: https://github.com/avr-rust/rust
[7]: https://github.com/rust-embedded/svd2rust
[8]: https://github.com/rust-embedded/awesome-embedded-rust#device-crates
[9]: https://github.com/rust-embedded/embedded-hal
[10]: https://github.com/rust-embedded/awesome-embedded-rust#hal-implementation-crates
> Насчёт std и аллокаторов: получается сейчас использовать большинство встроенных непростых типов данных, в МК не получится, так?
Встроенных - да. Я использовал в своём проекте библиотеку heapless [1]. Мне оттуда всего хватало.
> То есть с точки зрения "батареек" сейчас раст под голый мк не лучше C?
Сложно сказать
> А управление зависимостями вручную возможно вообще как-то?
Можно. Просто скачиваешь нужную версию крейта, проводишь необходимые изменения и в качестве источника указываешь каталог с крейтом [2]. Теперь вместо crates.io будет использоваться локальный каталог и обновлять зависимость сможешь только вручную. Можно даже сделать так, что при любом запросе этого конкретного крейта (даже если остальные берутся с crates.io) карго всегда отдавала локальную версию [3].
> Алсо, а что с поддержкой конкретных МК и их периферии?
Тут ответ нужно разбить на две части. (1) - поддежржка архитектуры и (2) поддержка периферии. Первое касается компилятора и пакетного менеджера, второе - библиотек.
1) Если твоя архитектура оффициально поддерживается [4], поздравляю, никаких проблем не будет. Учитывая, что боддерживаются Cortex-M[0-7][F] то скорее всего с этим особых проблем не будет. Иначе придётся пердолиться и самомму компилиовать libcore под свою архитектуру. И это если сам llvm эту архитектуру поддерживат. Если llvm не поддерживает, то есть два варианта - транслировать раст в Си, а потом компилировать уже сишный код [5], самому пердолиться с llvm и добавлять возможно компиляции на свою архитектуру, как делают с AVR [6].
2) Тут вопрос библиотек. Для работы с периферией используются специальный раст-файлы сгенерированные из SVD при помощи утилиты svd2rust [7]. Там генерируются относительно безопасные абстракции для работы с периферией. Для некоторых мк есть уже готовые [8]. Плюс пилится универсальный hal [9], работающий поверх этих файлов, сгенерированных из SVD. Для некоторых мк также есть уже готовые реализации [10].
[1]: https://github.com/japaric/heapless
[2]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#specifying-path-dependencies
[3]: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#overriding-dependencies
[4]: https://forge.rust-lang.org/platform-support.html
[5]: https://github.com/thepowersgang/mrustc/
[6]: https://github.com/avr-rust/rust
[7]: https://github.com/rust-embedded/svd2rust
[8]: https://github.com/rust-embedded/awesome-embedded-rust#device-crates
[9]: https://github.com/rust-embedded/embedded-hal
[10]: https://github.com/rust-embedded/awesome-embedded-rust#hal-implementation-crates
>>318342
На расте.
На расте.
>>318340
Не знаю что такое SVD. Ладно, буду читать, потому что очень интересно стало. Круто, что это всё активно развивается, в том числе самими разработчиками языка.
Ещё раз спасибо за развернутые ответы и ссылки.
Не знаю что такое SVD. Ладно, буду читать, потому что очень интересно стало. Круто, что это всё активно развивается, в том числе самими разработчиками языка.
Ещё раз спасибо за развернутые ответы и ссылки.
Ваше мертворождённое говно ещё живо?
>>318541
garbage collector
garbage collector
103 Кб, 640x775- User doesn't like the fact that buildbot (which they think is maintained by mozilla) uses "master/slave" terminology https://github.com/rust-lang/rust-buildbot/issues/2 . Mozilla gives buildbot $15k for changing it https://blog.mozilla.org/blog/2015/12/10/mozilla-open-source-support-first-awards-made/
- User doesn't like that dining philosophers is cited with some male and/or gender-neutral pronouns and placeholders (even though the original exposition was already changed to female pronouns) -- proceeds to change the rest of the pronouns to female (I guess gender-neutral didn't make sense) https://github.com/rust-lang/rust/pull/25640
- User thinks "bad code style" is offensive https://github.com/rust-lang/rust/issues/41646
- User doesn't like brotli encoding type being called "bro" https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147
- User thinks that the code of conduct is too general in its suggestions that all people be respected and treated fairly -- it needs to explicitly cite certain groups https://github.com/rust-lang/rust-www/issues/268
- User doesn't like that dining philosophers is cited with some male and/or gender-neutral pronouns and placeholders (even though the original exposition was already changed to female pronouns) -- proceeds to change the rest of the pronouns to female (I guess gender-neutral didn't make sense) https://github.com/rust-lang/rust/pull/25640
- User thinks "bad code style" is offensive https://github.com/rust-lang/rust/issues/41646
- User doesn't like brotli encoding type being called "bro" https://bugzilla.mozilla.org/show_bug.cgi?id=366559#c147
- User thinks that the code of conduct is too general in its suggestions that all people be respected and treated fairly -- it needs to explicitly cite certain groups https://github.com/rust-lang/rust-www/issues/268
39 Кб, 580x442>>318687
Щито поделаешь. Пидарасы.
Щито поделаешь. Пидарасы.
>>318687
Теперь точно меньше адекватных людей будут пытаться написать что-то на этом убогом недоязыке.
Теперь точно меньше адекватных людей будут пытаться написать что-то на этом убогом недоязыке.
>>318276
Он там нахуй не нужен. Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке без динамической аллокации (потому что стандартная библиотека с маллоками тупо не влезает). Плюс там всякая низкоуровневая ебала, в принципе не совместимая с идеологией раста. Вроде того, что регистры МК мапятся в глобальные переменные, и ты через них дергаешь какой-нибудь аппаратный функционал.
>чтобы когда-нибудь в ближайшее время он стал достойной заменой C/C++ для встраиваемых (особенно bare-metal) систем
Он там нахуй не нужен. Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке без динамической аллокации (потому что стандартная библиотека с маллоками тупо не влезает). Плюс там всякая низкоуровневая ебала, в принципе не совместимая с идеологией раста. Вроде того, что регистры МК мапятся в глобальные переменные, и ты через них дергаешь какой-нибудь аппаратный функционал.
>>318888
Bare-metal это не только старинные 8-битные контроллеры, где каждый бит на цену золота. Плюс раст вполне себе работает без аллокаций.
Не пизди. Тут только вопрос абстракций. Множество проверок неправильного использования проделываются во время компиляции. Для остальных используется unsafe (и то по большей части это не ограничение языка, а из-за того, что CMSIS-SVD файлы не описывают мк достаточно подробно, чтоб добавить все проверки).
В расте (конкретно в файлах, сгенерированных svd2rust) можно использовать как и синглтоны (но такое использование нужно оборачивать в unsafe) либо как специальные типы, которые могут быть только в единичном экземпляре, зато могут свободно перемещаться по функциям и потокам (в случае есть используется RTOS). Плюс встроенные в систему типов стандартные гарантии безопасности, например что может быть сколько угодно ссылок на чтение, но только одна на запись и т.д.
> Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке без динамической аллокации
Bare-metal это не только старинные 8-битные контроллеры, где каждый бит на цену золота. Плюс раст вполне себе работает без аллокаций.
> в принципе не совместимая с идеологией раста
Не пизди. Тут только вопрос абстракций. Множество проверок неправильного использования проделываются во время компиляции. Для остальных используется unsafe (и то по большей части это не ограничение языка, а из-за того, что CMSIS-SVD файлы не описывают мк достаточно подробно, чтоб добавить все проверки).
> Вроде того, что регистры МК мапятся в глобальные переменные, и ты через них дергаешь какой-нибудь аппаратный функционал.
В расте (конкретно в файлах, сгенерированных svd2rust) можно использовать как и синглтоны (но такое использование нужно оборачивать в unsafe) либо как специальные типы, которые могут быть только в единичном экземпляре, зато могут свободно перемещаться по функциям и потокам (в случае есть используется RTOS). Плюс встроенные в систему типов стандартные гарантии безопасности, например что может быть сколько угодно ссылок на чтение, но только одна на запись и т.д.
>>318857
Тут ты прав. с/с++ быстрее всех остальных языков создают утечки памяти и сегфолты.
>Всё быстрое
Тут ты прав. с/с++ быстрее всех остальных языков создают утечки памяти и сегфолты.
>>318917
Глупости, есть паттерны выделения и освобождения памяти, держишь их в уме и все чики пуки
>утечки памяти и сегфолты
Глупости, есть паттерны выделения и освобождения памяти, держишь их в уме и все чики пуки
>>318906
У большинства 32-битных микроконтроллеров ОЗУ не больше 64 килобайт:
https://www.chipdip.ru/catalog/ic-microcontrollers?x.3713=UCU
Остальная память - ROM разных видов.
Ну так в условные 64 килобайта у тебя много абстракций не влезет. Часто бывает, что и стек не влезает. Приходится делать локальные статические переменные вместо стековых. Раст такое умеет?
>Bare-metal это не только старинные 8-битные контроллеры, где каждый бит на цену золота.
У большинства 32-битных микроконтроллеров ОЗУ не больше 64 килобайт:
https://www.chipdip.ru/catalog/ic-microcontrollers?x.3713=UCU
Остальная память - ROM разных видов.
>Тут только вопрос абстракций.
Ну так в условные 64 килобайта у тебя много абстракций не влезет. Часто бывает, что и стек не влезает. Приходится делать локальные статические переменные вместо стековых. Раст такое умеет?
>>318946
Решаемую задачу держит в голове твой менеджер. Ты держишь в голове ее реализацию.
>Вместо того, чтобы держать в уме решаемую задачу.
Решаемую задачу держит в голове твой менеджер. Ты держишь в голове ее реализацию.
>>318949
Влезет. Почти все они zero-cost и все проверки происходят во время компиляции. Правда много оптимизаций (по встраиванию функций и удалению мёртвого кода) ложится на плечи LLVM, а не самого компилятора, так что ассемблерный код на всякий случай стоит проверять, учитывая что 90% багов мисскомпиляции это баги LLVM.
Умеет. Правда любой доступ к подобной переменной считается небезопасным. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=1ab67d50fec6df4d9eae343630749b9d
> Ну так в условные 64 килобайта у тебя много абстракций не влезет.
Влезет. Почти все они zero-cost и все проверки происходят во время компиляции. Правда много оптимизаций (по встраиванию функций и удалению мёртвого кода) ложится на плечи LLVM, а не самого компилятора, так что ассемблерный код на всякий случай стоит проверять, учитывая что 90% багов мисскомпиляции это баги LLVM.
> Приходится делать локальные статические переменные вместо стековых. Раст такое умеет?
Умеет. Правда любой доступ к подобной переменной считается небезопасным. https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=1ab67d50fec6df4d9eae343630749b9d
>>318952
И в итоге реализация не соответствует задаче.
И в итоге реализация не соответствует задаче.
>>318888
Лол, ты давно последний раз этим занимался? Сейчас разница в цене между микроконтроллерами не такая большая, поэтому очень часто конторы просто ставят железку позабористей, лишь бы сделать заказ быстрее и получить бабло. Никому не упёрлось мудиться с ассемблером и высчитывать байты полгода, если можно ту же задачу решить за месяц. На моем последнем рабочем месте вообще в некоторых проектах часть высокоуровневой логики была написана на питоне и работала под их собственной адаптацией micropython. Может, крупные компании при производстве в огромных количествах при таком подходе и меньше профита получат, чем если будут писать на асме, но тут ни в одной конторе я сам ни разу такого не видел и не слышал такого ни от одного из знакомых, кто байтоёбством ещё со студенческих годов занимается.
Аллокаторы с разными фичами по-моему в любую ртос уже завезли, да и newlibc не настолько жирная, не помню, чтобы она не влезала, но обычно без динамики можно обойтись в голом железе.
Я не любитель такого подхода, когда вместо оптимизации и использования приемлемых средств запихивают кучу говна и ставят железо помощнее и памяти побольше, но есть какая-то граница разумной борьбы за ресурсы, за которой уже начинается абсурдный дроч.
> Там же микроконтроллеры с килобайтами памяти, все пишется на ассемблере или очень низкоуровневой сишке
Лол, ты давно последний раз этим занимался? Сейчас разница в цене между микроконтроллерами не такая большая, поэтому очень часто конторы просто ставят железку позабористей, лишь бы сделать заказ быстрее и получить бабло. Никому не упёрлось мудиться с ассемблером и высчитывать байты полгода, если можно ту же задачу решить за месяц. На моем последнем рабочем месте вообще в некоторых проектах часть высокоуровневой логики была написана на питоне и работала под их собственной адаптацией micropython. Может, крупные компании при производстве в огромных количествах при таком подходе и меньше профита получат, чем если будут писать на асме, но тут ни в одной конторе я сам ни разу такого не видел и не слышал такого ни от одного из знакомых, кто байтоёбством ещё со студенческих годов занимается.
> без динамической аллокации (потому что стандартная библиотека с маллоками тупо не влезает).
Аллокаторы с разными фичами по-моему в любую ртос уже завезли, да и newlibc не настолько жирная, не помню, чтобы она не влезала, но обычно без динамики можно обойтись в голом железе.
Я не любитель такого подхода, когда вместо оптимизации и использования приемлемых средств запихивают кучу говна и ставят железо помощнее и памяти побольше, но есть какая-то граница разумной борьбы за ресурсы, за которой уже начинается абсурдный дроч.
>>318953
Как ты будешь, например, лямбды без стека делать, ты подумал? Инлайны тоже придется отключить.В итоге программа на расте под микроконтроллер будет выглядеть хуже сишечной из-за unsafe через каждое слово. Нахуя тогда этот раст нужен, если сишка для таких задач тупо проще?
>Почти все они zero-cost и все проверки происходят во время компиляции.
Как ты будешь, например, лямбды без стека делать, ты подумал? Инлайны тоже придется отключить.В итоге программа на расте под микроконтроллер будет выглядеть хуже сишечной из-за unsafe через каждое слово. Нахуя тогда этот раст нужен, если сишка для таких задач тупо проще?
>>318966
Путём встраивания. Учитывая, что 90% лямбд одноразовые это наилучшее решение.
Можно сказать LLVM, чтоб он не инлайнил автоматом, но инлайны заданные вручную через атрибут #[inline(always)] всё равно будут встраиваться. Это тебе не С/С++ где компилятор может игнорировать любой запрос ели ему захочется.
Никто не заставляет использовать unsafe. Я на мк писал довольно сложные приложения с RTOS и (псевдо)многопоточностью и unsafe там не нужен был от слова вообще поскольку библиотеки давали неплохие безопасные абстракции. Например если заранее известно, что на мк одно ядро и одну функцию не могут одновременно вызвать два разных потока, то локальные static mut являются безопасными. Так например делает фреймворк RTFM при помощи макросов.
> Как ты будешь, например, лямбды без стека делать, ты подумал?
Путём встраивания. Учитывая, что 90% лямбд одноразовые это наилучшее решение.
> Инлайны тоже придется отключить.
Можно сказать LLVM, чтоб он не инлайнил автоматом, но инлайны заданные вручную через атрибут #[inline(always)] всё равно будут встраиваться. Это тебе не С/С++ где компилятор может игнорировать любой запрос ели ему захочется.
> В итоге программа на расте под микроконтроллер будет выглядеть хуже сишечной из-за unsafe через каждое слово.
Никто не заставляет использовать unsafe. Я на мк писал довольно сложные приложения с RTOS и (псевдо)многопоточностью и unsafe там не нужен был от слова вообще поскольку библиотеки давали неплохие безопасные абстракции. Например если заранее известно, что на мк одно ядро и одну функцию не могут одновременно вызвать два разных потока, то локальные static mut являются безопасными. Так например делает фреймворк RTFM при помощи макросов.
>>318957
Очень сильно зависит от задачи и от серии. Если серийность небольшая, то можно и одноплатник с линуксом поставить. А если девайс миллионной серией выпускается, то заказчик каждый цент считает. То есть в условный китайский фонарик, который красиво моргает светодиодиками, ты можешь поставить только супердешевое восьмибитное говно без корпуса.
>Сейчас разница в цене между микроконтроллерами не такая большая, поэтому очень часто конторы просто ставят железку позабористей, лишь бы сделать заказ быстрее и получить бабло.
Очень сильно зависит от задачи и от серии. Если серийность небольшая, то можно и одноплатник с линуксом поставить. А если девайс миллионной серией выпускается, то заказчик каждый цент считает. То есть в условный китайский фонарик, который красиво моргает светодиодиками, ты можешь поставить только супердешевое восьмибитное говно без корпуса.
>>318969
Это все равно на уровне можнаследать. Вопрос, нахуя ебаться, если сишка с IDE у тебя искаропки, а с растом приходится пердолиться? И каких-то особых преимуществ он не дает, потому что нет ни многопоточности ни динамической аллокации, а все данные - в основном в глобальных переменных. Писать на нем может и приятнее, но каких-то суперудобных фич там нет.
Это все равно на уровне можнаследать. Вопрос, нахуя ебаться, если сишка с IDE у тебя искаропки, а с растом приходится пердолиться? И каких-то особых преимуществ он не дает, потому что нет ни многопоточности ни динамической аллокации, а все данные - в основном в глобальных переменных. Писать на нем может и приятнее, но каких-то суперудобных фич там нет.
>>318970
Так я об этом и писал. Просто в России по-моему китайские фонарики никто не делает, потому что стоимость выйдет не та, и они никому не нужны будут. А всё остальное не в таких масштабах делается.
Алсо, в фонариках и прочей подобной ебале часто заказные микросхемы стоят, которые реализуют нужную логику работы, написанную на каком-нибудь vhdl, и микроконтроллерами там не пахнет даже.
Так я об этом и писал. Просто в России по-моему китайские фонарики никто не делает, потому что стоимость выйдет не та, и они никому не нужны будут. А всё остальное не в таких масштабах делается.
Алсо, в фонариках и прочей подобной ебале часто заказные микросхемы стоят, которые реализуют нужную логику работы, написанную на каком-нибудь vhdl, и микроконтроллерами там не пахнет даже.
>>318974
Это всё на уровне ужеработает.
Это тебе для китайских фонариков многопоточность нужна? Чтоб двумя светодиодами моргать одновременно без задержек? И да никаких проблем с многопоточность нет, что в одноядерных системах, что в многоядерных (хотя на многоядерных мк я на расте не писал).
Странно ты как-то тему сменяешь, сначала мычал про то что абстракции не бесплатные. Хотя большинство абстракций тот же RTFM предоставляет через compile-time макрос, который всё проверяет во время компиляции и после чего генерирует растокод, т.е. по факту ты пишешь даже не на расте, а на растоподобном DSL заточенном на работу с мк. Теперь же вообще тебе раст не нужен, потому что тебе он не нравится.
> Это все равно на уровне можнаследать.
Это всё на уровне ужеработает.
> И каких-то особых преимуществ он не дает, потому что нет ни многопоточности ни динамической аллокации
Это тебе для китайских фонариков многопоточность нужна? Чтоб двумя светодиодами моргать одновременно без задержек? И да никаких проблем с многопоточность нет, что в одноядерных системах, что в многоядерных (хотя на многоядерных мк я на расте не писал).
Странно ты как-то тему сменяешь, сначала мычал про то что абстракции не бесплатные. Хотя большинство абстракций тот же RTFM предоставляет через compile-time макрос, который всё проверяет во время компиляции и после чего генерирует растокод, т.е. по факту ты пишешь даже не на расте, а на растоподобном DSL заточенном на работу с мк. Теперь же вообще тебе раст не нужен, потому что тебе он не нравится.
Раст это поделие тупых либерал-феменисток и лгбт, и для подобных создан. Когда они заменят все маняоффенсив термины, ни один нормальный человек никогда не станет писать на этом ебучем языке. Тьфу в ебало, растопидор.
>>318977
Прямо раст искаробки в фирменном IDE идет?
Так и есть. Лямбды не бесплатные, трейты не бесплатные, инлайны не бесплатные. Тупо вызов функции - не бесплатный, когда каждый такт и байтик экономишь.
Мне он не нужен, потому что я от него какой-то особой пользы не вижу. Можно типа срать не снимая свитера, охуенно.
>Это всё на уровне ужеработает.
Прямо раст искаробки в фирменном IDE идет?
>то что абстракции не бесплатные
Так и есть. Лямбды не бесплатные, трейты не бесплатные, инлайны не бесплатные. Тупо вызов функции - не бесплатный, когда каждый такт и байтик экономишь.
>Теперь же вообще тебе раст не нужен, потому что тебе он не нравится.
Мне он не нужен, потому что я от него какой-то особой пользы не вижу. Можно типа срать не снимая свитера, охуенно.
>>318980
Ну хоть один нормальный аргумент против раста. А то всё про тяжёлость, многопоточность, сложность. Вот этот сечёт почему раст говно.
Ну хоть один нормальный аргумент против раста. А то всё про тяжёлость, многопоточность, сложность. Вот этот сечёт почему раст говно.
>>318982
Нет. Такое доступно только илитным программистам на ассемблере. ИДЕ с линтером, который сыпет фатальными ошибками на каждый несэкономленный бит.
Верю тебе. Честное слово. Зачем мне смотреть на сгенерированный ассемблерный код и делать выводы, если анон с сосача всё пояснил как боженька. Вопрос закрыт. Ты абсолютно прав. Это даже обсуждать нельзя. Я запрещаю.
> Прямо раст искаробки в фирменном IDE идет?
Нет. Такое доступно только илитным программистам на ассемблере. ИДЕ с линтером, который сыпет фатальными ошибками на каждый несэкономленный бит.
> Так и есть.
Верю тебе. Честное слово. Зачем мне смотреть на сгенерированный ассемблерный код и делать выводы, если анон с сосача всё пояснил как боженька. Вопрос закрыт. Ты абсолютно прав. Это даже обсуждать нельзя. Я запрещаю.
>>318987
Тебя нет. Ты же либерал, за однополые браки небось и свержение патриархата.
Тебя нет. Ты же либерал, за однополые браки небось и свержение патриархата.
>>318985
Фу, либераха. Без сейф-спейса даже программу написать не может.
Фу, либераха. Без сейф-спейса даже программу написать не может.
>>318992
Это слово запрещено к использованию согласно нашему Code Of Conduct, кроме тех случаев если вы феминистки или транссексуалки и говном называете патриархально-белое капиталистическое общество и его адептов.
Пожалуйста, соблюдайте правила, или я вынуждены буду пожаловаться модератору.
И да, единственное число по отношению к человекам использовать тоже запрещено, как и все местоимения третьего числа, кроме они.
> говно
Это слово запрещено к использованию согласно нашему Code Of Conduct, кроме тех случаев если вы феминистки или транссексуалки и говном называете патриархально-белое капиталистическое общество и его адептов.
Пожалуйста, соблюдайте правила, или я вынуждены буду пожаловаться модератору.
И да, единственное число по отношению к человекам использовать тоже запрещено, как и все местоимения третьего числа, кроме они.
>>318995
Раст использует особую систему типов, разработанную на основе GST (gender studies theory), разновидности type theory, изначально испробованной в хаскеле, но убранной оттуда по причине недостаточной прогрессивности мейнтейнеров языка.
Раст использует особую систему типов, разработанную на основе GST (gender studies theory), разновидности type theory, изначально испробованной в хаскеле, но убранной оттуда по причине недостаточной прогрессивности мейнтейнеров языка.
>>319001
Привилегии проверены? А если обвиню в харрасменте?
Привилегии проверены? А если обвиню в харрасменте?
>>319305
Пару раз возникала мысль посмотреть раст как альтернативу крестам для своих проектов, но каждый раз я открывал список мейнтейнеров и кор команды языка, и понимал что не хочу шквариться используя что-то созданное этим биомусором.
Воистину, нормальный язык может быть создан только людьми.
Пару раз возникала мысль посмотреть раст как альтернативу крестам для своих проектов, но каждый раз я открывал список мейнтейнеров и кор команды языка, и понимал что не хочу шквариться используя что-то созданное этим биомусором.
Воистину, нормальный язык может быть создан только людьми.
>>319347
Да уж, что говорить о применимости языка вообще, если его кор разработчики на сайтах знакомств для пидоров сидят. Не удивлюсь, если еще и в чат-рулетках.
Да уж, что говорить о применимости языка вообще, если его кор разработчики на сайтах знакомств для пидоров сидят. Не удивлюсь, если еще и в чат-рулетках.
>>319349
Зато вкат простой, достаточно уметь долбиться в жопу и знать паттерны сосания хуев.
Зато вкат простой, достаточно уметь долбиться в жопу и знать паттерны сосания хуев.
>>319314
а я наоборот ценю раст за то, что гомофобная гопота типа тебя его обходит стороной
а я наоборот ценю раст за то, что гомофобная гопота типа тебя его обходит стороной
>>319314
Зависть плохое чувство
Зависть плохое чувство
подскажите, что в расте принято использовать для отправки запросов к серверу по rpc и последующего парсинга json-ответа
10,4 Мб, webm,1920x1056, 0:19
С новым годом, котятки!
Пока все дрыхнут после вчерашней пьянки, лениво пилю видеорелейтед.
А у вас как дела?
Пока все дрыхнут после вчерашней пьянки, лениво пилю видеорелейтед.
А у вас как дела?
>>319392
Ещё никого не увольняли за внедрение grpc в проект.
Ещё никого не увольняли за внедрение grpc в проект.
>>319437
На расте пилишь? Я бы такое в терминале пощупал, неплохо сделано, но хорошо бы вимоподобный инкрементальный поиск по тексту шапки например...
На расте пилишь? Я бы такое в терминале пощупал, неплохо сделано, но хорошо бы вимоподобный инкрементальный поиск по тексту шапки например...
>>319578
Конечно на расте, на чем же еще.
https://github.com/TatriX/dvach/tree/feat/tui
Оно как раз для терминала.
Ветка еще не смержена, ибо WIP, tui за пару часов накидан плюс я до этого никогда не делал этот самый tui.
Конечно на расте, на чем же еще.
https://github.com/TatriX/dvach/tree/feat/tui
Оно как раз для терминала.
Ветка еще не смержена, ибо WIP, tui за пару часов накидан плюс я до этого никогда не делал этот самый tui.
Нормально-ли в контроллере Rocket на необрабатываемые ошибки высираться с помощью panic!("[здесь_название_метода_который_вернул_error]: {:?}", e)? Есть-ли какие-то более правильные решения, чтобы не приходилось постоянно это писать в ручную?
>>319604
Как видишь добровольно и бесплатно пока что получается в основном на расте. Особенно это хорошо заметно в трендах гитхаба, где новые тулзы каждую неделю появляются.
cargo/crates.io очень сильно способствует этому.
Как видишь добровольно и бесплатно пока что получается в основном на расте. Особенно это хорошо заметно в трендах гитхаба, где новые тулзы каждую неделю появляются.
cargo/crates.io очень сильно способствует этому.
>>319607
Ну вот видишь, такой себе "язык". Не удивлюсь, если его разрабы в один день призовут убрать всех мужиков из проекта
Ну вот видишь, такой себе "язык". Не удивлюсь, если его разрабы в один день призовут убрать всех мужиков из проекта
>>319614
Да этож не жс, у нас тут все мужики, просто кукуолды немножк, всмысле, спонсоры пидоры, вот и приходится изворачиваться.
Да этож не жс, у нас тут все мужики, просто кукуолды немножк, всмысле, спонсоры пидоры, вот и приходится изворачиваться.
2,4 Мб, webm,1920x1056, 0:12
Картинки в ASCII пробовал конвертировать. Получается стремно.
>>320109
В браузере где можно шрифты для картинки отдельно от остального текста уменьшить — может быть.
В браузере где можно шрифты для картинки отдельно от остального текста уменьшить — может быть.
>>320061
есть pixterm, посмотри... и ещё я видел утилиты которые в консоль могут выводить графику
есть pixterm, посмотри... и ещё я видел утилиты которые в консоль могут выводить графику
86 Кб, 996x1024>>317439
Гм, не понятно в каком смысле они "нативные".
Под юниксы, у меня шиндовс.
Ну оно какое-то не оче и заточенное под менюшки, я вообще зачем-то тетрис пилю в терминале и мне было интересно потрогать curses.
Да и вообще вопрос был "какого хуя оно так?", не в том что я не могу осилить curses (просто использую addstr и по-прежнему не понимаю зачем в расто-версии printw и почему только у меня этот вопрос возник).
>нативную
Гм, не понятно в каком смысле они "нативные".
>tui-rs
Под юниксы, у меня шиндовс.
>Cursive
Ну оно какое-то не оче и заточенное под менюшки, я вообще зачем-то тетрис пилю в терминале и мне было интересно потрогать curses.
Да и вообще вопрос был "какого хуя оно так?", не в том что я не могу осилить curses (просто использую addstr и по-прежнему не понимаю зачем в расто-версии printw и почему только у меня этот вопрос возник).
>>320739
Вы тоже сосите хуй и даете в жопу?
Вы тоже сосите хуй и даете в жопу?
>>320386
зачем тебе на винде консоль? она же там вообще никакая, поэтому у вас мышевозить принято
>у меня шиндовс
зачем тебе на винде консоль? она же там вообще никакая, поэтому у вас мышевозить принято
>>319437
а этот cursive умеет отображать окно с меню в заданных координатах без всяких рамок, заголовков, кнопок и скроллбаров?
а этот cursive умеет отображать окно с меню в заданных координатах без всяких рамок, заголовков, кнопок и скроллбаров?
55 Кб, 909x623>>320743
Про MinGW и прочие MSYS, обмазанные всякими Cmder/ConEmu ты не в курсе, видимо?
Про MinGW и прочие MSYS, обмазанные всякими Cmder/ConEmu ты не в курсе, видимо?
54 Кб, 395x427https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#module-system-changes
Нахуя это сделали? Вроде раньше логично было.
И даже из более подробного описания
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-modrs
не всё понятно.
Старый foo/mod.rs и новый foo.rs - одинаково себя вести будут, как корень модуля? А если оба файла присутствуют?
>A foo.rs and foo/ subdirectory may coexist; mod.rs is no longer needed when placing submodules in a subdirectory.
Нахуя это сделали? Вроде раньше логично было.
И даже из более подробного описания
https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html#no-more-modrs
не всё понятно.
Старый foo/mod.rs и новый foo.rs - одинаково себя вести будут, как корень модуля? А если оба файла присутствуют?
>>321000
Убрали необходимость в mod.rs типа потому, что если у тебя есть три модуля:
./foo/mod.rs
./bar/mod.rs
./baz/mod.rs
То в некоторых говноредакторах у тебя будет три вкладки
mod.rs
mod.rs
mod.rs
Убрали необходимость в mod.rs типа потому, что если у тебя есть три модуля:
./foo/mod.rs
./bar/mod.rs
./baz/mod.rs
То в некоторых говноредакторах у тебя будет три вкладки
mod.rs
mod.rs
mod.rs
Что-то пока не очень понимаю enum. Производит впечатление какой-то смеси enum и union из C, правильно? У самих вариантов явного значения как в C это было нет, но при этом принцип работы при использовании в match примерно такой же, как в switch из C. Но при этом в вариантах можно хранить данные разных типов, если мы создаем экземпляр варианта и кладём его в переменную. Зачем это нужно, кроме случаев Some/None? Какие еще сценарии использования enum могут быть?
>>321951
Гугли "алгебраический тип данных". Гапример в хаскеле все, что не примитивные типы - оно самое.
Вообще enum'ы это полезная штука. Простой пример: мы любим запускать таски в тредах, а потом сохраняем все результаты. Таска может: успешно выполниться, завершиться с логической ошибкой или запаниковать. Для этого можно описать такой enum:
enum TaskResult<T> {
Ok(T),
Error { code: u8, description: Option<String> },
Panic(String)
}
А вот так описан IP-адрес в стандартной библиотеке: https://doc.rust-lang.org/src/std/net/ip.rs.html#49-56
-
Гугли "алгебраический тип данных". Гапример в хаскеле все, что не примитивные типы - оно самое.
Вообще enum'ы это полезная штука. Простой пример: мы любим запускать таски в тредах, а потом сохраняем все результаты. Таска может: успешно выполниться, завершиться с логической ошибкой или запаниковать. Для этого можно описать такой enum:
enum TaskResult<T> {
Ok(T),
Error { code: u8, description: Option<String> },
Panic(String)
}
А вот так описан IP-адрес в стандартной библиотеке: https://doc.rust-lang.org/src/std/net/ip.rs.html#49-56
-
>>321124
Поддержу. На Win10 ноутбучной решил поставить Раст вдобавок к Cpp, Haskell, Go... и только rustup отказывается ставиться: rustup install stable вываливается с ошибкой SSL[35], проще говоря валится на curl. Я даже _curlrc сделал. Ну и чего ждать от людей которые работу инсталлятора не могут сделать нормально настраиваемой?
Поддержу. На Win10 ноутбучной решил поставить Раст вдобавок к Cpp, Haskell, Go... и только rustup отказывается ставиться: rustup install stable вываливается с ошибкой SSL[35], проще говоря валится на curl. Я даже _curlrc сделал. Ну и чего ждать от людей которые работу инсталлятора не могут сделать нормально настраиваемой?
> обработка ошибок как в win32api
> дженериков нет и не будет
> официальный сайт и документация без подсветки синтаксиса, потому что главный разработчик (!) языка считает что она не нужна (!!)
> ущербный менеджер пакетов
> конфликты т.к. один монолитный путь GOPATH на все
>>322477
Братишка, ты тредом промазал. Загон годаунов где-то неподалеку.
Братишка, ты тредом промазал. Загон годаунов где-то неподалеку.
>>322477
Н-но ведь во второй версии обещали гонерики. Как генерики, только круче и проще для использования молодыми специалистами.
> > дженериков нет и не будет
Н-но ведь во второй версии обещали гонерики. Как генерики, только круче и проще для использования молодыми специалистами.
Служу в секретной мурманской залупе, читаю TRPL и Programming Rust, оторваться не могу. Единственное, не хватает сухой документации по стандартной либе, чтобы программировать на бумажке. Где-нибудь такое можно достать? Как же ущербно выглядит Go в сравнении. Зря столько говна писал на нем.
>>322640
Как-то не очень конкретно написал. Нужна офлайн-версия документации. PDF, например. Да хоть обычные текстовые файлы! Обнял.
Как-то не очень конкретно написал. Нужна офлайн-версия документации. PDF, например. Да хоть обычные текстовые файлы! Обнял.
>>322641
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/index.html
~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/std/index.html
>>322646
Хуево быть тобой. Че хотел-то?
Хуево быть тобой. Че хотел-то?
>>322646
Ставишь виртуалку, подключаешь через телефон к инету.
>и компьютер на Windows без доступа в интернет.
Ставишь виртуалку, подключаешь через телефон к инету.
>>322669
Буду очень благодарен, товарищ.
>>322661
Увидишь нить в какое-то не то русло, но отвечу. ЗГТшный софт, логирующий все подключенные PCI/USB устройства, отсутствие любой сетевой карты в принципе, отсутствие админских прав, возможность посидеть за компьютером без присмотра офицеров только во время дежурства по роте после общего отбоя. Я тут себе PDFки печатаю и сшиваю, а не с пацанами в доту и хартстоун катаю по сети, как пацаны с флотилии делают. Только за праздники чекист четыре раза приходил.
Буду очень благодарен, товарищ.
>>322661
Увидишь нить в какое-то не то русло, но отвечу. ЗГТшный софт, логирующий все подключенные PCI/USB устройства, отсутствие любой сетевой карты в принципе, отсутствие админских прав, возможность посидеть за компьютером без присмотра офицеров только во время дежурства по роте после общего отбоя. Я тут себе PDFки печатаю и сшиваю, а не с пацанами в доту и хартстоун катаю по сети, как пацаны с флотилии делают. Только за праздники чекист четыре раза приходил.
>>322678
Спасибо, анон! Отпишусь в тредике где-то в июле.
Спасибо, анон! Отпишусь в тредике где-то в июле.
Зачем служить в хуйне, если можно нормально программировать сидя дома на диване и получать за это деньги?
Там один из растовчан обиделся на мозилу и ушёл оттуда: https://www.reddit.com/r/rust/comments/adiq71/thank_u_next_steve_klabnik/
Поскольку он занимался в основном документацией, платили ему меньше всех, лол.
Поскольку он занимался в основном документацией, платили ему меньше всех, лол.
23 Кб, 400x400>>322712
Кстати, похож на патлатого гейба.
Кстати, похож на патлатого гейба.
>>322712
Если прочитать статью об уходе целиком, то станет понятно, что чел - гендерно небинарный вертосексуал и ушел оттуда из-за неравенства и харассмента, а не изза доков, как несведомый анон пишет.
Если прочитать статью об уходе целиком, то станет понятно, что чел - гендерно небинарный вертосексуал и ушел оттуда из-за неравенства и харассмента, а не изза доков, как несведомый анон пишет.
>>322715
Ой, да ладно. Раст и мозилла в частности самые толерантные сообщества для подобных лиц.
Ой, да ладно. Раст и мозилла в частности самые толерантные сообщества для подобных лиц.
>>322715
чо за херню ты несёшь, он там пишет, что ушёл прежде всего из-за мизерной зарплаты
чо за херню ты несёшь, он там пишет, что ушёл прежде всего из-за мизерной зарплаты
Самое идиотское что могли в расте придумать это константное значение переменой по умолчанию.
>>322712
причём намылился к конкурентам - в гугл
причём намылился к конкурентам - в гугл
>>322742
Ну он и не программистом был. Вот его интересные цитаты из hn:
И судя по гитхабу кодер из него так себе:
https://news.ycombinator.com/item?id=18845174
Ну он и не программистом был. Вот его интересные цитаты из hn:
> Mozilla is actually the best-paying job I've ever had, if that tells you anything. And it was an okay salary. I've never been more financially secure. But I'd like some of that "easy SV money" :)
> My peers are engineers, my job title was technical writer. Across the industry, writers make less than engineers do.
И судя по гитхабу кодер из него так себе:
> Looking at Steve's 177 'source' repositories @ Github and disregarding documentation and presentations, there is absolutely nothing that can be described as substantial engineering. Throwaway code, small sample projects and tiny tutorials and more often than not, skeletons and incomplete beginnings.
https://news.ycombinator.com/item?id=18845174
>>322746
ты его недооцениваешь, вон у языка программирования ди одни из лучших в мире кодеров, а с хайпом жопа, даже бенчмарков нет https://benchmarksgame-team.pages.debian.net/benchmarksgame/
ты его недооцениваешь, вон у языка программирования ди одни из лучших в мире кодеров, а с хайпом жопа, даже бенчмарков нет https://benchmarksgame-team.pages.debian.net/benchmarksgame/
>>322748
Я понимаю, что евангелисты нужны. Но он даже сам себя евангелистом не считает, хотя я его видел в каждом треде по расту, что в реддите, что в hn. Да и зачем кому-то нужен будет евангелист раста, кроме мозиллы?
Я понимаю, что евангелисты нужны. Но он даже сам себя евангелистом не считает, хотя я его видел в каждом треде по расту, что в реддите, что в hn. Да и зачем кому-то нужен будет евангелист раста, кроме мозиллы?
>>322744
Меня это тоже удивило, но не так сильно, как отсутствие возможности обращаться к строке по индексу и отсутствие в стандартной библиотеке возможности вытаскивать из строки букву. Только слайсы, причём я пока не понял как надо будет угадывать индексы, чтобы в середину символов не попадать, либо итерироваться по символам или байтам. После питона мне такие ограничения как серпом по яйцам.
Модули же как namespace в плюсах?
Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
Меня это тоже удивило, но не так сильно, как отсутствие возможности обращаться к строке по индексу и отсутствие в стандартной библиотеке возможности вытаскивать из строки букву. Только слайсы, причём я пока не понял как надо будет угадывать индексы, чтобы в середину символов не попадать, либо итерироваться по символам или байтам. После питона мне такие ограничения как серпом по яйцам.
Модули же как namespace в плюсах?
Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
>>322818
А отдельных файлов с хедерам с копипастой сигнатур и ifdef тебе не хватает?
Попробуй разобраться, сначала, почему что-то сделано так, а не иначе.
А отдельных файлов с хедерам с копипастой сигнатур и ifdef тебе не хватает?
Попробуй разобраться, сначала, почему что-то сделано так, а не иначе.
>>322818
Может ради безопасности? Чтобы не вызывать букву по не существующему индексу. Та же стори и с инкрементом.
Может ради безопасности? Чтобы не вызывать букву по не существующему индексу. Та же стори и с инкрементом.
>>322984
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5fd84ca1777d5f8c574af5b94b2fb2b2
В чем ваша проблема-то? Как по твоему пиздон это делает без итерации, то?
impl можно не только кастомные методы, но и трейты. Плюс ты можешь impl свои трейты для импортированных структур.
Короче, это для унификации синтаксиса.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5fd84ca1777d5f8c574af5b94b2fb2b2
В чем ваша проблема-то? Как по твоему пиздон это делает без итерации, то?
impl можно не только кастомные методы, но и трейты. Плюс ты можешь impl свои трейты для импортированных структур.
Короче, это для унификации синтаксиса.
>>322986
Просто не все привыкли к utf8 где нельзя взять символ по индексу, используя только арифметику указателей. Впрочем с приходом эмозди и прочего говна в 16-битрых кодировках тоже такая хуйня появилась.
> В чем ваша проблема-то?
Просто не все привыкли к utf8 где нельзя взять символ по индексу, используя только арифметику указателей. Впрочем с приходом эмозди и прочего говна в 16-битрых кодировках тоже такая хуйня появилась.
Например, в C# вся инфа объекта хранится в куче, а в стеке только адрес. Заметил что в С++/расте не так, и много инфы объекта хранится в стеке (например, длина векторов). Из-за чего приходится переменные из стека передавать по ссылке, со всеми "прелестями" вроде dangling pointer и прочего.
Я не понимаю, зачем так сделано и почему нельзя сразу хранить в куче свойства объекта?
Я не понимаю, зачем так сделано и почему нельзя сразу хранить в куче свойства объекта?
>>323107
Потому что выделение памяти на стеке это инкремент регистра, а выделение на куче это сложная хуйня с обращением к ОС. Плюс минус.
Потому что выделение памяти на стеке это инкремент регистра, а выделение на куче это сложная хуйня с обращением к ОС. Плюс минус.
>>323107
Ты сишарп тоже недавно изучать начал? Там с самого появления есть структуры, которые тоже на стеке хранятся. А ещё недавно появился Span, который вместе со stackallock позволяет хранить на стеке вообще что угодно без использования небезопасного кода. Правда майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен (раньше он вообще был только для unsafe кода).
>>323110
А в C# и подобных языках ещё и нагрузка на GC.
Ты сишарп тоже недавно изучать начал? Там с самого появления есть структуры, которые тоже на стеке хранятся. А ещё недавно появился Span, который вместе со stackallock позволяет хранить на стеке вообще что угодно без использования небезопасного кода. Правда майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен (раньше он вообще был только для unsafe кода).
>>323110
> это сложная хуйня с обращением к ОС
А в C# и подобных языках ещё и нагрузка на GC.
>>323125
Я аж вспомнил как спорил с каким-то дауном в си треде где-то год назад, и он доказывал что надо всё выделять только на стеке и вообще куча это хуйня, небезопасно и 4 мб хватит всем, alloca наш б-г.
Да потому что он и не может быть безопасен, долбойоб блять.
Определение стека знаешь? Смысл превращать его в кучу?
>>323107
Ахуеть, а ты откуда вылезла, обезьяна? Где ты вообще такое видел? Всё, что вмещается в стек, обычно просто копируется, ибо это примерно всегда быстрее из-за особенности работы процессора с оперативкой.
>stackallock позволяет хранить на стеке вообще что угодно без использования небезопасного кода
Я аж вспомнил как спорил с каким-то дауном в си треде где-то год назад, и он доказывал что надо всё выделять только на стеке и вообще куча это хуйня, небезопасно и 4 мб хватит всем, alloca наш б-г.
>раньше он вообще был только для unsafe кода
Да потому что он и не может быть безопасен, долбойоб блять.
>Правда майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен
Определение стека знаешь? Смысл превращать его в кучу?
>>323107
> Из-за чего приходится переменные из стека передавать по ссылке
Ахуеть, а ты откуда вылезла, обезьяна? Где ты вообще такое видел? Всё, что вмещается в стек, обычно просто копируется, ибо это примерно всегда быстрее из-за особенности работы процессора с оперативкой.
>>323294
Чтобы снизить нагрузку на GC. Особенно актуально для короткоживущих объектов, даже escape analysis не всегда осиливает их убрать. Не зря же даже в жаве проект вальхаллу пилят (аналог структур из C#).
> Определение стека знаешь? Смысл превращать его в кучу?
Чтобы снизить нагрузку на GC. Особенно актуально для короткоживущих объектов, даже escape analysis не всегда осиливает их убрать. Не зря же даже в жаве проект вальхаллу пилят (аналог структур из C#).
>>323294
У тебя странное определение безопасности. stackalloc был небезопасен потому что возвращал raw-указатель на стек, который CLR не мог отслеживать. Span же это умный указатель, про содержимое которого CLR в курсе, а потому stackalloc с ним стал абсолютно безопасен. StackOverflowException это вполне себе безопасное исключение.
> Да потому что он и не может быть безопасен, долбойоб блять.
У тебя странное определение безопасности. stackalloc был небезопасен потому что возвращал raw-указатель на стек, который CLR не мог отслеживать. Span же это умный указатель, про содержимое которого CLR в курсе, а потому stackalloc с ним стал абсолютно безопасен. StackOverflowException это вполне себе безопасное исключение.
>>322962
Бля, вот хэдеры и вся эта ебатня с ними и миллион ifdef и прочего макросоговна, размазанного тонким слоем по проекту -- это пиздец. Но пока я не понимаю какое это отношение имеет к выносу реализации методов. И копипаста сигнатур нинужна, если реализовать методы прямо там же, но насколько я помню, в какой-то книжке по ++ писали, что в самих классах обычно заголовок только.
>>322984
Зачем нельзя по индексу букву получить я понимаю, причины хорошо описаны в разделе про String. Чего я не понимаю так то, что не включили возможность вытащить именно букву в стандартную библиотеку. Если правильно понял, то основная проблема в том, что операция взятия значения по индексу должна выполняться за o(1), а с буквами это не прокатит. Ну хуй с ним, почему отдельный метод нельзя запилить?
Бля, вот хэдеры и вся эта ебатня с ними и миллион ifdef и прочего макросоговна, размазанного тонким слоем по проекту -- это пиздец. Но пока я не понимаю какое это отношение имеет к выносу реализации методов. И копипаста сигнатур нинужна, если реализовать методы прямо там же, но насколько я помню, в какой-то книжке по ++ писали, что в самих классах обычно заголовок только.
>>322984
Зачем нельзя по индексу букву получить я понимаю, причины хорошо описаны в разделе про String. Чего я не понимаю так то, что не включили возможность вытащить именно букву в стандартную библиотеку. Если правильно понял, то основная проблема в том, что операция взятия значения по индексу должна выполняться за o(1), а с буквами это не прокатит. Ну хуй с ним, почему отдельный метод нельзя запилить?
>>323318
В жаве сделали так же. Хочешь нормальный символ с учётом всех этих суррогатов, используй метод chars(), который возвращает IntStream. И оттуда уже бери необходимый символ используя методы stream'ов. В расте просто нет легаси API, которые не учитывают многобайтовые символы.
> Чего я не понимаю так то, что не включили возможность вытащить именно букву в стандартную библиотеку.
В жаве сделали так же. Хочешь нормальный символ с учётом всех этих суррогатов, используй метод chars(), который возвращает IntStream. И оттуда уже бери необходимый символ используя методы stream'ов. В расте просто нет легаси API, которые не учитывают многобайтовые символы.
>>323294
Ага, потом выясняется, что
>Я аж вспомнил как спорил с каким-то дауном в си треде где-то год назад, и он доказывал что надо всё выделять только на стеке и вообще куча это хуйня, небезопасно и 4 мб хватит всем, alloca наш б-г.
Ага, потом выясняется, что
>Из ядра Linux убрали массивы переменной длины (VLA), размер которых определяется на этапе выполнения, а не компиляции кода. Они замедляли работу и могли влиять на безопасность операционной системы. Линуса Торвальдса уже давно просили избавиться от VLA, да и сам он активно критиковал решение использовать массивы переменной длины. В kernel 4.20 большую часть из них наконец исключили.
38 Кб, 1669x257Кто-нибудь в rocket.rs шарит?
Гляньте https://github.com/TatriX/realworld-rust-rocket/pull/7
Гляньте https://github.com/TatriX/realworld-rust-rocket/pull/7
>>323298
Я у тебя, дурака, про определение спросил. Не про высосанные из пальца проблемы вм.
Ты писал что
Я тебе, овощу блядь, отвечаю: стек отличается от кучи в том числе принципиальным отсутствием индексации, о каком апи для определения свободного места можно говорить?
>>323303
Ты это вообще к чему написал? Ну придумали майки (auto)unique_ptr спустя 15 лет его появления в крестах, ну залатали они дырку которую сами сделали хз когда. stackalloc безопасен? Нет, блять, он тебе за выигранные спички потенциально создаст ещё хуйлиард проблем. Если escape analysis не понимает, что объект можно держать на куче, то этот код гарантированно запутаная хуйня, где и человек рано или поздно накосячит.
Вообще, не понятно нахуя дотнет-то нужен, если ебаться приходится похлеще чем в плюсах. В жаве-то ладно — всё под капотом, рядовой мартышке не накосячить.
>>323318
Потому что итераторы, архитектура и у-н-и-в-е-р-с-а-л-ь-н-о-с-т-ь.
Я у тебя, дурака, про определение спросил. Не про высосанные из пальца проблемы вм.
Ты писал что
>майки не добавили АПИ для определения свободного места на стеке из-за чего этот stackallock довольно опасен
Я тебе, овощу блядь, отвечаю: стек отличается от кучи в том числе принципиальным отсутствием индексации, о каком апи для определения свободного места можно говорить?
>>323303
Ты это вообще к чему написал? Ну придумали майки (auto)unique_ptr спустя 15 лет его появления в крестах, ну залатали они дырку которую сами сделали хз когда. stackalloc безопасен? Нет, блять, он тебе за выигранные спички потенциально создаст ещё хуйлиард проблем. Если escape analysis не понимает, что объект можно держать на куче, то этот код гарантированно запутаная хуйня, где и человек рано или поздно накосячит.
Вообще, не понятно нахуя дотнет-то нужен, если ебаться приходится похлеще чем в плюсах. В жаве-то ладно — всё под капотом, рядовой мартышке не накосячить.
>>323318
>Ну хуй с ним, почему отдельный метод нельзя запилить?
Потому что итераторы, архитектура и у-н-и-в-е-р-с-а-л-ь-н-о-с-т-ь.
>>323413
Изи. Это managed-стек. VM запросто может отслеживать свободное место на нём.
А, понятно. Ты managed от unmanaged не отличаешь. Точно дурачёк и пытаешься умничать. Не мудрено, что
> стек отличается от кучи в том числе принципиальным отсутствием индексации, о каком апи для определения свободного места можно говорить?
Изи. Это managed-стек. VM запросто может отслеживать свободное место на нём.
> Ты это вообще к чему написал?
А, понятно. Ты managed от unmanaged не отличаешь. Точно дурачёк и пытаешься умничать. Не мудрено, что
> Вообще, не понятно нахуя дотнет-то нужен
>>323424
Отлично гений, из управляемой кучи в управляемый стек. Почему он такой какой есть используется, ты, ебанатина, не задумывался? Носом опять ткнуть или сам головой подумаешь?
Ну да, не мудрено что ты пришёл в растотред и начал пороть нюфагу бред про хуй пойми что.
Про ненужность дотнета хуйню спорол, извини. Специально создавать столько проблем для холостой траты на них времени и денег — такой хуйнёй даже плюсы никогда не были, такой вот кортельный заговор погромистов.
>Изи. Это managed-стек. VM запросто может отслеживать свободное место на нём.
Отлично гений, из управляемой кучи в управляемый стек. Почему он такой какой есть используется, ты, ебанатина, не задумывался? Носом опять ткнуть или сам головой подумаешь?
>А, понятно. Ты managed от unmanaged не отличаешь. Точно дурачёк и пытаешься умничать. Не мудрено, что
Ну да, не мудрено что ты пришёл в растотред и начал пороть нюфагу бред про хуй пойми что.
Про ненужность дотнета хуйню спорол, извини. Специально создавать столько проблем для холостой траты на них времени и денег — такой хуйнёй даже плюсы никогда не были, такой вот кортельный заговор погромистов.
>>323496
Он и так управляемый. Безусловно взятие оставшегося места будет занимать относительно много времени (на раскрутку стека и расчёт уже занимаемого места), но такое можно сделать и на простом стеке, ничего волшебного тут нет.
Хватит под умного косить. Работал бы ты хоть раз со стеком, знал бы, что ничего невозможного тут нет.
> из управляемой кучи в управляемый стек.
Он и так управляемый. Безусловно взятие оставшегося места будет занимать относительно много времени (на раскрутку стека и расчёт уже занимаемого места), но такое можно сделать и на простом стеке, ничего волшебного тут нет.
Хватит под умного косить. Работал бы ты хоть раз со стеком, знал бы, что ничего невозможного тут нет.
>>323499
К тому же JIT/интерпретатор сам по себе хранит кучу метаинформации о функции (даже если она заинлайнена, чтобы при эксепшоне выдавать полный стек), так что ничего сложного тут не будет.
К тому же JIT/интерпретатор сам по себе хранит кучу метаинформации о функции (даже если она заинлайнена, чтобы при эксепшоне выдавать полный стек), так что ничего сложного тут не будет.
>>323421
А вот тут расскажи подробнее? Что делаете, как используете? Я думал что CL вообще только как промежуточный этап до Scheme какого-нибудь.
> Ну и commmon lisp в продакшне.
А вот тут расскажи подробнее? Что делаете, как используете? Я думал что CL вообще только как промежуточный этап до Scheme какого-нибудь.
6 Кб, 259x194>>323499
>>323298
Что с этим ебанавтом? Это managed рак мозга?
> Безусловно взятие оставшегося места будет занимать относительно много времени
>>323298
>>>1323294
>> Определение стека знаешь? Смысл превращать его в кучу?
>Чтобы снизить нагрузку на GC.
>Хватит под умного косить. Работал бы ты хоть раз со стеком, знал бы, что ничего невозможного тут нет.
Что с этим ебанавтом? Это managed рак мозга?
8 Кб, 275x183>>323502
>К тому же JIT/интерпретатор сам по себе хранит кучу метаинформации о функции
>указатель на стек для обхода ссылок
>>323511
Наш хаскель гуру заебался месить говно лопатой в жабо-имплементации openauth и сделал свой сервис. Потом еще фронтэнд тесты на нем же были, но загнулись.
Как по мне, >>323512 прав. Смысла никакого в CL в 21 веке нет.
Я раньше пробовал на кложаскрипте писать, но все что хоть немного связано с jvm тормозное и уебищное, поэтому бросил это дело. А недавно начал немного заниматься синтезом, и вот для этого дела clojure+overton зашло мне на ура.
Наш хаскель гуру заебался месить говно лопатой в жабо-имплементации openauth и сделал свой сервис. Потом еще фронтэнд тесты на нем же были, но загнулись.
Как по мне, >>323512 прав. Смысла никакого в CL в 21 веке нет.
Я раньше пробовал на кложаскрипте писать, но все что хоть немного связано с jvm тормозное и уебищное, поэтому бросил это дело. А недавно начал немного заниматься синтезом, и вот для этого дела clojure+overton зашло мне на ура.
28 Кб, 640x480>>322101
Пошел нахуй. Вот просто пошел нахуй.
У меня всё собирается без проблем. Это единственный язык и система сборки/менеджер пакетов где у меня всё собирается без проблем.
Всем бы языкам такое. У тех же npm и pip нет кучи очевидных фич которые есть у cargo.
Пошел нахуй. Вот просто пошел нахуй.
У меня всё собирается без проблем. Это единственный язык и система сборки/менеджер пакетов где у меня всё собирается без проблем.
Всем бы языкам такое. У тех же npm и pip нет кучи очевидных фич которые есть у cargo.
>>324166
Да, признаю ошибку. Просто трафик с мобилы был завернут в ВПН, а ноут подключался к мобиле. С pip та же история, что-то в этой цепочке ломает SSL. Дома нормально зашло.
Да, признаю ошибку. Просто трафик с мобилы был завернут в ВПН, а ноут подключался к мобиле. С pip та же история, что-то в этой цепочке ломает SSL. Дома нормально зашло.
24 Кб, 229x300Как создать вектор фиксированной длинны заполненный пустыми String'ами?
(В общем случае заполненный выдачей функции-конструктора, в случае String'ов - String::new())
Только ручками пушить в цикле?
(В общем случае заполненный выдачей функции-конструктора, в случае String'ов - String::new())
Только ручками пушить в цикле?
>>324453
let mut v = vec![String::default(); 5];
или
let mut v = vec![String::new(); 5];
но default идиоматичней, как бы.
let mut v = vec![String::default(); 5];
или
let mut v = vec![String::new(); 5];
но default идиоматичней, как бы.
>>322818
Потому что дженерики. У тебя может быть такая структура:
[code]
struct Cage<T> {
animal : T
}
[/code]
Ты можешь сделать так:
[code]
struct Cat {}
struct Dog {}
imlp Cage<Cat>{
fn meow(){}
}
imlp Cage<Dog>{
fn bark(){}
}
[/code]
Само по себе это не даёт нихера, но ведь есть еще система трайтов:
[code]
trait Mammal {
}
impl Mammal for Cat{}
impl Mammal for Dog{}
impl <T = Mammal> Cage<T> {
fn stink(){}
}
[/code]
Ну и красота. Теперь у тебя есть клетка с котом, которая может мяукать и вонять и клетка с собакой, которая может гавкать и вонять, причем второе ты описал только один раз, но обошлось без наследования, когда хрен проссышь, из чего в итоге состоит класс, и без динамической диспетчеризации. А если динамическая диспетчеризация таки нужна, то не нужно вносить никаких изменений в структуру, работает из коробки.
>Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
Потому что дженерики. У тебя может быть такая структура:
[code]
struct Cage<T> {
animal : T
}
[/code]
Ты можешь сделать так:
[code]
struct Cat {}
struct Dog {}
imlp Cage<Cat>{
fn meow(){}
}
imlp Cage<Dog>{
fn bark(){}
}
[/code]
Само по себе это не даёт нихера, но ведь есть еще система трайтов:
[code]
trait Mammal {
}
impl Mammal for Cat{}
impl Mammal for Dog{}
impl <T = Mammal> Cage<T> {
fn stink(){}
}
[/code]
Ну и красота. Теперь у тебя есть клетка с котом, которая может мяукать и вонять и клетка с собакой, которая может гавкать и вонять, причем второе ты описал только один раз, но обошлось без наследования, когда хрен проссышь, из чего в итоге состоит класс, и без динамической диспетчеризации. А если динамическая диспетчеризация таки нужна, то не нужно вносить никаких изменений в структуру, работает из коробки.
>>322818
Потому что дженерики. У тебя может быть такая структура:
[code]
struct Cage<T> {
animal : T
}
[/code]
Ты можешь сделать так:
[code]
struct Cat {}
struct Dog {}
imlp Cage<Cat>{
fn meow(){}
}
imlp Cage<Dog>{
fn bark(){}
}
[/code]
Само по себе это не даёт нихера, но ведь есть еще система трайтов:
[code]
trait Mammal {
}
impl Mammal for Cat{}
impl Mammal for Dog{}
impl <T = Mammal> Cage<T> {
fn stink(){}
}
[/code]
Ну и красота. Теперь у тебя есть клетка с котом, которая может мяукать и вонять и клетка с собакой, которая может гавкать и вонять, причем второе ты описал только один раз, но обошлось без наследования, когда хрен проссышь, из чего в итоге состоит класс, и без динамической диспетчеризации. А если динамическая диспетчеризация таки нужна, то не нужно вносить никаких изменений в структуру, работает из коробки.
>Зачем для методов отдельное ключевое слово impl, почему их нельзя сразу в структуре описать? Ну или хотя бы заголовки там, а тело ниже. По-моему это гораздо нагляднее, учитывая, что методы непосредственно к структуре и её данным относятся.
Потому что дженерики. У тебя может быть такая структура:
[code]
struct Cage<T> {
animal : T
}
[/code]
Ты можешь сделать так:
[code]
struct Cat {}
struct Dog {}
imlp Cage<Cat>{
fn meow(){}
}
imlp Cage<Dog>{
fn bark(){}
}
[/code]
Само по себе это не даёт нихера, но ведь есть еще система трайтов:
[code]
trait Mammal {
}
impl Mammal for Cat{}
impl Mammal for Dog{}
impl <T = Mammal> Cage<T> {
fn stink(){}
}
[/code]
Ну и красота. Теперь у тебя есть клетка с котом, которая может мяукать и вонять и клетка с собакой, которая может гавкать и вонять, причем второе ты описал только один раз, но обошлось без наследования, когда хрен проссышь, из чего в итоге состоит класс, и без динамической диспетчеризации. А если динамическая диспетчеризация таки нужна, то не нужно вносить никаких изменений в структуру, работает из коробки.
>>324588
и тут я неожиданно понял как переводится dinamyc dispatch. Все время думал что это динамическое расщепление. Кстати Generic Programming это изначально русское определение Обобщенное програмирование, перевденное на английский.
и тут я неожиданно понял как переводится dinamyc dispatch. Все время думал что это динамическое расщепление. Кстати Generic Programming это изначально русское определение Обобщенное програмирование, перевденное на английский.
>>324649
Нихуя себе
>Кстати Generic Programming это изначально русское определение Обобщенное програмирование
Нихуя себе
3,1 Мб, mp4,640x360, 3:08
>>324456
Лол, я почему-то думал что этот вариант макроса только с литералами работает.
Поясни о чём ты или ссылку на почитать дай.
>let mut v = vec![String::new(); 5];
Лол, я почему-то думал что этот вариант макроса только с литералами работает.
>но default идиоматичней, как бы.
Поясни о чём ты или ссылку на почитать дай.
>>324709
Я про трейт Default: https://doc.rust-lang.org/std/default/trait.Default.html
Обычно через него задают значения по-умолчанию. У строки - это пустая строка.
> Поясни о чём ты или ссылку на почитать дай.
Я про трейт Default: https://doc.rust-lang.org/std/default/trait.Default.html
Обычно через него задают значения по-умолчанию. У строки - это пустая строка.
>>324724
Да никак. Просто если например делать генерик метод для создания вектора определённого размера с пустыми данными, то лучше делать с default, а не new: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d182650a3db74c9094be433d585ad733
Да никак. Просто если например делать генерик метод для создания вектора определённого размера с пустыми данными, то лучше делать с default, а не new: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d182650a3db74c9094be433d585ad733
>>324588
Понятно, все через жопу.
Понятно, все через жопу.
10 Кб, 437x253VSСode-растеане, как убрать эту кнопку "Run tests"?
В настройках rust-экстеншена не нашел ничего.
В настройках rust-экстеншена не нашел ничего.
17,3 Мб, webm,560x420, 7:14
>>322986
Насколько я помню в Пиздоне у строк фиксированное кол-во байтов на символ в рамках одной строки, которое подстраивается в зависимости от того какие символы в строке.
Ну, то бишь если в строке только ASCII - символы один байт занимают. Но если ты к строке зааппендишь какой-нибудь смайлик на который нужно 4 байта - вся строка станет 4-х байтной (UCS-4 кодировка) и те ASCII-символы тоже конвертнуться в UCS-4.
>Как по твоему пиздон это делает без итерации, то?
Насколько я помню в Пиздоне у строк фиксированное кол-во байтов на символ в рамках одной строки, которое подстраивается в зависимости от того какие символы в строке.
Ну, то бишь если в строке только ASCII - символы один байт занимают. Но если ты к строке зааппендишь какой-нибудь смайлик на который нужно 4 байта - вся строка станет 4-х байтной (UCS-4 кодировка) и те ASCII-символы тоже конвертнуться в UCS-4.
>>324867
Но это же ужасно. Ты хочешь сказать что при конкатенации пиздону придется проверять типы и копировать строки при их несовпадении?
Но это же ужасно. Ты хочешь сказать что при конкатенации пиздону придется проверять типы и копировать строки при их несовпадении?
12,4 Мб, webm,568x420, 5:40
>>324868
Ну так Питон оптимизирован так чтобы код быстрее писался, а не быстрее работал.
Ну и в реальном коде переходы к более многобитной кодировке наверное редки.
И ничего плохого в этом нет, должны быть языки и для хуякхуякиготово.
Ну так Питон оптимизирован так чтобы код быстрее писался, а не быстрее работал.
Ну и в реальном коде переходы к более многобитной кодировке наверное редки.
И ничего плохого в этом нет, должны быть языки и для хуякхуякиготово.
>>324921
Зависит от криворукости бенчера. Вполне может победить питон, если питонокод будет представлять из себя тонкую обёртку над оптимизированной библиотекой на С/С++, а растокод будет написан вручную и при этом вместо использования ссылок (потому что автор не осилил борроу чекер) большая часть объектов будет копироваться при передачу в функцию.
Хотя чаще всего теститруют I/O и тут может победить кто угодно в зависимости от того у какого языка запись на диск быстрее с параметрами по-умолчанию, поскольку про такие страшные вещи как flush или буферизацию большинство бенчеров даже не слышали.
Зависит от криворукости бенчера. Вполне может победить питон, если питонокод будет представлять из себя тонкую обёртку над оптимизированной библиотекой на С/С++, а растокод будет написан вручную и при этом вместо использования ссылок (потому что автор не осилил борроу чекер) большая часть объектов будет копироваться при передачу в функцию.
Хотя чаще всего теститруют I/O и тут может победить кто угодно в зависимости от того у какого языка запись на диск быстрее с параметрами по-умолчанию, поскольку про такие страшные вещи как flush или буферизацию большинство бенчеров даже не слышали.
Аноны, сам я не местный, вкатываюсь с пистона с промежуточной остановкой на джулии. В пистоне заебали вылеты в рантайме после пары минут работы, а я то ещё невнимательное хуйло. В джулии вроде всё заебок, но эта задумчивость, это пиздец, да и от ошибок рантайма защита немногим лучше.
В связи с чем вкатываюсь в раст и обнаруживаю, что работы с матрицами-массивами никакой и нет. Даже инициализировать массив циферками от 0 до 10 - уже сложность-невозможность м.б. есть макрос для этого?.
Сторонние либы юзать пока не хочу - доверишься им, а они заглохнут, тем более, шта мне многого и не надо. Хочу, для начала, такие вещи:
- глубокие срезы многомерных массивов. Типа xs[::2,::3]+1
- простенькую инициализацию циферками-интервалами
На будущее, когда надоест велосипедить, нашёл такие либы
ndarray cgmath nalgebra simple-matrix - кто что из этого юзал, что скажете?
В связи с чем вкатываюсь в раст и обнаруживаю, что работы с матрицами-массивами никакой и нет. Даже инициализировать массив циферками от 0 до 10 - уже сложность-невозможность м.б. есть макрос для этого?.
Сторонние либы юзать пока не хочу - доверишься им, а они заглохнут, тем более, шта мне многого и не надо. Хочу, для начала, такие вещи:
- глубокие срезы многомерных массивов. Типа xs[::2,::3]+1
- простенькую инициализацию циферками-интервалами
На будущее, когда надоест велосипедить, нашёл такие либы
ndarray cgmath nalgebra simple-matrix - кто что из этого юзал, что скажете?
>>324943
Бери nalgebra. Ее решили юзать как дефакто-старндарт для игростроения, так что не прогадаешь.
Раст все таки не интерактивная хуйня для математики, а типа системный язык, поэтому странно ожидать от него таких специфичных штук в стандартной либе/языке.
Бери nalgebra. Ее решили юзать как дефакто-старндарт для игростроения, так что не прогадаешь.
Раст все таки не интерактивная хуйня для математики, а типа системный язык, поэтому странно ожидать от него таких специфичных штук в стандартной либе/языке.
М>>325008
Ой точно. Надо бы перекатить. Дайте пикчей штолле.
Ой точно. Надо бы перекатить. Дайте пикчей штолле.
>>325010
Очевидный HH. Ну или ищи работу на C(++), становись авторитетом и толкай раст.
и чем тебя криптохуйня не устраивает?
Очевидный HH. Ну или ищи работу на C(++), становись авторитетом и толкай раст.
и чем тебя криптохуйня не устраивает?
>>325152
Но тут нет баксов и адекватной работы
Хороший вкат в язык
Я не гей.
>Очевидный HH.
Но тут нет баксов и адекватной работы
>Ну или ищи работу на C(++)
Хороший вкат в язык
>и чем тебя криптохуйня не устраивает?
Я не гей.
>>325194
А чего ты хочешь? На дворе 2019 год, тут либо месить легаси лопатой и потихоньку толкать что-то новое, либо пилить очередной криптовысер (ибо только тут все свои высеры пишут с нуля).
Ну, а вообще есть вариант повысерать чего нить на гитхабе и попробовать разослать резюме во всякие дропбоксы/мозилы (но с твоим отношением к геям тебя туда не возьмут, лол) и другие компашки с 4-го оппика.
>Я не гей.
А чего ты хочешь? На дворе 2019 год, тут либо месить легаси лопатой и потихоньку толкать что-то новое, либо пилить очередной криптовысер (ибо только тут все свои высеры пишут с нуля).
Ну, а вообще есть вариант повысерать чего нить на гитхабе и попробовать разослать резюме во всякие дропбоксы/мозилы (но с твоим отношением к геям тебя туда не возьмут, лол) и другие компашки с 4-го оппика.
>>325517
Последний раз когда я смотрел вакансии, удаленки не видел. Может я плохо смотрел?
>дропбоксы/мозилы
Последний раз когда я смотрел вакансии, удаленки не видел. Может я плохо смотрел?
>>325726
Когда ты вообще вакансии в открытом доступе видел у таких компаний? Я не про висячую хуйню, которую просто всем лень убрать. Там очень высокая конкуренция и либо ты сам всем своё cv будешь пихать в рот, либо на тебя всем будет похуй.
>Последний раз когда я смотрел вакансии
Когда ты вообще вакансии в открытом доступе видел у таких компаний? Я не про висячую хуйню, которую просто всем лень убрать. Там очень высокая конкуренция и либо ты сам всем своё cv будешь пихать в рот, либо на тебя всем будет похуй.
Тред утонул или удален.
Это копия, сохраненная 31 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 января 2019 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.