Аналог Vaadin для Rust

Интересная тема, подпишусь (нет).

Есть Rocket – https://rocket.rs/ там правда шаблоны, а не такое как в Vaadin, когда разработчик на Java кодит на Java и не залазит в отвратную HTML/CSS/JavaScript Web-помойку макакичей вообще.

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

аналог Vaadin

хочу GUI на html, ведь есть куча готового в интернете

Вам не кажется, что здесь несостыковка?

Если Вы хотите использовать готовенькие HTML, то на кои Вам кодогенерация HTML из Rust?

А если бы Вы нашли уже готовенькое на Rust, то не задавали бы такого вопроса.

Вы сами знаете, чего хотите? Или premature optimisation? Делайте, как получается, причёсывать потом будете :P

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

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

Есть PHP-фреймворк Livewire, мне кажется это то что тебе нужно.

https://laravel-livewire.com/

Будь аккуратней с Растом, парень. Один раз его коснешься, а потом тебя в приличном обществе за стол не пригласят

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

Попробуй, сам расскажешь. Я возможности шаблонов этого Web-фреймворка на Rust увы не проверял, так как не стал заморачиваться с установкой ночных сборок Rust’а, а на стабильных оно не взлетело.

Kali-школьники тоже не по назначению этот Kal используют, и что?

Когда это Web Components взлететь успели? ;)

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

RC 0.5 уже собирается на stable-версии компилятора.

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

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

особенно всякие Grid с возможностью фильтрации, возможностью сводных данных (Pivot table) и т.д.

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

Можешь пару примеров привести?

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

в percy есть зачатки ssr только «компоненты» ты будешь сам делать руками, но подход +- тот же.

Спасибо за наводку, выглядит интересно

Можешь пару примеров привести?

Как кратко делегировать реализацию трейта?

struct Child {
    base: Base,
    flag: bool,
}

impl Trait for Child {
    // boring #1
    fn foo(&self) -> bool { self.base.foo() }
    
    // boring #100500
    fn bar(&self) -> bool { self.base.bar() }
    
    fn baz(&self) -> Option<usize> {
        if self.flag {
            self.base.baz()
        } else {
            None
        }
    }
}

https://github.com/ivanceras/sauron еще можешь посмотреть тоже сервер сайд рендеринг

Как кратко делегировать реализацию трейта?

Меня интересовали примеры как именно язык допиливают «чтобы этих извращений нужно было меньше».

P.S. Есть ambassador и delegate, например.

Меня интересовали примеры как именно язык допиливают «чтобы этих извращений нужно было меньше».

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

P.S. Есть ambassador и delegate, например.

«Как кратко делегировать»

Ого какие интересные интерфейсы можно делать https://ivanceras.github.io/futuristic-ui/

https://xaeroxe.github.io/init-struct-pattern/

сакрализировать хипстеров?!

фигня у Dead Space навороченный UI в мире веба не может быть продвинутого UI

https://yew.rs/ вот фронт на Растишке.

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

Сильно хотели - уже давно сделали бы. RFC на эту тему есть, но особой активности не видно.

«Как кратко делегировать»

И? ambassador - два атрибута добавить, вполне себе кратко.

https://xaeroxe.github.io/init-struct-pattern/

Дык, описанное там (Default трейт и такая инициализация структур) было в 1.0, а может и раньше, лень проверять. При этом в библиотеках чаще встречается всё-таки билдер, чем этот «трюк». В язык ничего для упрощения написания билдеров пока тоже не завезли.

В общем, так себе пример.

Сильно хотели - уже давно сделали бы. RFC на эту тему есть, но особой активности не видно.

Дело не в хотели или не хотели. Дело в том, что есть более приоритетные задачи при ограниченных человеческих ресурсах. Как и с const-generics это не быстро.

2000-const-generics.md Start Date: 2017-05-01

label:A-const-generics 101 Open

Уже всё реализовали?

И? ambassador - два атрибута добавить, вполне себе кратко.

Два аттрибута говоришь?

«If you want to make an existing trait that lives outside you crate available for delegation, you can do so by copy-pasting it’s signature into your code and using the #[delegatable_trait_remote] attribute»

Дело не в хотели или не хотели. Дело в том, что есть более приоритетные задачи при ограниченных человеческих ресурсах. Как и с const-generics это не быстро.

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

Уже всё реализовали?

Не понимаю, что этот аргумент должен доказывать.

Два аттрибута говоришь?

Ну ладно, подловил. Хотя я всё равно считаю, что краткость тут особо не страдает (если надо много раз делегировать, то оно всё равно лаконичнее ручной реализации), просто коряво это.

Но я что-то не пойму о чём мы спорим. Изначальное утверждение было «язык допиливают чтобы извращений было меньше нужно». Как по мне, на это тянет разве что значительное улучшение эргономики работы с ошибками через ?, а всё остальное - просто обычные фичи или допиливание давно запланированного. Вот и стало интересно, что человек подразумевал.

Ха, у меня анонимы отключены, а тут открыл, оказывается пользователи с нулевым скором тоже прячутся. Хм

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

Изначально вопрос состоял в:

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

Я тебе и показал одно из таких вот «извращений». Это ты уже сам придумал про сильно хотели или не очень сильно хотели.

Не понимаю, что этот аргумент должен доказывать.

Это ещё одно решение «извращений», которое долго добавляют (или по твоему это быстро?). Как предлагаешь без этого реализовать трейт для fixed-size массива любой длины? Извращаться с макросами как раньше? Нужная фича? Нужная. Быстро добавили, ну не то чтобы. Хотя вопрос стоял с самой стабилизации языка.

Хотя я всё равно считаю, что краткость тут особо не страдает (если надо много раз делегировать, то оно всё равно лаконичнее ручной реализации), просто коряво это.

Краткость — это пол беды. Проблемы начнутся, когда в таких трейтах что-то изменится…

Но я что-то не пойму о чём мы спорим. Изначальное утверждение было «язык допиливают чтобы извращений было меньше нужно». Как по мне, на это тянет разве что значительное улучшение эргономики работы с ошибками через ?, а всё остальное - просто обычные фичи или допиливание давно запланированного. Вот и стало интересно, что человек подразумевал.

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

чтобы можно было использовать вместо js раст

если речь о js на клиенте - тебе нужен webassembly

https://rustwasm.github.io/book/

а именно vaadin в расте нет (и не нужно)

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

Я тебе и показал одно из таких вот «извращений».

Увидеть я хотел пример допиливаний, так что нет, не показал.

А кривые (или медленно развиваемые) места языка я и сам знаю: специализация (которая в частично сделанном виде в найтли годами живёт), асинк-трейты, макро 2.0 (которые обещают, кажется, с релиза), HKT наконец (ну или гаты). Список можно долго продолжать.

Более того, целиком цитата выглядит вот так:

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

Как конст-дженерики относятся к «полуфункциональщине» тоже интересно.

Краткость — это пол беды. Проблемы начнутся, когда в таких трейтах что-то изменится…

Ничего страшного не случится. Из ошибки очевидно, что изменилось и где:

error[E0050]: method `fmt` has 3 parameters but the declaration in trait `std::fmt::Display::fmt` has 2
 --> src/main.rs:6:12
  |
6 |     fn fmt(&self, f: &mut ::std::fmt::Formatter, a: u8) -> Result<(), ::std::fmt::Error>;
  |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected 2 parameters, found 3
  |
  = note: `fmt` from trait: `fn(&Self, &mut Formatter<'_>) -> Result<(), std::fmt::Error>`
  = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

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

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

Лол, нет.

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

Увидеть я хотел пример допиливаний, так что нет, не показал.

А кривые (или медленно развиваемые) места языка я и сам знаю: специализация (которая в частично сделанном виде в найтли годами живёт), асинк-трейты, макро 2.0 (которые обещают, кажется, с релиза), HKT наконец (ну или гаты). Список можно долго продолжать.

По твоему это разные вещи? Мне кажется, что это одно и тоже. Вопрос только в том, когда это перейдёт в категорию «допилено».

Как конст-дженерики относятся к «полуфункциональщине» тоже интересно.

А как к этому относится делегация трейтов? Не из-за того ли это, что в Rust не стали добавлять привычный всем ООП, а сделали «полуфункциональщину»? Например в С++ с этим примером нет никаких проблем.

Ничего страшного не случится. Из ошибки очевидно, что изменилось и где:

А как же лишние извращения с внесением изменений во всех местах где происходит делегация? Или например где тут хотя бы сообщение компилятора?

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

Потому, что это всё колхоз, лишняя зависимость и почти такие же извращения.

Вероятно, возникло недопонимание. Я всё-таки считаю, что «полуфункциональность» раста не имеет отношения к перечисленным проблемам, поэтому и хотел узнать о чём шла речь. Ответ получил, хотя связи всё равно не не увидел. Опять же, мне не кажется, что «функциональщина» в расте довольно условная. Отсутствие (привычного) ООП автоматически не делает язык функциональным.

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

А как же лишние извращения с внесением изменений во всех местах где происходит делегация?

В смысле лишние? Ведь при ручном прокидывании эти изменения точно так же понадобились бы.

Или например где тут хотя бы сообщение компилятора?

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

Потому, что это всё колхоз, лишняя зависимость и почти такие же извращения.

Зависимостей бояться - на расте не писать. (:

Эта библиотека тянет за собой proc-macro2, syn и quote, которые скорее всего и так будут в проекте.

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

Отсутствие (привычного) ООП автоматически не делает язык функциональным.

Но, определённо подталкивает его в эту сторону в современных реалиях.

Ведь сделать какой-нибудь сахар было бы явно куда дешевле чем асинки и прочие большие фичи.

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

В смысле лишние? Ведь при ручном прокидывании эти изменения точно так же понадобились бы.

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

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

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

Эта библиотека тянет за собой proc-macro2, syn и quote, которые скорее всего и так будут в проекте.

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

Обычно когда видишь макросы в таком использовании, то что-то с этим не так. Смотри сам, недавно затронутые темы:

• try! => ?
• #[async] => async
• impl_trait_for_array!(0, 1, 3, ... 100500) => <const N: usize>

Думаю при желании этот список можно легко продолжить.

Ну дык, нас давно к анонимам приравняли :P

Нет конечно, ты что. Это же не очередной grep переписать, тут работать надо.

rust

какой-то слишком уж поехавший человек

Всё нормально.

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

Ну ок, не вижу смысла спорить.

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

Погоди, давай ещё раз. Вот берём мы «язык с нормальным ООП» и там если в базовый класс добавился метод с реализацией, но мы хотим сделать что-то другое в каждом наследнике, то придётся точно так же просматривать все места и править. Никакая «магическая делегация» тут никак не поможет.

Погоди, давай ещё раз. Вот берём мы «язык с нормальным ООП» и там если в базовый класс добавился метод с реализацией, но мы хотим сделать что-то другое в каждом наследнике, то придётся точно так же просматривать все места и править. Никакая «магическая делегация» тут никак не поможет.

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

https://godbolt.org/z/eexaWaTfW

В Rust только ручками делать, потому как нормально делегировать всю/часть реализацию/и полю нельзя.

Ок, теперь я понял о чём ты.