Опубликован релиз языка системного программирования Rust 1.51, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54839
просто лучший ЯП (сарказм)
А почему сарказм?
Нельзя сказать, что он прям лучший среди языков (спойлер: таких нет, каждому свое, и на каждую задачу свое). Но, без сомнения, он хороший и перспективный, признан крупными компаниями, пятый год получает звание самого любимого языка на stackoverflow.
Сомнительное достижение быть "самым любимым" языком на площадке "я что-то делаю, а оно не работает, подскажите как правильно". Перед этим самым любимым языком на стековерфлоу был джаваскрипт.
А в каком году JavaScript был самым любимым языком по мнению опрашиваемых посетителей Stackoverflow?
В Твиттере есть такая шутка: какой у вас самый любимый ЯП и почему это ДжаваСкрипт?
>Сомнительное достижение быть "самым любимым" языком на площадке "я что-то делаю, а оно не работает, подскажите как правильно".На ЛОРе его тоже любят. Каждый тред про Rust -- лютый срач.
Синтаксис тому очень способствует. Плюсовики over time - разгребают винтажные костыли, улучшают синтаксис. Растовики over time: обезьянят старые траблы плюсовиков.На раст не надо проводить obfuscated code contest. Он в каждой первой программе. Охренеть как интуитивно и читаемо.
То что людей беспокоит то и важно и нужно
В мире раньше всех беспоколи три вещи секс. бухло и рок н рол
А теперь вот пришло время раста =)
Определи, в какую категорию относится раст.
Потому что Раст он как морская свинка. Не имеет никакого отношения ни к безопасности ни к скорости. Поэтому растофанатики придумывают какие-то аморфные плюсы типа «любимый» язык на стековефлоу (что это за бред такой?).
А по TIOBE его даже FORTRAN и COBOL обгоняют
https://www.tiobe.com/tiobe-index//
Индекс TIOBE не показатель популярности, он лишь показывает число запросов вида "<имя языка> programming language". Полумертвый D стоит на 24-том месте, тебе это не о чем не говорит?
И вообще рейтинг делается мартышками, ищущих вопросы по своему языку, например: "python language how to add int with string"
Это ты как вывел что он полумертвый?! Народ в ЕС набирали год назад, у нас в компании на нем пилили одну штуку, развивается бурно, Уолтер даже переносит фичи из Раста и модерн С++ (заисмствования всякие и пр.)
> Народ в ЕС набирали год назад, у нас в компании на нем пилили одну штуку,Ну если бы не эта компания и пара энтузиастов, можно было бы говорить о том, что язык мертвый.
> развивается бурно
Ага прям как фанаты Моргенштерна
> Уолтер даже переносит фичи из Раста и модерн С+Ну да, ведь с самого начала в нем не было такой простой вещи поэтому этот язык такой скудный
Учитывая, как часто появляются новые пакеты для D в Dub registry, он будет иметь популярность в узких кругах ещё долго. Сам дома только на нём и пишу. Коммерчески значимые проекты тоже писал
В целом сложно поспорить, но вот `признан крупными компаниями` - вот тут зацепочка. Чего они только не "признавали" :) Ну там сидит какой-то фанат, пропихнул идейку и вот уже в новостях `признан крупными компаниями`.Когда компания начинает экпериментировать с Хаскелем, крика на весь мир. А когда туда приходят профессионалы и стирают все нах. и переписывают весь этот недо-Хаскель и выпиливают даже его следы, про это уже молчок, на всех страницах лет десять будет висеть что "используется компанией Х".
после shell
https://swizard.livejournal.com/202744.html
У нас есть Rust, поэтому C++ больше не нужен.Сие есть полное и исчерпывающее разъяснение, и окончательная жырная точка в спорах. Победителю достанется отведать овсянки из одной тарелки с манулом.
вперёд, к диктатуре? ни шагу в сторону! прыжок на месте - расстрел!
Страус труп, получается?
fn main()
aaaargh! Думал, хоть в расте заставят писать полноценные заголовки с (void), но нет! >:(
Это шутка?
да.
aaaargh! nope
fn main()
aaaargh! Думал, хоть в расте заставят писать полноценные заголовки с (void), но нет! >:(
в Си:
при объявлении прототипа функции:
- функция c аргументом void подразумевает, что у функции нет аргументов.
- функция с пустые скобки аргументом подразумевает, что у функции произвольное число любых аргументов.Очень часто люди, чтобы не путаться(особенно в сложных) при написании прототипа копируют имя функции и ее описание - вот Вам и прототип.
Естественно для пустые скобки в прототипе или void в прототипе это очень разные вещи.
Хороший релиз
Долгих лет жизни языку
Долгих лет жизни и большого объема памяти проекту!
Это значит, что он тормозной и жручий по памяти?
Нет
А на микроконтроллере с 16КБ флеша и 2КБ ОЗУ, где на стек 0x400 байт, и на кучу 0x200, получится?
Например, вот так? https://www.avr-rust.com/
По потреблению памяти он на уровне C/C++
Это был просто дружеский подкол на фразу с пожеланием )
Местами, он даже быстрее С++, а где-то и чутка медленнее - +- паритет. Язык определенно заслуживает самого пристального внимания.
> Долгих лет жизни языкуКонечно, пожелание пригодится, а то за 16 лет ещё не смогли стабилизировать его.
Заврались вы батюшка. Стабильная 1.0 вышла в 2015, это было 6 лет назад, а первая публичная альфа в 2011-2012, то бишь за 3-4 года, а не за 16.
А до 1.0 что было в промежутке 2006-2015?> The language ... begun in 2006
Где взял 2006, там и прочитай - один чувак первые несколько лет в качестве хобби в свободное от работы и семьи время проектировал (не разрабатывал). Зачем тут ложь писать?
> проектировал (не разрабатывал).Известная ситуация, растаманы всегда проектируют, не разрабатывая :) у них одни пpoЭкты.
Зачем они пишут копию плюсов? Не хотят учить плюсы?
Как плюсовик, могу сказать, что Раст не копия плюсов, спроектирован лучше и без тонны легаси, мешающие развитию языка.
Уже с тонной заплаток поверх уже легаси.
Каждый релиз новые заплатки. Через годик два он станет намного, намного хуже плюсов.
Аргументы в студию.
За:
https://kerkour.com/blog/the-biggest-threat-to-rust-sustaina.../Против(?):
https://steveklabnik.com/writing/how-often-does-rust-changeЯ не уверен, что "против" против, но там методология исследования разобрана в деталях, и результаты налицо, суди сам.
Какая же это копия плюсов? Классов у них, я так понял, нет. Можно структуры, но там полная опа с наследованием.
> Можно структуры, но там полная ООПа с наследованием.
Куда этому поделию до плюсов. Ты чего ? Тут вон итераторы к семнадцатому году подвезли, радуйся :D
жыр с монитора потек
Не хотят по две недели трахаться с зависимостями каждый раз, когда нужно собрать проект на другой машине. Серьёзно, хуже плюсового тулчейна с зависимостями не работает вообще никто. Где ещё при сборке абсолютно любого крупного проекта организуется такой геморрой буквально на ровном месте? Попробуйте собрать любой мало-мальски крупный плюсовой проект с временем сборки свыше 8 часов, скажем TensorFlow, и вы уже через пару дней начнёте разговаривать исключительно матом и искренне возненавидите эти плюсы с их вечным шаманством в попытках хоть что-то собрать.
Доходит уже до смешного, когда для сборки проекта поднимают docker или иную подобную хрень с определённым набором библиотек и инструментов внутри, потому что нигде больше оно не соберётся (и даже там ухитряется падать, никогда не собираясь с первого раза).
В этом плане Rust выглядит просто чем-то совершенно божественным, потому что блин оно просто берёт и собирается! Оно само подтягивает все зависимости, если чего-то нет, и ничего шаманить не надо. А в C++ тулчейне это уже которое десятилетие осилить не могут.
Уж молчу про кросс-компиляцию, где трахотня с зависимостями возводится в куб. Попробуйте, скажем, собрать OpenCV-проект под винду, сидя в Linux. Это миссия из разряда невыполнимых.
П.С.: На почётном втором месте по дерьмовости в плане работы с зависимостями у нас Python. Это почти такое же дерьмо, как C++, никогда и ничего не запускается с первого раза, для проектов сложнее HelloWorld вечно требуется часами шаманить, выясняя, что и в каком порядке разворачивать и куда каких симлинков напихать, чтоб завелось.
Как я понял комментарий выше, iLex прославляет аналог maven и npm под названием rust. О самом языке ни слова.Ну все как обычно - неосиляторы прославляют удачу по сборке своего хелловорлда.
А потом к ним подключаются другие неосиляторы, вместо того, чтобы вкладывать свои усилия в ваш проект.Невыгодно быть крутым программистом осилятором, с ними никто не хочет работать.
> П.С.: На почётном втором месте по дерьмовости в плане работы с зависимостями у нас Python. Это почти такое же дерьмо, как C++, никогда и ничего не запускается с первого раза, для проектов сложнее HelloWorld вечно требуется часами шаманить, выясняя, что и в каком порядке разворачивать и куда каких симлинков напихать, чтоб завелось."Плюсую". Не писал на Python-е ничего сложного на данный момент и против данного языка ничего не имею, как и за. Моя ситуация: На Linux-е устанавливал софт работающий с Python(из репозитариев), после этого перестал запускаться Terminator(Терминал который мне очень нравился и которым я постоянно пользовался). В итоге обновил Python, Обновил Terminator, попробовал поставить зависимости которые просит при запуске из терминала Terminator. В итоге он так и не запускается. Переехал на Kitty.
Забавный факт: в арчике пакет rust 1.50 весил 567мб, а 1.51 — 496мб. Доколе его вес будет так штормить?
Ставь rustup и не морочь мозги.Да и ты сравниваешь не размер package, а его разжатый вид:)
Размер package: 80мб.
Я же пользуюсь растом в разжатом виде. Зачем мне обращать внимание на размер архива? ¯\_(ツ)_/¯
clang + все зависимости не штормят?
Не знаю. Но gcc в порядке.
Предлагаю округлить до 1 ГиБ и искусственно поддерживать это значение чтобы анонимы не пугались шторма. Их укачивает.
По-твоему это совершенно нормально, что плагин к LLVM весит примерно столько же, сколько clang + llvm-libs + llvm?
Это наверное со всеми зависимостями и исходниками, а сам раст весит около 5Mb
До ff жрущего 600-800мб привыкли и до этого тоже привыкнут.
Не надо, палемун на системе с 512Мб на борту в три браузера по десятке вкладок шевелит только в путь.
600-800 - это много?
У тебя там 2 ГБ ОЗУ что ли?
// Раньше для перебора
for item in array.iter().copied() {// Теперь можно указать
for item in std::array::IntoIter::new(array) {Помоему язык развивается в противоположенную от упрощения сторону.
Норм
for item in array.iter().copied() {
for item in IntoIter::new(array) {
foreach (var item in array)
for (auto item : array)
{}просто, удобно надёжно и не нужно даже новый язык придумывать...
Почему злой и страшный С++ выглядит удобнее и понятнее Rust ?
к плюсам не из-за этого претензии
Сколько ни спрашивал, все либо затрудняются сформулировать претензии к C++, либо несут ахинею. С учётом последних нововведений, C++ рулит и педалит остальные ЯП почти во всех областях применения.
Нововведения убили плюсы
Недавно на хабре видел статью человека, который устал пытаться писать на C++ без UB. Я пытался писать без UB, устал и забил. Теперь с покерфейсом пишу код с UB, потому что так и не нашел куда спрыгнуть. Человек, который не увидит в следующей функции UB, за которое ОСь может прибивать программу, не должен допускаться до C++.size_t count_spaces(const std::string& str)
{
size_t ret = 0;
for (char c: str)
{
if (std::isspace(c))
++ret;
}
return ret;
}Спойлер UB есть в описании isspace на en.cppreference.com
Ну в принципе ожидаемо. Особенно на хабре, как раз тот уровень.
Называется: надо читать описания-то.
А поделитесь своими ощущениями от чтения стандарта по плюсам во время написания программы? Или вы даже из тех, кто помнит его наизусть, учитывая намек на разницу уровней? А то мой потолок - это стандарт чистых сей. При чтении плюсового, даже не всегда могу понять правильно ли понял прочитанное.
Читать стандарты надо, в общем-то, ДО написания программы. Простая аналогия: если ты словарь и грамматику китайского, скажем, языка начнешь читать только во время общения на оном, то много не наобщаешь, поверь.
А те, кто не видят проблем в C++, стандарт читали? Запомнить я его не смог, перечитывать каждый раз запарился. Где чудо богатыри, которые могут выйти и сказать: "Пишу на C++ без UB, проблем никаких". Я от стандарта плюсов даже 2003 года помню сильно меньше половины. В основном то, что с сями пересекается.
Ты правда считаешь, что это проблемы именно C++? Похоже, у меня для тебя плохие новости... )))
Достали шаблоны, многоэтажные конструкции с кучами двоеточий. Прешёл обратно на Си. Потому и не кусают. \(o_O)/
Шаблоны - прекрасная штука, если с умом готовить.
Особенно когда у тебя куча однотипных вещей для различных вложенных типов.
Это и на си можно делать. Точнее на gcc расширении c, которое сто лет поддерживают и шланг и тайниси.
Правда, на плюсах это красивее выглядит.Ну и да, под разные задачи разные инструменты, факт.
Возьмите MaNGOS, попробуйте разобрать код. Попутно прокачаетесь :)
А так-то без хендбука под рукой лезть в дебри языков вообще смысла нет. Любых.
Ну и бОльшую часть нужного надо запомнить прежде, чем начинать писать что-либо серьёзно.
А всё, что постоянного использования не имеет - в хендбуке.
UB - само по себе не плохо и не хорошо. Это не ошибка. UB - это когда определяет не стандарт, а реализация.Примерно тоже самое в нашей жизни: не всё определяется юридическими законами, а что-то просто здравым смыслом. Вы же не сетуете, что закон не расписывает вам подробно как срть в туалете, вам ведь хватает и здравого смысла ?
Конкретно в вашем примере, нужно просто прочитать документацию к isspace. Ещё можно почитать почему так сделано (что это даёт взамен)
Если вас печалит необходимость знать такие фишки языка (детали реализации), то посмотрите на это под другим углом: знание инструмента, который вы используете, повышает вашу квалификацию. А ваша квалификация это то, что не даёт бизнесу заменить вас дешёвой обезьянкой, работающей за еду.
Наличие языков с жёсткими ограничениями нужно, в первую очередь, бизнесу для снижения издержек. Для остальных жёсткие ограничения - это не столько невозможность ошибиться, сколько невозможность создать что-то быстрое, красивое или интересное.
Нет. Детали реализации это - unspecified behavior или implementation-defined behavior. Undefined behavior - это вот это вот:
Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
Вообще UB при кривом исходном вводе - это нормально, и существует даже вне ЯП - в железе, в приложениях в целом. Где-то ловишь exception или прерывание исключения, где-то срач в логи и терминацию, где-то - вывод, вполне соответствущий вводу, но никуда далее не годный. C'est la vie.И вообще Сначала мы загоняем в функцию, обрабатывающую данные как unsigned char, просто char, а потом удивляемся - ОЙ. А ЧОЭТООНО??!!!! БОЛЬНОЖЕ!!!
Это не оно, это руки. Изящно изогнутые.
А для кого приведен пример на том же cppreference?
int count_spaces(const std::string& s)
{
return std::count_if(s.begin(), s.end(),
[](unsigned char c){ return std::isspace(c); } // correct
);
}
Я привел пример для отсева абсолютно некомпетентных и пример того, что даже самая безобидная на вид функция может уронить программу. Плюсы - это минное поле, где ты примерно знаешь мины на участке где ходишь, при этом продолжаешь топтаться по нему каждый день. И знаешь, что вне участка полно мин, о которых не знаешь. Чтоб писать на плюсах надо 100% времени поддерживать 100% концентрацию. У меня вот есть проблема - не получается так.
"Трехколесный велосипед лучше мерседеса, потому что на нем вы никогда не въедете в столб на скорости 200 км/ч" Да, не въедете, потому что не разгонитесь до такой скорости. А так-то программисты обычно думают мозгом, когда пишут программы. Ну, как минимум некоторые )))
> А так-то программисты обычно думают мозгом, когда пишут программы.Вы можете часть своего рабочего времени искать уб при подсчёте пробелов (не факт, что вы найдёте проблему оперативно, вам может тупо не хватить везения).
Вы можете тратить то же время на разгребание тех-долга или выделение произвольной области на рабочем столе в прямоугольник с помощью мыши.
> Трехколесный велосипед лучше мерседеса
Вы явно перегнули палку в сравнении, можете за место мерседеса поставить метавелосипед, который каждый понедельник с вероятностью 0.09 пропадает на пол часа?
Это плохо. Если с концентрацией проблемы первым делом проверьте уровень кортизола и пейте витамины группы Б - при их дефиците у организма возникают проблемы с выработкой тормозящих нейромедиаторов. Наврятли вам Rust с этим поможет.Хотя, если чтение длинных исходников с причудливо запутанным синтаксисом вас успокаивает, то почему бы и нет...
Если концентрацию поддерживать "не получается" - лучше сразу сменить профессию.
> Я пытался писать без UB, устал и забил. Теперь с покерфейсом пишу код с UB, потому что так и не нашел куда спрыгнуть.Рекомендую прочитать статью MA Ertl'а "What every compiler writer should know about programmers". В ней, в частности, рассказывается, что исторически UB использовались для заточки под конкретный компилятор и систему. И, в общем, язык системный => написание "generic" кода, который системно независим, это выход за пределы области применения C.
К сожалению, это конфликтует с желанием компиляторщиков использовать UB для чего угодно. :-(
Спасибо за статью. Истоки UB я знаю и с рассуждениями по ходу статьи согласен. Когда я начинал программировать, я выделывался с оптимизациями. А теперь мне нужен способ написать код, который будет гарантированно одинаково работать под STM32, Linux(ARM и x64) и Windows(x86) независимо от компилятора. И я его не вижу. Обмазал всё тестами, включил предупреждения на почти максимум, прогнал через анализаторы, а гарантий то нет. Мне нравится идея раста, что если хочешь, пиши unsafe и выделывайся. Но сам он как-то не зашел.
Потому что unsigned char надо использовать. Вроде бы не такая сложная головоломка, чтоб прям "спрыгивать".
Это просто одна из мин, на которой я подорвался. Мне о ней лет 10 назад сказал MSVC с отладочным рантаймом, тогда я даже не задумался, что что-то не так если функция не модифицирующая строку роняет программу. Спрыгнуть хочу потому, что концентрацию теряю, ну не больше 10 раз в год. А после каждого такого случая минимум 3 дня: думаю как может происходит странная херня о которой сообщили, листаю коммиты, перечитываю исходники... Странная херня не обязана начать происходить сразу. Вот есть проект в котором больше 1МБ исходных кодов и ищи как хочешь, стрелять то может всё. Крайне боюсь, что когда-нибудь придется иметь дела с проектами больше 10МБ. Если знаешь, что не потянешь, лучше спрыгнуть.
Она реально роняет? Интересно бы в либе код посмотреть, как им это удаётся)
> Сколько ни спрашивал, все либо затрудняются сформулировать претензии к C++.У меня одно только - упоротые программисты, у которых в голове эхо войны и они не способны простейшую логику без десяти кешей, двадцати абстракций, и арифметики указателей написать. Еще обязательно чтобы полиморфно было
Полиморфные указатели на абстракции от структур :D
(всерьёз воспримется только теми, кто понимает, как оно внутри работает)
foreach ($arr as $key => $value)
{
}куда "красивее", пхпешники поддержат :)
Только у вас нарушение PSR-12 (секция 5.5), фигурная скобка в foreach должна быть на той же строке, что и закрывающая круглая скобка
> Только у вас нарушение PSR-12 (секция 5.5), фигурная скобка в foreach должна
> быть на той же строке, что и закрывающая круглая скобкав топку, когда после цикла идет длинная строка - не удобно читать, дело вкуса.
У меня часто складывается ощущение, что в написании PSR отчасти участвовали неадекваты.
Нет, там очень много здравого, чему стоит следовать.
Но вот эти MUST типа "There MUST NOT be more than one statement per line"
Ага, вот прямо сейчас разбежался 10-15 переменных для цикла инициализировать портянкой по пять букв в строчке.
То же самое со скобками. Здесь конечно лучше наверх вытащить. Но в ряде случаев действительно читабельнее, когда открывается на своей строке.
Потом открываешь какой-нибудь моднявый прожектик килобайт в 25 для вызова внешней утилиты с тремя параметрами в 5-10 классов, видишь там нечитабельное говно, сплошь состоящее из PSR, закрываешь, и пишешь один класс в три килобайта, делающий больше и правильнее, и куда осязаемее (за отсутствием необходимости помнить про те самые (5-10)-1 классов из 50 строчек, 3/4 из которых - скобки, отступы и комментарии), чем вот та самая портянка.
(причём качество тех же комментариев, записанных правда покороче, без лишних строк, у тебя получается не хуже, и даже аргументы описаны так же хорошо, просто ты уже не PSRаведник)
Поддерживаю.
PSR идут в задницу, но да, скобочку лучше таки утащить в первую строку.
Индекс нам там тоже в исходной задаче вроде не нужен.foreach ($array as $item) {
}
> скобочку лучше таки утащить в первую строку.в 135 коменте выше, однострочник и скобочку унесли почему-то вниз. Мне в принципе без разницы, дело вкуса, а если дело доходит до разбирания чужого кода, то для начала его отформатирую под свои стандарты, а потом уже сяду читать и выяснять что и как работает. Но это все относится к стороннему коду, конечно это потеря времени если ты в команде и каждый пишет по своему, тут уже должен быть стандарт какой-то. А на изучение стороннего кода ты в любом случае должен потратить время.
Согласен, дело вкуса. Кроме вкуса ещё есть дело читабельности.
Я например легко читаю почти весь код, даже откровенный говнокод - кроме кода, написанного строго по PSR... :D Возможно потому, что нынешние мониторы широки вширь, но узки ввысь, и листать километровую портянку задалбывает.
А вообще чессгря с годами всё больше уверенности, что PHP занимаются практики, а не теоретики.Даже на этом примере. Очевидное foreach. Обычное для C-подобных языков открытие блока кода. Все переменные сразу видны - с ключевыми словами не спутаешь никак. as в нужном месте, сразу понятно, кто есть кто. Ну и $key => $value, учитывая, что значения хешей к ключам именно через => объявляются, тоже вполне логично.
То жеfor item in IntoIter::new(array)
ШТО ЭТО, БЛ***???
IntoIter - это класс какой-то? Статический вызов new - ну, тут вроде понятно.
А array что такое? Ключевое слово именования типа? То есть IntoIter::new принимает имя типа на входе?
БРРРГГГ...
std::array::IntoIter::new(array) же - это вообще лютый Ц
Уже давно можно писать "for item in &array".
// Раньше для перебора
for item in array.iter().copied() {// Теперь можно указать
for item in array.iter().copied() {
ИЛИ
for item in std::array::IntoIter::new(array) {Поправил, не благодари.
Я одного только не пойму - вы эти бредовые заклинания "std::array::IntoIter::new" наизусть вызубрили все стопиццоттыщ, или каждый раз гуглите когда надо просто перебрать массив?(нет, array.iter().copied() ничем не лучше, разумеется)
Просто кури https://doc.rust-lang.org/std/index.html
> Просто куриЧто ещё можно ждать от растаманов...
Спасибо, я лучше пока так, на травке посижу.
А мне кажется синтаксическим бредом С++, дальше что? Мне срать язык, потому что не нравится синтаксис?
Как тема про раст, так сразу дискуссии о нужности, полезности и тщетности бытия.
for i in array {
// ...
}
> Помоему язык развивается в противоположенную от упрощения сторону.Не, тут пример показывает не простоту, а возможность. into_iter реально не хватало для array, потому что если хочется сделать что-то типа:
...
.map(|arr| arr.into_iter())
.flatten()
.collect();
То это нифига не работало, поскольку arr никак в into_iter, а arr.iter() -- это итератор, который ссылается на arr, и если arr прекращает существовать, то ссылка оказывается висящей. Здесь же, arr существует только внутри замыкания передающегося в map, и собственно фишка в том, чтобы итератор пожил подольше, чтобы все эти итераторы можно было бы flatten в один единый итератор по всем элементам, чтобы потом сделать collect.
Охренеть какие сложности просто для того, чтобы обработать массив.Сразу возникает вопрос - а почему не сделать было сразу нормальную итерацию по массивам? Почему надо навешивать очередную заплатку поверху?
Впрочем, вопрос риторический.
> Сразу возникает вопрос - а почему не сделать было сразу нормальную итерацию
> по массивам? Почему надо навешивать очередную заплатку поверху?Это безопасность. Если в коде выше заменить into_iter() на iter(), то borrow-checker пошлёт тебя куда подальше, потому как итератор содержит в себе ссылку на локальный массив лежащей в переменной-аргументе arr, но после выхода из лямбды локальный массив перестанет существовать, и получается, что пытаясь сделать такое, ты пытался вернуть указатель на локальную переменную.
Вот тут оказывается полезным into_iter, который не просто так итератор по внешнему по отношению к нему массиву, а итератор который владеет массивом, по которому он итерирует. То есть этот массив будет существовать столько, сколько существует итератор.
А все потому что в новости не удосужились нормально объяснить.
> А все потому что в новости не удосужились нормально объяснить.Мне нормально. А тем, кто не понимает, зачем это надо, явно это не надо. Ну, реально, я понял с первого взгляда в чём фишка благодаря тому, что я как-то пытался отрисовать палитрованое изображение, заменяя номера цветов на цвет из палитры, добавляя к нему alpha компоненту, и впоролся в то, что когда я итератор по номерам цветов из палитры превращаю в итератор по rgba четвёркам, я потом не могу из этого итератора по [u8; 4] сделать итератор по итераторам по [u8; 4]. Надо было либо писать что-то типа IntoIter для [u8; 4], либо закапывать функциональщину и переписывать императивно. Кстати императивно лучше вышло, потому что таким образом я смог предвыделить память сразу под все четвёрки rgba. Но не так идеоматично.
... когда я итератор по номерам цветов из палитры превращаю в итератор по rgba четвёркам, я потом не могу из этого итератора по [u8; 4] сделать итератор по итераторам по [u8; 4] ...На этом месте стоило перестать курить раст, взять C, и сделать всё по-человечески, без итераторов.
(я охренел только от одного описания процесса, на код кмк там лучше даже не смотреть уже)
Для тех, кому ненужен низкоуровневый доступ, есть Go.Для чего форсят это ржавое убожество, мне совершенно непонятно.
Просто ты упоротый технарь и совсем не понимаешь, что в айти решает бабло, а не технологии.
А ты, я смотрю, философ.
про технаря ты погорячился
go и технарь в 1 предложении? молодежь совсем оборзела.
гугель и go - это не бабло, а мозила и раст - это бабло? яснопонятно.
>go и технарь в 1 предложении?Я на этом на пишу, если что.
Зачем сборщик мусора на уровне низком уровне?
Go и системщина не очень совместимы)
А с чем оно вообще совместимо ? С сотней гигов памяти ?
Вот как раз нет. За счет внутренней многопоточности, которая быстрее системной и экономнее и делается одним оператором. Потому и на серваки ставят, чтобы кушало меньше в десятки тысяч потоков.
А ну да, корутины же только в го есть
А зачем он вообще нужен? На нем ведь только микросервисы делают, да простые консольные утилитки
Если Rust и Go лучшие языки программирования, почему Firefox и Chrome сделаны на c++?
Из первого С++ уже выпиливают, из второго - планируют
Нужно будет запланировать докупить оперативочки.
Бхахахахах. Пока что выпилили сам раст, на мороз.
Вот Столлмана выпиливают из фонда СПО ... Если что-то откуда-то выпиливают, это, не факт, что к добру.
> Из первого С++ уже выпиливают, из второго - планируютНет, и в мыслях ни у кого небыло и не будет.
> Из первого С++ уже выпиливают, из второго - планируютУ тебя опять памяти не хватило или раст рухнул?
Падать твоё гавно уже перетало? Утечки починили?
Эка технология совершенной работы с памятью. Не могут правильно определить её размер, но усех учат как надо.
Эпик фейл года, падает не прога криво написанная на языке, а падает сам язык. Вер безопасности.
>> в коде аналог сишного
>> fprintf(stderr,"что-то пошло совсем не так! капец!"); exit(1);
> Эпик фейл года, падает не прога криво написанная на языке, а падает
> сам язык.Эпик обсер года от очередного "Ыксперта".
>>> в коде аналог сишного
>>> fprintf(stderr,"что-то пошло совсем не так! капец!"); exit(1);
>> Эпик фейл года, падает не прога криво написанная на языке, а падает
>> сам язык.
> Эпик обсер года от очередного "Ыксперта".Обделался :D fprintf не упал, exit не упал. Хаааа. Rustтун ыкпыртызыт си оборжатся.
>>>> в коде аналог сишного
>>>> fprintf(stderr,"что-то пошло совсем не так! капец!"); exit(1);
>>> Эпик фейл года, падает не прога криво написанная на языке, а падает
>>> сам язык.
>> Эпик обсер года от очередного "Ыксперта".
> Обделался :D fprintf не упал, exit не упал. Хаааа. Rustтун ыкпыртызыт си
> оборжатся.Ой, в слове "ыкпыртызыт" пропустилось "с". Должно быть "ыкcпыртызыт" - это раст с памятью поработал.
>>>> panic!("OOB");
>>>> Macro std::panic
>>>> This allows a program to terminate immediately and provide feedback to the caller of the program. panic! should be used when a program reaches an unrecoverable state.
>>>> в коде аналог сишного
>>>> fprintf(stderr,"что-то пошло совсем не так! капец!"); exit(1);
> Обделался :D fprintf не упал, exit не упал. Хаааа. Rustтун ыкпыртызыт си
> оборжатся.Сам написал бессмылицу, сам ее оспорил. Ыксперд, че.
Там выше объяснили, что чтобы не падало, надо новую заплатку на язык повесить. точнее ее как раз привесили. А сколько еще всего надо сделать... ммм... не описать.--cut--
into_iter реально не хватало для array, потому что если хочется сделать что-то типа:.map(|arr| arr.into_iter())
.flatten()
.collect()
То это нифига не работало, поскольку arr никак в into_iter, а arr.iter() -- это итератор, который ссылается на arr, и если arr прекращает существовать, то ссылка оказывается висящей. Здесь же, arr существует только внутри замыкания передающегося в map, и собственно фишка в том, чтобы итератор пожил подольше, чтобы все эти итераторы можно было бы flatten в один единый итератор по всем элементам, чтобы потом сделать collect.
--cut--Я, как старый лиспер и функциональщик до мозга костей, в полном ах_е.
> Я, как старый лиспер и функциональщик до мозга костей, в полном ах_е.Ах, вот оно что, лиспер? Ну дык в лиспе у тебя сборка мусора, там не надо следить за временем жизни объектов, потому что gc за тебя последит. В таких языках как C/C++/Rust это так не работает.
> Из второго Rust уже выпиливают, в первом - не планируют внедрять.Поправил. Не благодари.
Почему же? Все новости об обратном говорят.
> Если Rust и Go лучшие языки программирования, почему Firefox и Chrome сделаны на c++?Если C++ такой крутой ЯП, то почему OpenNet на Perl?
Потому что перл лучше с++. А ты не знал?
Perl отличный язык и не менее крут чем С++. А после того, как все гвнкдры свалили с него в PHP, так вообще сказка
> Perl отличный язык и не менее крут чем С++. А после того,
> как все гвнкдры свалили с него в PHP, так вообще сказкаИстина
А UTF лучше КОИ8?
Хуже. Имя файла в два раза короче.
С чего бы это, если оно латиницей и цифрами?
Ну и да, запиши мне な в KOI8.
> な в KOI8ISO 3602: "na"
"na" - это то, куда с такой записью стоит пройти.
Потому что opennet желтый) и духом из 90х))
вспомнию с ностальгией инет 90х - дружелюбие и все-просто-работает. Без поганого Жабоскрипта кек
> Если C++ такой крутой ЯПКрутая кривая познания? )
> почему OpenNet на Perl?
Потому что, очевидно, автор его знал.
Потому что уже сделаны
Осмелюсь предположить, что эти браузеры появились раньше, чем rust и go.
Сейчас налетят растохейтеры
Даёшь Rust++ с обобщёнными асинхронными абстрактными шаблонами полиморфных классов!
Растаманы ещё через 15 лет обнаружат, что сделали ещё один С++
ну и пусть, один раз живём. И пока язык на начальной стадии, работать с ним в удовольствие
> один раз живёмЭто тебе кто сказал?
> язык на начальной стадии
Ага, начальная стадия тянется с 2006-го года.
> Ага, начальная стадия тянется с 2006-го года.На википедии написано, что язык появился 7 июля 2010 года.
Если перейти по сноске, то там вот такое письмо https://mail.mozilla.org/pipermail/rust-dev/2010-July/000001...
> 2010Вы уж определитесь, то говорите, что в 2015, то в 2010. Но разработка начата, почему-то, в 2006-ом.
> Вы уж определитесь, то говорите, что в 2015, то в 2010. Но разработка начата, почему-то, в 2006-ом.Считайте как как вам выгодно. Для утверждения, что "языку уже 15 лет, и он нинужен" 2006 год подходит отлично.
>На википедии написано, что язык появился 7 июля 2010 года.Rust (programming language) - Wikipedia
https://en.wikipedia.org › wiki › Rust_(programming_l...
History — The language grew out of a personal project begun in 2006 by Mozilla employee Graydon Hoare, who stated that the project was possibly named after the rust family of fungi. Mozilla began sponsoring the project in 2009 and announced it in 2010.
> Ага, начальная стадия тянется с 2006-го года.Кстати, с другой стороны, если за 15 лет (по вашему мнению) из языка не сделали монстра - то, думаю, уже и не сделают
Очередные заплатки к очередным граблям.Вангую появление нового языка "новыйязык", который вырастет на трупе раста и, учтя все его проявившиеся грабли, возможно, действительно станет заменой монструозному с++.
Вот почему бы расту не сделать было так? Почему бы не изучить ошибки D, например? Нет, они сваяли на коленке какую-то поделочку и теперь с завидной ослиной упорностью обвешивают ее очередными заплатками.
> Стабилизированы макосы "ptr::addr_of!" и "ptr::addr_of_mut!", позволяющие создавать raw-указатели для невыровненных полей.
Не прошло и, сколько, 14 лет для полноценной имплементации такой базовейшей вещи?
Кстати, растаманы. А не подскажете зачем макросы выделять отдельно от функций значком "!"? Какая в этом практическая польза, помнить что макрос а что нет? А то у меня только один вред в голове возникает - кроме названия метода почему-то обязательно запоминать макрос он или нет.
Тогда когда язык сам ничего не позволяет приходится пихать в него все возможные API и макросы чтобы хоть что-то на нем писать.
> Какая в этом практическая польза, помнить что макрос а что нет?да
А зачем ?
Чтобы "Life of people who have no F12 (Go to definition) key matters!"
> Чтобы "Life of people who have no F12 (Go to definition) key matters!"Не нашёл статьи с таким названием. Или зачем вы в кавычках и по английски написали?
Чтобы вам было менее понятно читать ответ - напишу на украинском:
Для налагодження метапрограмирування програміст використовує метабрейкпоінти. (представляєт, що поставiв брейкпоінт)
А программiруете вы, наверное, тоже на украiнском ) Мне даже страшно представить ваш аналог 1С /(o_o)\Но вообще глубокая суть сего псевдоцитирования в пародировании BLM, котрого на Руси и в помине не было. И вот пусть оно там, в англоязычной среде, и останется.
> учтя все его проявившиеся грабли, возможно, действительно станет заменой монструозному с++Гугли про механизм редакций Rust. Язык спроектирован так, что может позволять себе удалять устаревшие и плохо спроектированные фичи без потери обратной совместимости. Так что для того, чтобы становиться качественно лучше, не нужно создавать новый язык. На месте авторов стандарта плюсов, я бы перенял практику редакций, пока не стало слишком поздно.
> Кстати, растаманы. А не подскажете зачем макросы выделять отдельно от функций значком "!"? Какая в этом практическая польза, помнить что макрос а что нет? А то у меня только один вред в голове возникает - кроме названия метода почему-то обязательно запоминать макрос он или нет.
Гугли про гигиеничность макросов. У Rust гигиеничные макросы, в отличие от C или C++. Восклицательный знак не имеет прямого отношения к гигиеничности, но это просто часть здоровой взрослой практики: отделять вызов макроса от вызова функции, потому что семантически это разные вещи, а если выдавать одно за другое, это может приводить к неверной интерпретации кода программистом.
> Язык спроектирован так, что может позволять себе удалять устаревшие и плохо спроектированные фичи без потери обратной совместимости.То-есть я могу свободно собрать и запустить код десятилетней давности? Ню-ню.
> Гугли про гигиеничность макросов. У Rust гигиеничные макросы, в отличие от C или C++. Восклицательный знак не имеет прямого отношения к гигиеничности
Зачем гуглить гигиеничность, если гигиеничность к расту отношения не имеет? В свою очередь предлагаю погуглить то же самое по отношению к древней-предревней scheme. Вот там "!" действительно очень важен в контексте кода.
> но это просто часть здоровой взрослой практики: отделять вызов макроса от вызова функции, потому что семантически это разные вещиЧто-что семантически разные вещи? write и writeln! - семантически разные вещи? Муа-ха-ха-ха-ха-ха-ха!
> а если выдавать одно за другое, это может приводить к неверной интерпретации кода программистом.Чем write отличается от writeln!, что без восклицательного знака ты как программист неверно проинтерпретируешь код? Ничем.
В scheme, на которую я выше кивал, это действительно важно. Потому что в первую очередь язык функциональный и поощряет функциональное программирование где, на секунду, чистота функций очень важна. Потому что чистые функции можно вычислять в любом порядке и любым количеством, а нечистые - нельзя. Поэтому в схеме set! с восклицательным знаком (чтобы не забывали), а let - без.
> гигиеничность к расту отношения не имеетЛол, окей. Мне че-то лень с тобой спорить. На самом деле не первый раз пересекаемся и я уже знаю, каких надменных софизмов от тебя ждать, так что сэкономлю свое время на этот раз. Ты задал вопрос, я ответил - дальше делай с этой инфой и относись к ней что хочешь, все свободные люди.
Слив, как говорится, засчитан.Смею предположить, что из-за этого вот моего вопроса:
>> это просто часть здоровой взрослой практики: отделять вызов макроса от вызова функции, потому что семантически это разные вещи
> write и writeln! - семантически разные вещи?
Умнее слиться в споре, где побеждают не аргументами и здравым смыслом, а напором и аппеляцией к одобрению большинства местной аудитории :)А вопрос я проигнорил, потому что он непонятен. В-первых, неточен. Под write понимается std::io::Write::write или может std::fs::write? В любом случае, если ты имел в виду какую-то фнкцию, то да, это совершенно разные вещи, потому что, макрос и функция - это разные вещи (внезапно).
Хм, непонятен вопрос "чем write и writeln! семантически разные вещи?".
Ну ок.> Под write понимается std::io::Write::write или может std::fs::write...?
Совершенно без разницы, потому что _семантически_ эти функции ничем не отличаются.
Разговор шел и идет о том, что в расте была введена (и до сих пор используется) бессмысленная и, по большому счету, вредная сущность "!", как обозначение макросов.
Семантически, макросы ничем, никогда и никак не отличаются от функций. Макросы и функции - это одно и то же. Есть аргументы на вход, есть некое действие, есть результат на выход. В середине черный ящик.
Программист программирует с помощью языка, а не для языка. Идеальный язык программирования вообще позволяет писать человеческим языком что программисту надо и переводит его слова в последовательность команд процессору.
Так было во времена лиспа, так осталось в современные времена.
В языке С++ реализация правильная. Модификатор constexpr превращает функцию в макрос без каких-либо переделок, потому что это одно и то же (при условии, конечно же, что компилятор с этим может справиться).
В языке С это вообще не сделано. Причина простая - С достаточно низкоуровневой язык с возможностью тонкой оптимизации кода. Программисту приходится думать, что он вычисляет в рантайме, а что на этапе компиляции.
Решение об этом принимает сам программист - если он считает, что не важно когда и как вычисляется функция, то он ее пишет как обычно. И в стандартных хидерах С таких примеров - масса.В расте решили разницу прибить гвоздями. Не знаю, чем при этом руководствовались авторы - боюсь, что ничем.
Характерный пример: write - печать, writeln! - печать с переводом строки. Программисту надо знать только одно - что эти функции делают, ему не надо знать как эта функция реализована в библиотеке - макросом, функцией, на ассемблере или через виртуальную машину. Ему надо только знать что эта функция делает и настолько эффективно.
Если бы, повторяю, если бы функция write была чистой функцией, а функция writeln ею не была, тогда с целью облегчения жизни функциональщику стоило бы ее как-то выделять. И никаких претензий к этому бы не было.
Почему я к этому придрался? Потому, что это одна из многих вещей, которая делает раст плохим языком и я с удовольствием обращаю на это внимание. Глядишь, меньше будет .овноязыков, качественнее софт и легче наша будущая жизнь.
>Разговор шел и идет о том, что в расте была введена (и до сих пор используется) бессмысленная и#define TRUE FALSE //счастливой отладки
> Потому, что это одна из многих вещей, которая делает раст плохим языкомне для вас его роза цвела, поймите уже
Если для вас макросы и функции это одно и то же, то может расскажете как в том же C++ или C сделать именно функцию, которая вызывалась бы похожим образом:lisp!(
defun is_whitespace ((b u8)) bool
(match b
(0x20 | 0x09 | 0x85 | 0x0a | 0x0b | 0x0c | 0x0d => (true))
(_ => (false) ))
);Это пример использования Rust-макроса для lisp-like DSL.
writeln! - это совсем не функция и в принципе не сможет в Rust стать функцией ни какими constexpr. Просто потому, что в Rust функции не могут принимать переменное число аргументов. А макросы могут "эмулировать" передачу переменного числа аргументов. Что собственно и делается в writeln!, и что отличает её от абстрактной функции write.
Макросы в Rust - это инструмент для генерации кода, и не обязательно, что полученный код будет эквивалентен вызову аналогичной функции. Например макрос сможет сгенерировать код с описанием структуры, функции или чего-то ещё.
А ещё от функции можно получить ссылку, а от макроса - нельзя.
И с макросами в Rust даже не обязательно использовать именно круглые скобки для передачи "аргументов" - можно фигурные или квадратные (например vec![0; 10] - вот как тут убрать восклицательный знак?).
Не кажется ли вам, что как-то многовато уже отличий между макросами и функциями, что бы за уши притягивать их к единому формату использования?
Вы не понимаете, что значит "семантически"? А что такое "алгоритмизация" знаете?То, что вы написали никакого отношения к программированию не имеет. Зато имеет отношение к трансляции - переводу из одного представления (например, на языке rust) в другое (например, на языке asm).
Только вот в чем засада - трансляцией уже более 40 лет занимаются трансляторы(компиляторы), причем очень успешно. Это не работа человека. Это, в данном случае, работа компилятора rust.
А работа человека - перевести задачу в алгоритм. И хороший программист от гоbнoкодера отличается тем, что он умеет переводить задачу в алгоритм, а не умеет только транслировать ее из записи на одном языке программирования в другой.
--
Так вот, возвращаясь к тому, что написали вы. Ваш комментарий никакого отношения к понятиям "функция" не имеет. Он имеет отношение к понятию "трансляции языковых единиц rust под условным названием "function" и "macro" в низкоуровневое представление". В лиспе, между прочим, различия между макросами и функциями не вводятся, не так ли?Рекомендую почитать курс MIT sicp (pdf на русском - https://newstar.rinet.ru/~goga/sicp/sicp.pdf). Осилив книгу вы сможете вполне спокойно писать на более чем 300 (трехстах) из существующих языков программирования (приблизительный список с примерами можно глянуть здесь: http://rosettacode.org/wiki/Hello_world/Text).
> Чем write отличается от writeln!write это функция, а writeln! это макрос.
> А не подскажете зачем макросы выделять отдельно от функций значком "!"? Какая в этом практическая польза, помнить что макрос а что нет?Потому что макросы принимают аргументами кастомный синтаксис, и творят с ним магию кодгена.
Полезнее сразу видеть, где в коде творится магия (макросы очень мощная штука)
> Потому что макросы принимают аргументами кастомный синтаксис, и творят с ним магию
> кодгена.
> Полезнее сразу видеть, где в коде творится магия (макросы очень мощная штука)Полезнее названия методов/макросов писать так, чтобы сразу было понятно что они делают, а не где внутрях происходит "магия".
Рекомендую почитать "Совершенный код" Макконела. Очень рекомендую.
https://ru.pdfdrive.com/%D0%A1%D0%BE...
Не знаток Rust, но учитывая его работу с памятью, предположу, что макросы и функции просто обязаны прямо отличаться.
Функция определяет новую область видимости, нужно специально следить за владением передаваемых и возвращаемых параметров. Макрос просто подставляет код макроса в текущую область видимости не влияя на владение. Плюс возможности макросов шире чем у функций.
Из приведенного примера с writeln вопрос почему это макрос, видимо в том, что в коде он автоматом преобразуется в два вызова write или один с добавлением к аргументу \n, а не обертки функции перекладывающие значения по стеку туда и обратно.
> Функция определяет новую область видимости, нужно специально следить за владением передаваемых
> и возвращаемых параметров. Макрос просто подставляет код макроса в текущую область
> видимости не влияя на владение.
> Из приведенного примера с writeln вопрос почему это макрос, видимо в том,
> что в коде он автоматом преобразуется в два вызова write...Другими словами "макрос не влияя на владение параметров преобразуется в два вызова влияющих на владение параметров функций". Таким образом прямо противореча задекларированному.
Как видите, вы ошиблись. Это не так.
Макрос не влияет, но код к которому он в итоге приводит вполне может.
Не вижу тут противоречия. Сама логика его использования это подразумевает.
Главное что он не маскируется в какую-то самостоятельную функцию, которой на самом деле там и нет вовсе.
Для системного программирования думаю это очень хорошая практика. Тем более в доке видел макросы вида sql!(select * from TABLE1), тут уж явно не функция.
В остальном вопрос сводится к выбору подходящего имени самого макроса.
Так можно назвать макрос readln, а вызывать в нем write. Это запутывает, но к самой системе макросов это отношения не имеет.
(facepalm)
>(facepalm)Ну это зря)
Если копнуть вопрос поглубже.
Единый синтаксис вызова функций и макросов, хотите поговорить об этом?
Является ли это подавленным ощущением ущербности системы функций в языке? Или может это желание насолить компилятору, который своей излишней опекой не хочет инлайнить нашу функцию? А может результат реакции на травму после случайно подсмотренных где-то аннотаций, декораторов и всяких аспектов?
Стоит также рассмотреть и как симптом неприятия естественных функций (builtin) и подсознательное желание переопределить их. Я уже не говорю, о таких щекотливых темах как скрытая любовь к уточкам и вообще к утиной типизации при передаче аргументов.Как видите не самая радужная клиническая картина...)
> Полезнее названия методов/макросов писать так, чтобы сразу было понятно что они делают,
> а не где внутрях происходит "магия".Не вижу ничего взаимоисключающего в этих двух вещах.
> Полезнее названия методов/макросов писать так, чтобы сразу было понятно что они делают, а не где внутрях происходит "магия".Дык их и пишут так. Что-то в слове println! тебе не ясно? Но println! при этом, в compile-time'е разбирает форматную строку, чтобы сгенерить нужную последовательность вызовов для вывода, плюс принимает переменное количество аргументов, что функциям недоступно. Сие есть магия, об этом следует помнить. Скажем, функция может заинлайниться или незаинлайнится, и как правило можно полагаться на то, что компилятор сделает как лучше. println! же нагенерит кода, который будет "заинлайнен" в любом случае, будет ли он занимать пять байт, килобайт или мегабайт.
Макрос всегда ведёт себя странно, не так как функция, потому что если бы можно было сделать его функцией, его бы сделали функцией. И да, как-то так выходит, что специальная подсветка для макросов очень показательна, всякие такие штуки как assert!, panic!, println!, и тп полезно видеть в коде сразу.
Я думал джаваскриптеку совсем прибитые своим языком. Но вы мне открываете новые горизонты.
> Я думал джаваскриптеку совсем прибитые своим языком. Но вы мне открываете новые
> горизонты.Завсегда пожалуйста.
> sicp
> Code completeКогда стало нормальным тыкать людей в то, что сам не удосужился хотя бы открыть?
Судя по комментариям, Урри-таки хаскелист, увидевший картиночку с xkcd и пописавший пару строчек на lisp. А судя по выводам, то не факт, что даже до хотя бы HelloWorld дошло.
> Не прошло и, сколько, 14 лет для полноценной имплементации такой базовейшей вещи?Базовейшей? Подавляющее большинство экспертов опеннета компилируемые языки и не видели никогда, а уж "указатель к невыровненному полю" я даже и не знаю когда может понадобиться использовать.
Подажжи, ведь раст замена с++. А значит раст оперирует с указателями. А указатели всегда могут быть не выравнены.Получается, раст не замена плюсам. Раст замена, ну я не знаю, джаваскрипту?
А кто сказал что этого нельзя было делать раньше? Открываем ту же ссылочку по add_of! и читаем.> Create a const raw pointer to a place, without creating an intermediate reference.
То есть это можно было делать и раньше, но через промежуточную ссылку. А теперь можно делать напрямую.
А раст как раз и создавали для того, чтобы не оперировать указателями. Указатели обычно нужны для граничных случаев типа лазания через ffi.
Фигня какая-то получается....Раст создавали для того, чтобы не было указателей, но указатели в нем есть; однако с указателями работать нормально нельзя, надо это делать через промежуточные вызовы, поэтому мы теперь, через 14 лет, делаем наконец прямой вызов...
Извини, но реально звучит как бред какой-то. Точнее как полуосмысленное бегание "а что бы такого еще запилить".
Есть уже что-то типо Django на Rust?
Лол язык не для этого он чтобы хвасаться, а не работать.
Ждём примеров на C и С++
Прикола ради - ты хоть пытался искать ? Этого г-на на самом деле хоть отбавляй.
Искать для растофанатика, ты что матюгнулся так? Настоящие растофанатики не в состоянии заняться поиском в силу умственных способностей.
actix-web
rocket
Нет. Есть actix, hyper, ntex но они по уровню абстракции как golang примерно.
Есть какой-нибудь софт на расте?
Нету, совсем, от слова ващщщще.
Смотрите наhttps://github.com/rust-unofficial/awesome-rust
Там в основном библиотеки, но оттуда можно по гитхабам походить и посмотреть, что на расте написано
Глянул - калькуляторы, враперы к Си либам, vim-клоны и прочее дерьмо.
Болезный сам перейди по своей ссылке и посмотри что это за софтины. Это нелепая показуха для хомячков. В MeeGo раньше таже каждую читалку рсс ленты одного сайта называли приложением и говорили: «Смотрите сколько у нас много приложений! Для каждого сайта своё!»
Вот ещеhttps://rust.libhunt.com/categories/1496-applications-writte...
> actix-web
> Firecracker
> нелепая показуха для хомячковНу-да, ну-да, посмотреть ты-таки не удосужился.
> Смотрите на
> https://github.com/rust-unofficial/awesome-rustРебята постарались, каждый хелловорлд проиндексировали.
Но в любом случае спасибо, интересно.
> actix
> FireCracker
> ...Если для Вас это
> хелловорлд
то что же Вы разрабатываете? Вселенную?
https://xkcd.com/224/
> https://github.com/rust-unofficial/awesome-rustреально список бесполезного и ненужного и даже нерабочего чего-то, софтом это не назвать. и это нам навязывается как некое светлое будущее ? нет уж спасибо
А забавно какой-то растафанатик пробежался по всем этим абсолютно правдивым комментариям. Подгорает, видимо, не слабо.
> А забавно какой-то растафанатик пробежался по всем этим абсолютно правдивым комментариям.растафанатик это такой человек, который забивает своими ненавистными комментариями новость про язык, который ему не интересен? Вы как персонаж фильма красота по американски, который был гомофобом, а под конец полез к мужику целоваться.
> Подгорает, видимо, не слабо.
Нет, не подгорает. Наоборот, если не злиться, то относишься к таким фанатикам как вы с долей жалости. Вот что-то же двигает вас брызгать в разные стороны желчью, согласитесь? А от того, что вы повторяете одни и те же ложные тезисы, уважения к вам не прибавляется.
Не являюсь растафанатиком или еще каким-либо фанатиком. Имхо, фанатизм - это трата энергии с низким КПД. Но это имхо, ибо суть ПД зависит от ситуации, т.е. зависит от поставленной цели. Я больше за поиск истины (особенно на фоне сегодняшнего мира с фейками/враньем/псевдо-сми/etc) - с этой целью хочется поделиться личным опытом. Бегло вспомнил парочку программ на Rust, что в моей личной практике используется: ripgrep (localhost) и linkerd (24/7 production). Не могу сказать, что это бесполезный софт или софт ради демонстрации возможностей языка. Мне то и язык, на котором написан этот софт, особо не важен - главное, что свою функцию выполняет.
Очень много консольных утилит: ripgrep, bat, fd и т.д.Большого софта с нуля на расте пока нет, но большой софт вообще редко появляется с нуля в наше время - чаще Rust встраивают в существующую кодовую базу. Компоненты на Rust есть в Firefox, Brave, Discord (как на клиенте, так и на сервере), VSCode и множестве другого софта. Значительная часть гугловой операционной системы Fuchsia написана на расте.
Плюс многие новые сервисы конторами, вроде Amazon, Cloudflare, Google и т.д., пишутся на расте.
>> Значительная часть гугловой операционной системы Fuchsia написана на расте.Вот откуда вы берете весь этот бред. Еще и «значительная» часть. Кто-то завендорил несколько библиотек и их зависимости не больше.
https://www.reddit.com/r/rust/comments/k9r3s4/fuchsia_lines_.../Нормально так вендорят. И какая, к слову разница, завендореный это код или написанный гуглом? Это то же самое, как если бы эту часть ОС просто написал подрядчик, а не гугл. А сишный и плюсовый код гугл, по-твоему, не вендорит? Нелепый аргумент.
Там автор сразу исправился, выкинув совершенно лишние сердпати депенденси. Картина сразу стала не такой радужной.
Можно тогда и само микроядро на плюсах выкинуть и расчетов - его тоже не гугл написал :)
Ну как же нет большого софта)Возьмём криптовалюты - Polkadot, Kusama, прочие - все написаны на Rust, на фреймворке https://github.com/paritytech/substrate/
Я открыл глянуть в код.
--cut--
pub struct LightStorage<Block: BlockT> {
db: Arc<dyn Database<DbHash>>,
meta: RwLock<Meta<NumberFor<Block>, Block::Hash>>,
cache: Arc<DbCacheSync<Block>>,
header_metadata_cache: Arc<HeaderMetadataCache<Block>>,#[cfg(not(target_os = "unknown"))]
io_stats: FrozenForDuration<kvdb::IoStats>,
}
...
fn number(&self, hash: Block::Hash) -> ClientResult<Option<NumberFor<Block>>> {
if let Some(lookup_key) = block_id_to_lookup_key::<Block>(&*self.db, columns::KEY_LOOKUP, BlockId::Hash(hash))? {
let number = utils::lookup_key_to_number(&lookup_key)?;
Ok(Some(number))
} else {
Ok(None)
}
}--cut--
И эти люди хейтят с++. Хых.
Немудрено, что растаманы путают > и <=
> Я открыл глянуть в код.Вот теперь я не боюсь попробовать лисп.
Лисп - божественный язык.
Берём пример плохо написанного кода и делаем выводы о языке. Уровень: опеннетовский эксперт.
Я помню, как мне нахваливали этот рип, типа, вау! На деле же, кривая поделка с неудобным синтаксисом, крашится через раз, на нжмд пытается читать в несколько потоков и что логично в результате этого результат выдаёт в сотни раз медленнее однопоточного гну греп. Хотя сам по себе то греп не слишком сложный при этом, но и тут не осилили. Пусть лучше остаётся для вебни -- там вполне стоит заменить го и жс, а нормальное программирование уж оставят для нормальных программистов на нормальных языках.
Что вам плохого веб программисты сделали ? Не надо этого в веб.
Все лучше чем джаваскрипт. Даже раст.
Я почитал новые комменты и теперь уже в этом не уверен.
Если читать все комментарии на этом ресурсе, можно потерять веру в разумность человечества. К счастью, это будет не репрезентативная выборка.
Разработчики чтобы показать хоть какие-то улучшения в языке следующиую версию выпустят 152.
Ну да, ведь намного лучше несколько лет толочь воду в ступе, а потом выкатить огромный релиз, срывающий шаблоны, с крутой кривой обучения, и таким образом разделить сообщество на консерваторов, которые сидят на говне мамонта, и хипстеров, которые тут же бросят старый код и понесутся писать новый, с пасьянсом и надувными женщинами. Куда там этим идиотам, ничего не знают о разработке ЯП, надо было на Опеннете спрашивать, как правильно делать.
> получила статус минимально жизнеспособногоСобственно всё что вы хотели знать о Rust но боялись спросить.
Шутки за 200.
А с мысл? Чтобы оказаться там-же где и все прочие убийцы C/C++? На свалке времён?Приблезительно через равный промежуток времени появляется очередная порция подростков неосиляторов. Для которых всё сложно и непонятно и оуни начинают велосипедить свои истинно верные убийцы С/С++. И каждый раз оказываются в одном и том-же месте. В нигде, на свалке времён.
Очердной убийца? Т.е. тот который самоубьётся апстену?
Хоть синтаксис бы оставили привычный большенствую языков. И терминалогию. А то отсебятина сексуального меншинства прямо.
Конечно, прыщавому васяну из компании два васяна продакшен виднее.
> Приблезительно через равный промежуток времени появляется очередная порция подростков
> неосиляторов. Для которых всё сложно и непонятно и оуни начинают велосипедить свои истинно верные убийцы С/С++.Graydon Hoare и Brendan Eich - подростки-неосиляторы? Вот оно че!
> Конечно, прыщавому васяну из компании два васяна продакшен виднее.Какой ты самокритичный.
> А с мысл? Чтобы оказаться там-же где и все прочие убийцы C/C++?
> На свалке времён?Никто ваш c++ не заберёт, не волнуйтесь так.
> C/C++Один язык хорошо, а два лучше!
И много говнософта уже написал на языке zig?
У тебя там память не течёт, сисишник?
А у тебя уже занчилась ?
в ресдохе течёт память, но растаманы объяснили, что это норма.
> в ресдохе течёт памятьПотому что половина кода на СИ
> Приблезительно через равный промежуток времени появляется очередная порция подростков
> неосиляторов. Для которых всё сложно и непонятно и оуни начинают велосипедитьУже довелосипедились. Я выше пример привел из широкоизвестной в узких кругах растолибы substrate:
--cut--
pub struct LightStorage<Block: BlockT> {
db: Arc<dyn Database<DbHash>>,
meta: RwLock<Meta<NumberFor<Block>, Block::Hash>>,
cache: Arc<DbCacheSync<Block>>,
header_metadata_cache: Arc<HeaderMetadataCache<Block>>,
#[cfg(not(target_os = "unknown"))]
io_stats: FrozenForDuration<kvdb::IoStats>,
}
...
fn number(&self, hash: Block::Hash) -> ClientResult<Option<NumberFor<Block>>> {
if let Some(lookup_key) = block_id_to_lookup_key::<Block>(&*self.db, columns::KEY_LOOKUP, BlockId::Hash(hash))? {
let number = utils::lookup_key_to_number(&lookup_key)?;
Ok(Some(number))
} else {
Ok(None)
}
}
И что тут не так?
Код слегонца наркоманский и контринтуитивный, а так все хорошо, прекрасная маркиза. Признайся, что ты жрешь чтобы затюнить мозг для работы с такими закорюками? А то даже у лютых игроделов такого нет, они догадываются что это потом еще и майнтайнить надо, при том не факт что тому же человеку...
> Код слегонца наркоманский и контринтуитивный, а так все хорошо, прекрасная маркиза. Признайся,
> что ты жрешь чтобы затюнить мозг для работы с такими закорюками?Тут всё довольно просто. Если с подсветкой синтаксиса, будет вообще тривиально. У тебя просто глаз непривычен к синтаксису, и поэтому парсинг всего этого требует большого количества усилий. Тренированный глаз выхватывает знакомые блоки, и либо пляшет от них, либо отвергает их как неважные в данный момент. Ну, там, Arc скажем -- это thread-safe reference count. Если мне в данный момент это не важно, то я тут же выделяю оттуда dyn Database<DbHash>, а это значит, что речь про ref counted указатель на объект, реализующий трейт Database, с параметром DbHash, который явно задаёт алгоритм хеширования база данных пользуется. Последнее суждение правда вынесено чисто на основании названия типа, которое я впервые вижу, но... ну и чо? Можно задаться вопросом, зачем тут индирекция через трейт в сочетании с типом-параметром DbHash, но это, возможно, чтобы позволить компилятору выбирать функцию алгоритма хеширования на этапе компиляции, без десятка вложенных virtual вызовов. Впрочем, это уже совсем спекуляции, поскольку я не знаю зачем этот код.
Или в функции -- там же сразу видно, что функция возвращает результат выполнения выражения if let, которое либо находит key и выполняет то что перед else'ом и возвращает результат, либо не находит и возвращает результат выполнения того, что после else'а.
> А то даже у лютых игроделов такого нет, они догадываются что
> это потом еще и майнтайнить надо, при том не факт что
> тому же человеку...rust отличается как раз тем, что его мейнтейнить довольно просто. Это люди часто отмечают: сложные рефакторинги с растом занимают на удивление мало времени, потому что все твои косяки вылезут на компиляции, тебе не придётся потом как с C/C++ долго отлаживать программу, или ещё как-то вылавливать, что же там в процессе рефакторинга было упущено.
Мне кажется, что есть риск, что именно это станет проклятьем раста: когда в языке что-то просто, то программисты начинают этим злоупотреблять. И возможно растоманы начнут писать просто мозговыносящий код. Местами я вижу мозговыносящий код -- скажем генераторами парсеров я так и не научился уверенно пользоваться, надо как-нибудь посвятить пару-тройку дней разбору того, как это работает и как этим пользоваться вообще.
Вообще-то тут все плохо. Даже более скажу - очень, очень плохо; я за подобный c++ код увольнял людей.Программист не должен быть механическим придатком одного-единственного компилятора. Программист должен писать интуитивно понятный другим программистам код на любом нужном в данный момент языке, потому что программист в первую очередь - алгоритмизатор. А если язык не позволяет писать интуитивно понятный код, это плохой язык.
Код выше хорошо бы смотрелся как результат кодогенерации некоего языка более верхнего уровня. Но как первичный язык - это полный отстой.
Вы пока этого не понимаете, судя по вашим комментариям. Так что я вам предложу простую аналогию.
Представьте, что вы сейас читаете макроассемблерный код, где в дополнение к простым инструкциям MOV, ADD, SUB добавлены более сложные VMOVDQU64, VPBROADCASTQ, PINSRQ. "В чем сложности, бро" спросите вы? В том, что с этим кодом может работать (причем обязательно без перерывов) специалист узкого профиля. Прервался - забыл, сиди вспоминай и строй в голове все по новой. Причем познания этого специалиста вообще никак не могут пригодится вне этой области - например, при переходе на arm ассемблер или даже на языки более высокого уровня.Код выше обладает всеми недостатками примера с ассемблером. Это и многократные вложения, заставляющие каждый раз строить в голове цепочку структур "кто на чем стоял", и акронимы (слава богу попроще чем PINSRQ), и перегруженность спецсимволами, которые в любом языке очень плохая идея, и практическая невозможность сопровождения, когда надо быстро вносить минимальные правки не ломая все и вся.
Да, если вы заточите свой мозг под этот язык, вы будете его вполне адекватно читать и писать. Но вы превращаетесь в кодера - придаток одного конкретного языка (я, например, хорошо владею брейнфаком - помогли ли мне эти знания где-то вовне брейнфака? нет). Придаток, который в ближайшем будущем можно легко заменить на алгоритм кодогенерации (как, например, из c генерируют адекватный джаваскрипт). Придаток, совершенно бесполезный вне границ языка.
У Макконела есть великолепная книга, "Совершенный код". Если ее ненавязчиво понемногу читать, со временем вырабатывается интуитивное чувство правильного кода - кода, который легко читать, легко сопровождать, который можно легко сбросить на коллегу, если ты временно недоступен, легко разбросать на целую команду, не теряя кучу времени на постоянные выяснения "а что же эта конструкция значит" и легко фиксить небольшие баги, когда достаточно поменять пару строк в одном или двух местах.
Вот как то так.
> Вообще-то тут все плохо. Даже более скажу - очень, очень плохо; я за подобный c++ код увольнял людей.В C++ этот код не скомпилируется. Это не C++, детка, это раст. Не надо критериями C++ мерять раст. Ты ещё критериями лиспа померяй C++, что получится?
> Представьте, что вы сейас читаете макроассемблерный код, где в дополнение к простым инструкциям MOV, ADD, SUB добавлены более сложные VMOVDQU64, VPBROADCASTQ, PINSRQ. "В чем сложности, бро" спросите вы? В том, что с этим кодом может работать (причем обязательно без перерывов) специалист узкого профиля. Прервался - забыл, сиди вспоминай и строй в голове все по новой. Причем познания этого специалиста вообще никак не могут пригодится вне этой области - например, при переходе на arm ассемблер или даже на языки более высокого уровня.
Я только что прочитал этот код, не зная откуда он, не видя документации к трейту Database, не видя документации к DbHash, не видя документации ко всем остальным типам. Самой большой проблемой было, что я привык читать с подсветкой синтаксиса, поэтому здесь приходилось вглядываться, где там :, отделяющее имя поля от сигнатуры типа, и все эти #[] не подсвечиваются, и поэтому замусоривают поле зрения.
Если тебе нужен пример кода, в котором сам чёрт ногу сломит, то я порекомендую глянуть на генераторы парсеров или, скажем, библиотеки для immediate mode GUI: conrod и особенно egui. Особенно egui отличается пустой и не объясняющей ничего документацией, из которой непонятно как это использовать, разглядывание сорцов тоже ничего не проясняет, обрывки кода в документации непонятно как склеивать и увязывать с остальной логикой... ууу... вот это срань, реально. conrod ещё куда ни шло, к нему хоть примеров можно найти, и разглядывая их вперемешку с документацией и кодом можно сообразить, что к чему. А то что ты цитируешь -- это детский лепет, который у тебя вызывает проблемы по тем же причинам, по которым у меня вызывает проблемы C++: перенос навыков с одного языка на другой не срабатывает и ещё усугубляется схожестью языков.
> Код выше обладает всеми недостатками примера с ассемблером. Это и многократные вложения, заставляющие каждый раз строить в голове цепочку структур "кто на чем стоял", и акронимы (слава богу попроще чем PINSRQ), и перегруженность спецсимволами, которые в любом языке очень плохая идея, и практическая невозможность сопровождения, когда надо быстро вносить минимальные правки не ломая все и вся.
Всё завёртывание там -- это умные указатели. Про Arc я рассказал, а значение RwLock и FrozenForDuration понятно из названия. Единственное, что неясно из кода без чтения документации, это что за Meta такой. И про разумность использования его параметризованным я ничего не могу сказать. Остальное, блин, очевидно при первом прочтении.
> Но вы превращаетесь в кодера - придаток одного конкретного языка (я, например, хорошо владею брейнфаком - помогли ли мне эти знания где-то вовне брейнфака? нет). Придаток, который в ближайшем будущем можно легко заменить на алгоритм кодогенерации (как, например, из c генерируют адекватный джаваскрипт). Придаток, совершенно бесполезный вне границ языка.
Мне похрен. Rust -- это уникальная вещь, мне приходилось эпизодически раньше оказыватся в стане фанатов какого-либо языка, но каждый ненадолго, довольно быстро я начинал видеть в языке фатальные недостатки. Rust'ом я фанатею уже 6 лет, с момента выхода 1.0. И я не хочу знать про другие языки. Я шелл-скрипты сегодня пишу на расте. Однострочники так же набираю в шелле bash, но ежели однострочником не обойтись, я пишу на расте. Мне сегодня не интересны все эти lisp'ы, C, и прочие. Я могу разглядывать другие языки, типа go, но мне неинтересно на них писать.
> У Макконела есть великолепная книга, "Совершенный код".
Я закину её в список чтения. Может как-нибудь почитаю.
> Это и многократные вложения, заставляющие каждый раз строить в голове цепочку структур
> "кто на чем стоял", и акронимы (слава богу попроще чем PINSRQ), и перегруженность спецсимволамиОписал C++.
> Код выше обладает всеми недостатками примера с ассемблером.
Ага, понятно.
> я, например, хорошо владею брейнфаком
Судя по Вашим комментариям во всех тредах, где упоминается Rust, только этот язык Вы и осилили, остальные, видимо, слишком сильно от него отличаются, поэтому не получилось.
> я за подобный c++ код увольнял людей.Получается, ты остался без плюсовиков?
Мои глаза вытекли, спасибо.
как язык раст то может и ничего..
но я вот думаю: настанет момент, и всякие редхаты с мозиллами, укажут Линусу на дверь: уж слишком он харизматичен.
> всякие редхаты с мозиллами, укажут Линусу на дверьТипичное поведение боевых 3,14: подождать, пока кто-то что-то сделает, а потом захватить готовое. Ничего не напоминает? (Хинто: как украли 5G у Хуавея).
Плохая дорога так то тоже в совет директоров хруста втерлась, так что им не на что жаловаться.
Втёрлась, чтобы посмотреть на других и у себя так не делать.
Торвальдс, так яростно обожествляемый тобой, является действующим акционеров Red Hat, которому принадлежит довольно крупный пакет акций.Т.е. по сути он даже не сотрудник, а совладелец компании.
Продолжай и дальше делать из него святого великомученика.
> Торвальдс, так яростно обожествляемый тобой, является действующим акционеров Red Hat,
> которому принадлежит довольно крупный пакет акций.
> Т.е. по сути он даже не сотрудник, а совладелец компании.
> Продолжай и дальше делать из него святого великомученика.с чего ты взял, что я его обожествляю?
я вообще к тому, что скоро линукс может измениться в инструмент контроля. а от бацки Сталлмана избавляются, чтобы он не орал со всех колоколен и людей не пугал
Linux теперь точно такой же мейнстримный корпоративный продукт, как Windows, например.А от бородача избавляются как раз по причине его принципиальной позиции, касательно всех этих корпораций добра на подобие Red Hat, Canonical, Microsoft и прочих там Oracle.
Просто он им больше ненужен.
> статус минимально жизнеспособного продуктаКак и весь раст. Никто и не сомневался, раз за 16 лет еле-еле только сейчас стабилизируют.
Оно еще шевелится?
Оно зомби, 16-ый год уже идёт, а растаманы всё ещё стабилизируют базовые понятия (указатели).
> Rust 1.0, the first stable release, was released on May 15, 2015.Но анониму конечно виднее.
The first and the final stable release xDD
> Rust 1.0А до этой версии типа ничего не было?! Вот так взяли, сели растаманы в кружок в 2015-ом и сразу родили 1.0-язык?
> The language ... begun in 2006 ...Но Андрию виднее...
> покровительством независимой некоммерческой организации Rust FoundationС советом директоров из амазона, майкрософта, и кого там еще. Вот такая вот хреновая независимость...
Нужно запретить писать на опеннет новости про руст и написанные на нем программы
Растаманы разрабатывают раст с 2006-го, а версия всего лишь полуторная О_о
Заодно бы ещё запретить демагогию и петросянство. Да и вообще запретить людям быть идиотами.
> запретить людям быть идиотамиДа вас, батенька, за такие нетолерантные слова сами эти идиоты и повесят. Это же дискриминация по здоровью. Вот Столлмана взяли и начали гнобить какие-то токсичные идиоты. А вы говорите - запретить... Ну, попробуйте... Кто кого запретит :)
Фраза про идиотов как бы не очень тонко намекала, что нельзя в этой жизни получить всё желаемое. Так что будут и новости про Rust, и срач под ними в комментах ещё долгое время. А потом Rust перестанет быть людям в новинку, на нём напишут больше софта, они привыкнут и им станет пофиг. Найдут себе новую грушу для битья.
> Фраза про идиотов как бы не очень тонко намекала, что ... будут и новости про RustКонечно будут! Идиоты никогда не переведутся.
Слишком жирно.
Почему Майкрософт примазалась к Расту. Чтобы потом сделать платными компоненты как в Дельфи?Раст не взлетит пока не избавится от Майкроссофт, потому-что Майкрософт проклятая компания. Любое сообщество, которое связывается с Майкрософт обречёно на деградацию.
Растаманы, пишем петицию за вывод майкрософт из состава директоров!
Следует задуматься, почему раст пропихивают в ядро линуха, и что спонсирует это M$. Процитирую сказкой про Вавилон:Господь сошёл посмотреть на город и башню, которые строили люди, и сказал:
– Все люди – один народ, у них один язык; вот они и затеяли такое; теперь не будет для них ничего невозможного. Сойдём же и смешаем им язык, чтобы они перестали понимать друг друга.
И Господь рассеял их оттуда по всему свету, и они перестали строить тот город.
Заклятый друг опенсорса.
перестали
Они просто наняли программистов уволенных из Мозиллы. А планы у них собственный хипстерский язык, у которого нет фатального недостатка.
> у которого нет фатального недостатка."написан не ими" :)
но для Дельфи тонны бесплатных компонент. Сейчас даже и сам Дельфи бесплатен (коммюнити едишн)
Нужные платны. Попробуй загрузить Дельфи без создания аккаунта и регистрации email.
коммюнити эдишн - урезанная и триальная версия?
по-русски - https://www.embarcadero.com/ru/products/delphi/product-editions
https://www.embarcadero.com/docs/Delphi-Feature-Matrix.pdf
https://www.embarcadero.com/docs/rad-studio-feature-matrix.pdfЛинукса в коммюнити не было.
https://www.embarcadero.com/ru/products/delphi/starter -Delphi Community Edition предоставляет возможность использования встроенных профессиональных инструментов разработки с самого первого дня.
Разработка приложений для Windows, macOS, Android и iOS осуществляется с использованием единой базы кода.
Визуальная разработка с использованием программных каркасов Delphi VCL и FireMonkey.
Built-in Debugging Tools and integrated toolchain that allow you to debug on any device
Rapidly build database apps with data binding and local/embedded capabilities
Сотни встроенных компонентов позволяют повысить уровень разрабатываемых приложений и сократить количество циклов разработки.
Direct access REST services and local/embedded databases such as InterBase, SQLite, MySQL, and more.
Лицензия на использование продолжает действовать до тех пор, пока прибыль физического лица или компании от приложений Delphi не достигнет 5 000 долларов США, или штат команды разработчиков не превысит 5 человек.
А русского термина нет, сладкие мои птенчики? Ну што за ДЖЕНЕРИКИ-то, а?
"термин" - не русский термин.
Слово "термин" уже более 300 лет с нами. Так что рот свой на замок закрой