Опубликован релиз языка программирования общего назначения Rust 1.78, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61104
Надо брать лучшее от обоих языков - синтаксис от раста, ГК от го.
Лучшее это синтаксис от Go и GC от Go.
Вы не прошли тест на сарказм
Анонисты спорят
Не ну действительно, зачем язык который медленный как go и сложный как rust. Rust выбирают потому что быстрый, но не всем понятная система владения. Go выбирают потому что простой как пень.
Система владения понятная. Все переменные - это либо значение в стеке (числа, символы, истина/ложь), либо структура в стеке с ссылкой на данные в куче (строка). Второй тип - это способ Rust управлять данными в куче и обезопасить нас от ошибок с кучей. При передачи в функцию значения в куче копируется ссылка на значение в куче, а не само значение. Также и при присвоении другой переменной. Rust следит, куча перемещалась ссылка, делая недействительной прошлую переменную.Грубо говоря, при передачи кучи в функцию она уходит в неё "с концами" и надо делать return, иначе потеряешь значение. Другой вариант - передавать владение (является даже отдельным типом данных), тогда передаётся ссылка на ссылку на данные в куче. Тогда старая переменная остаётся рабочей, но данные через владения изменять нельзя. Если передать изменяемое владение, то Rust следит, чтобы всегда была только одна такая переменная. Всё.
И ради этого нужно городит отдельный язык с мудреным синтаксисом и фанатично требовать переписать на него все программы на свете? Да это можно было бы реализовать небольшим расширением синтаксиса Си и парой новых опций компилятора. Но кому=то очень хочется контроля.
Си язык дохлый и убогий, в нём ничего нельзя реализовать. Однако плюсы потихоньку сахарят подобную логику. Rust как минимум подходит где нужен ЯП вроде с++, но плюсы нельзя засунуть из-за отсутствия ABI
Язык Rust и есть это самое небольшое расширение. А не нравится синтаксис - иди haskell/erlang/lisp учи. Языков миллион, но надо именно к Rust придраться.
Ну вот это кстати неплохо придумано. И вообще borrow. Плохо - постоянный перетряс и зависимость от мегакорпов, увы и ах.
Не понимаю зависимости. Вроде бы язык Rust открытый полностью и Open Source. Любой форкнуть может. Тут скорее зависимость от LLVM, ибо Rust поверх него построен. Но тот тоже Open Source.
> зачем язык который медленный как goПочему ты решил, что Go медленный?
>> зачем язык который медленный как go
> Почему ты решил, что Go медленный?Потому что вон тех господ от фуксии с драйвером на игого - немного уволили, задвинув проект.
Система владения понятна, здесь нет ничего особенного. А синтаксис, и заигрывания с синтаксисом из функциональщины, - ужас. И есть немного ложечек дерьма вроде пропаганды засовывания UT в комментарии к методам.
Что за UT? Unreal Tournament 99?
Unit Test, конкретно в rust называется Documentation Tests
Ещё ООП от Javascript - и будет вообще конфетка.
Стрелочные функции обязательно и самый простой метод отладки через console.log
и побольше =
Ну это то нужно. Вдруг данные не пришли и null, а не '', 0 или []
Ещё ни один шутник не догадался явно указать претензии к синтаксису. Пишите объяснительную на имя Евгения ВП.
Дополню список всего лучшего для будущих ЯП - синтаксис от Rust, GC от Go, стандартную библиотеку от C, скорость от JS, безопасность от C++
а чем GC от golang лучше GC от джавы?
> а чем GC от golang лучше GC от джавы?Не бойтесь ща мы им патч в вишлист закинием. Стандартную библу и VM как у жабы, во. Нехай качают по 200 мегов за присест. Это еще по божески, в сжатом виде. А, и оптимизатор с генерацией нативных ассемблей как в дотнете. Пусть тоже полдня после инсталла комп кладет.
Скорость от питона, у JS с этим как разно норм.
Не, норм как раз у питона, он по крайней мере не даёт ложных обещаний и не треубет вагон памяти за лапшу на ушах
Безопасность лучше от чистого C
А там ее никому и не обещали. Нужна безопасность - делаешь безопастно.
Только на жс скорость весьма неплохая при норм выставленных параметрах джит )
Некоторые ругались на медленность жс, особенно раньше. И даже не задумывались, что претензии даже не к жс, а к работе с ДОМ, за которую отвечает браузерное двигло. Сам по себе жс - весьма шустрая штукаПо плюшкам, добавил бы крейтсы от раста ну и нпм/пихон-модули, куда же без них. Хотя у доджо вроде ещё лучше - там бывали тупо прямые ссылки на репозитории
C++ безопасен, если не использовать навороты из обычного Си.
Лучшее - это без GC.
Зачем всё это, когда есть божественный C++?
паскаль -> модула -> оберон
Дмитрий, кресты слишком сложные и в изучении и в написании и в отладке.
До того как начать рожать новые языки раз в месяц бездельники накидывали в кресты всякое разное и продолжают это делать до сих пор.https://github.com/eranif/codelite/issues/3355 кусок со LanguageServerCluster.
В коде там что то типа:
char *path = build()->debug()->server().get_path();
это же полный треш и угар и виноват тут как автор так и язык.
На С до такого бы никогда не дошло, потому что там нет классов и никто бы не стал обмазывать обычные структуры так жирно бесполезным кодом с конструкторами/деструкторами.
Те, кто пишут подобное приведённому вами на любом языке напишут плохо.
Раньше C++ был "дефолтным языком для всего" - и благодаря этому нам остались кучи примеров monkey-кода на нём.
Сейчас "дефолтным" стал JS - результат работы JS-обезьян видят все и каждый день с ними соприкасаются.
Сделаете популярно-дефолтной "ржавчину" - будет то же самое, но на ней.
Нет, не будет. Синтаксис Rust нарочно такой подробный, чтобы было трудно написать много говнокода.
вообще в приципе много кода, не только говно-
> В коде там что то типа:
> char *path = build()->debug()->server().get_path();
> это же полный треш и угар и виноват тут как автор так
> и язык.
> На С до такого бы никогда не дошло, потому что там нет
> классов и никто бы не стал обмазывать обычные структуры так жирно"Классы" в Си всегда были: struct в Си++ это class, где члены public по-умолчанию.
Подобного выше коду в Си - вагон и маленькая тележка, на вид он получится более громоздкий, поскольку передача this явная, потому разделяют на несколько строчек вроде такой:
/* Curiouser and curiouser... NULL ->open() as "no device" ? */
if (file->f_op->open)
err = file->f_op->open(inode, file);> бесполезным кодом с конструкторами/деструкторами.
Где конструкторы в той строке?
А как это выглядело бы на С++?
Вот функция целиком:
static int usb_open(struct inode *inode, struct file *file)
{
int err = -ENODEV;
const struct file_operations *new_fops;down_read(&minor_rwsem);
new_fops = fops_get(usb_minors[iminor(inode)]);if (!new_fops)
goto done;replace_fops(file, new_fops);
/* Curiouser and curiouser... NULL ->open() as "no device" ? */
if (file->f_op->open)
err = file->f_op->open(inode, file);
done:
up_read(&minor_rwsem);
return err;
}file->f_op->open(inode, file);
f_op - это таблица виртуальных функций. То есть было бы:
file->open();
replace_fops(file, new_fops);
/* Curiouser and curiouser... NULL ->open() as "no device" ? */
if (file->f_op->open)Можно было считать аналогом dynamic_cast, если бы не вопрос в комментарии. Основная проблема переписать именно это на Си++ - код в ядре, исключения кидать может быть не уместно.
Классов нет в Си, ведь в структуре можно создать ссылку на функцию, но нельзя в этой функции сослаться на эту структуру. То есть никакого self.
>но нельзя в этой функции сослаться на эту структуруНикто не мешает Вам сделать это явно obj.vtbl->myfunc(&obj, param);
И потом обернуть в макрос, чтобы писать короче. Это будет ООП на уровне синтаксиса, а не компилятора. Нельзя на Си написать функцию, которая знает адрес структуры, в которой она находится. Скомпилируй в ассемблер через ggc --save-temps и посмотри.
> Это будет ООП на уровне синтаксиса, а не компилятора.Вам шашечки или ехать ?
>Скомпилируй в ассемблерС точки зрения ассемблера ООП не существует вообще. И даже методы и функции не существуют. Всё методы классов это точки перехода на огромной стене из кода. Они не находятся внутри данных, в данных могут быть только адреса точек перехода. И так же как и Ассемблер, Си позволяет реализовать логику опирающуюся на ООП. А именно обеспечить привязку логики функции к набору данных.
Результат в виде машинного кода или ассемблера важнее всего. Ведь это именно то, что и будет выполнять процессор.
Ну так там отличий и нет. Разве, что способ передачи параметров может отличаться.
Не проверял, но отличия есть. Иначе не стали бы о наличии ООП отдельно в особенностях языков указывать.
Я вот как раз проверял ещё в юности при фанатичной увлечённости Ассемблером. На низком уровне объект это просто указатель на структуру передаваемый первым параметром и не более того. В случае MSVC это параметр передаётся через ECX. Если у класса есть виртуальные методы, то первым параметром структуры идёт указатель на таблицу методов. ООП делают ради китов ООП полиморфизма, изоляции, инкапсуляции, наследования, что снижают вероятность выстрелить себе в ногу и дают немного сахара. Си может имитировать ООП в части логики, но запретить редактировать содержимое структур функциям не имеющим отношения к классу не может.
Никогда не понимал зачем приватить что-то в классе? Берёшь просто и не используешь.
На самом деле классов в понимании ООП нет в Си++. class это struct из Си, где по умолчанию область видимости private. У class нет никаких методов, есть функции-члены. Как только кто-то начинает говорить об ООП в Си++ в противовес чему-то там на Си, можно начинать делить его аргументы на 360°. В Си всё примерно тоже самое, Страуструп начал с того, что пытался уменьшить количество писанины и диагностировать часть ошибок.
мусор в плюсы сейчас накидывают не бездельники, а очень даже трудолюбивые вредители из компании яндeкc
>char *path = build()->debug()->server().get_path();Это как раз написано легко и понятно, аки в Библии.
Вот когда шаблон, параметризируемый типом , который сам шаблон переопределенный в хрен знает каом файле последством макросана 2 с половиной экрана - вот там без бутылски или understand scitools не разберешся....
>Для целевых платформ x86_64-pc-windows-msvc, i686-pc-windows-msvc, x86_64-pc-windows-gnu, i686-pc-windows-gnu, x86_64-pc-windows-gnullvm и i686-pc-windows-gnullvm теперь требуется как минимум версия Windows 10.Сразу ффтопку такие ЯП, программы на них, и программистов, выбирающих настолько заражающей своей негодностью инструмент для своих программ.
Ты против винды как платформы компиляции или что?
Я против навязывания новых версий продуктов M$. Сказки про>аяаяй, кто это сделал, никто ничего никому не навязывает, не хочешь - сиди без компьютера и интернета на своей 95
- оставь при себе. Навязывают. Кто-то получил блестящую какаху-ЯП по цене соучастия в навязывании. И так получится, что влияния всех этих подкупленных этой какахой для навязывания хватит. А у завязангых на эту какаху и выбора то и нет, кроме как вылезти из раста. Но нет, пргдолжают и зругих в него тянуть.
>>новых версийWindows10 вышла восемь лет назад.
А дерьмом не перестала быть до сих пор. Следующие версии ещё хуже.
Переходи на линукс
После чего поймешь что винда очень даже неплохая система.
Если особо не вникать в Windows, то да. Windows - это синяя пилюля. Живёшь в иллюзии безопасности и надёжности. Внутренне это монструозный комбайн из наслоения древних бесполнезных технологий (тм). Система создавалась для выкачивания бабла из людей.
Ну запусти в Wine.
Не в этом проблема, сначала прочитай на что отвечаешь.
Технологически венда интересная (по крайней мере фундамент там не ипахабили ещё и азуровцы как то вытягивают ситуацию), но то что она полностью закрытая и огороженная ставит на ней крест, для любого кто уважает себя и своё время.
Теоретически любой тьюринг-полный ЯП можно скомпилировать под любую систему. Пракрически - кто содержит Foundation - тот её и танцует. Вместе со всеми разрабами, решившими поучаствовать в этой пляске, и со всеми пользователями, которые к плясунам можно сказать наручниками пристёгнуты.
Те, кто пишут подобное приведённому вами на любом языке напишут плохо.
Раньше C++ был "дефолтным языком для всего" - и благодаря этому нам остались кучи примеров monkey-кода на нём.
Сейчас "дефолтным" стал JS - результат работы JS-обезьян видят все и каждый день с ними соприкасаются.
Сделаете популярно-дефолтной "ржавчину" - будет то же самое, но на ней.
Промазал с веткой
Хоть вы и вроде как не мне но я пожалуй отвечу :)Плохо - это понятие относительное.
Я бы оценивал код в порядке убывания важности:
- решает ли задачу
- насколько сложно поддерживать
- насколько глючно и не безопасно
Многие фонатики вообще не смотрят на решение реальных задач, им главное чтобы вроде как "безопасно".С++ никогда не был дефолтным языкм для всего.
Так может думать только человек который начинал на венде примерно лет 20 назад, когда вижал бейсик уже вроде как закопали, .NET толком не взлетел и но вижал с++ как был так и дальше работал и до сих пор работает. Там вроде как последние лет 10 C# взлетел.За пределами венды я бы сказал что основной язык С, который даёт фундамент всему, а дальше там просль ++, пхп, жавы, питона и прочих.
А касательно того фрагмента, так проблема крестов и прочих переусложнённых языков в том, что нужно быть супер гуру чтобы пользоватся ими правильно.
На практике гуру почти не существует и они тоже часто фигачат всякую фигню.Я вижу что автор там всё обмазал классами и прочими непотребствами из крестов, и я его прекрасно понимаю.
Тоже когда то пробовал кресты и у меня получилась абракадабра, и в какой то момент я понял что трачу время не на функционал а на всякую фигню связанную с крестами.
Тогда я был молодым, не опытным а проект был уже достаточно большим для начинающего в том плане что рефакторить на каждую ошибку было много.Потом я ходил по пути: надо написать свои функции для всего и везде ими пользоватся.
Да, свои memset, memcpy и пр.
Правда быстро выяснилось что они более медленные и утывая сколько там нюансов для оптимизации скорости я сдался :)Потом были врапперы:
mem_set(void *buf, const size_t size, const uint8_t c);
#define mem_bzero(__buf, __size) mem_set((__buf), (size_t)(__size), 0x00)
#define zalloc(__size) calloc(1, (size_t)(__size))
#define zallocarray(__nmemb, __size) calloc((__nmemb), (size_t)(__size))
#define mem_new(__type) (__type*)malloc(sizeof(__type))
#define mem_znew(__type) (__type*)zalloc(sizeof(__type))
#define mallocarray(__nmemb, __size) reallocarray(NULL, (__nmemb), (size_t)(__size))
Удобно же?Удобно, и идеологически правильно, и ваще офигенско!
Но только вот постороннему разработчику не до конца понятно что это, те по сути это введение своего диалекта для С.В итоге я это выкинул, и даже не стал брать bcopy(), bzero() - потому что они уже типа депрекейтед.
Только explicit_bzero() местами воткнул где было похоже что memset() компелятор выкинет.И продолжаю думать как бы сделать так чтобы код переносился копипастой (не был привязан к остальному коду) и был понятен любому кто знает базовый С.
А что делают в крестах?
Там исправляют старые ошибки, при сохранении совместимости, а это значит что радом со старым кодом/функциями появляются новые.
И как итог чтобы читать код надо знать все диалекты, начиная от самого старого и заканчивая самым новым.
И всё это для того чтобы в итоге получить тот же самый машинный код который выходит из под С компилятора.
К врапперам вопросов нет, вопрос практичности/объема проекта/степени реюза и туевой хучи факторов.> И продолжаю думать как бы сделать так чтобы код переносился копипастой (не
> был привязан к остальному коду) и был понятен любому кто знает
> базовый С.лол, никак.
Знание синтаксиса С - это достаточный уровень чтоб выстрелить себе в голову. Твой код бесполезен для таких людей. А эти люди, в свою очередь, бесполезны для тебя, т.к. С - просто lingua franca для решения задачи в какой-то предметной области. Именно знания в какой-то предметной области, такая экспертиза тебе и нужна в своём коде. И ты возьмёшь человека с такими знаниями, и проведёшь его по безопасному пути в конечный пуш-коммит своим код-ревью и советами. Цель твоего кода - решать задачу, а не быть понятным любому долб. Так как каким бы ты простым его не сделал, всегда придёт долб. который ничё не понимает. =)
P.S. KISS, скажем, был KISS'ом для инжинера, а не васяна с базовыми знаниями стрелки осциллографа. Таки дела.
Вы тут сильно смешиваете всё в одну кучу.Да, знание технологий важнее знаний языка, потому что технологии решают проблемы, а язык это скорее цемент из которого можно отлить реализацию технологии или соединить уже готовые куски.
Но одно дело описывать технологию простым и доступным языком а другое описывать её максимально не понятно никому кроме автора. Более того, по прошествии времени я и сам забываю детали и становлюсь не лучше людей пришедших со стороны.
Некоторым кускам моего кода уже более 20 лет :)
> Вы тут сильно смешиваете всё в одну кучу.ой ли.
> Да, знание технологий важнее знаний языка, потому что технологии решают проблемы, а
> язык это скорее цемент из которого можно отлить реализацию технологии или
> соединить уже готовые куски.или вы начинаете смешивать "технологии" (с)(r)(tm) (метод решения?) и предметную область.
и чем больше бла-бла, тем меньше смысла.> Но одно дело описывать технологию простым и доступным языком а другое описывать
> её максимально не понятно никому кроме автора.и где в этом континууме от и до, ваше желание писать на С чтоб можно было васяну со стороны копипастить код, не напрягая извилины? дайте угадаю: максимально описывать "технологию" (c)(r)(tm) простым и доступным языком, да? Так это не язык программирования. И даже не псевдоязык программирования что используется математиками. Это картинки. Не 3Д.
> Более того, по прошествии
> времени я и сам забываю детали и становлюсь не лучше людей
> пришедших со стороны.
> Некоторым кускам моего кода уже более 20 лет :)документировать надо :)
Возможность копипастить код - это просто индикатор того что там нет зависимостей от других частей кода.Я писал про использование упрощённого и общепонятного синтаксиса, без замусоривания его сахаром, который надо лазать по коду искать и запоминать что он означает.
Конечно, есть большие проекты и там придётся лазать и смотреть что означают функции для понимания, без этого не обойтись.
В целом поинт в том, чтобы писать компактно и понятно, не создавая неудоств читающему.
> Возможность копипастить код - это просто индикатор того что там нет зависимостей
> от других частей кода.нарушает принцип DRY, а в запущенной стадии ведёт к туевой хуче антипаттернов. копипастить код - это не задача кода и/или проекта :) на тебя "clean code" (c) (r) (tm) так подействовал, чтоб до степени фарса доводить? я видел его воздействие на коллег когда-то: ужасающе. Но хуже было то, как они бродили по наркодиспансеру и всем его толкали: - "ты читал?! ты читал?!"
> Я писал про использование упрощённого и общепонятного синтаксиса, без замусоривания его
> сахаром, который надо лазать по коду искать и запоминать что он
> означает.ты выдумал проблему: (не)возможность копипастить код какими-то yep-LAN-ами, с начальными навыками владения инструментом, которыми они себе собираются выстрелить в голову.
А я, как человек, у которого иногда бывает мессианское настроение наставить на путь праведный, истинно говорю тебе: это не твоя проблема, чувак. ^_^
> Конечно, есть большие проекты и там придётся лазать и смотреть что означают
> функции для понимания, без этого не обойтись.
> В целом поинт в том, чтобы писать компактно и понятно, не создавая
> неудоств читающему.точно клин код.
Нет, это не оно. )У меня моя liblcb и я её делал линкуемой, идея была в том, чтобы инклюдить и линковать по минимуму.
Но местами там стал наступать монолитизм, когда ради одного функционала надо приличное колличество от либы.
Абсолютно согласен, то же пришёл к такому выводу, но никогда не обмазывал родные типы и функции. Вот только со `String` обмазывал, что бы получать форматированную строку по месту, типа
```
printf(MyString("a=%d", a).c_str());
```
Но справшивается, до коле каждый будет обмазывать себя сам? Уже 40 лет языку, а строк как таковых по сути и нет.
> Абсолютно согласен, то же пришёл к такому выводу, но никогда не обмазывал
> родные типы и функции. Вот только со `String` обмазывал, что бы
> получать форматированную строку по месту, типа
> ```
> printf(MyString("a=%d", a).c_str());
> ```это С или С++? Если С - что это за обвязка такая? O_o Что за обращение к элементу c_str()?
Что за строка такая, что требует конвертации (malloc?) в null-end, и передачи как первого аргумента в printf, когда он требует другого вообще... А если С++, то зачем... ох, вы реально так делаете или это вброс?> Но справшивается, до коле каждый будет обмазывать себя сам? Уже 40 лет
> языку, а строк как таковых по сути и нет.Похоже таки вброс. Ну ок, какие именно строки вам нужны в стандарте?
Это не вброс, это что-то похуже. Такие сначала утверждают, что strlen() требуют оптимизации, а потом не могут сказать, где и для чего они берут null-terminated строки размером в мегабайт.
strlen() это memchr(,, 0x00) :)
Я думаю вы пошли по не правильному пути :)
Нужно признать что в С нет строк, есть только куски памяти с непредсказуемым содержимым.
Единственное что можно называть строками - это строковые константы задаваемые в коде двойными кавычками.
>Нужно признать что в С нет строк,А этот факт кто-то отрицал? Паскальщики уже полвека об этом говорят. Си - это не ООП язык.
ООП на сях вполне себе есть, просто оно не обмазано сахаром.
Оно в общем и на ассемблере есть.
Потому что ООП это не фича языка а подход.
> Нужно признать что в С нет строкстандарт знает об этом, или инфа от инсайдера?
Так это вопрос интерпретации стандарта, не более.Кто то считает что по сокету на 80 порту он может получить исключительно текст, я против такого подхода и призываю ожидать текст только от строковых констант из кода.
> Так это вопрос интерпретации стандарта, не более.разрабы компиляторов об этом знают? ну, что написанное в стандарте - вопрос интерпретации этого самого стандарта.
> Кто то считает что по сокету на 80 порту он может получить
> исключительно текст, я против такого подхода и призываю ожидать текст только
> от строковых констант из кода.какого подхода? лан, простой вопрос: каких строк вам не хватает в стандарте? ты считаешь что строк нету, окей, разрабы сишки как-то не живут с тобой в одной вселенной, и не знают что такое строка. Дай определение, какие строки им нужно имплементировать в следующем стандарте. :-D
В стандарте чистаго Си про строки, ничего не написано.
> В стандарте чистаго Си про строки, ничего не написано.экспертиза которую мы заслужили.
> Потом были врапперы:
> mem_set(void *buf, const size_t size, const uint8_t c);
> #define mem_bzero(__buf, __size) mem_set((__buf), (size_t)(__size), 0x00)
> #define zalloc(__size) calloc(1, (size_t)(__size))
> #define zallocarray(__nmemb, __size) calloc((__nmemb), (size_t)(__size))
> #define mem_new(__type) (__type*)malloc(sizeof(__type))
> #define mem_znew(__type) (__type*)zalloc(sizeof(__type))
> #define mallocarray(__nmemb, __size) reallocarray(NULL, (__nmemb), (size_t)(__size))
> Удобно же?
> Удобно, и идеологически правильно, и ваще офигенско!По какой идеологии правильно? Такое г-но ещё Ален И. Голуб расчихвостил в своё время, но народ всё так и ходит по граблям макросов https://bugzilla.altlinux.org/show_bug.cgi?id=38212#c2 священная корова же, трогать нельзя!
reallocarray это тоже макрос?> А что делают в крестах?
Там отчасти решают проблемы вон того непотребства, в том числе и с ошибками из-за приведения типов. inline в Си откуда заимствовано?
> Там исправляют старые ошибки, при сохранении совместимости, а это значит что радом
> со старым кодом/функциями появляются новые.
> И как итог чтобы читать код надо знать все диалекты, начиная от
> самого старого и заканчивая самым новым.
> И всё это для того чтобы в итоге получить тот же самый
> машинный код который выходит из под С компилятора.Вопрос в том, какой ценой выходит код. Ну и -- если кто-то увидел в Си макросы и принялся их абузить, то в Си++ с этим хуже, да -- там возможностей для таких "рационализаций" гораздо больше.
reallocarray() это функция, появилась в OpenBSD и растащилась как минимум во фрю.mem_set(void *buf, const size_t size, const uint8_t c);
Вот это идеологически правильно: буфер, размер и только потом фиговина которую туда пихать.
В традиционном memset() иногда размер пишут вторым аргументом.
> Там отчасти решают проблемы вон того непотребства, в том числе и с ошибками из-за приведения типов. inline в Си откуда заимствовано?Это выдуманная проблема.
> Вопрос в том, какой ценой выходит код.Ну это тоже как посмотреть.
Кресты же пытаются дотянуть до уровня высокоуровневых языков практически без ручного манагемента памяти, куда то чуть ли не до LUA/PHP/python.
> reallocarray() это функция, появилась в OpenBSD и растащилась как минимум во фрю.Значит код чуть лучше, чем я написал, но основные проблемы никуда не делись: вложенные макросы, неотличимые по именам от функций. Проблема с sequence point ещё и в том, что с одним транслятором получится в соответствии с наивными ожиданиями программиста, а на другом она выстрелит в ногу.
> mem_set(void *buf, const size_t size, const uint8_t c);
> Вот это идеологически правильно: буфер, размер и только потом фиговина которую туда
> пихать.
> В традиционном memset() иногда размер пишут вторым аргументом.Ну и я так писал :) и не только в memset. Потому предпочитаю по возможности инициализировать в определении, присвоив {0}. Правильно будет, когда транслятор выдаст как минимум предупреждение при приведении типов.
>> Там отчасти решают проблемы вон того непотребства, в том числе и с ошибками из-за приведения типов. inline в Си откуда заимствовано?
> Это выдуманная проблема.Если макрос локальный (определён в .c файле и дальше него не вылазит), то проблемы обычно нет, поскольку неподходящий случай использования будет видно.
По ссылке:
2020-03-12 - обнаружено (им ещё повезло, что отловили тестами).
2020-04-23 - нарыли причину.Я только сейчас увидел, что год 20-й! Сижу как идиот жду, когда и как исправят в glibc... думал, ещё месяца 3.
>> Вопрос в том, какой ценой выходит код.
> Ну это тоже как посмотреть.Я на плюсы начинал смотреть как раз со стороны генерируемых асм-листингов, и мне было непонятно, зачем нужен Си, кода результат (иногда даже лучший) можно получить меньшим количеством строк, плюс вынести часть ошибок на этап трансляции. Тогда я не учитывал, что в BSD/Linux есть традиция, как и вес .so с библиотекой плюсов.
> Кресты же пытаются дотянуть до уровня высокоуровневых языков практически без ручного манагемента
> памяти, куда то чуть ли не до LUA/PHP/python.Мне приходилось за весьма грамотным перловиком переделывать проект на плюсах, совершенно рабочий, одна беда -- всё передавалось по значению вместо ссылок (потребляло лишнюю память и тормозило, соответственно). Это как если бы в Си он все массивы копировал, вместо передачи указателей -- такое никто не напишет, поскольку придётся писать лишнее.
Вот этом основная проблема плюсов, если не считать объёма стандарта: с одной стороны, понижен порог вхождения; с другой стороны, кто мог бы взять какие-то полезности из плюсов и упростить код на Си говорят "мы с вон теми за один стол не сядем". Может быть, её отчасти решит Rust, перетянув к себе первых.
В какое место ставит крест?Я бы оценивал OS в порядке убывания важности:
- решает ли задачу
- насколько сложно поддерживать
- насколько глючно и не безопасно
Многие фонатики вообще не смотрят на решение реальных задач, им главное чтобы вроде как "безопасно".
>в порядке убывания важности:
> - решает ли задачу
> - насколько сложно поддерживать
> - насколько глючно и не безопасноЧисто корпоративный подход - снижение издержек важнее безопасности.
А вот для потребителя/юзера безопасность данных важнее прибыли корпораций.
юзеру пох, он сидит на венде даже без (обожемой) юблока. пока инфоцыгане пытаются его напугать до ус-чки, чтоб продать "безопасность" (с) (r) (tm).
Нет, юзеру безопасность не важна, ему важнее функционал.Зачем смартфон без порнухи и котиков но зато безопасный? Уверены что такое купят?
Посмотрите на продажи всяких аврор, кашмарских и прочих фриковских поделок.Даже когда доходит до безопасности жизни юзер выбирает функционал.
Вы видели хоть одно популярное серийное авто с лимитом скрости в 40-60 км/ч и обвешенное подушками безопасности? (а свыше 60км/ч уже практически не возможно гарантировать сохранность тушки при мгновенной остановке ТС)
А видели чтобы на гражданских самолётах отсреливалась верхняя часть фюзеляжа и все кресла пассажиров катапультировались и потом у них у каждого раскрывался парашют, как у военных?В плане огнестрела не заходят даже не просто девайсы с аворизацией выстрела по отпечатку но и просто оружейные боксы открываемые сложнее чем булавкой за минуту.
И таких примеров - сколько угодно.
Приведите хоть один пример когда юзер деньгами проголосовал за безопасность против функционала.
(сфера всяких сигнализаций - не считается, там сразу платят за видимость безопасности)
Потому подотритесь своей безопасностью, у вас просто перенос фобий из реальной жизни где у вас нет гарантий вашей физ безопасности на компьютеры где вы типа что то решаете.
>Даже когда доходит до безопасности жизни юзер выбирает функционал.Абсурд!
Ты многих встречал, которые ради функциональности (не таскать с собой связку ключей - это же так удобно) не закрывают квартиру или машину?Другое дело, что многие еще не понимают, что безопасность смартфона подороже будет, чем незакрытая квартира. Но таких все меньше. Особенно, после того как пропадут деньги со счета, или попадутся на оформление кредита.
>Потому подотритесь своей безопасностью
Желаю тебе не познать отсутствие безопасности на своем кошельке. Пребывай в розовых очках и дальше.
Наверное для вас будет шоком но есть много мест где люди не заморачиваются закрытием квартир и машин.Смартфон вы к теме за уши притянули.
Но опять же проблемы перечислили свои местные.
"Закрытие" смартфона на пароль не уменьшает его функционала, как и закрытие квартиры, машины на ключ.Речь была про код и потом про вещи: фичи VS безопасность.
Речи про безопасность VS удобство не было.Машина/квартира/телефон - единственный функционал которых закрыватся опять же не нужны :)
Он просто обеженный непрофессионал, у которого вечно зудит.
Продолжать поддерживать древние версии Винды в 2024 году, в особенности не получившие популярность версии 8 и 8.1 - это верх идиотизма. Тем более в современном ЯП, не успевшем обрасти легаси.
Не вижу arm в списке.
А седьмая винда существует под арм? У раста есть таргеты относящиеся к арму с виндой, в сортах не разбираюсь:
[ul]aarch64-pc-windows-msvc aarch64-pc-windows-gnullvm arm64ec-pc-windows-msvc aarch64-uwp-windows-msvc thumbv7a-pc-windows-msvc thumbv7a-uwp-windows-msvc
[/ul]
Windows 7 всё ещё поддерживается, но уже как отдельная Tier 3 платформа (точнее, две платформы: x86_64-win7-windows-msvc и i686-win7-windows-msvc); об этом писали в феврале: https://blog.rust-lang.org/2024/02/26/Windows-7.html
А надо - и XP, 2000, 98, 95, 3.1, ReactOS... Поддержка языка программой должна определяться не хотелками авторов компилятора, а задействованными в программе API и несовместимыми фичами формата (при этом должна быть возможность редактором формата подредактировать бинарь, чтобы он и без этих фич заработал на старье).
Надо - значит делай. Исходники компилятора открыты всем желающим, качай и патчи как считаешь нужным.
Проще использовать другой язык где таких проблем нет.
Используй. А пособники Micro$oft будут использовать ванильный компилятор с ванильным рантаймом. Точно так же, как MSVC используют вместо MinGW, навязывая быдлы покупку лицензий на винду и компов под них.
> Точно так же, как MSVC используют вместо MinGWГнутый вендорлок? Это другое, понимать надо!
> навязывая быдлы покупку лицензий на винду и компов под них.
Да, покупать надо у правильных пацанов вроде IBM, Oracle, Canonical или Suse и стоить это будет дороже чем у MS. Всякие анекдоты про community-based дистры в проде рассказывать не нужно ибо давно уже не смешно.
>Код на языке Borgo компилируется в представление на языке Goто есть наследует все наиболее критичные недостатки языка go.
Теперь всё, что было переписано на расте, надо переписывать на Borgo
И компилировать Go... ну ты понял, что сморозил пургу.
Кто то ещё не вырос и изобретает свои языки.
Одни запутались в крестах и кривой архитектуре, потому решили что ну его нафиг и для своей гнили изобрели отдельный гнилой язык.
Другие просто фигнёй маятся вместо решения насущих практических проблем.GO - то понятно зачем: автору хотелось выпендрится а гуглю нужны обезьянки за дёшего, так бы тоже можно было обойтись PHP+LUA.
Проблема банальнее - люди в массе тупые и программисты не исключение. В том числе, которые пишут новые ЯП и которые считают, что существующих ЯП достаточно и ничего больше делать не нужно. Со временем повышается порог вхождения в профессию и сейчас делать новый ЯП лучше других могут только по настоящему яйцеголовые.
Все такие: а нахрена этот язык? А автор такой пожимает плечами. В отпуске был наверное.Если же в рабочее время сделал, то это любопытно, с точки зрения атмосферы, скажем так, если вы понимаете о чём я
На Rust и Borgo всё ещё невозможно писать GUI-приложения?! Не нужно.
А на чём их возможно писать?Серьёзно, я не фонат этих двух языков, но по ИМХО дело не в языках, а в том что за пределами венды нет адекватных графических тулкитов, либо они не очень популярные.
На венде я писал гуёвые проги на вижал бейсике и на С, дёргал WinAPI напрямую, SendMessage(), сублассинг и тп.
Помню когда появилась 2к - там в API добавили совсем каплю, для прозрачности.
И для ХР тоже чуток докинули для тем.
Но все старые проги продолжили работать и работают до сих пор.И субклассинг был офегенной штукой, когда ты мог для любого окна (объекта) добавить добавить свой обработчик оконных сообщений и он становился первым, и если тебе не надо обрабатывать все сообщения то ты мог из своего обработчика вызывать старый обработчик, который тоже мог быть не дефолтным/оригинальным, и там по цепочке таких обработчиков могла быть куча.
И не надо было ни исходных кодов ни знаний других языков, всё это могло работать совместно.
Можно было инжектнуть свою либу в чужой проект, она бы там субкласила и допустим красила в разные цвета окна, а в остальном приложуха бы работала как раньше.А тут QT/GTK - ненужно CSS и переписывать приложения раз в 2 года чтобы только они компелялись с новой версией.
Притом я то по сути не против CSS, просто в том же GTK он и нафиг не упал, проще было бы тогда просто в электрон переехать и не страдать от всех этих GOBJECT фиговин, а сразу писать html и указывать именя функций для обработки нажатий и прочего.
И в той же венде не нужен был никакой CSS для того чтобы темы менять. Мы ещё 20 лет назад извращались с WinAPI и делали и дырки в окнах (через которые было не только видно но и кликалось), и кастомной формы объекты.
На Жабе- великой и ужасной,бгг
На Rust возможно писать GUI приложения. Вы просто не в теме.
>Код на языке Borgo компилируется в представление на языке Go
>Код компилятора написан на языке RustНе хватает пакетного менеджера, написанного на Dart и системы сборки, написанной на Haskell.
Всё это уже есть.
Проекты на нем есть? Мне от внезапно понадобился другой редкий язык программирования. Там сплошная математика исходя из уроков. Пока сейчас компилируется IDE, думаю — за что мне так не повезло в жизни? Ну сделали Borgo и что? Теперь вопрос в комьюнити — сколько людей наберётся под какие проекты?
>Теперь вопрос в комьюнити — сколько людей наберётся под какие проекты?Берёшь и снимаешь с ним тикток, на следующий день будет на опеннете.
Какие ешё проекты этот язык заброшен уже 8 месяцев. А в новость его добавили чтобы сделать вид что на расте написаны какие-то проекты. Но проекты на расте достигают неподъмной когнитивной сложности уже на ранних этапах и их забрасыват как и сабж.
> Borgo комбинирует лучшие черты Go и Rust, восполняя недостатки каждого из языков.Самый современный на сегодняшний день язык. Выбор настоящих профессионалов.
Golang с человеческим лицом, допиленный для использования человеком и не вызывающий отвращения? Это интересно..
Он всего лишь избавился от if err != nil и от <- в каналах (обе эти сущности gyano обезьяны я согласен полностью). Но йопт нахрена это было делать на rust. Весь язык можно заменить на программу которая будет при запуске генерировать go код, написать LSP и все.
Справедливости ради тут ещё ADT, которого в go тоже не хватает.
Язык ` в ` котором ` на ` каждый ` чих ` дичь ` полнейшая ``.А вот Borgo интересный. Но ответьте, кто знает, в нем также рантайм решает, где хранить объект (stack/heap)? Если да то можете закапывать, ибо все что сложнее примитивного кода у вас будет вызывать раздражение в сложной архитектуре.
De##lo, read:>> Код на языке Borgo компилируется в представление на языке Go
Я знаю что Борго никто больше не развивает это всё что надо про него знать.
Почему же, активность в репозитарии есть, запрос общества на чистый синтаксис есть, может не сейчас, но шанс взлететь у него есть.
а где сравнения про вес простого текста в hello w?
Зависит от кодировки. В Rust по умолчанию utf8.
> Проект развивает Marco Sampellegrini, автор книги "The Simple Haskell Handbook" и разработчик системы непрерывной интеграции Quad CI.Брошенный проект, о котором никто не знает и не использует.
А как ругатели Borgo относятся к Elixir ? :)
Этот язык borgo - Мб он компилируется в go, но написан на расте, что значит, что он тащит весь невменяемый cargo. Синтаксис мб и лучше, но самая большая проблема раста не устранена.
Для сборки программы нужно сперва запустить cargo, затем go, пусть выкидывает на мусорку, это не язык, а очередной псевдотранспиллер, иными словами у вас никогда не будет полноценного дебаггкра в нем. Истории "не успеха" nim и vala никого не учат.
вот кстати да, nim - прикольный язык, пока тебя не задолбает расставлять echoдебажить как бы можно, но сгенерированный сишный код, т.е. дебаггера нет
>но сгенерированный сишный код, т.е. дебаггера нети в чем проблема? деманглер некому написать?
https://plugins.jetbrains.com/plugin/15128-nim тут есть, тут прекрасная поддержка nim, ну до какой степени ее может реализовать один разработчик, но у них сразу 2 проблемы: плагин не своевременно обновляет поддержку новых релизов IDE (да можно сидеть на старой вообще без проблем), а самое главное он практически не развивается.
> Support for 2024.1
> Plugin Versions
> Apr 11, 2024
> Version 1.5.4-223ого, да он же уже того... сдох.
Он не сдох, он в режиме поддержки доступности для новых версий Idea и все. Новых разработок в нем нет, потому что нет ни людей на проект ни, по-видимому, у них желания.
жаль, это проприетарная и крайне тормозная ideнадо посмотреть, как там всё реализовано
Да нафиг надо ещё один ЯП! Есть старые, проверенные временем python, java, c++
Скорее нафиг ещё один синтаксис, если синтаксис почти не влияет на результат и не прибит гвоздями к процессу компиляции. Внезапно, можно добавить в C++ синтаксис Python и т.д. и не изобретать ещё один ЯП.
Почему тогда Rust не сохранил простой и понятный синтаксис Си а изобрел свои каракули?
Ну незнаю. Мне Rust больше напомнил Python. Когда уже будет конкретика?
> Есть старые, проверенные временем python, java, c++Удачный вброс. Поместил свой "python" рядом с нормальными языками - и он уже не кажется таким убогим?
Python самый лучший язык в Мире после чистого Си.
Если писать своё мнение никак не аргументируя, то его обязательно все выслушают и примут к сведению. Что C++, что Java возникли и развились, как недоразумение, выносящее людям мозг. Почему Java не ругают за тормоза также, как и Python? Если Си это выстрел себе в ногу, то С++ это отпиливание и сжирание своей ноги вместе с костью. Мощное комбо из свободы действий и этих богатства действий.
не надо python... Совсем не надо...
А что нужно?
докопаться до языка, который тебе назовут
И зачем докапываться до указанных языков?
самоутверждаться
И повысить свой навык троллинга.
COBOL ещё более проверен временем.
Добрый день! А есть язык программирования, сочетающий сильные стороны Visual Basic и Rust?
Есть не язык, а типичный подход. Кроссплатформенная разработка, предполагающая интерфейс на достаточно простом и удобном VB или его вариантах, а интенсивные вычисления на компилируемом языке.
Чё то мелко плаваешь. Ищи уже тогда сочетание брэйнфака и пролога, заправленное макропроцессором M4. Хотя пролог сам по себе тот еще брэйнфак.
m4 нетрошь, эта святое!!
M4 – ископаемое из докембрия. Ему место в палеонтологическом музее.
> Добрый день! А есть язык программирования, сочетающий сильные стороны Visual Basic и Rust?Скорее всего нет, но ты можешь его написать.
Больше языков хороших и разных!
Заодно получишь незабываеммый опыт.
(С прищуром змея в Эдеме) Молодой человек, а пробовали ли вы изучить Scala ?
Сишарб и дотнет
Все проходит и это пройдет. (С) Соломон
>язык программирования Borgo, который пытается быть более выразительным, чем язык Go, но менее сложным, чем язык RusRust несомненно однажды уступит свою нишу другому, более эргономичному языку и Borgo это полезный эксперимент в правильном направлении, но пока что сыроват. Ребята молодцы, уловили тренд. Именно наличие чистого и хорошо читаемого синтаксиса важно в эпоху LLM, так как в сгенерированном коде могут скрыватся сложнообнаружимые галлюцинации и даже вредоносные закладки, которые в кракозяблях Rust можно просто не заметить и пропустить в продакшн.
А ничего, что у borgo последний коммит был 8 месяцев назад? То есть, он уже практически не живой.
Есть аналоги rust живые?
Если кто не в курсе - язык Borgo назван в честь актрисы IngeBorga Dapkunaite - такой же непостоянный и глючный, пытающий совместить в себе 2 култруры, но так и остающийся чужим для всех.
Вопрос знатокам, а это Borgo JSON распарсить сумеет? Избавились ли там от такого "прикола", как в Go — язык для "бекенда", но при этом не могущий распарсить JSON?