LINUX.ORG.RU

Rust 1.91.0

 ,


0

4

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

Список изменений:

  • aarch64-pc-windows-msvc теперь является платфомой первого уровня поддержки (ранее было второго уровня). По сравнению со вторым уровнем поддержки, первый уровень подразумевает обязательное успешное прохождения всех тестовых наборов на платформе.

  • Добавлена проверка линтера при возвращении из функции «висячего» указателя. Встроенный в компилятор Borrow Checker уже имеет проверку на тот случай, когда возвращается «висячая» ссылка, но это не работало при использовании сырых указателей. Теперь будет сгенерировано предупреждение:

fn f() -> *const u8 {
    let x = 0;
    &x
}
warning: a dangling pointer will be produced because the local variable `x` will be dropped
 --> src/lib.rs:3:5
  |
1 | fn f() -> *const u8 {
  |           --------- return type of the function is `*const u8`
2 |     let x = 0;
  |         - `x` is part the function and will be dropped at the end of the function
3 |     &x
  |     ^^
  |
  = note: pointers do not have a lifetime; after returning, the `u8` will be deallocated
    at the end of the function because nothing is referencing it as far as the type system is
    concerned
  = note: `#[warn(dangling_pointers_from_locals)]` on by default

В разряд стабильного API было переведено:

  • Path::file_prefix
  • AtomicPtr::fetch_ptr_add
  • AtomicPtr::fetch_ptr_sub
  • AtomicPtr::fetch_byte_add
  • AtomicPtr::fetch_byte_sub
  • AtomicPtr::fetch_or
  • AtomicPtr::fetch_and
  • AtomicPtr::fetch_xor
  • {integer}::strict_add
  • {integer}::strict_sub
  • {integer}::strict_mul
  • {integer}::strict_div
  • {integer}::strict_div_euclid
  • {integer}::strict_rem
  • {integer}::strict_rem_euclid
  • {integer}::strict_neg
  • {integer}::strict_shl
  • {integer}::strict_shr
  • {integer}::strict_pow
  • i{N}::strict_add_unsigned
  • i{N}::strict_sub_unsigned
  • i{N}::strict_abs
  • u{N}::strict_add_signed
  • u{N}::strict_sub_signed
  • PanicHookInfo::payload_as_str
  • core::iter::chain
  • u{N}::checked_signed_diff
  • core::array::repeat
  • PathBuf::add_extension
  • PathBuf::with_added_extension
  • Duration::from_mins
  • Duration::from_hours
  • impl PartialEq<str> for PathBuf
  • impl PartialEq<String> for PathBuf
  • impl PartialEq<str> for Path
  • impl PartialEq<String> for Path
  • impl PartialEq<PathBuf> for String
  • impl PartialEq<Path> for String
  • impl PartialEq<PathBuf> for str
  • impl PartialEq<Path> for str
  • Ipv4Addr::from_octets
  • Ipv6Addr::from_octets
  • Ipv6Addr::from_segments
  • impl<T> Default for Pin<Box<T>> where Box<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Rc<T>> where Rc<T>: Default, T: ?Sized
  • impl<T> Default for Pin<Arc<T>> where Arc<T>: Default, T: ?Sized
  • Cell::as_array_of_cells
  • u{N}::carrying_add
  • u{N}::borrowing_sub
  • u{N}::carrying_mul
  • u{N}::carrying_mul_add
  • BTreeMap::extract_if
  • BTreeSet::extract_if
  • impl Debug for windows::ffi::EncodeWide<'_>
  • str::ceil_char_boundary
  • str::floor_char_boundary
  • impl Sum for Saturating<u{N}>
  • impl Sum<&Self> for Saturating<u{N}>
  • impl Product for Saturating<u{N}>
  • impl Product<&Self> for Saturating<u{N}>

Признак const добавлен к следующим функциям:

  • <[T; N]>::each_ref
  • <[T; N]>::each_mut
  • OsString::new
  • PathBuf::new
  • TypeId::of
  • ptr::with_exposed_provenance
  • ptr::with_exposed_provenance_mut

>>> Подробнее

★★★

Проверено: hobbit ()
Последнее исправление: Wizard_ (всего исправлений: 2)
Ответ на: комментарий от unC0Rr

Да не лучше оно, я пробовал. И то и то js по сути. Хтмла в электроне что то в районе 2.9% у меня - остальное js: https://github.com/Vladgobelen/NSQCuE/

По гибкости и возможностям чистый веб всетаки превосходит Qt Quick.

Так при этом Qt Quick требует интеграции с плюсами, что минус.

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Проблема в том, что разработчики гэтэка скорее всего сидят в макоси:

https://bbs.archlinux.org/viewtopic.php?id=299624

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

steemandlinux ★★★★★
()
Ответ на: комментарий от LightDiver

Ещё проблема это проблемные бекпорты. Захотел ты вмержить в свою, не интегрированную в репозитории, программу фикс. Будь добр собрать всё это под старый glibc, либо любись с флетпаком.

steemandlinux ★★★★★
()
Ответ на: комментарий от steemandlinux

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

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

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

LightDiver ★★★★★
()
Ответ на: комментарий от steemandlinux

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

LightDiver ★★★★★
()
Ответ на: комментарий от Somebody

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

unC0Rr ★★★★★
()
Ответ на: комментарий от LightDiver

Qt Quick требует интеграции с плюсами

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

В том, что это не костыль сверху рендеринга хтмл, а изначально ориентированная на создание гуи библиотека

Ээээээммм... А это точно не реклама HTML была?? ;P ;)) :)))

С настоящими кнопками, списками, настоящими лэйаутами

Ну, не с настоящими, а с нарисованными! )

Точь в точь как и в HTML... ;))

Somebody ★★★
()
Ответ на: комментарий от Somebody

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Ты серьёзно считаешь язык разметки текста подходящей штукой для рисования гуи?

Не только «считаю», но использовал это на последнем месте работы «на дядю», лет с 15+ тому назад. Этакий прототип «веб-приложений» был, благодаря которому моё начальство смогло показывать работу нашей местной ГРЭС совету директоров компании в реальном времени за почти 1000 километров.

Очень так нормально и шустро всё отрисовывалось, при частоте обновления данных, «разлетавшихся» от аппаратуры телемеханики по UDP в локальной сети станции 1 раз в секунду, включая графики с параметрами выдаваемой турбогенераторами энергии — напряжение «в линию» 110 киловольт, мощность, частота и что-то там ещё...

Всё, что требовалось для оценки работы электростанции в реальном времени, в общем.

«Красивое!..» © :))))

Тогда это был шок для «господ директоров», реально. :)

Ты точно тот же человек, что гордится написанием кода на Си под микроконтроллеры?

Нет, ты меня с кем-то спутал. :)

Я не «горжусь», я просто задачи решаю. ;) ))

Чай, не пОдросток, чтобы «гордиться» элементарной работой...

P.S. Этот «гуй» нормально «шевелился» в браузере на тех ещё компах... ,А сейчас и подавно «летал» бы... Не знаю, жива ли ещё там эта задача, но сомневаюсь: там руководство поменялось на «дефективных манагеров», молодых и не очень умных... Говорят, очень многое «по[here]ли»... Ну да мне сейчас это по... То была «попутная задачка», задуманная и реализованная «на коленке» и очень быстро, «между делом». Удовольствие я тогда получил, а используют ли её дальше — проблемы «конторы»... :)

Somebody ★★★
()
Ответ на: комментарий от Somebody

1 раз в секунду

А, ну понятно.

Я пишу на Qt Quick, у меня приложение в кучей кнопок, менюшек, таблиц, с трёхмерным глобусом, на котором точки, полигоны, модели кораблей, спроецированные картинки и видеокадры с лайвстримов. Обновления данных прилетают до примерно 200 раз в секунду. Плюс ещё отображение сразу нескольких видеопотоков, в том числе fullhd, проецирование данных поверх видео, телеуправление камерами. Всё это крутится у клиентов в 60 fps на 4k.

unC0Rr ★★★★★
()
Ответ на: комментарий от seiken

Если бы софт IRS для Ариан4/5 писали на расте, ракета бы не навернулась

Она бы до сих пор до старта не доехала - переписывали бы софт не только ракеты, но и ЦУПа.

BydymTydym ★★
()
Ответ на: комментарий от unC0Rr

1 раз в секунду

А, ну понятно.

И шо??.. :)

Что тебе «понятно»?? И что ты бы сделал другое, «на бегу», за считанные часы, 15+ лет тому назад??.. Чтобы с юга Приморья «показать в» Хабаровский край и Амурскую область?.. И на чём... Это при условии, что задача для меня была «штучная» и раньше я ничем хоть немного «таким» не занимался. Позже, впрочем, тоже. :)

P.S. «Куча кнопок» для меня — верный признак плохого проектирования и дизайна..

«Ничего личного», просто реакция на знакомый «до слёз» «раздражитель»... :))

Somebody ★★★
()
Ответ на: комментарий от Somebody

Что тебе «понятно»??

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

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

Ты передёргиваешь и искажаешь смысл сказанного мной.

Тогда, в тех условиях — да, безусловно лучше, при отсутствии опыта решения таких задач, лимита времени, на тех компьютерах и по тем каналам связи, и и совершенного отсутствия каких-либо «специализированных решений».

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

А что сейчас — мне не интересно, таких задач передо мной больше не стояло: я много лет в той компании не работаю, и рад этому. :)

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

Somebody ★★★
()
Последнее исправление: Somebody (всего исправлений: 2)
Ответ на: комментарий от Somebody

Ты передёргиваешь и искажаешь смысл сказанного мной.

Напоминаю контекст:

Ты серьёзно считаешь язык разметки текста подходящей штукой для рисования гуи?

Не только «считаю», но использовал это на последнем месте работы «на дядю», лет с 15+ тому назад.

Мы обсуждаем сегодняшнюю ситуацию с гуём, древний опыт нерелевантен, вот и всё.

никаких других попросту не было

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Мы обсуждаем сегодняшнюю ситуацию с гуём, древний опыт нерелевантен, вот и всё.

«Как скажешь, начальник...».

Впрочем, даже 15 лет назад это не было лучшим решением.

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

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

Тебе самому-то ржачно не было, когда ты эту глупость писал?? ;)) :)))

То есть, мне надо было «всего-то» подождать три года (sic!), а заодно убедить подождать Совет директоров ДГК (Дальневосточной Генерирующей Компании), потом как-то откуда-то узнать, что наконец-то «начата работа», найти, изучить и освоить сырой ещё инструмент, и т.д., и т.п... LOL, да и только... :)

У меня не только трёх лет, трёх часов не было... кажется, не помню уже... :)

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

Somebody ★★★
()
Ответ на: комментарий от LightDiver

Какой то skill issue, возьми ImGui и если надо делать графики добери ImPlot. Но на C++

snake266 ★★★
() автор топика
Ответ на: комментарий от Somebody

Я же сказал, уже тогда были технологии для такого простого софта. А для более производительного уже точно были через три года. Может и раньше были, зачатки того же Qt Quick были ещё в четвёртом Qt.

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

Знаешь, в мире много всякого софтового говна, наляпанного кое-как по-быстрому, пошедшего в продакшен и живущего десятилетиями. Это не повод считать подлежащие технологии чем-то хорошим. Особенно по прошествии лет.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Я же сказал, уже тогда были технологии для такого простого софта

У тебя глаза на каком месте сейчас? ;))

Спрашиваю потому, что ты в своих суждениях как-то так обходишь, явно предпочитая «не замечать», «граничные условия» моей тогдашней задачи, исключавшие возможность поиска и изучения-освоения любых «технологий для такого простого софта» и вынуждавшие использовать «то, что уже есть под рукой»...

Знаешь, в мире много всякого софтового говна, наляпанного кое-как по-быстрому, пошедшего в продакшен и живущего десятилетиями.

Поверю твоему, явно очень личному, опыту. ;)

Это не повод считать подлежащие технологии чем-то хорошим. Особенно по прошествии лет.

Ты не читаешь... Просто отвечаешь, «продавливая» свою точку зрения...

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

Ладно, закончим на этом.

Somebody ★★★
()
Ответ на: комментарий от Somebody

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

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

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

Ты лжёшь.

Somebody ★★★
()
Ответ на: комментарий от Somebody

Ну само собой, однако в последние годы я замечал все эти приложения на электроне, дискорд например, и люто бесило - они еще и жрали дохренища ОЗУ. А тут сам попробовал - а удобное! Еще и красивое!

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

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

Somebody ★★★
()
Ответ на: комментарий от LightDiver

Да, когда есть время для подбора и освоения инструмента решения задачи, его можно найти. У меня, в описанной чуть раньше ситуации, времени не было, поэтому делал теми средствами, которыми владел. Так прототип (HTML+php+mysql+jQuery+какая-то-графическая-либа-к-jQuery+немного-JS), который я думал, «быстренько слепить, чтобы „материализовать идею“ » и показать руководству, превратился в «готовое решение», поскольку начальству понравилось и оно сказало «Хватит! Не надо ничего переделывать, оставь вот это!»... :))

Так мой «наколенный» «Proof of Concept» превратился в «решение», которое, в, итоге, понравилось всем и пережило сколько-то лет «боевой» эксплуатации. :)))

Но, разумеется, при бо́льшей скорости поступления данных эта моя «залипуха» не справилась бы... А так все были довольны. :)

Somebody ★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Чего? Я тыкал QML коммерчески и для души в 2015-2017-м, и это пушка! Такой гибкости твой електрон, боюсь, не даст. О производительности електрону лучше вообще не заикаться.

BruteForce ★★★
()
Ответ на: комментарий от Somebody

Что тебе «понятно»?? И что ты бы сделал другое, «на бегу», за считанные часы, 15+ лет тому назад??.. Чтобы с юга Приморья «показать в» Хабаровский край и Амурскую область?.. И на чём… Это при условии, что задача для меня была «штучная» и раньше я ничем хоть немного «таким» не занимался. Позже, впрочем, тоже. :)

Похоже ты всё-таки «горжусь»

BruteForce ★★★
()
Ответ на: комментарий от BruteForce

Так js вообще не про производительность в целом. Хоть QML, хоть электрон. Они про интерфейсы. Где не нужны события высокой нагрузки.

Хочешь высокую нагрузку, бери питон*, плюсы, раст, го.

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

Это инфраструктура, это node.js, это сборка под линукс, винду, мак одной командой. В QML ты уже модули js не подключишь - там свой js-движок.

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Да не просто гибкость, а универсальность, кроссплатформенность, удобство, 3-4 ляма модулей!!!

У меня сейчас 3 приложения-на-електроне запущено. Мне не нравится ни одно из них, и мне не легче от того, что их разработчикам было удобно и что там ещё. Я бы предпочёл, чтобы они чуть больше пострадали (или поучились), и не страдали миллионы других.

бери питон*

Простите? Разве что вызывай-Си-через-питон.

не про производительность

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

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

BruteForce ★★★
()
Ответ на: комментарий от BruteForce

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

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

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

LightDiver ★★★★★
()
Ответ на: комментарий от unC0Rr

Кажется это новый Царь, но не сишечки, а же-ес-пе-ха-пе

BruteForce ★★★
()
Ответ на: комментарий от BruteForce

Ну вот смотри. Я не программист. Я доволен приложением телеграм, которое они написали нормально на плюсах кажется и я недоволен дискордом на электроне. Но я не смогу написать все на плюсах. Однако я могу взять модули js, электрон и сделать примено как в дискорде. И оно работает так, как мне надо.

Чтобы сделать вручную «правильно», мне пришлось бы потратить с десяток лет на учебу, потом столько же на набор опыта.

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

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Я не программист.

Это ведь оборачивает всё на 180°. Потому что я говорю о разработке ПО программистами. Я не могу критиковать самоделкиных, которые собрали внедорожник в гараже. Я критикую тех, кто работает в Тойота.

Есть ведь и вещи поприкольнее, начиная прям с https://www.blockly.ru/apps/turtle/index.html

П. С. Visual Basic? Как-то пришлось декомпилировать прогу на VB, которую заказчику передал другой подрядчик вместе с железками, чтобы переписать по-человечески, переписано было на C++/QML, очень мило выглядело и, что самое главное, работало. Заняло дня 4. Причём будь авторы VB-программы программистами, работало бы оно прекрасно и на VB.

BruteForce ★★★
()
Ответ на: комментарий от BruteForce

А у профессионалов все еще более жестко. Им нужна производительность труда. Они уже не могут позволить себе лишние траты времени и усилий. Если можно сделать быстрее и дешевле и получить 80% результата - они это сделают.

LightDiver ★★★★★
()
Ответ на: комментарий от BruteForce

Похоже ты всё-таки «горжусь»

«Похоже» ©, аргументы у тебя закончились, не успев начаться, и ты окончательно перешёл от обсуждения подходов к созданию" гуя" к обсуждению меня. Расслабься, мне это не интересно, а ты не умеешь...

Тут есть более понимающие и вменяемые собеседники...

Somebody ★★★
()
Последнее исправление: Somebody (всего исправлений: 1)
Ответ на: комментарий от LightDiver

Если можно сделать быстрее и дешевле и получить 80% результата - они это сделают

А иногда не только можно, но и нужно...

Somebody ★★★
()
Ответ на: комментарий от LightDiver

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

unC0Rr ★★★★★
()
Ответ на: комментарий от LightDiver

Так js вообще не про производительность в целом. Хоть QML

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

свой js-движок

Обычный там движок.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

А не нужно. Вот у меня была задача - отстранить пользователей от выбора. Вообще. То есть он должен был запустить приложение и просто в нем работать без настроек.

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

Я снизил процент требований в пользу действительно полезного.

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

Представь, что программист на плюсах может за единицу зарплаты сделать 1 единицу продукта, а на js в электроне 10 единиц продукта. Работодателю что выбрать? Да, оно будет жирнее, будут чуть огранчиение. Но это приемлемо.

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 3)
Ответ на: комментарий от LightDiver

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

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

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Проблема в том, что гуй - не самое затратное и сложное. Вот у меня основа проектов - бэкенд. 90% всего там. Логика работы с данными.

И вот оно мне надо вместо 10% прикладывать 50% усилий для гуя? Когда в электроне это все делается отлично без приложения лишних усилий. Я на гуй трачу меньше процента времени наверное. Причем гораздо меньше процента.

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

Ладно, надо мне что то низкоуровневое и производительное - я напишу модуль на раст, например и подключу к электрону. Все - максимальная производительность, гибкость. Вон выше пример был.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

10% прикладывать 50% усилий для гуя?

Ну это точно не про Qt Quick. Накидать элементы на форму недолго, и даже добавить анимаций дело пяти минут.

unC0Rr ★★★★★
()
Ответ на: комментарий от unC0Rr

Это лютая возня в любом случае. Qt Quick использует собственный JS-движок (на базе V4 или Qt Quick Compiler), не V8/Node.js.

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

Короче, это инструмент интересный, но хрен знает еще - разовьют ли его до нормальной юзабельности. Посмотрим.

Вот представь - есть у меня веб-клиент к войс-чату: https://ns.fiber-gate.ru/

Я его за полчаса перенес на электрон. Допилил модуль раст для пуш ту толк, подключил. Все работает, нормально, красиво. Работает так же, как и в веб-клиенте. Я посмотрел сколько надо переделать под тот же Qt Quick и это жопа. Проще даже не смотреть в эту сторону, ибо нахрен надо самому же себе стрелять в колено.

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 3)
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.