Компания JetBrains представила новую интегрированную среду разработку RustRover, ориентированную на написание приложений на языке Rust. Среда RustRover нацелена на повышение эффективности разработки на языке Rust, удовлетворение потребностей связанной с Rust экосистемы и первичную поддержку данного языка. Проект будет развиваться как коммерческий продукт, но похожее окружение можно сформировать на основе бесплатной cummunity-версии среды IntelliJ IDEA с плагином intellij-rust. В настоящее время для тестирования без ограничений доступен пререлиз RustRover, сборки которого подготовлены для Linux, macOS и Windows. Первый стабильный релиз RustRover планируют опубликовать до сентября 2024 года...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59754
Ниасилили написать IDE на расте.
Просто не было чего-то готового на Сишке, чтоб можно было переписать на Расте.
а так же на питоне, руби, haxe, scala, php, c/c++, go, dart, ..., sql. На одной только яве осилили, бездари. Верно, Иксперт Опеннета? Вы держите нас в курсе результатов вашего Глубокого Анализа.
Они и Java то не осилили. Специально, чтобы не изучать, сделали свой язык Kotlin и на нём пишут IDE...
Учитывая как эта поделка тормозит, они и свой язык не осилили 🤣
Фанатик джетбрейнсов порвался. Растовики нигде своё IDE не смогли создать, а переписать пытаются всё на свете.
> Растовики нигде своё IDE не смогли создать, а переписать пытаются всё на свете.Не переписать, а понадписывать
А вот для языка V уже есть лёгкая IDE, написанная на V. Без многомиллионного финансирования и широкого распространения языка.
дык это сложно!
вот тут что-то пытаются… https://lapce.dev
А что, на Rust'e уже появилась вменяемая продакшен реди GUI библиотека ?
Один из примеров: https://docs.rs/fltk/latest/fltk/Вообще же, из программы на Rust достаточно просто вызываются функции из библиотек, написанных на других ЯП.
fltk - это не вменяемая библиотека для GUI, а кусок говна. Единственная вменяемая библиотека для GUI - это Qt, и к сожалению коммерческие интересы The Qt Corporation её скатили в сраное говно, но лучше ничего нет, к сожалению. По удобству API изьоставшихся только Dear Imgui более-менее удобен, поэтому его и используют не смотря на то, что это Immediate mode gui, жрущий процессор на каждом кадре вместо использования GPU, OpenGL и текстур.
> Единственная вменяемая библиотека для GUI - это Qtпереписывают уже на расте
>Для вывода предоставляется несколько бэкендов, позволяющий использовать для отрисовки Qt, OpenGL ES 2.0, Skia и программный рендеринг
>переписывают
>QT в зависимостях
да, тут есть таблица
Давайте посмотрим.tauri - он работает через electron, зашквар.
druid - как они завявляют рисует 2D GUI, но авторы его уже забросили сами об этом заявили.
slit - для десктопа до сих пор зависит от Qt для своей работы, хотя позиционировалось что они хотят сделать так как на других платформах, рисовать GUI сами, так как под android/ios/web(canvas).
gtk-rs - ох если бы только вы знали сколько тонн кодового клея в самом gtk-rs вы бы ужаснулись, более того на gtk совершенно не просто делать простые вещи, манипуляции с combobox/treewidget.
fltk-rs - кошмар из 90-тых!
iced - один из активно развивающихся, видимо потому что pop-os спонсирует? (не уверен). Тем не менее https://github.com/iced-rs/awesome-iced?tab=readme-ov-file весь софт написанный на данный момент на iced страшный и своеобразный, больше похожий на игровое GUI написанное на Unity чем десктоп приложения.
relm - опять GTK.
azul - вот это интересно оно вообще использует mozilla webrender что по сути тоже самое что запускать electron, но у них есть поддержка Python, что в разы лучше, чем писать на Rust.
egui - опять imgui клон.
> slit - для десктопа до сих пор зависит от Qt для своей работыу них основное направление embedded - там можно заработать и как ни странно не только им, кому нужны эти десктопы ? мне хватает С шного gtk настолько что я даже никогда не пробовал что-то писать на нём для своего десктопа на убунте - совсем не интересует.
>tauri - он работает через electron, зашквар.Нет там электрона только webview.
>>tauri - он работает через electron, зашквар.
> Нет там электрона только webview.Какая разница? Какое webview? Там буквально WebKitGTK, там грузится полноценный вебкит, чем это отличается от элекрона? Можно использовать хоть Chromium Embeded Framework + Qt это по сути будет Electron на коленке. Все эти сущности вышеперечисленные кушают одинаково CPU/GPU/RAM.
>Там буквально WebKitGTK, там грузится полноценный вебкит, чем это отличается от элекрона?С собой таскать не надо, исполняемый файл на порядок меньше, грузится системная библиотека, ресурсы разделятся при работе, кроме того грузится только один js интерпретатор вместо двух в электроне, только фронт, бэк на компилируемом языке и потребляет ресурсов намного меньше.
>Можно использовать хоть Chromium Embeded Framework + Qt это по сути будет Electron на коленке.
Это ближе к электрону так как таскает все с собой, но плюсы бека на компилируемом языке тут тоже присутствуют.
>Все эти сущности вышеперечисленные кушают одинаково CPU/GPU/RAM.
Разно кушают и существенно, выше уже описал.
Небольшие, чуть дальше хеловорда программки на tauri съедают 60 - 80 метров (в сумме на три процесса один свой и два от вебкит). Электрон минимум еще 50 метров добавит на второй интерпретатор и другие вспомогательные вещи. А если бек будет что-то реальное еще делать то потребление памяти у электрона в разы больше будет.Но лучше всего для десктопа из веб подобных технологий по потреблению ресурсов это sciter https://sciter.com/ в нем подобный хеловорд это 15 метров всего, то есть сопоставимо с обычным небольшим Qt приложением, жаль что не получилось у автора sciter открыть исходники.
fltk-rs вполне миловидно, и точно не кошмар.
Теперь вы довольны, опеннетовцы?
Все, кому нужно, давно используют rust-analyzer вместе с любым LSP-клиентом. Проблема только в том, что связка LSP-сервер и LSP-клиент нерационально использует память, не говоря уже об оверхедах на сериализацию и работу с диском. В этом виноваты:* Microsoft, придумавшие неудачное решение с разделением по процессам и общению по сети
* создатели LSP-клиентов и серверов, поддержавшие неудачный протокол вместо создания консорциума, который оптимизирует LSP, устранив оверхеды. Такой LSP будет несовместим с оригинальным LSP, ибо потребует другой модели взаимодействия клиента и сервера.
> неудачный протокол вместо создания консорциума, который оптимизируетПреизобильно примеров, когда стартап выкатывал технически далёкий от идеала протокол и захватывал рынок, пока консорциум жевал сопли с оптимизацией. Такова селяви.
LSP-протокол неудачен в принципе. Он появился только по одной причине: M$ - богатая корпорация, которая имеет свои деньги не за счёт IDE, IDE вообще побочный продукт, и которая может себе позволить инвестировать в разрушительные инновации. Обычные разработчики IDE LSP придумать и реализовать по своей инициативе не могли в принципе. Потому что инвестиции в LSP - это инвестиции в продукты КОНКУРЕНТОВ, а разработчикам IDE нужно развивать СВОЙ IDE и вырываться вперёд конкурентов. Мало спроектировать протокол LSP, нужно сделать ещё несколько серверов для него. Более того, спроектировать протокол в отрыве от проектирования сервера и клиента невозможно. Зачем разработчикам IDE тратить свои деньги на то, что конкуренты просто возьмут готовым?А вот M$ прямая выгода есть. При сетевой модели LSP-сервера можно сделать проприетарными, разместить в СВОЁМ облаке Azure и продавать доступ к ним по подписке, и вообще не раскрывать ни исходников, ни бинарников, при этом наоборот получив доступ ко всем исходникам проектов пользователей облачного LSP. Жор же памяти - это плюс: тем меньше людей смогут хостить их опенсорсные аналоги локально. При этом наличие LSP стирает различия между IDE к GUI и в то же время создаёт им необходимость вкладываться в реализацию неудобного в реализации протокола. То есть провайдеры облачных LSP в выигрыше, а создатели локальных LSP - в убытке, но вынуждены участвовать во внедрении LSP.
По хорошему создателям IDE нужно бы собрать консорциум и сделать новую мажорную версию LSP вокруг ООП и shared-библиотек. То есть утвердить набор интерфейсов для каждого языка. Сишка, плюсы, джава, шарп, питон и остальные языки. Все интерфейсы должны иметь соответствие 1-1 и иметься набор адаптеров. А также адаптер в предыдущие версии LSP. Клиенты должны иметь прямой доступ к модели кода LSP и иметь возможность её использоватт непосредственно в своей программе и для этого расширять.
Но тут опять всплывают коммерческие интересы: своя IDE ближе к телу, зачем вендору писать код, который будет использован в IDE конкурентов?
Ну давай разберём тобою написанное.1. Начинаешь с «LSP-протокол неудачен в принципе» — дальше должны бы следоавать какие-то доказательства или объяснения, чтобы не было просто твоим мнением, но вместо этого меткие жизненные наблюдения («M$ - богатая корпорация, которая имеет свои деньги не за счёт IDE», «разработчикам IDE нужно развивать СВОЙ IDE и вырываться вперёд конкурентов») и тезиса из разряда «просто поверьте мне на слово» («Обычные разработчики IDE LSP придумать и реализовать по своей инициативе не могли в принципе», «спроектировать протокол в отрыве от проектирования сервера и клиента невозможно»).
2. «При сетевой модели LSP-сервера можно сделать проприетарными, разместить в СВОЁМ облаке Azure и продавать доступ к ним по подписке» — ну можно. Но ведь можно и не сделать? И как это делает протокол плохим? Можно сделать HTTP-сервер проприетарным — всё, HTTP выбрасываем?
3. «вкладываться в реализацию неудобного в реализации протокола» — «дядя, я не обманываю, правда-правда неудобный»
4. «нужно бы собрать консорциум и сделать новую мажорную версию LSP» — такие сервера тоже можно будет сделать проприетарными и разместить в облаке Azure. В чём смысл, учитывая, что протокол уже открытый?
Итого: дальше $ в «M$» можно было не читать.
1. >M$ - богатая корпорация, которая имеет свои деньги не за счёт IDE
>Microsoft's revenue is generated by three segments: Intelligent Cloud, More Personal Computing, and Productivity and Business Processes. In 2022, Microsoft generated $63.4 billion from its Productivity and Business Processes segment. It also made more than $75.3 billion through its Intelligent Cloud segment.Большая часть выручки - за счёт облаков.
2. >разработчикам IDE нужно развивать СВОЙ IDE и вырываться вперёд конкурентов
Результат теоретико-игрового анализа: для сторонных ситуация похожа на игры "Дилемма заключенного" и "Охота на оленя".
3. Очень неудобный, если ты это не понимаешь - ты просто не пробовал сделать LSP-клиент. Вместо вызова функций из dllки прихозится в добавок иметь дело с управлением процессами, их падениями, их завершением при падении IDE (чтобы не было так, что IDE упала - а процесс остался и жрёт память, ты перезапустил IDE, она опять упала, и ещё один сервер сидит и жрёт память, повторять до исчерпания памяти и 12309), IPC/сетью, сериализацией, десериализацией во внутренние структуры программы и туевой хучей boilerplate-кода. При этом неудобства и на сервере, и на клиенте.
4. В облаке можно будет разместить сервера только протокола, основанного на сети. Для протокола, основанного на shared библиотеках, тоже можно (и нужно) сделать адаптер, как и в обратную сторону. А смысл в том, что LSP-клиент - это по сути основная часть IDE. Её движок. Без него IDE бесполезна. Поэтому архитектура IDE должна быть максимально заточена на взаимодействие с этим движком, а не ехать за ним прицепом. Движок должен втраиваться в машину, а машина должна быть сделана так, чтобы в неё встраивался движок. В настоящее время IDE приходится дублировать кучу вещей на своей стороне и синхронизировать их по сети - это как если бы буксировали машину со своим двигателем и трансмиссией, установленной не в нейтраль. Вместо того, чтобы доверить LSP манипуляцию своими структурами данных напрямую.
Хочу запускать IDE с гуем на своём лаптопе под управлением OpenBSD, а кодить под мейнфрейм на z/OS. Можешь мне кратенько накидать тут схемку без сетевого взаимодействия, чисто на вызовах общих библиотек? А то у меня чёт не получается никак, спотыкаюсь об разноконечность процессоров.
Накидываю: используешь сервер-адаптер, который на вызовы функций генерит команды, которые пишутся в очередь, и далее в отдельном потоке уже пересылаются по сети. В сети их ловит сервер-адаптер, который преобразует их в вызовы методов сервера-библиотеки. Результаты пишутся в очередь, которые опять же пересылажтся по сети. В результате двойной оверхэд - только у тебя, и он размазан по 2 физическим машинам, а не как сейчас, когда двойной оверхэд у всех, даже у кого 1 физическая машина, + куча проблем корректно реализовать клиент. Но сеть - это асинхронно, так что интерфейс между сервером-библиотекой и клиентом должен проектироваться полностью асинхронным. При этом учти, подобные объектно-ориентированные асинхронные интерфейсы и так приходится использовать в клиентах, но у каждого свой и является прокладкой между грёбанной моделью, как в LSP, и тем, что можно в редакторе юзать - вызов методов и т.д., и каждому создателю редакторов приходится геморроиться, и выдернуть этот слой из конкретного редактора и оформить в переиспользуемую библиотеку - непростая задача. Так же, как и в серверах. В ЯП вдь нет понятия RPC, в ЯП есть понятие "вызвать функцию". И все эти вызовы RPC должны быть превращены в вызовы функций, чтобы их можно было использовать в програмаах. То есть первичны именно вызовы функций, а не способы их сериализации и отправки по сети - реализация RPC как раз любой может быть. Но M$ ради своих коммерческих интересов поставили телегу впереди лошади.
> Обычные разработчикизвучит как обычные разработчики ничего и не потеряли
Не вырывайте из контекста. Полное предложение:>Обычные разработчики IDE LSP придумать и реализовать по своей инициативе не могли в принципе.
Скажем так. Я перестал пользоваться текстовыми редакторами без LSP. Больно тоже, в принципе, так как в тех, что с ним, нет кое-каких нужных функций. Но без них в принципе пользоваться редактором можно, а без поддержки твоего ЯП, если этот ЯП делался в предположении, что в современном мире есть IDE с автодополнением, подсветкой и рефакторингом - нет. Это сишку можно в редакторе просто с подсветкой относительно комфортно писать. Но не современный C++ и не Rust, в которых нужно знать, как распаковывается возвращённое значение. Всплывающие подсказки и переходы по ctrl-click существенно облегчают написание кода.
Поэтому либо текстовый редактор для программистов имеет поддержку LSP, либо он загибается. А реализовать LSP-клиент - это трудно, в значительной части - из-за выбранной модели взаимодействия клиента с сервером.
> Обычные разработчики IDE LSP придумать и реализовать по своей инициативе не могли в принципе.Всё уже придумали до нас. SWANK протокол для IDE языка lisp существует как минимум с 2001 года. Т.е. разработчики IDE придумали language server protocol (но другой) по собственной инициативе. Разработчики LISP вообще придумали много чего, что потом подавалось разработчиками других языков как великий прорыв.
>LISPВот в том числе поэтому поэтому и не взлетело. LISP - это эзотерический язык. В энтерпрайзе его если где и используют - то очень нишево.
Этот оверхед по памяти у LSP ничто по сравнению с любым продуктом джетбрейнсов.
Я полностью согласен с этим утверждением. Но тем не менее от этого оверхэда у LSP мне с 2 гигами памяти (на которых Visual Studio 2013 с Resharper летала, Qt Creator без LSP еле ползал, а Qt Creator с clangd LSP вообще не работает даже на 8гиговой рабочей машине, не говоря уже о моей личной 2хгиговой) очень больно. Сам rust-analyser на 8 гиговой машине компилировался довольно долго и жрал кучу памяти, зачастую краша сесию XOrg и сам жрал дофига памяти и жутко тормозил. Но это уже претензии к rust analyzer во многом и к расту - его бинарник сам занимал, если верно помню, около 200 мегабайт, с огромным деревом зависимостей из всякого говна, которое LSP-серверу вообще ни к чему, но прописано в зависимостях какой-нибудь зависимости.
> зачастую краша сесию XOrgзабавная стабильность, продуманная архитектура системы - не знал про такое, спасибо
Любая программа упадёт по bad alloc, когда mmap вернёт -1. Другой вопрос - зачем XOrg постоянно выделять память? Если бы вся необходимая память выделялась 1 раз, а не выделялась и освобождалась несколько раз в секунду, то упала бы не вся сессия, а скорее всего только сама жрущая программа.
Зачем вы программируте на машине с 2 гигабайтами памяти? Сейчас даже 8 мало. Браузер ведь не хочится закрывать во время написания кода)
Если я пишу кода на Java или С++, зачем мне браузер?
В браузере может открыта куча вкладок со справкой по разным возможностям, которые вы, в данный момент, используете. Например про STL можно почитать тут:
https://cplusplus.com/reference/
https://en.cppreference.com/w/cpp
1. Не хочется. Но это браузер - говно. Как и неустановленный комонент в экосистеме Linux, ответственный за выделерие памяти (firefox на винде и на линуксе имеет разные требования к памяти). И Qt Creator хоть и жрал больше Студии (притом, что Студия - на C#, а Creator - на C++) и работал намрого хуже, но тогда ещё им в голову не приходило перейти на ущербный LSP полностью. В общем пользоваться Creatorом тогда хоть было и больно, но не невыносимо.
2. Ещё раз: 8 мало по большому раздолбайству долбоящеров. Прогибаться под долбоящеров и покупать всякий TEE-DRM-ME-PSP-TrustZone-backdoor-хлам с пониженной надёжностью за свои кровные я не буду. Единственное, в каком случае я буду готов купить новый комп - это возможность хостить настоящий сильный ИИ (такой, чтобы мог быть првктически полезен, чтобы окупиться) на своей машине. И только в том случае, если отдистиллированная модель не будет нормально работать на моей текущей машине.
3. Поэтому я теперь Creatorом вообще не пользуюсь, только Kate без всяких LSP и только малюсенькие проектики, где можно обойтись без автодополнения и навигации по коду.
4. Насчёт "браузер не закрывать". Это говно даже от 4 вкладок начинает глючить, если в одной из них видео - то вообще тушите свет. То есть вот есть 3 вкладки. Открываешь 4ю - она сразу падает. Перезапускаешь её - после нескольких попыток она таки загружается, но падают другие вкладки. А потом глючит вообще процесс интерфейса, перестают открываться новые вкладки и перезагружаться. Иногда весь браузер просто падаетэ Если отключить выделенные карго-культовые процессы для обработки видео, сети и т.д - то та подсистема перестаёт работать напрочь - видимо долбоящеры уже выпилили код для однопроцессного варианта. Так и живём.
5. "зачем прогреммируете с 2 гигами" - я как-то подумывал о том, чтобы нарастить до 8. Но память принципиально всегда очень дорогая. Никогда такого не было, чтобы память была дешёвая. На неё всегда есть огромный спрос. Даже если бы софт не разбухал - потребности в обработке данных бы никуда ни делись, потребности в дисковом кеше бы никуда ни делись. А тут ещё софт жрёт как не в себя из-за карго культовых практик растаскивания по процессам и статической линковки. Когда память новая - она дорога из-за повышенного спроса на память в общем, и повышенного спроса на новую память в частности, как на что-то новое, превосходящее старое. Когда память старая - она снята с производства, а спрос хоть и пониже, но есть.
Ну вообще "да" - на "настоящий" язык похож стал, даже вот IDE появилась...
Блин, народ годы ждёт не вот это, а когда они в востребованных IDE баги пофиксят, типа проблем с рендером на нескольких мониторах (когда к ноуту со скейлом 125% подключается обычный монитор) и прочее это вот из багтрекера вместо ответа бота аля "спасибо, мы сейчас очень заняты, ответим вам никогда-нибудь"
Зачем фиксить то, что не уменьшает клиентскую базу? Потратить бюджет, чтобы порадовать юзеров? Пффф
> типа проблем с рендером на нескольких мониторах (когда к ноуту со скейлом 125% подключается обычный монитор)Как я понимаю они это пофиксить и не могут, у них же GUI на Java, это надо джаву фиксить.
Хотя тут была новость что они таки фиксят - https://www.opennet.dev/opennews/art.shtml?num=59691 (см. последний абзац).
Они уже очень давно таскают свой форк openjdk вместе со своими IDE.Баги в экзотичных конфигурациях известны, но их править не будут, поскольку есть миллион более приоритетных багов, которые проявляются не у двух человек, а у тысяч.
Они мигание окна в стиле стробоскопа на маках с м1/м2 чинили где-то год, или полтора, хотя этот баг затрагивал гигантскую аудиторию
> маки
> гигантская аудитория
> макина ноль делишь, всем известно что на маках работают только редкие безумцы а сами эти девайсы ни на что кроме соцсеточек и не способны
Сколько не вижу блоХеров-фронтендщиков на Ютубе, везде у них Маки. Винду я видел только у дотнетчиков, одинэсников, крестанутых (ибо C++/WinAPI) и разработчиков игр под Unity3D (ибо C#) и Unreal Engine (ибо Win-only). А Линукс я видел в основном у бэкендщиков (ибо 70-80% серверов работают на Линуксе) и эмбедщиков под потребительские девайсы, вроде роутеров, телевизорах, умной технике и тому подобном, где явно не нужны дорогие RTOS'ы, на подобии QNX, за 1000$ на каждое устройство, и уж тем более не нужны были WinCE (за исключением навигаторов на Навителе и подобном шлаке, которые тоже Win-only).
Лол то что ты видел укладывается в понятие безумцы.
Линупc частенько пишут на макбуках и год его же на десктопе тоже с них объявляют. И то и другое - из-под OSX.
Учитывая "качество" эппловской документации, подозреваю, что починить там было непросто
У меня на линуксе с вейландом идея стробоскопила
В режиме видеосвязи в Телеграме на Mac M2 изображение как мигало, так и мигает. Хотя и не постоянно, и не всегда.
Это java проблема. И её должен чинить oracle, которому ВНЕЗАПНО на java gui как-то положить. Вообще любые java проблемы гуя чинить ой как не просто.
В обсуждениях до этого часто всплывали вопросы, что будет с официальным ростовским плагином, который можно было установить на тот же бесплатный PyCharm и не иметь проблем.
Теперь же всё стало очевидно — халява кончилась. Хочешь писать на расте, значит плати.
Растоманы настолько фанатичные, что даже в тексте вакансии можо увидеть: "Хочешь работать у нас и писать на Rust'е? Плати!"
А неплохая бизнес-идея...
rust-analyzer бесплатный, цепляется к любому редактору или ide через lsp (vscode например) во многом лучше идеевского плагина.
Наниматели сборщиков авторучек и составителей мозаик смотрят на тебя с иронией.
Т.е., работать на работодателя и ещё платить работодателю?
"Программирование - это как секс: если ты не платишь за это, ты не получаешь хорошего". Бьярн Страуструп (c)
Именно поэтому настрадавшиеся сидят на VS Code или его подобиях и забот не знают
Реинкарнация Блокнот++, которую мы заслужили. Бесплатная с огромным обилием плагинов и уютной работой от джавы, жс, веба и вплоть до написания прошивок под esp32 с esp-idfЛадно, раньше интеллиджу аналогов не было, но последние годы уже далеко не так
Зачем оно нужно, если есть emacs?
Зачем емакс, если есть ed?
В ed нет подсветки синтаксиса и встроенного терминала :(
Запускать емакс из терминала, чтобы потом в нем открыть терминал. Всё, что надо знать о любителях емакса.
Emacs в терминале запускают только извращенцы
Вот не троллинга ради. Сколько нужно усилий, чтобы довести emacs до состояния IDE для <randomname> языка? И чтобы это IDE было не для инопланетян.
С vim это довольно просто.
Да я не спорю, что несложно (фигня, сишнику обо…сья и коммон лисп изучить). Вопрос — зачем, а главное, зачем?
Я имею в виду, что учить ничего не надо. Подключил пару плагинов и поехал. Если ты понимаешь, что конкретно тебе нужно от IDE, то для этого вероятно уже есть плагин (а то и несколько). Некоторой функциональностью я никогда не интересовался, может, чего и нет, но скорее всего есть всё.
Я 20 лет назад начал его настраивать и до сих пор не закончил.
Если программировать на vscode, то ничего платить не надо кстати. (Тип комментария: Информация к размышлению, пища для ума)
особенно когда JB запилили интерфейс как в VSC
так верни старый в настройках пока можно
Платить приходится своими данными.
VSCodium же
Сегодня не надо, а завтра надо. И будешь платить, куда денешься, проприетарщик. Не говоря о том, что уже сейчас товар - это ты.
За Vim или Еmacs платить не надо а они уже поддерживают давно LSP, как и многие другие среды разработкиЮ типа Sublime и т.д.
эти мифические разработчики на вим и емаксе - где они?
только в манямирках онанистов
4 года назад vscode был сильно медленнее продуктов jetbrains.
Если программировать на helix, то ничего платить не надо кстати. (Тип комментария: Информация к размышлению, пища для ума)
> Если программировать на helix, то ничего платить не надо кстати. (Тип комментария: Информация к размышлению, пища для ума)А чем оно лучше neovim с учётом того, что последний есть в репе, а ради helix надо держать какую-то мерзоту аля flatpak/snap?
Это нейросеть галюцинирует? Он спокойно устанавливается на все популярные дистры стандартным пакетным менеджером.
$ apt search --names-only helix
Sorting... Done
Full Text Search... Done
У тебя какой-то отсталый дистрибутив без софта.~ > nix search nixpkgs helix
* legacyPackages.x86_64-linux.helix (23.05)
A post-modern modal text editor
==> helix: stable 23.05 (bottled), HEAD
Post-modern modal text editor
https://helix-editor.com
Not installed
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/...
License: MPL-2.0
==> Dependencies
Build: rust ✘
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 1,335 (30 days), 4,015 (90 days), 14,848 (365 days)
install-on-request: 1,335 (30 days), 4,015 (90 days), 14,848 (365 days)
build-error: 0 (30 days)
Юзай нормальные дистры, типа Arch-а. Там даже AUR не надо подключать для установки helix-a.
flatpak/snap оставь тем, кому надо тестировать Enterprise для Enterprise
> Юзай нормальные дистры, типа Arch-а. Там даже AUR не надо подключать для
> установки helix-a.
> flatpak/snap оставь тем, кому надо тестировать Enterprise для EnterpriseЯ года 3 подряд юзал Арч. Потом 1 обновление сломало сразу 2 моих системы. На главной странице проекта была новость в духе "action required", но я накатил до того как прочёл. С тех пор не прикасаюсь - мне работать надо, а не чинить. Это было довольно давно, средний местный анон ещё в школу тогда не пошёл)
А какой дистр был выбран?
> А какой дистр был выбран?Сначала был Debian, потом стабильные openSUSE, потом попробовал Fedora... И был приятно удивлён (предыдущие набеги на неё во времена 3, 7, 15, 17 версий оставляли плохое впечатление). Так на ней и остался с тех пор.
>JetBrains представила очередную IDE, жрущую память как не в себяЧто ещё ожидать от тех, кто додумался писать IDE на Java?
Я был несколько удивлён когда Clion на весьма примитивном проекте выжрал несколько гигабайт памяти и тормозил. Я так понимаю, там типичные проблемы с парсером и подсветкой. Но это не повод жрать память и тормозить на маленьких файлах.
Вскод сделал просто переписал подсветку с джаваскрипт на с плюс плюс. Всё полетело.
Ннужто scintilla заюзали вместо HTML?! Неужто уже можно на него переходить?
> жрущую память как не в себяНачнем с того, что на яве писать гораздо легче, чем на плюсах. Следовательно, новый функционал будет появляться чаще и быстрее. Сравни с Qt Creator например, который устарел уже в 2010 году.
Далее, по поводу "жрать как не в себя". Программисты -- народ богатый. Если у тебя IDE не умещается в память, то купи побольше оперативки. Если ты ее купить не можешь, потому что у тебя нет денег, значит ты и не программист вовсе, следовательно, эта IDE тебе не нужна, и ты не являешься ее целевой аудиторией.
Есть такая вещь, как "системные требования". Ключевое слово здесь -- "требования". Тебе дают функционал, но требуют что-то взамен, в данном случае -- денег и соответствующего железа. Если функционал показался тебе привлекательным, то приготовь: 1) деньги, 2) соответствующее железо. Если функционал тебе не нужен, то: 1) деньги не платишь, 2) совершенно не обязательно апгрейдить железо.
Надеюсь, объяснил доходчиво.
> Начнем с того, что на яве писать гораздо легче, чем на плюсахЧто-то с первого предложения уже не так
А работодатель бедный. Ты в реальной жизни бывал? Некоторые банки компы больше 8 гигов оперы не выдают. Крутись как хочешь.
> Некоторые банки компы больше 8 гигов оперы не выдаютЗвучит как проблема "некоторых банков". Я в таких шарашкиных конторах не работаю.
Эти "некоторые банки" существуют дольше чем ты, а их владельцы ходят в "друзьях" президентов США
> существуют дольше чем тыНет, эти "некоторые банки" зародились в 90-е, в то время, как я существую дольше, чем целая Российская Федерация, под чьей юрисдикцией эти нищие банки с восемью гигами и работают.
Я не знаю в каких барках ты был, но те банки в которых я работал, 8 гектар рамы перестали ставить ещё 10 лет назад
> А работодатель бедныйУ нищих нет слуг. Раз бедный, пусть CEO пишет софт себе сам. За последние лет 15-20 я не могу вспомнить такого случая, чтобы у программистов не было топового железа и топового софта.
pиздеж, у программистов в конторах очень часто нет топового железа, я бы даже сказал почти всегдалюбой конфиг организуется конторой исходя из потребностей и задач
про 8 гигов - это сказки, про топовое железо - тоже сказки
> Некоторые банки компы больше 8 гигов оперы не выдаютОбычным кассирам и операционистам - может быть. Им больше и не надо на текущий момент. А вот разработчикам, программистам - всегда давали относительно топовое железо и по мере необходимости проводят апгрейд. Это должен быть ну уж совсем какой-то затухающий недо-банк с двумя отделениями при трех кассирах и двух клиентах.
Хех, я в банке запускал пару инстансов идеи внутри линуксовой виртуалки, запущенной под виндой. Ибо последняя была огорожена безопасниками, и так кодить было даже проще и удобнее. Оперативки было предостаточно.
> Некоторые банки компы больше 8 гигов оперы не выдают.Мужик, ты из какого прошлого к нам на машине времени прилетел? Сейчас минимальный стандарт - это 16 гигов, а у нормального работодателя не меньше 32, как у меня например.
>не меньше 32, как у меня например.
>zogНикто не сомневался, что ZOG своим агентам поставляет топовое железо, но я был удивлён, что железо оказалось недостаточно топовым. Меньше 256 гигов как-то не очень для анализа данных паствы.
> Лохи -- народ богатый. Не мамонты, не вымрут.Ясно.
Если они лохи, то почему богатые, и если ты не лох, то почему бедный? Где-то тут не состыковка.
Причина и следствие у вас перепутаны.
Они богатые потому-что родились такими, а лохами их сделали природа и родители
Плюсую! Windows xp - умещался на болванку 700mb CD-R.
Android - 14 гигов системной херни и 2 свободных гига под прон.
Жирнота, Windows 95 весела меньше 25 мег и умещалась на 13 дискетах.
Ты что-то напутал. Столько дискет было у Windows 3.11 for Workgroups.
Чтобы писать на расте надо поставить яву. Какая ирония.
>> CLionЧтобы писать на плюсах или сишке, надо поставить яву. Какая ирония.
Ну если ты пользуешься софтом джетбрейнз, то у меня для тебя плохие новости
> Ну если ты пользуешься софтом джетбрейнз, то у меня для тебя плохие новостиНу если ты считаешь, что пользуешься логикой и умеешь в аргументацию, то у меня для тебя плохие новости.
В твоём утверждении столько логических ошибок, что я просто разведу руками.
Если ты думаешь, что у тебя есть руки - у меня для тебя плохие новости
JVM написана плюсовиками на плюсах, выходит плюсовики написали себе менджмент язык для написания нормального IDE под плюсы. Шах и мат!
А если ещё немного подождать, напишут себе нормальный ЯП.
Ставить ничего не надо, идёт в комплекте
Ты это дописывай. Раст неполноценный язык.
> Чтобы писать на расте надо поставить яву.Не надо, она так уже упакована в директории jbr.
Я что-то пропустил? У них же все эти PhpStorm/PyCharm/RubyMine были лишь Идеей, докостыленной плагинами до разработки на нужном языке. Сейчас всё поменялось? Или они просто заявили, что разработка плагина для раст теперь будет поддерживаться в рамках работы над Идеей?
Вот и РастРовер будет ещё одной такой же Идеей. Просто раньше они пилили бесплатный плагин, который мог ставиться в бесплатную Идею, а теперь решили, что пора его монетизировать.
Понял, спасибо.
а че оно жрет это так дохера?
Жаба - это всегда про жадность. :)
Писать на Rust это теперь привилегия за деньги? Ржомба, собаки лаят - караван идёт.
Эм... Ну не пользуйся JetBrains и не надо будет платить деньги.
Зачем пиарить эту проприетарщину на сайте про свободное ПО?
Наверное потому что людям может быть интересно о инструментах для разработки на свободном rust, не?
Так раст не свободен. Он принадлежит консорциуму за которым скрывается майкрософт, гугл и амазон.
Даже использовать слово раст и его логотип можно только при одобрении консорциума. На одну растоманскую конференцию даже наехали по этому поводу. Открытые проекты даже писали манифест почему раст не свободен и почему они не будут его использовать. Так что по-хорошему на опеннете не стоило бы писать про раст.
> Так раст не свободен. Он принадлежит консорциуму за которым скрывается майкрософт, гугл и амазон.И то ли дело
https://isocpp.org/std/the-committee
> Convener: Herb Sutter (Microsoft).
> Project Editor: Thomas Köppe (Google), backup editor Richard Smith (Google)....
> Core Language Wording, aka CWG: Jens Maurer, assistant chairs Jason Merrill (IBM), Jonathan Caves (Microsoft).
>> Так раст не свободен. Он принадлежит консорциуму за которым скрывается майкрософт, гугл и амазон.
> И то ли дело
> https://isocpp.org/std/the-committee
>> Convener: Herb Sutter (Microsoft).
>> Project Editor: Thomas Köppe (Google), backup editor Richard Smith (Google).
> ...
>> Core Language Wording, aka CWG: Jens Maurer, assistant chairs Jason Merrill (IBM), Jonathan Caves (Microsoft).Молодец. Отфильтровал нужное для твоей точки зрения, убрал то что твоей конспирологической теории не соответствует и вот типичный российский журналист готов.
А вот если дальше почитать
> At most meetings, we typically have experts representing about twenty national bodies. Recently attending nations include Austria, Bulgaria, Canada, China, Czech Republic, Denmark, Finland, France, Germany, Ireland, Israel, Italy, Japan, Republic of Korea, Netherlands, Norway, Poland, Portugal, Romania, Russia, Slovakia, Spain, Sweden, Switzerland, United Kingdom, and United States.И дальше список что там групп как миниум 3 и компаний там до кучи и далеко не все IBM, мелкософт, гугель, есть для сравнения Codeplay, Kitware, Bloomberg, Argonne National Laboratory, Paris Observatory/NCSA, Raven, тайота не говоря уже о таких очевидных как интел, невидия, эппле и т.д.
Ну а то что большая часть разработчиков не одиночки вполне очевидно - как только разработчик начинает из себя что-то представлять его сразу хантят, а за участников комитета топовые компании готовы платить и просто за то что ты есть. Так что за комитет я гораздо больше спокоен чем за раст. Если в комитет можно но сложно что-то протащить, то в расте скорее сложно не протащить.
>>> Так раст не свободен. Он принадлежит консорциуму за которым скрывается майкрософт, гугл и амазон.
> Молодец. Отфильтровал нужное для твоей точки зрения, убрал то что твоей конспирологической
> теории не соответствует и вот типичный российский журналист готов.А ты самокритичный.
> А вот если дальше почитать
> И дальше список что там групп как миниум 3 и компаний там до кучи и далеко не все IBM, мелкософт, гугель, есть дляЭто ты сейчас (наконец) почитал за раст "принадлежит консорциуму" или это очередное "этодругоепониматьнадо!"?
> А ты самокритичный.Удачи вам, здоровья, деградируйте в свое удовольствие.
> Это ты сейчас (наконец) почитал за раст "принадлежит консорциуму" или это очередное
> "этодругоепониматьнадо!"?Раст это ручной язык гугла и мелкософта. Примерно как гугловский хром - против могут быть только пользователи (разработчики). По сути мелкософт может просто пушить и получить апрув от гугла и наоборот. Примерно как джава для оракла, тут просто две компании вместо одной.
Плюсы это сборная солянка комитета, где одна компания может предложить идею, но ее могут зарубить остальные. В целом это полноценный PR с представлением фичи пускай и узкому но сообществу (не две, три, и даже не десять компаний, нет явных чемпионов). Тоже не идеальная структура, но можно ожидать некоторого уровня адекватности. Есть конечно и обратная сторона что из-за этого некоторые полезные фичи не проходят или проходят ощутимо позже. Или проходят странные штуки на которые просто всем начхать.
>> А ты самокритичный.
> Удачи вам, здоровья, деградируйте в свое удовольствие.Унылости вам спрыгивать с неприятной темы и передергивать далее в свое удовольствие.
>> Это ты сейчас (наконец) почитал за раст "принадлежит консорциуму" или это очередное
>> "этодругоепониматьнадо!"?
> Раст это ручной язык гугла и мелкософта. Примерно как гугловский хром -
> против могут быть только пользователи (разработчики). По сути мелкософт может просто
> пушить и получить апрув от гугла и наоборот.Какое многословное "этодругоепониматьнадо!" и не менее стойкое игнорирование реальности (в которой PR в ржавчине как раз предлагается из сообщества разработчиков и на оценку этому сообществу, причем "мухи" из корорации фаундешна тут сильно отдельно от "котлет") ...
Ты сейчас пишешь про логи и все такое.
Но сам язык свободен - вот сорцы: хочешь - форкай, хочешь - дописывай, хочешь - нуди на опенке
> Ты сейчас пишешь про логи и все такое.
> Но сам язык свободен - вот сорцы: хочешь - форкай, хочешь -
> дописывай, хочешь - нуди на опенкеС андройдом такое уже проходили. Через релиз сломают изменения, 99% разработчиков на дефолте, всё, твой форк не работает в принципе. Так что этот условный опенсурс не считается - форкнуть его удастся на полгода-года-два, чисто проект поддержать (примерно также как и проприетарщину), с дописыванием также.
"Свободный раст" — это тот, у которого корпоратское покровительство и чей foundation угрожает подать в суд за нарушение копирайта, если их ржавое лого слегка модифицируешь?
> "Свободный раст" — это тот, у которого корпоратское покровительствоhttps://gcc.gnu.org/steering.html
David Edelsohn (IBM)
Marc Lehmann (nethype GmbH)
Jason Merrill (Red Hat)
Ian Lance Taylor (Google)
Опять растоманы кому-то в штанишки наклали?
Именно эти ребята действуют в интересах шланга. Саботажники в опенсорсе на каждом шагу.
>> "Свободный раст" — это тот, у которого корпоратское покровительство
> https://gcc.gnu.org/steering.html
> David Edelsohn (IBM)
> Marc Lehmann (nethype GmbH)
> Jason Merrill (Red Hat)
> Ian Lance Taylor (Google)
> Опять растоманы кому-то в штанишки наклали?Так gcc не единственный компилятор. Вот платный закрытый сишный стандарт это реально проблема. Но как показывает практика компиляторы пишут и поддерживаются и живут и без доступа к этим докам в принципе.
> Так gcc не единственный компилятор.Ну да, ведь есть еще более свободные и совсем независимые от корпоратов шланг, vc, icc ...
Прикольно конечно, но слишком забагованое, когда нажимаешь Build оно пытается обновить кеши крейт.ио, но у меня есть подозрение что оно обращается именно на крейт.ио, а должно на крейтс.ио. И в итоге у тебя ничего не работает.
Поясните какие преимущества перед использованием JetBrains IDE перед использованием редактора вроде Vim с Language Server?
ты про раст или вообще?если вообще то у них любое IDE - это IDE
а редактор это блокнот чем ты его не обвяжи
расскажи как дебажить под вимом
может тебе еще сказать как выйти из вима !?
:!gdb
Если тебе для этого требуются пояснения, впору проходить IQ тест - там явно что-то ниже 80.