Состоялся (https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html) релиз языка системного программирования Rust 1.32 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.
Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).
В подготовке нового выпуска приняли участие 152 разработчика. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...):- Добавлен новый макрос "dbg!", позволяющий упростить наблюдение за состоянием переменных в отладочных целях. Кроме непосредственного значения переменной, предложенный макрос также показывает имя файла, номер строки и название переменной, что делает его более удобным инструментом для отладки, чем вывод при помощи "println". Информация выводится в поток "stderr". Макрос также можно применять для анализа вычисления выражений и условных операторов, например, можно указывать "if dbg!(n <= 1) {" или "dbg!(n*f(n-1))";
- Прекращено использование по умолчанию библиотеки распределения памяти jemalloc (http://jemalloc.net/) в пользу штатных системных функций выделения и освобождения блоков памяти. Несмотря на то, что jemalloc обеспечивает более высокую производительность, его применение приводит к увеличению размера исполняемого файла приблизительно на 300 Кб. Кроме того, jemalloc специфичен для Unix-подобных систем и в некоторых ситуациях приводит к возникновению проблем (https://github.com/rust-lang/rust/issues/36963#issuecomment-...). При необходимости продолжения использования jemalloc теперь нужно явно подключать пакет jemallocator (https://crates.io/crates/jemallocator);
- Пути к модулям в выражении use, не начинающиеся с ключевых слов super, self и crate, теперь приводят к извлечению элемента (структуры, перечисления и т.п.), определённого в модуле до попытка определения внешнего пакета. Например, указание "use Color::*;" при наличии определения "enum Color { Red, Green, Blue };" до выражения "use", приведёт к импорту вариантов значений перечисления "Color";- В макросы добавлен новый проверочный признак "literal", позволяющий определить является ли переменная литералом, независимо от типа (строковым, числовым, символьным);
- В определениях макросов теперь можно использовать оператор "?", позволяющий определить, что шаблон встречается 0 или 1 раз, по аналогии с тем как операторы "*" и "+" проверяют наличие шаблона 0 и более раз или один и более раз;
- В разряд стабильных переведена новая порция API, в том числе стабилизированы методы to_be_bytes (big endian), to_le_bytes (little endian) и to_ne_bytes (native) в модулях i8, i16, i32, i64, i128, isize, u8, u16, u32, u64, u128 и usize;
- 19 различных функций (https://github.com/rust-lang/rust/blob/master/RELEASES.md#li...) определены с признаком "const" и могут применяться не только как обычные функции, но и использоваться в любом контексте вместо констант;- В пакетный менеджер Cargo обеспечена возможность указания имени пользователя в URL реестра и добавлена команда "cargo c", которая является сокращённым псевдонимом команды "cargo check".
URL: https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=49984
Ура! X)
>Несмотря на то, что jemalloc обеспечивает более высокую производительность[[citation needed]]
https://github.com/rust-lang/rust/issues/6897
http://ithare.com/testing-memory-allocators-ptmalloc2-tcmall.../
glibcThread 333063936 adjusted timing: 0.675780 seconds for 16777216 requests of 1024 bytes.
Thread 349849344 adjusted timing: 0.911601 seconds for 16777216 requests of 1024 bytes.
Thread 324671232 adjusted timing: 0.914302 seconds for 16777216 requests of 1024 bytes.
Thread 341456640 adjusted timing: 1.035064 seconds for 16777216 requests of 1024 bytes.jemalloc
Thread -79698176 adjusted timing: 0.263953 seconds for 16777216 requests of 1024 bytes.
Thread -71305472 adjusted timing: 0.363943 seconds for 16777216 requests of 1024 bytes.
Thread -88090880 adjusted timing: 0.356622 seconds for 16777216 requests of 1024 bytes.
Thread -54528256 adjusted timing: 0.357841 seconds for 16777216 requests of 1024 bytes.
А что за отрицательные номера потоков?
Да, они скорее сослались на очень большой размер бинарей и убрали его.
Вроде развивается язык довольно стремительно, шуму вокруг него развели нормально. А единственный крупный проект на нем - Firefox,и то пока лишь частично. Это что-то не так с языком или просто ему ещё время нужно?
кол-во хипстеров в природе ограничено,
и на все языки одновременно их просто не хватает,
есть же ещё ruby, go, clojure, swift, kotlin и прочие ништяки.
> есть же ещё rubyА он разве есть? В среде хипстеров вроде давно как сдох.
Да вот кааанешна, сдох. До сих пор на нём (точнее, на рельсах) сотни сайтов формошлёпают. Потому что быстраааа и мозг включать почти не надо.
Это не хипстеры, это бывшие PHP-шники.Хипстарки на ноде обычно онанируют.
Что-то не так с языком. Нет ООП.
> Что-то не так с языком. Нет ООП.Не, не оно.
Нет возможности фунционально-логического программирования!
Было бы оно, Rust бы давно взлетел!
В Си его на уровне языка тоже нет
И много на С появляется новых проектов?
Вполне прилично, полагаю их каждый час по миру создаётся больше, чем на расте есть за всё время его существования.
Си умер в конце 70х, вместе со своими процессороми PDP-8/11, это мертвая технология, которую тщательно реанимировали производители железа, а программисты, понимая, что это технологический и инженерный ад, тормозящий развитие, переписывали все реальное программное обеспечение на хоть чуть-чуть вменяемые языки, шедшие по пути повышения строгости.
на си невозможно написать надежную ОС, текстовый процессор, систему визуализации... и прочая, и прочая. это язык ненадежных поделок, и чтобы хоть как-то справиться со сложностью разработки на этом позорном языке, вводят внешние строгие ограничения на разработку, вводят ООП как в linux, gtk/gnome, postgres...
А вменяемые люди пошли по альтернативному пути: вместо создания "неконтролируемого говнокода", создавали более строгие языки, дающие слабые, но все же большие гарантии, чем у асм и си: си++ ( модульность через ооп, эволюцию системы преобразований типов, RTTI, stl/qt... ), java (jvm, давший большую переносимость, чем у "переносимого" си, более простую систему работу с динамической памятью), D/c# - альтернативы (решающие "самый главный недостаток" си++ и явы), golang (закрывающий нишу "си-поделок на один запуск"), и здесь раст/ржавчина видится как вполне резонный шаг эволюции, решающий последний баг си: обеспечение строгой параллельной обработки, которая, действительно! не возможна на одноядерных клонах PDP-11, и отсутствие которой в си наглядно проявилось уже в 70х, на VAX-11 и суперкомпьютерах.Время си - время катастрофы в программировании, когда все инженерные принципы были попраны в угоду гордыни антисоциальных хакеров.
> на си невозможно написать надежную ОС, текстовый процессор, систему визуализации... и прочая, и прочаяЫыыыы... жжош!
> в угоду гордыни антисоциальных хакеровАааааа, ты сделал мой день, прямо с самого утра!!!!11
Даже если C сделали "в угоду гордыни антисоциальных хакеров", на нём уже написано стопицот дофигаллиардов нужного и эффективно работающего софта, а в угоду слабоумным, которые в школе не освоили сложение целых чисел и из-за этого вечно попадают впросак с указателями - в угоду им нагородили кучу "правильных" языков, а они, сюрпрайз, на любом языке в своём г-коде косяк за косяком порят.
Ладно, спасибо хоть за жир - пойду ботинки намажу, у нас как раз сегодня слякоть.
> Ыыыыы... жжош!Найди хоть одну. Сплошное тормознутое, забагованное недоразумение, предназначенное для запуска вирусов и организации бекдоров.
> Даже если C сделали "в угоду гордыни антисоциальных хакеров", на нём уже
> написано стопицот дофигаллиардов нужного и эффективно работающего софта, а в угоду
> слабоумным, которые в школе не освоили сложение целых чисел и из-заСмешно, в свое время было написано мегатонны(стопицот дофигаллиардов) кода на фортране и паскале, до сох пор от этого мусора не избавились, а теперь ответь: зачем нужно (теперь!) писать одноразовый код на мусорном языке для создания багов? И несмотря на опенсорц переписывать "с нуля" раз за разом, потому, что проще написать "с нуля" на си, чем переписать, это цена его "эффективности", программист (должен!) проектировать структуры данных раньше кодирования, иначе потеряет хваленную "эффективность си", построив устойчиво-падучую систему костылей переводящих одни "эффективные структуры" в другие...
Напомню, в свое время, фортран и паскаль генерировали более качественный и эффективный код, чем си из юникса, имели более качественную поддержку ОС, вменяемую диагностику.
Да, код нужный, но бесполезный [на си], языке не предназначенном для поддержки. Языке, практически, непрерывно 60 лет проигрывавшем всем конкурентам, апофеозом развития которого стал javascript (js), даже - "не компилятор". Не расскажите, как "полный победитель" потерял за 50-60 лет, практически, всю свою экосистему, он же эффективный, простой и удобный?> этого вечно попадают впросак с указателями - в угоду им нагородили
> кучу "правильных" языков, а они, сюрпрайз, на любом языке в своём
> г-коде косяк за косяком порят.И ... по этому нужно писать на языке, который создавался как временный костыль для программирования контролеров с 16 килобайтами ОЗУ, серьезно?! Проблема не в си, а в том, что его еще не похоронили, но, вы правы, и раст похоронят, но пока лучше нет, и есть только один путь - эволюция языков, и исключение все большего количества возможных багов.
Прими таблетки и одень очки, си вокруг тебя везде.
Сложность разработки - я бы не сказал, но если ты привык к пхп или ещё какой фигне которая за тебя всё подтирает то да, мегасложно ибо надо думать в мозг самому.Если слушать таких как ты то и электричество низя, оно убивает, и машины нельзя там аварии со смертями и вообще ничего нельзя, всё небезопасно для жизни.
Клонирование PDP-11 и VAX прекратилось ещё в начале 1990-х с распадом советской электронной промышленности.
Чушь не гоните товариш. Мне интересно, сколько времени вы будете ваш новомодный Rust портировать под новый проц? Тем более в этом аспекте смешно звучат java (не беру подмножество java card и ME) и D. Особенность C в том, что компиль к нему поднимается за 1-2 мес. Tiny C compiler - 12k строк кода (когда последний раз его видел), при этом собирает линь. Кто ещё может таким похвастаться? C - это баланс между юзабильностью и скоростью разработки ПО под совершенно новые платформы.
> Чушь не гоните товариш. Мне интересно, сколько времени вы будете ваш новомодный
> Rust портировать под новый проц? Тем более в этом аспекте смешно
> звучат java (не беру подмножество java card и ME) и D.
> Особенность C в том, что компиль к нему поднимается за 1-2
> мес. Tiny C compiler - 12k строк кода (когда последний раз
> его видел), при этом собирает линь. Кто ещё может таким похвастаться?
> C - это баланс между юзабильностью и скоростью разработки ПО под
> совершенно новые платформы.Чушь это ваше заявление, llvm проще си, и си это не tiny-c, который генерирует код не качественнее хаскеля, но да, для него "можно" быстро написать бекэнд, но даже у гнутого-си проблемы с "качественной" кодогенерацией бекэндов для армов, спустя десятилетия, несмотря на подавляющее засилие этой архитектуры, ограниченное количество ОС, и это не говоря об остальных новых архитектурах, для которых невозможно написать си, из-за полного отсутствия многозадачности, и... в 80х уже были транспьютеры, си для которого генерировал отвратительный код, а многозадачность организовывалась через библиотеки на языке более высокого уровня.
Новые процы как бы не ограничиваются arm'ами и mips'ами. В железе лучше и компактнее C пока ещё ничего не придумали.
И да, не думаю, что от говногенерации очень сильно llvm спасёт. В C хотя бы есть шанс "по ловировать" самим языком (на что пару раз натыкался при использовании avr gcc).
Ну так ведь и Си не нyжeн. Но по уровню фанатизма Си-фанатики И Rust-фанатики сравнимы. В коде гoвнo, но если кто-то пришлёт PR, переделывающий макросы и енамы на плюсовые типобезопасные замены, то отклонят с формулировкой "так хочет BDFL".
Потому что это всё нужно только автору патча, который не понимает разницы между компелятором для си и крестов.
Компилятор для "крестов" - это развитие компилятора для Си, потому что "кресты" - это развитие Си. А Си - это obsolete and deprecated language, ведь есть "ненужные кресты" с "ненужным" ООП и "ненужными" наворотами, которые Труъ Сишник презирает и продолжает колоться и жрать свой гoвнoкoд, слепленный из макросов, копипаста и лестниц if else.
Си это устоявшийся язык.
Если ты вытащишь голову из компа и посмотришь в реал, то увидишь что сложные языки умирают в пользу примитивного английского.Я для себя не вижу смысла в крестах потому что 1к страниц книжка и теперь каждые пару лет ещё страниц 200, чисто чтобы не отстать от прогресса = бег на месте.
Чего ради - мне не понятно, я редко лазаю в крестовые проекты, в основном удаётся понять и сделать что я хочу, хотя есть один проект от креатнутого автора, там уходит много времени на патчинг.
Раст вообще ещё и не родился даже, наколенная поделка, которой каждый месяц прикручивают новые колёса, в надежде что оно взлетит.ООП - это не фича языка а подход, мне никто не мешает использовать ООП в си, там где это имеет смысл. И я его использую совмещая с функциональным подходом. Всё лучшее.
Что меня раздражает - так это придумывание ещё больше ненужных языков и расширений к существующим - работа по повышению энтропии без реальной пользы.
Вон в крестах, ну пилили бы себе дальше свой буст как либу и не тащили в язык.И ещё мне дико не нравится как медленно кресты компелируют, если бы llvm был на сях он бы у меня собирался не 11-16 минут а 3-5, аналогично с другими крестовыми пакетами.
А раст ещё больший тормоз, потому что и сам тормоз и его ещё собрать надо чтобы им можно было что то собрать.
>>что сложные языки умирают в пользу примитивного английского.зачем тогда родился Си, если есть асм? Си такое же "дерьмо" как все ЯП. Язык "Машины Тьюринга" три оператора (взять, положить, сдвинуть головку) - необходимо и достаточно для любого алгоритма.
А то сам не знаешь: чтобы легко переносить проги с одной архитектуры на другую, ну и вообще чтобы кодить не озираясь постоянно на особенности архитектуры.
И асм не простой, команд там сильно больше, даже на Z80.
>>ну и вообще чтобы кодить не озираясь постоянно на особенности архитектуры.ага компилятор не озирается на особенности архитектуры. Такая же история с ВМ.
>>И асм не простой, команд там сильно больше, даже на Z80.
ага большая половина которых - "пустышки" из микрокода.
пс: выше я описал, для любого алгоритма необходимо и достаточно всего три "операции".
Компелятор это одна программа.
Когда у тебя появляется новая платформа то ты пишишь на неё хоть какой то компелятор который хоть как то работает и платформа оживает, потому что там уже можно собирать любые программы.
Бутстрап.На браинфаке пиши сам.
> Я для себя не вижу смысла в крестах потому что 1к страниц книжка и теперь каждые пару лет ещё страниц 200, чисто чтобы не отстать от прогресса = бег на месте.Тогда программирование не для вас. Разве что байтошлепство в ембеддед на c89. Я не говорю, что это хорошо или плохо, просто это факт: в программировании сейчас надо постоянно что-то учить и такие языки как c++ еще наиболее консервативны, в каком-нибудь js и вебе все вообще каждый месяц меняется.
> Тогда программирование не для вас.При вашем подходе "программировать" просто некогда - всё время будет тратиться на чтение таких книг и экспериментирование.
Но на самом деле всё проще: вы просто путаете кнопкотыкательство и программирование.
Программировать можно на любом языке, позволяющем решать задачи. Если у вас есть необходимость решить какую-то существующую задачу, то с 99.99% вероятностью существующих в современных языках возможностей достаточно, чтобы решить её достаточно быстро и безошибочно. И если вы уже владеете каким-то инструментом, то нет необхдоимости изучать, как то же самое с теми же затратами можно решить по-другому.
А если у вас критерий - не чтобы работало хорошо и предсказуемо, а чтобы выглядело как в последней книжке, то это уже не программирование.
Учить для чего?
Разуй глаза, ничего нового за последние лет 30 не появилось, всё что вы там накодили это просто обёртки над обёртками, работаете не на результат а на корзину.Не, я конечно изучаю новое, но это подсистемы ядра ОС, библиотеки на сях написанные, протоколы которые мне нужны (L3, L4, L5), железо немного - все базовые и фундаментальные вещи, на которые строится современный мир.
Следующее новое что будет - квантовые компы, там реально нужен свой язык программирования типа си и прочего, и он будет отличатся от того что сейчас, потому что база другая.
Мне работы хватает, тут ядро ОС запатчить, там дрова, там какие то либы или ещё какую фигню, которую ты используешь через 5-10 прослоек.
Эмбедет я не люблю - там железо слишком часто меняется, только закончишь полировать железку - а её уже не выпускают, надо брать новую и всё с начала - ну нафик, я не вендор с контейнерами денег чтобы на корзину работать. Один раз сделал - списал на самообучение, второй раз мне за это платили.
>Следующее новое что будет - квантовые компы, там реально нужен свой язык программирования типа си и прочего, и он будет отличатся от того что сейчас, потому что база другая.Обрадую тебя: для квантовых компов ЯВУ невозможен и беспобезен. Квантовые компы - они о линейной алгебре и преобразованиях Фурье чисто, никакого взаимодействия с периферией быть не может - периферия - она классическая, взаимодействие с ней - это измерение, рушащее квантовые состояния.
Поэтому яп для квантовых компов - это DSL на основе линейной алгебры, когда вектора из кубитов множатся на матрицы, перегруппируются и измеряются в классические биты.
Отрасль молодая - это сейчас там с периферией проблемы.
Да, язык там наверняка будет достаточно радикально другой, поживём увидим.
> Отрасль молодая - это сейчас там с периферией проблемы.У нас (физика) был небольшой курс про квантовые компы, и преподаватель рассказывал, что они имеют достаточно ускоспециализированное применение, так что замены классического компьютера квантовым не будет. Будет обычный классический, с периферией и прочим, и к нему подключен отдельный блок квантовых вычислений.
Так же когда-то делали с сопроцессором. Сейчас сопроцессор встроен в современные процессоры, однако бОльшая часть деятельности процессоров (взаимодействие с периферией, работа с памятью, и т.д.) приходится на целочисленную арифметику.
Как только они достаточно подешевеют то специализация внезапно расширится до просмотра порнухи и шпилинья в игры на ящике.
Не нужно забывать что:
- компы когда то были меинфреймами с конским ценником, потреблением и габаритами
- комерсам уже нечего продавать а это определённо новинка
Посмотрите Q#. И он не единственный под квантовые. Просто запомнился из-за активной рекламной политики MS.
> Следующее новое что будет - квантовые компы, там реально нужен свой язык программирования типа си и прочего, и он будет отличатся от того что сейчас, потому что база другая.Существуют уже) В дотнет впиливали Q#. И это только один из последних. На самом деле под квантовые уже десяток ЯП наберётся.
>>что сложные языки умирают в пользу примитивного английского.Навряд-ли в переписке на гитхабе кто-то использует сложные конструкции английского. Хватает простых.
> Если ты вытащишь голову из компа и посмотришь в реал, то увидишь что сложные языки умирают в пользу примитивного английского.Tengo esperanza, que estas hablando del japones !?
> сложные языки умирают в пользу примитивного английского.Эволюция и деградация идут рука об руку, но в следующее поколение переходит лишь одна ветка.
> Если ты вытащишь голову из компа и посмотришь в реал, то увидишь что
Это всего лишь твоя точка зрения, наивно спроецированная на окружающих.
> Эволюция и деградация идут рука об руку, но в следующее поколение переходит лишь одна ветка.Надеюсь, лишь масломаслянистая, стремительная и домкратистая?
>> Эволюция и деградация идут рука об руку, но в следующее поколение переходит лишь одна ветка.
> Надеюсь, лишь масломаслянистая, стремительная и домкратистая?Каждому своё.
>что сложные люди умирают в пользу примитивного вируса эболыпофиксил, не благодари.
Полностью поддерживаю. Намучился с допотопным printf (показывал то мусор, то 0), а потом включил ++ и через >>cout сразу и декременант показал и корни, причём одной командой. Вообще, хорошо, что на гуманитарной специальности дают основы кодинга (я по совместительству админю, LAMP, DOCKER, вот это вот всё). Будущее за С++. Если кто-то жить не может без Ц, но не осилил ++, пусть хоть на 1Ц переквалифицируется - хоть что-то полезное.
> хорошо, что на гуманитарной специальности дают основы кодингаТак тонко, что почти не видно :)
Мне тоже понравилось :))
>Будущее за С++.Так уже лет тридцать говорят. Но что-то будущее все не наступает, лол.
Оно уже наступило просто.
Кто-то printf не осилил?)
> Кто-то printf не осилил?)Имеешь в виду его разработчиков? Не будем к ним столь строги.)))) Кстати, специально для "осиляторов" мамонтовых технологий запилил демонстрацию, которая показывает, что место printf на свалке истории.
>> Кто-то printf не осилил?)
> Имеешь в виду его разработчиков? Не будем к ним столь строги.)))) Кстати,
> специально для "осиляторов" мамонтовых технологий запилил демонстрацию, которая показывает,
> что место printf на свалке истории.
> https://ideone.com/DJcDFHКак бы printf("%.8f", D). Нахер тот изврат? Стоит отметить, короче std::cout (и быстрее, ибо в той C++ макаронине уйма времени тратится в перегрузках <<". При помощи std::cout вообще извращение что-то форматировать. Гуглим libfmt.
> Как бы printf("%.8f", D).Это было бы слишком хорошо, чтобы быть правдой. С какой такой стати в этой команде возникает буква f? Похоже, никто даже не вник в мою задачу: нужно вывести число D (dецимальное), а не F (füнфальное что ли?)! Я бы ещё, может быть, потестил printd("%.8d", D), но для меня это всё давно пройденный этап. В fmtlib углубляться не стал (ибо сейчас отгружаю контейнеры в продакшн и не досуг), но априори ясно, что это очередная попытка утешения ретроградов, которые не осилили писать современный объектно-ориентированный код на С++ через std::cout.
f - для вывода плавающих. В документации она описана. Из примера ни разу не ясно, что пытаетесь вывести. Строка:
printf("%d.%08d", int(cel), int(drob));
как бы указывает на очень странную попытку вывести дробное.
Если же была попытка вывести плавающее как целое, то C++ вариант из примера с ней также не справляется.> нужно вывести число D (dецимальное)
Это какие-то новые числа? %d - это вывод целых, %f - вывод плавающих. Вы бы хотя бы доки почитали прежде чем пилить такие "versus'ы".
> но априори ясно, что это очередная попытка утешения ретроградов, которые не осилили писать современный объектно-ориентированный код на С++ через std::cout.
А вы вникните и сравните богомерзкую мокорони-конструкцию на C++ и libfmt, который синтаксис форматирования берёт у питона. printf пожалуй только ему по фозможностям и проигрывает, но никак не std::cout.
>> Кто-то printf не осилил?)
> Имеешь в виду его разработчиков? Не будем к ним столь строги.)))) Кстати,
> специально для "осиляторов" мамонтовых технологий запилил демонстрацию, которая показывает,
> что место printf на свалке истории.
> https://ideone.com/DJcDFHУже 17-ый стандарт на дворе, а в плюса так и не завезли (да и не планируют) нормальное форматирование вывода.
> Компилятор для "крестов" - это развитие компилятора для Си, потому что "кресты" - это развитие Си.Нет. C++ -- это существенно другой язык. Он _задумывался_ как развитие C, но через 25 лет развития получилось что-то совершенно иное.
> Сишник презирает и продолжает колоться и жрать свой гoвнoкoд, слепленный из макросов, копипаста и лестниц if else.
Найди мне копипаст или лестницу if-else в ядре линукс. Если кто-то не умеет пользоваться языком, то это ещё недостаточная причина, чтобы утверждать, что язык плох.
Вы тоже из тех, кто путает C и C++ или считает C подмножеством плюсов? Сам подход к написанию софта у этих языков в корне разный. Идеалогия тоже разная.
Не соблаговолит ли многоуважаемый Аноним привести примеры отвергнутых исправлений вышеупомянутых саботажа, вандализма и хамства?
Примеры вымышленные и очевидные, но отличаются от реальных только идентификаторами.#define AAAA_BBBB 10
на
enum class AAAA:uint8_t{
BBBB = 10u
};или
#define CCCC(X,Y) ....
на
constexpr template<typename T> T CCCC(T x, T y){
....
}
Замены, очевидные для любого, словившего кучу боли при отладке, и решившего проблему только после разбора километрового препроцессированного дампа.
> enum class AAAA: uint8_t {
> constexpr template<typename T> T CCCC(T x, T y) {
> очевидныеВот поэтому вас и не любят.
Те вместо того чтобы
-#define AAAA_BBBB 10
+#define AAAA_BBBB ((uint8_t)10)
и
-#define CCCC(X,Y) ....
+#define CCCC(_T, X,Y) ((_T)(....))
ты предлагаешь менять компелятор на тормознутый крестовый и фиксить пол проекта чтобы оно для начало собралось? (кресты же обругают в 100500 местах за типы если вот так в наглую попробовать собрать)Я бы тоже тебя послал, очевидно ты крестанутый неадекват, возомнивший себя крестоносцем во славу пресвятого Трупстрауса.
Да предлагаю, и не просто предлагаю, я сделал это. Но PR отклонили.Макросы искажают исходный код и использоваться не должны, если без них можно обойтись. А без них можно обойтись - просто перейти на плюсы и использовать плюсовые конструкции.
> Да предлагаю, и не просто предлагаю, я сделал это. Но PR отклонили.То есть вы зашли в чужой проект на сях, сказали, как им надо писать правильно, что надо перейти на другой яп, показали на примере, а вас даже не отблагодарили?
>То есть вы зашли в чужой проект на сях, сказали, как им надо писать правильно, что надо перейти на другой япИменно так.
>а вас даже не отблагодарили?
Спасибо сказали (часть изменений таки была влита, но к сожалению часть таки не влили). Спасибо в карман не положишь, но иного я и не ожидаю от людей, пилящих либы just for fun.
Мне макросы нравятся, но без фанатизма.
На фоне всяких gobject я их весьма умеренно использую, и большей частью для констант и флагов.
Плюсы не вариант, я уже писал: время сборки растёт в разы и потребуется правка кучи мест. А потом набегут крестоносцы со своими темплейтами, и прочими новомодными штуками и код станет невозможно читать без освоения крестов, что не вариант, ибо повышает кратно порог входа в проект.
>что не вариант, ибо повышает кратно порог входа в проект.То есть ваш проект рассчитан на контрибьютеров-неосиляторов, которые не то что в архитектуру, но даже в подмножество "крестов" не могут?
Он рассчитан чтобы решать мои задачи.
Для изучения крестов нужна большая мотивация ибо процесс долгий, отсутствие мотивации не означает что не осилил, оно означает что не нужны кресты.
Для изучения C++ знающему Си нужно несколько часов. Стандарт можно не зубрить и даже не читать, достаточно книг, сайтов и блогов. Из книг рекомендую Марченко "Бархатный путь", Скота Мейерса Effective Modern C++ и Wrox Professional C++. Нужно понимать перечисления, битовые поля, приведения типов, классы, наследование, виртуальные функции, структуру стандартной библиотеки (где контейнеры, где алгоритмы, где потоки и что ещё есть) и несколько раз просмотреть списки UB в Интернете.
> рекомендую Марченко "Бархатный путь"Это которая "возьмём очередную форму Бэкуса-Наура, развернём её, допустим, вот таким образом, а теперь давайте разберёмся, что тут у нас получилось, как это работает и что означает"?
Вот из-за таких книг и появляются толпы плюсистов, для которых язык - это лишь синтаксис. Пользоваться языком они не умеют, просто вставляют в исходный код синтаксические конструкции. Уж изучать, так по Страуструпу" Язык программирования C++".
Кроме того согласно здешнему контингенту, эта книга устарела, так как описывает Borland C++ 4.5,а это стандарт, который был перед стандартом 1998 года.
Несколько часов нужно школьнику, чтобы навелосипедить класс МояМатрицаЭмНаЭн с перегрузкой операторов для арифметики и ввода-вывода. А специалисту для эффективного применения понадобится где-то 3 дня, семь месяцев и 5-20 лет. Знания Си придётся фильтровать из-за несовместимостей, и в любом случае они растворятся в океане фич, спец. случаев и крестовых паттернов. Нужны очень хорошие причины, чтобы вместо простой Сишечки выбрать очень сложную не-Сишечку типа Крестов.
Изучение крестов знающему Си не очень то и нужно, если только он не решит пойти в манки кодеры в геймдев или ещё куда то, где будет кодить от забора и до обеда что скажут.
Впрочем это моё личное мнение, мне интереснее с сишечкой где то не далеко от ядра и железа, или пилить свои либы типа libuv/libevent.
> Для изучения C++ знающему Си нужно несколько часов.Жжёте. Видимо на столько хорошо знаете плюса и, главное, знаете, где их уместно применять.
> То есть ваш проект рассчитан на контрибьютеров-неосиляторов, которыене могут осилить лисп, так же, как и ваши плюсовые неосиляторы.
/thread
>Ну так ведь и Си не нyжeнАга. Вот только практика, показывает что не нужен, как раз таки раст.
Rust - это замена C, а не C++. Поэтому он и не нyжeн.
анон, хватит норкоманить, раст обьектно-ориентированный, по этому они работают на разных уровнях абстракции и заменой друг другу не являются
Крупных проектов на расте, предостаточно. Не уровня браузеров, но всё же. Браузеров, скажем так, и так немного,чтобы им ещё на всех языках быть.> и то пока лишь частично.
Это одна из фич языка, что его можно использовать в существующих проектах, не переписывая их с нуля.
Есть ещё популярный стек для Ethereum - Parity. За счёт использования Rust'а он самый быстрый и нетребовательный к ресурсам.
В блокчейнах ещё встречается: Grin и Exonum.
У DropBox на расте ядро стораджа.
TiKV - распределенный key-value для TiDB - самой многообещающей из открытых кластерных SQL.
Те теперь на расте целых 3 проекта на всём земном шарике?)
Нормальное ООП с нормальным наследованием не завезли. Пока не завезут - нe нyжен.
Так вроде ж и не собираются🤔
На нэт и суда нэт. Так и останется маргинальным нeнужным языком.
> Так и останется маргинальным нeнужным языком.Зачем ыт тык о себе, ОПП-макак?
Воспринимайте это как возможность сломать шаблон ООП-программиста и писать код в необычном для Вас стиле.Даже если не понравится - то много для себя нового откроете. И, вероятно, станете лучше понимать код (стиль) коллег.
А на кой черт мне тратить время на говнокод коллег?Мы пишем на объектных языках, если они начнут писать на ООП языке "структурно" - я им яйца оторву.
К сожалению раст не альтернатива даже в перспективе, чтобы соскочить на него с плюсов, джавы, шарпа.
MZ пилит его для себя, как замену C. Отсюда очень похожие нотации именования, принцип организации кода.
>MZ пилит его для себя, как замену C.Firefox написан на C++
> А на кой черт мне тратить время на говнокод коллег?Понял, наверное я зря Вам отвечал
>> А на кой черт мне тратить время на говнокод коллег?
> Понял, наверное я зря Вам отвечалНу почему же зря.
Теперь вы знаете, что вашу "индивидуальность" в коде скорее всего не оценят.
Особенно когда это всё ценой прозрачности.
> Теперь вы знаете, что вашу "индивидуальность" в коде скорее всего не оценят.Я ничего не говорил про свою индивидуальность.
> Особенно когда это всё ценой прозрачности.
Тут вообще не понял.
> Нормальное ООП с нормальным наследованием не завезли. Пока не завезут - нe нyжен.Нормальное ООП -- это как в Smalltalk? Или как в Жабе?
А наследование лучше single или multiple?
А MRO -- это нормально или лучше без?
---
public static const final Borscht borscht = new Borscht()
(c) Аноним
BorschtFactory забыл.
ещё надо обернуть в try/catch BorschtCreationProblemsWhileCookingMeatException
> ещё надо обернуть в try/catch BorschtCreationProblemsWhileCookingMeatExceptionКак известно, в каждой шутке ;)
https://github.com/zxlooong/jdk16045/blob/master/com/sun/jav...
class InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState extends State {
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState() {
super("WindowNotFocused");
}
В чем прикол-то?Что остановит дурака от создания подобной портянки на любом другом языке?
> В чем прикол-то?
> Что остановит дурака от создания подобной портянки на любом другом языке?Копирайт посмотри. Ну или в код:
http://kickjava.com/src/com/sun/java/swing/plaf/nimbus/Inter...
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState.java 07/12/12
3 *
4 * Copyright 2007 Sun Microsystems, Inc. All rights reserved.
5 * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
6 */
Человек, где смеяться-то?Я могу взять любой язык, написать подобную портянку с любыми копирайтами, выложить на левый сайт и веселиться.
Очевидно же, что в данном случае мы видим какую-то подставную ахинею.
При чем тут Ява?
> Человек, где смеяться-то?Лопата <--
> Очевидно же, что в данном случае мы видим какую-то подставную ахинею.
> При чем тут Ява?Ох уж эти очевидцы подстав …
Ладно, признаюсь -- на самом деле все фейк хейтеров и завидующих! Даже вон ораклю хакнули, чтобы вставить подставу :)
http://hg.openjdk.java.net/jdk10/sandbox/jaxws/rev/0b6f442e81fe
public static Localizable localizableRUNTIME_MODELER_EXTERNAL_METADATA_UNSUPPORTED_SCHEMA(Object arg0, Object arg1) {
return MESSAGE_FACTORY.getMessage("runtime.modeler.external.metadata.unsupported.schema", arg0, arg1);
}
public static Localizable localizableRUNTIME_MODELER_PORTNAME_SERVICENAME_NAMESPACE_MISMATCH(Object arg0, Object arg1)public static Localizable localizableRUNTIME_MODELER_WEBMETHOD_MUST_BE_NONSTATICFINAL(Object arg0) {
Что ты все показать-то хочешь?Ну название у переменной длинное и что?
Это что, что-то неповторимое в других ЯП?
Или ты хочешь сказать, что в Яве по другому никак? Ты там здоров?
Нормальное - это прежде всего иаеющееся в наличии.
Кстати да, вот и Erlang — не ООП, а объекты есть и свои задачи он решает хорошо.
Беда тех же плюсов, что описывая объект ты как бы должен упрощать себе жизнь, а вместо этого тратишь много времени на описание конструкторов, деструкторов, перемещалок, итераторов и прочего на убогом сишном синтаксисе. Нет ничего удивительного в том, что энтерпрайз, который умеет считать деньги, выбрал дотнет и жабу — это тупо быстро и выстрелить себе в ногу сильно сложнее.
Что вы понимаете под "сишный синтаксис". Дотнет и жаба как бы тоже C family, и соотв. "сишный синтаксис". Вообще, так себе затея сравнивать C и C++. Хотя, меня поражает массовый тупизм вида: "Учебный курс по C/C++".
> А наследование лучше single или multiple?множественное наследование - это как бы антипаттерн, разве нет? Да и вообще неудобно
const в Яве зарезервировано, но не используется, грамотей копипастный.Понятно, что тебе хочется поглумится, но что ты показал и доказал?
Объявление и инициализацию переменной в классе?
public static final Val val = new Val();
Публичная статическая константа(ссылка) на объект.. И?В методе это будет:
Vak val = new Val();
или
Val val = Val.of();Factory многие не пишут.
Сейчас модно Type.of() делать.Так над чем и в каком месте нужно смеяться?
Над тем, что один рисует акварелью, другой гуашью, а третий карандашами?
>> public static const final Borscht borscht = new Borscht()
>> (c) Аноним
> const в Яве зарезервировано, но не используется, грамотей копипастный.
>> (c) АнонимОчередной кэп? Автограф можно?
> Понятно, что тебе хочется поглумится, но что ты показал и доказал?
Судя по усиленному проставлению минусиков и потрясанию кулачками -- например, что у (Нео) Жабистов от классики нещадно подпекает?
> Factory многие не пишут.
> Сейчас модно Type.of() делать.Интересно, где ты углядел Factory? И почему не ответил на остальное -- т.е. не соизволил дать определение OOP?
> Так над чем и в каком месте нужно смеяться?
Очевидно, над Жабистами -- из них получаются самые ярые апологеты OOP (это при том, что OOP в жабе при любом раскладе довольно посредственное), пытающиеся применить этот подход к месту и не очень (и даже совсем не) -- поэтому традиционно в качестве примера "ООП головного мозка" приводят что-то на Жабе.
Судя по отклику тут в новости -- совсем не зря.Ваш КО
Честно признаться, я вообще не понимаю, о чем ты пишешь и чего ты такой озабоченный на тему ООП или не ООП.Чтобы что-то ответить, нужно сперва понять, что говорят, но это не представляется возможным по всей видимости.
Давай не будем продолжать эту бессмысленную переписку. Мне без разницы как ты относишься к ООП и вообще к чему либо. Я лишь указал, на твое передергивание по поводу Явы. Просто это читают другие люди и не хотелось бы чтобы кто-то велся на очевидную чушь. Поэтому я высказался, а не для того чтобы тебе что-то доказывать. Мне ты тоже ничего не докажешь.
> Честно признаться, я вообще не понимаю, о чем ты пишешь и чего ты такой озабоченный на тему ООП или не ООП.Потому что для понимания желательно читать ветку целиком, а не только высматривать знакомые слова:
#4 >>> Нормальное ООП с нормальным наследованием не завезли. Пока не завезут - нe нyжен.
#10 >> Нормальное ООП -- это как в Smalltalk? Или как в Жабе?//<в общем, дайте определение OOP + бородатая шутка>
# 173 > <как ты посмел непочтительно отозваться о Java! Еретик! Проигнорировав весь контекст, прискипался к последнему предложению>
> Чтобы что-то ответить, нужно сперва понять, что говорят, но это не представляется возможным по всей видимости.Что жабисты опеннета слабоваты в чтении и теории, совсем не сюрприз. Увы.
Как там говорил Dijkstra?
> It is practically impossible to teach good programming to students that have had a prior exposure to JAVA:
> as potential programmers they are mentally mutilated beyond hope of regeneration.(хотя в мелочах могу и ошибаться - всеж по памяти цитировал).
Там есть все то же самое, но только лучше, современнее, более расширяемое. Это языки с оопа потихоньку съезжают на подход раста. Например swift называет себя протокол ориентированным, хотя имеет и обычный классический ооп.
Правильно говоришь, люди еще не знают раста, а уже... Ууу наследования нет, перезагрузки методов нет, ууу. А я скажу что есть и даже больше, только обучения требуется еще больше
И кода больше и вообще давайте исключительно на голом llvm-ассемблере без всего писать понтов ради.
Насколько я помню, ООП и правила владения, заимствований и др. в расте не очень совместимы
Да, обычный небезопасный ООП-говнокод вообще запрещен. Приходится передумывать некоторые старые паттерны.
Всмысле, какое наследование? Вы не знаете как пользоватся типажами?
типажи - это не наследование
Знаю. Но не хочу. Один элемент синтаксиса с наследованием заменяет [1, +∞) определений функций с типажами. Не хочу пользоваться языком, авторы и пользователи которого недостаточно умны, чтобы понять это.
Чо сказать-то хотел?
То что типажи не могут полноценно заменить наследование. Могут заменить с извращениями и гoвнoкодом, но не нужна мне такая замена.
Агрегация и композиция вам в руки
Трейтами — знаем, а типажами пусть надмозги пользуются.
как "пророк" без "чудес"? - слепая вера
От наследования все пытаются убежать последние лет 30. Вначале сделали языки с одиночным наследованием и заговорили о композиции вместо наследования, затем начали продвигать интерфейсы. В большинстве случаев в ООП можно отлично обойтись композицией, а наследование оправдано только в паре с полиморфизмом. В Расте полиморфизм подтипов реализован через интерфейсы и этого вполне достаточно.
Только пробрасывать приходится вручную.
А Qt когда-нибудь завезут?
https://github.com/woboq/qmetaobject-rs
https://www.vandenoever.info/blog/2018/09/16/browsing_your_m...
Раст - не нужен, он собирается дольше, чем FreeBSD целиком.
Rust с jit и префетч кешем может собирать моментально сразу после сохранения в файл .rs. Бзда нет.
Это никому не интересно: я получаю фаирфокс (других расто содержащих продуктов у меня нет) в виде архива, который распаковывается и собирается. Ничего править я не собираюсь. Время сборки фф всегда большое, и ccache мне с ним не помогает потому что он про раст ничего не знает, а других кешеров у нас в портах не прикручено ибо раст никому не нужен, его нет и в 0,005% портов.И собственно что ты описал для си не интересно, ибо есть и ccache и среда разработки. Но если станет надо то делается простой демон который мониторит изменения в директории и на основе диффа гоняет компелятор.
Гордится тут нечем.
https://github.com/mozilla/sccache
Лажа, латентность до вражеского облака убьёт весь профит.
Синтаксис ужасен, фичи сомнительны, создан хрен знает кем.. спасибо, не надо.
Даже не столько ужасен, сколько вымучен и натужен. Как будто идея этого языка и первая реализация были созданы, когда разработчик страдал запором))
В целом согласен.
>> создан хрен знает кем.. спасибо, не надо."Чего добился?" (С)
Вот и выросло поколение неосиляторов, ударенных сиплюсплюсной шпалой по контейнеру с серым веществом, напоминающим мозг довольно развитых в остальном приматов. А ничего, что синтаксис ну очень сильно напоминает языки семейства ML, которым уже лет 50, и, вообще-то, попроще, чему у некоторых других популярных языков? Попробуйте для разнообразия расширять кругозор языками программирования и computer science в целом. Фичи сомнительны разве что для полного нуба, который колется C++ по три раза на день, и которого кумарит без полной свободы действий, которая обычно приводит к хроническому сегфолтиту. Два-три года назад я тоже ленился вникать в суть, дрался с borrow checker, пока не понял, что не обязательно буквально всё передавать по ссылке, как и хранить в структурах только ссылки, и что трейты универсальнее и гибче, чем ООП, и т.д. Необходимость инициализировать все переменные, immutability по умолчанию, правила использования ссылок и всё прочее - это манна небесная, а не геморрой, когда поворачиваешься к ним лицом.Если трудно перестроить закостенелое мышление, это ещё не признак того, что язык программирования плохой. Скорее, это признак того, что вы так долго употребляли паттерны других, знакомых вам ЯП, что они почти намертво вплавились в ваше сознание, и сложно с них слезть, начать думать в перпендикулярном направлении и внимательно читать доки.
Подыши свежим воздухом, завари какого-нибудь улуна/пуэра, RTFM и пиши какую-нибудь хрень для души, пока не достигнешь просветления и способности свободно плавать в озере библиотечных структур, трейтов и функций. Повторять час-два в день в течение не менее трёх месяцев. Понимание придёт не сразу, но оно стоит затраченных усилий.
TL;DR: Если слишком долго сидеть на одном и том же стуле, то скорее задница примет форму сидения, чем наоборот.
Зря смеётесь над Растом. Он скоро GStreamer попортит, прямо наподобие ржавчины на металле. Есть парочка лидеров коммьюнити (впереди всех конечно неутомимый Себастиан Дроже), которые года 3 как стали на всю голову растаманами, в плане разговоров только о нем на конференциях, в твиттерах и т.д.
На предстоящей FOSDEM тоже будут обрабатывать.
Соответственно новые плагины из под их пера тоже на расте.
https://youtu.be/W_mnFFqpMpQМне почему-то кажется, это Интел старается. Ведь Раст готов только для их архитектур, а для остальных - "гарантия сборки, но нет гарантии работы", на оф.сайте. И вообще, убить кросплатформенность.
А я то думал, почему фаерфокс только на штеуде работает, а оно вот как, оказывается.
То что GStreamer стеремится перейти на rust это плохо?
А GStreamer кому нибудь нужен?
ls /usr/lib/x86_64-linux-gnu/gstreamer*
ls: невозможно получить доступ к '/usr/lib/x86_64-linux-gnu/gstreamer*': No such file or directory
>Мне почему-то кажется, это Интел старается.Теория заговоров? Или всё таки потому что тестеров тех же ARM/MIPS намного меньше, чем для x86/x86_64? В Go ситуация иная, Google заинтересован в ARM.
В librsvg rust засунули, пусть и в GStreamer засунут, чего уж. Может, гном хоть меньше течь станет и будет какая-то польза от этого раста.
mpv не юзает GStreamer, так что ГОРИТЕ!
в gstreamer сейчас куда кода, реализующего велосипеды с композицией, атомным подсчетом ссылок, и т.п. Если перейти с C на ржавчину, то все эти велосипеды можно будет выкинуть на помойку, где им и место, заменив их штатными средствами языка. (но ты конечно не вникал в такие детали, да?)
У меня Rust на микроконтроллерах STM32 прекрасно работает - даже лучше, чем C и его приплюснутый сынок. Временное отсутствие гарантийного талона вообще не мешает. Если STM32 у меня из хобби когда-нибудь перерастёт в профессию, к тому моменту всё будет не хуже, чем на x86 и иже с ними.
> Зря смеётесь над Растом. Он скоро GStreamer попортит, прямо наподобие ржавчины наgstreamer невозможно испортить. К счастью, мурзила уже отправила его лесом, убедившись в этом.
> Мне почему-то кажется, это Интел старается. Ведь Раст готов только для их
ну вроде бы мурзила на армах как-то работает же ж?
> архитектур, а для остальных - "гарантия сборки, но нет гарантии работы",ой, молодцы-то какие.
> на оф.сайте. И вообще, убить кросплатформенность.
gstreamer'а? Скорей-скорей!
Чем быстрее эта уродливая поделка сдохнет, тем лучше для всех нас.А шансов пролезть с этим мусором в ffmpeg и рядом у них около нуля в ближайшие десять лет.
P.S. А можно еще авторам гнома подкинуть эту прекрасную идею, а?
Поржал с обсуждения.
Как говаривал старик Линус Торвальд - "C++ - редкое дерьмо. Если вы хотите нормально программировать на C++, то выкиньте оттуда все, чтобы в вашем коде остался только чистый С" А он знает толк в программировании, в отличии от метных знатоков- любителей =)
Страуструп о своем детище - Задумка C++ была прекрасна, а реализация оказалась ужасна"
Про Java говорить и не стоит. Этот язык ненавидят все. И это не ООП.
ООП - это Smalltalk и только. И автор этого языка искренне недоумевает почему Java или C++ называют ООП языками.
Си будет жить, Asm будет жить, а хипстеры, пускающие слюни восторга от любого синтаксического сахарка, так и будут визжать, что они уже давно мертвы. Но сами они уже будут в могиле, а Си и Аsm как были, так и будут.
Throw your C++ and use Rust
> Throw your C++ at the MGIMO-window, abandon it and use Rustфикзед!
Донт юз тзе гугол-транслатор, плиз! Тзе результ из хоррибл!
Пробабли хи мент: Throw C++ away and use Rust. Соу, онли уан вёд из мисинг. Донт би ту харш он им.
>Пробабли хи ментВона как ...
C++ ужасен, но лучше и мощнее еще ничего не придумали
Решил ответить не в длинные нити а сюда.Наследование в Расте не всегда и нужно. Иногда эту задачу могут решить макросы. Часто есть решения тривиальных задач. Расширяет возможности структуры иногда даже более гибко чем наследование.
А ещё это скорее дело привычки. В js вроде как тоже нет наследования и никто по этому поводу не пищит. (Да, я знаю про proto)
> В js вроде как тоже нет наследования и никто по этому поводу не пищит.Потому что все заинтересованные в ООП используют TS
> В js вроде как тоже нет наследования и никто по этому поводу не пищит.В JS наследование куда лучше, чем в большинстве ваших ООП языков. В JS вообще более чистый и элегантный ООП
Только приватных членов нет
* пока нет. Но в TS есть.
Пока для этого языка не будет вменяемого бесплатного IDE он мало кому будет нужен.
Intellij idea community edition
IDE без поддержки интерактивного дебагера - не IDE.
intellij idea - это не IDE, это ненасытный тираннозавр, жрущий память.
Пусть даже тиранозавр, но хотя бы интерактивный дебагер должен поддерживаться без необходимости за это платить JetBrains-у.
В vscode вполне вменяемо. И, да, дебагер есть.
Невменяемый редактор для альтернативно одарённых.
vscode хорош по функциональности, но то, что он жрет полтора гига на одно открытое окно, напрягает. А еще у него часто процесс парсинга внутри cpp экстеншена начинает жрать 100% ядра и висит.
Какой язык с ООП подойдет для новичка ?
Python 3.
Ок
ООП может быть немного трудно понять, он довольно магический и абстрактный во многих языках. В таком случае я бы очень рекомендовал JS без ООПа (его же я бы порекомендовал наравне с Python для новичка и ООПа), либо SICP курс, либо какой-либо функциональный язык.
java / c#. На мой взгляд в этих языках самый адекватный ООП. На сишарпе можете пописать игрушки под unity, если совсем новичёк.
Java или C#. Если выучите один - второй сможете освоить за пару недель. Потом для саморазвития полезно ознакомиться со Smalltalk'ом.
На FreeBSD 12-STABLE пакет (архив с бинарниками) rust-1.32.0.txz собирался почти 45 минут на Ryzen 5 2600.Для сравнения: llvm70-7.0.1_2.txz — 30 минут; gcc9-devel-9.0.0.s20190113.txz — 7 минут; openjdk8-8.192.26_4.txz — 8 минут; libreoffice-6.0.7_5.txz — 44 минуты; thunderbird-60.4.0_3.txz — 19 минут; firefox-64.0.2_1,1.txz — 19 минут.
Ты его каждый день собираешь что ли? Для таких как ты есть rustup
> Ты его каждый день собираешь что ли?Зачем каждый день? Опакечивается только новая версия, нужная для сборки чего-то. Если вышел Rust новой версии, он появился в портах, но Firefox или Thunderbird не обновились, то Rust не обновляю.
Сумосброд конченных в комментах, которые просто не могут порадоваться прогрессом в языках программирования. Защеку вам, хейтеры.
Бздуны просто не одобряют прогресс, ведь у них у самих там застой и перестройка.
> СумосбродЭто какой-то чемпионат по сумо? Или сумоисты собрались компашкой сходить куда-нибудь пожрать?
> компашкой сходить куда-нибудь пожрать?В биотуалет.
Когда выйдет Clay, то Rust канет в. лету уже навечно, как и прочие С++ и тд)
последнее обновление в 2012?
"Валера, верим" (с) :)
Главное, чтобы этот клей не сдох по дороге
>> Главное, чтобы этот клей не сдох по дорогеГлавное, чтобы не выдохся...
ЖИР НЕ ОТ ПИЩИ! ИЗБАВИТЬСЯ ДО 15КГ ЖИРА МОЖНО БЕЗ ХИМИИ, ГОЛОДА И ФИЗИЧЕСКИХ НАГРУЗОК.
Для того, чтобы похудеть не так важно, что именно есть можно питаться любыми продуктами и снижать вес
Как сбросить лишний вес и не испортить здоровье?
Как победить лишний вес при гормональных изменениях?
Почему техника дыхания по книжкам и видео-урокам не приносит результата?
Хотите узнать, за счет чего 15 минут Биокомплекс заменяют 45 минутную пробежку?
Рассказывает, доктор медицинских наук Громов Виктор Александрович.
Читайте с пользой Для вашего здоровья