Они дошли до состояния, когда Линус аргументрированно высказывается на тему, что нужно поменять в Rust, чтобы его приняли.
При этом, что важно, ни одно из его требований не противоречит идеям разработчиков самого Rust: все они и так у них были в состоянии “а неплохо бы сделать такую шнягу”… просто рабочих рук не хватало.
Ясно, что если что-то лежит не в разделе “а было бы неплохо”, а в разделе “это нужно, чтобы Rust приняли в ядро”, то приоритет у таких фич повышается.
Так что… будем ждать.
Правда некоторые из нужных фичей весьма тяжёлые. Вот это вот, например.
С одной стороны решение принято: Rust поверх GCC одобрен. С другой… это ж сколько работы предстоит!
Мне кажется проще написать с нуля чем переписывать то что есть.Чисто психологически - в первом случае ты создаешь что-то новое, во втором - исправляшь старое багованое.
Переписывать — это все хотят. Google тоже отметился. Только не работает.
Ядро — это не только тысячи багов, но и тысячи, десятки тысяч, человеко-лет опыта, в том числе получеамого только на весьма экзотическом железе, кодифицированного в программе на C.
Воспроизвести это фактически невозможно. Недаром Microsoft в WSL2 отказался от идеи эмулировать Linux и взял готовое ядро.
Думаю что написание ОС будет сопровождаться так или иначе большим количеством unsafe раст кода.
Пока неизвестно насколько много реально unsafe кода там потребуется. Часть ядра, делающая вещи, которые в безопасные абстракции не оборачиваются, на самом деле крошечная. Буквально 1-2%. Хотя там есть и довольно хитрые структуры данных, которые тоже в безопасный Rust не засунешь.
В любом случае даже если unsafe кода будет не 5%, а целых 10% — это сократит объём кода, где могут быть проблемы в 10 раз.
И да, я не зря говорил именно про воздушный шар, а не про самолёт или парашют.
Уже в самом облаке, конечно, виден только туман. Но вот вблизи, когда расстояние несколько метров, это выглядит круто.
То же самое и со “столпами”: уже прямо внутри них, скорее всего, никакого особого вида там нету, но на расстоянии 5-10 световых лет (а может и на расстоянии 1го светового года) они бы выглядели офигительно.
Неясно только может ли там где-нибудь существовать цивилизация, способная это всё увидеть...
Не знаю что вы там наблюдаете в иллюминатор самолёта, они, так-то, стараются в сами облака не залетать. Но если вы когда-нибудь летали на водушном шаре, то уж точно так бы не говорили. Вот тут кто-то даже видео снял — облака вблизи реально впечатляют.
Обоначать оно может что угодно, только это всё были влажные мрии. Первый процессор, EV4 21064 вышел в 1992, последний, EV6 21264 — в 1998м.
Есть ещё, правда, вами упомянутый EV7 21364, ну так он тоже должен был в 1999м выйти, то, что он вышел через 4 года после этого — это скорее курьёз.
Dec Alpha - процессор конца XX века, так же как Itanic — процессор первого десятилетия XXI.
Хотя его Intel до сих пор отгружает (и будет ещё целых два дня отгружать!), но вы же не собираетесь, надеюсь, заявлять, что в 2020х он ещё кого-то интересует?
Я понимаю, если бы был ИИ который написал код и сделал корпорацию и люди не смогли с ним конкурировать…
Вполне возможно что, после изобретения “сильного ИИ”, и появится. Но непонятно почему он ринется замещать именно программистов и, главное, почему его вообще должны будут интересовать заказчики с их дикими хотелками.
Ну то есть как я и сказал: потеряют работу люди с мизерным опытом, знаниями и умениями. Условные программисты после курсов “как стать крутым профи за 21 день”.
Ну дык это и везде происходит: даже внедрение автопилота не высвободит шофёров полярных экспедиций или там водителей автокранов. А уж врачи могут не опасаться ничего блишайшие бог знает сколько лет: спрос на врачей превышает их наличие в разы, так что пока ИИ сделает ненужным ну вот хоть кого-то (кроме идиотов и дуболомов, к которым идти — лучше уж дома посидеть, авось само пройдёт), пройдут десятилетия.
Начинается всё с низкоквалифицированных рабочих. А уж какой специальности оные: строители или ИТшники — неважно.
Я просто к тому, что тут жалуются, что программисты к 40 годам приобретают профзаболевания. А непрограммисты? Если там шить, строгать или землю копать — все здоровые будут? Да?
Ну поговорите со своими знакомыми других специальностей, иллюзии развеются…
Ваше имя не Дункан Маклауд, часом? А то для большинства людей то, что случилось буквально в прошлом веке — ни разу не “совсем недавно”… уже даже все патенты протухли, там срок давности 20 лет…
И даже у майкрософт у которых есть операционка не в силах выйти на железный рынок со своим железом так широко как это делает Эппл.
Главное не втом, что она не могут выйти. Главное— они не могут уйти.
Apple меняла платформу трижды. И все три раза важным элементом манёвра был отказ от использования топовых комплектующих старой архитектуры после выхода новой. Ни одной модели Mac на 80686 не было. На одного лаптопа на 64-битных PowerPC не было. И Ryzen тоже не замечен ни в одной модели.
И вот этого как раз Microsoft добиться не может… а так да, всё верно.
А до того, как стать Data Engineer, я потратил 1.5 года, чтобы изучить Data Science, и после этого не смог найти работу, так как порог для входа человеку без опыта просто зашкаливал по требованиям. И на собеседованиях не жаловали – гоняли по полной по математике, статистике и тд. При этом я бы не сказал, что я ничего не знал о своей профессии. Пришлось даже в универ на магистратуру поступить, чтобы изучить как можно глубже. Кроме времени потратил около $6 тыс. Мне это говорит о том, что конкуренция со стороны программистов-сайентистов уже больше, чем необходимо бизнесу.
А мне это говорит о том, что “халява кончилась”. И всё. Да, дикая нехватка программистов в нулевые привела к феномену, когда люди, пройдя двух-трехнедельные курсы, могли претендовать на ту же зарплату, что, скажем, у врачей, отучившихся лет 8-10 минимум (5-6 собственно обучение, потом ординатура без которой вас никто на работу не возьмёт).
Сейчас программистам всего-навсего предлагают обучиться плюс-минус столько же, сколько в других областях — и сразу начались стоны.
Заменит ИИ кого-нибудь там или нет, но в любом случае пока ваша “суперсистема” не сможет создать ну, скажем, ядро OS (хоть какое-нибудь, фиг с ним, с “лучше и быстрее, чем те же программисты… даже топовые”) — говорить не о чем.
Пока что ИИ освоил решение типовых задач. Создание 100500го магазина (такого же, как и все предыдущие, только с другими “рюшечками”) — легко. Написать что-то хоть сколько-нибудь уникальное — фиг.
Нет никаких выборок, не на чём обучаться. Даже банальное создание языка программирования ИИ и близко недоступно. Хотя вроде их и тысячи, но потроха у них настолько разные, что никакое машинное обучение ничего там сотворить пока неспособно.
Где, кого, как? Какашкоязык — это, в принципе, состояние любого нового языка сразу после релиза, “микроязыка” — в особенности. Даже на каком-нибудь оригинальном Pascal (где не было указателей на функций) мало чего можно написать.
Уж сколько я этих поделок видел. Конечных состояний в 99% случаев — ровно два: либо язык удовлетворяет потребности автора, но не позволяет решать почти никаких других задач (выпиливается из соотвествующих проектов при первой же возможности как только отттуда свалит автор), либо, что куда хуже, им начинают пользоваться, по необходимости, многие — а в результате получаем многоуровневые слои костылей (что-нибудь типа такого).
В очень редких случаях языку-таки везёт и, вбухав в него тысячи человеко-лет, его доводят до состояния, когда при работе с ним не очень тошнит (хорошо известные примеры — Java, JavaScript, PHP, Python), но как-то странно затевать что-то новое в рассчёте на то, что с вашим языков такое произойдёт.
Особенно с учётом того, что когда-то в далёком прошлом вы, кажется, публиковали достойные материалы.
Было дело. Когда казалось, что на Хабре есть люди, которым было бы интересно чему-то научиться. Однако большинство — они ж чукчи-писатели, не чукчи-читатели. Ваш пример — как раз очень показателен.
Упоминание Go, Haskell, Rust, Swift я считаю вообще неуместным, поскольку всё это языки совершенно иного назначения.
Это с какого перепугу? Вот вам скрипты на Go в системе сборки Android, Haskell используется для скриптов настолько часто (инструкция), что любители даже PureScript изобрели, чтобы всё это в браузере использовать, Swift тоже можно, было бы желание. Вот Rust да, в последнее время на нём как-то перестали скрипты писать.
Остаётся Lua. Ну а преимущества относительно Lua я перечислил выше.
Ну то есть мотивация в стиле “ничего, кроме C и Lua я толком не знаю, но я ж не гений, я не мегагений, я омегагений — ща как создам… все ахнут”.
Таким путём можно создать только какашкоязык. Если вы “попадёте в струю” (как один известный товарищ сумел), то ваш язык, возможно, подхватят другие (как с PHP случилось) и превратят его… ну не в конфетку, конечно, но хотя бы во что-то, от чего при первом взгляде сразу глаза слезиться не будут.
Но это сродни выигрышу в лотерею, вряд ли вы на это рассчитываете.
Вот потому я и пытаюсь понять — зачем?
Этого для начала вполне достаточно.
Для начала чего, извините? Чтобы вы сами смогли свой язык использовать? Для этого вообще почти ничего не нужно: вы-то всё про него знаете и “делать странного” не будете.
А вот когда им начнут пользоваться другие… вот тут-то и начинаются чудеса: либо вам приходится составлять талмуды на тысячи страниц с сотнями правил на тему “как правильно держать наш телефон” (C и С++ прекрасные примеры), либо потребуется в ваш язык кому-то вбухать сотни (или, скорее, тысячи) человеко-лет разработки.
Я не вижу просто смысла изобретать ещё один какашкоязык непонятно для чего.
Если бы это была курсовая или даже дипломная работа — это можно было бы понять… хотя нет, всё равно нельзя: там обычно новизна требуется. Но какая цель вообще достигается этим велосипедом? Вроде как заявляется как скриптовый язык, но при этом структуры, совместимые с C, и списки. То есть вроде как что-то простое, но на самом деле нет.
Самое смешное, что я даже не говорю, что это не взлетит. Как раз если не влетит — так ещё полбеды, всё что случится — вы потеряете некое количество времени на бессмысленную работу.
А вот если взлетит — получим ещё несколько тысяч (или десятков тысяч) разработчиков, вынужденных тратить время и силы на то, что уже до них много раз сделали. На других языках.
Цель у этого всего какая? Куда это всё? Что вы умеете делать лучше, чем другие, те же Go, Lua, Haskell или Rust со Swift ом?
А уж если мы ссылаемся на int, который просто будет выкинут на мороз, когда удалится структура — это уже из области ССЗБ.
А тогда нафига вообще огород городить, если несмотря на “автоматическое управление памятью” у вас всё равно никаких гарантий ничего нету?
Меня посещало дежавю — полуавтоматическое управление памятью в Delphi.
Ну да, масса языков через это проходят: C++, Delphi, всякие Operon'ы.
Обычно всё кончается либо “побитием горшков”, отказом от прямой совместимости с C, и прикручиванием трассирующего GC (с которым потом приходится бороться вечно), либо введением явного понятия “времени жизни” для переменных и развлекухой вокруг этого всего.
Пока только горстка языков прошли путь до конца и добрался до чего-то, на чём не страшно писать программу для управления ядерным реактором: Rust и Swift из больших
Большинство же как Delphi: у вас всё будет отлично… только если не вы не будете писать сложного кода… но для простого-то кода хватает “джентельменского набора” BASICа (классического: числа, строки, массивы… всё, хватит, наслаждайтесь)!
А почему нельзя из адреса поля вычесть размеры предыдущих полей с учетом выравнивания?
А откуда у вас возьмётся информация о том, какие там вообще поля имеются? Вот есть у вас ссылка на какой-нибудь int. Ну int и int, как узнать какой структоре он принадлежит?
P.S. А вообще развитие IT идёт, как положено, по спирали… только вот не по той спирали. Каждое следующее поколение умудряется решить ту же задачу, какую решали до них, только хуже и менее эффективно. В большинстве случаев. Впрочем я как-то говорил с математиками, у них та же история: процент людей, изобретающих что-то новое ничтожен, большая часть работ — это то, что было до них, только “с перламутровыми пуговицами”.
Так, стоп, что за паразитирование и в чём оно состоит?
В бессмысленной трате ресурсов, очевидно.
Если я из rust-а вызываю системную либу, написанную на сях - это тоже паразитирование?
Нет, потому что системная либа, написанная на сях, отработала — и успокоилась.
Если вы фортрановскую либу, дёргаете раз в 5 минут, когда пользователь просит график обновить — то оставшиеся 4 минуты 59 секунд у вас она не тратит вообще никаких ресурсов, а в последнюю секунду — потратит ровно столько, сколько потребуется на один график (даже если перед этим вы их уже оторисовали десять тысяч, но они вам пока не нужны и спокойно хранятся где-то в кеше).
Если есть крутая, уникальная либа под jvm и я её вызываю из языка без gc - это тоже паразитирование?
Если вы её вызываете, то тут ещё ладно. А если нет? Загрузили какую-нибудь крутую библиотеку для 3D-спецэффекктов в Protoshop, а пользователь нарисовал кубик и стар обратаывать его в 2D? JVM-runtime у вас всё равно будет “гудеть” производить какую-то бурную деятельность, жрать память и батарейку.
И это пока мы ещё не добавим другой рантайм — тут уже речь пойдёт не о бессмысленной трате ресурсов, а о том, как сделать, чтобы эта конструкция не обрушилась, выжрав всю память.
Любой язык с GC считает, что он в процессе — вамый важный, самый главный, что ради него вообще эту программу писали.
Даже если это крошечная библиотечка на 100 строк. Процитирую себя же самого из поста, на который вы затеяли отвечать:
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е.
С чего вы рассматриваете редкий и малоинтересный вариант, когда используются один рантайм, то есть редкие языки?
В Top10 языков с GC сейчас у нас в десятке: Java, Python, C#, VisualBasic, JavaScript. Общий рантайм только у VisualBasic и C#.
А что происходит если программисту на Java предлагают C# или наоборот? Я лучше нативную для моего рантайма поищу — разве не типичный ответ?
Языки с GC предполагают что в мире останется только один рантайм, но этого не просходило в прошлом, не происходит сейчас и не будет происходить в будущем.
При этом все они могут использовать нативные библиотеки (на C, C++, FORTRAN, Rust), а вот их частные библиотеки без их рантайма, увы, использовать невозможно.
Вот об этом паризитировании и речь: всё брать у нормальных языков, но ничего не давать взамен.
P.S. Замечу, что везде, где я пишу про GC нужно читать трассирующий GC. То есть такой, как в C#/Java/Go: “лезущий во все дыры” и требующий знания о том, живы или нет все объекты, в том числе те, которые созданы вообще в других языках, и которые его ну никаким боком касаться не должны. Некоторые бодро объявляют то, что есть в Rust или в Swift (а иногда даже в C++) “разновидностью GC”, но нет, это радикально разные вещи: автоматический подсчёт ссылок в Rust и Swift, всякие std::unique_ptr и std::shared_ptr в C++ действительно позволяют вам не писать вызов деаллокатора руками, но они, в отличие от “настоящего”, “трассирующего” GC не лезут куда их не просят. Для их работы не нужно нарушать инкапсуляцию: Box в Rust будет прекрасно работать независимо от наличия в языке стандартной библиотеки libstdc++. Запросы в неё уйдут только тогда, когда удаляемый Rust-объект будет содержать ссылку на C++-объект. И наоборот. а вот ситуация с GC — совсем иная. Максимум, что вы можете себе позволить - не запускать всю эту бандуру, пока не создадите первый объект. Создали хоть что-нибудь? Всё, теперь вам на “право использования GC” платить вечно (до окончания процесса в смысле… большинство языков с GC даже не предоставляют возможности остановить всё это и выгрузить библиотеку, когда она не нужна).
В рамках одной платформы (runtime-а) языки с GC совмещаются практически без жвачки/скотча/проволоки
Ну дык я об этом и говорю: хотите GC - выкиньте всё, что вы наробрали для других систем.
Если же в арсенале имеются жвачка/скотч/проволока, то внезапно оказывается, что код под JVM можно совмещать с нативным в обе стороны (при чём, на сколько я помню, даже не один способ есть), код на .NET еще легче чем в java совмещается с нативным (даже писать скотч и проволока не потребуется, надо будет только немного клея написать).
Это, собственно, то самое паразитирование, о котором я и пишу.
Аллокация в языках с GC по сложности - O(1), т.е., почти не зависит от объёма памяти.
Только при условии, что этой памяти у вас — дофига и больше. Если у вас есть информация, что кто-то где-то изобрёл GC, способный как-то работать в условиях, когда количество “живых” объектов сравнимо с объёмом доступной памяти — поделитесь ссылкой.
Я за этой темой не слежу (в силу бессмысленности), но во времена написания этой статьи ситуация была такая же, как и в прошлом веке: если вы можете выделить для системы с GC в 10 раз больше памяти, чем суммарный объём всех “живых” объектов — то время, затрачиваемое на GC, оказывается приемлемым, если “всего лишь в 4” — начинаются проблемы, при приближении к 2 — получаем катастрофу.
Не получится ли в итоге, что время, теряемое на поиск свободного участка в куче при каждой аллокации, сравнимо по порядку с временем работы GC (я не утверждаю, что оно будт одинаковым - всё-таки, GC еще и перемещать объекты может, да и на поиск тратится время)?
Нет, не получится. Описываемый вами эффект действительно может, в теории, наблюдаться (современные аллокаторы, скажем, создают пулы на каждый поток, чтобы память оттуда разрадавать, то есть им тоже нужен некоторый “запас” по памяти).
Однако это начинает происходить в момент, когда аналогичная система с GC уже упёрлась в свои пределы и либо начала тратить 99% времени на сам процесс распределения памяти, либо начала кидать OutOfMemoryError (притом, что память, теоретически, ещё не исчерпана, но найти её уже невозможно).
Они дошли до состояния, когда Линус аргументрированно высказывается на тему, что нужно поменять в Rust, чтобы его приняли.
При этом, что важно, ни одно из его требований не противоречит идеям разработчиков самого Rust: все они и так у них были в состоянии “а неплохо бы сделать такую шнягу”… просто рабочих рук не хватало.
Ясно, что если что-то лежит не в разделе “а было бы неплохо”, а в разделе “это нужно, чтобы Rust приняли в ядро”, то приоритет у таких фич повышается.
Так что… будем ждать.
Правда некоторые из нужных фичей весьма тяжёлые. Вот это вот, например.
С одной стороны решение принято: Rust поверх GCC одобрен. С другой… это ж сколько работы предстоит!
Мне кажется проще написать с нуля чем переписывать то что есть.
Чисто психологически - в первом случае ты создаешь что-то новое, во втором - исправляшь старое багованое.Переписывать — это все хотят. Google тоже отметился. Только не работает.
Ядро — это не только тысячи багов, но и тысячи, десятки тысяч, человеко-лет опыта, в том числе получеамого только на весьма экзотическом железе, кодифицированного в программе на C.
Воспроизвести это фактически невозможно. Недаром Microsoft в WSL2 отказался от идеи эмулировать Linux и взял готовое ядро.
Думаю что написание ОС будет сопровождаться так или иначе большим количеством unsafe раст кода.Пока неизвестно насколько много реально unsafe кода там потребуется. Часть ядра, делающая вещи, которые в безопасные абстракции не оборачиваются, на самом деле крошечная. Буквально 1-2%. Хотя там есть и довольно хитрые структуры данных, которые тоже в безопасный Rust не засунешь.
В любом случае даже если unsafe кода будет не 5%, а целых 10% — это сократит объём кода, где могут быть проблемы в 10 раз.
Некоторые облака и гораздо выше самолётов бывают.
И да, я не зря говорил именно про воздушный шар, а не про самолёт или парашют.
Уже в самом облаке, конечно, виден только туман. Но вот вблизи, когда расстояние несколько метров, это выглядит круто.
То же самое и со “столпами”: уже прямо внутри них, скорее всего, никакого особого вида там нету, но на расстоянии 5-10 световых лет (а может и на расстоянии 1го светового года) они бы выглядели офигительно.
Неясно только может ли там где-нибудь существовать цивилизация, способная это всё увидеть...
Не знаю что вы там наблюдаете в иллюминатор самолёта, они, так-то, стараются в сами облака не залетать. Но если вы когда-нибудь летали на водушном шаре, то уж точно так бы не говорили. Вот тут кто-то даже видео снял — облака вблизи реально впечатляют.
Обоначать оно может что угодно, только это всё были влажные мрии. Первый процессор, EV4 21064 вышел в 1992, последний, EV6 21264 — в 1998м.
Есть ещё, правда, вами упомянутый EV7 21364, ну так он тоже должен был в 1999м выйти, то, что он вышел через 4 года после этого — это скорее курьёз.
Dec Alpha - процессор конца XX века, так же как Itanic — процессор первого десятилетия XXI.
Хотя его Intel до сих пор отгружает (и будет ещё целых два дня отгружать!), но вы же не собираетесь, надеюсь, заявлять, что в 2020х он ещё кого-то интересует?
Я понимаю, если бы был ИИ который написал код и сделал корпорацию и люди не смогли с ним конкурировать…Вполне возможно что, после изобретения “сильного ИИ”, и появится. Но непонятно почему он ринется замещать именно программистов и, главное, почему его вообще должны будут интересовать заказчики с их дикими хотелками.
Ну то есть как я и сказал: потеряют работу люди с мизерным опытом, знаниями и умениями. Условные программисты после курсов “как стать крутым профи за 21 день”.
Ну дык это и везде происходит: даже внедрение автопилота не высвободит шофёров полярных экспедиций или там водителей автокранов. А уж врачи могут не опасаться ничего блишайшие бог знает сколько лет: спрос на врачей превышает их наличие в разы, так что пока ИИ сделает ненужным ну вот хоть кого-то (кроме идиотов и дуболомов, к которым идти — лучше уж дома посидеть, авось само пройдёт), пройдут десятилетия.
Начинается всё с низкоквалифицированных рабочих. А уж какой специальности оные: строители или ИТшники — неважно.
Я просто к тому, что тут жалуются, что программисты к 40 годам приобретают профзаболевания. А непрограммисты? Если там шить, строгать или землю копать — все здоровые будут? Да?
Ну поговорите со своими знакомыми других специальностей, иллюзии развеются…
Ваше имя не Дункан Маклауд, часом? А то для большинства людей то, что случилось буквально в прошлом веке — ни разу не “совсем недавно”… уже даже все патенты протухли, там срок давности 20 лет…
И даже у майкрософт у которых есть операционка не в силах выйти на железный рынок со своим железом так широко как это делает Эппл.Главное не втом, что она не могут выйти. Главное— они не могут уйти.
Apple меняла платформу трижды. И все три раза важным элементом манёвра был отказ от использования топовых комплектующих старой архитектуры после выхода новой. Ни одной модели Mac на 80686 не было. На одного лаптопа на 64-битных PowerPC не было. И Ryzen тоже не замечен ни в одной модели.
И вот этого как раз Microsoft добиться не может… а так да, всё верно.
Насколько я помню статью, к 40 годам программистов без болезней почти не было.А непрограммистов?
Госсподя…
А до того, как стать Data Engineer, я потратил 1.5 года, чтобы изучить Data Science, и после этого не смог найти работу, так как порог для входа человеку без опыта просто зашкаливал по требованиям. И на собеседованиях не жаловали – гоняли по полной по математике, статистике и тд. При этом я бы не сказал, что я ничего не знал о своей профессии. Пришлось даже в универ на магистратуру поступить, чтобы изучить как можно глубже. Кроме времени потратил около $6 тыс. Мне это говорит о том, что конкуренция со стороны программистов-сайентистов уже больше, чем необходимо бизнесу.А мне это говорит о том, что “халява кончилась”. И всё. Да, дикая нехватка программистов в нулевые привела к феномену, когда люди, пройдя двух-трехнедельные курсы, могли претендовать на ту же зарплату, что, скажем, у врачей, отучившихся лет 8-10 минимум (5-6 собственно обучение, потом ординатура без которой вас никто на работу не возьмёт).
Сейчас программистам всего-навсего предлагают обучиться плюс-минус столько же, сколько в других областях — и сразу начались стоны.
Заменит ИИ кого-нибудь там или нет, но в любом случае пока ваша “суперсистема” не сможет создать ну, скажем, ядро OS (хоть какое-нибудь, фиг с ним, с “лучше и быстрее, чем те же программисты… даже топовые”) — говорить не о чем.
Пока что ИИ освоил решение типовых задач. Создание 100500го магазина (такого же, как и все предыдущие, только с другими “рюшечками”) — легко. Написать что-то хоть сколько-нибудь уникальное — фиг.
Нет никаких выборок, не на чём обучаться. Даже банальное создание языка программирования ИИ и близко недоступно. Хотя вроде их и тысячи, но потроха у них настолько разные, что никакое машинное обучение ничего там сотворить пока неспособно.
Ну то есть я угадал? Вам нужна была “Lua с перламутровыми пуговоцами”?
Ну что ж… будет интересно посмотреть когда вы свой язык забросите и что будете делать с завязанными на него проектами.
Всяческих узбеков.
Я вижу, вы взялись унижать и оскорблять.Где, кого, как? Какашкоязык — это, в принципе, состояние любого нового языка сразу после релиза, “микроязыка” — в особенности. Даже на каком-нибудь оригинальном Pascal (где не было указателей на функций) мало чего можно написать.
Уж сколько я этих поделок видел. Конечных состояний в 99% случаев — ровно два: либо язык удовлетворяет потребности автора, но не позволяет решать почти никаких других задач (выпиливается из соотвествующих проектов при первой же возможности как только отттуда свалит автор), либо, что куда хуже, им начинают пользоваться, по необходимости, многие — а в результате получаем многоуровневые слои костылей (что-нибудь типа такого).
В очень редких случаях языку-таки везёт и, вбухав в него тысячи человеко-лет, его доводят до состояния, когда при работе с ним не очень тошнит (хорошо известные примеры — Java, JavaScript, PHP, Python), но как-то странно затевать что-то новое в рассчёте на то, что с вашим языков такое произойдёт.
Особенно с учётом того, что когда-то в далёком прошлом вы, кажется, публиковали достойные материалы.Было дело. Когда казалось, что на Хабре есть люди, которым было бы интересно чему-то научиться. Однако большинство — они ж чукчи-писатели, не чукчи-читатели. Ваш пример — как раз очень показателен.
Упоминание Go, Haskell, Rust, Swift я считаю вообще неуместным, поскольку всё это языки совершенно иного назначения.Это с какого перепугу? Вот вам скрипты на Go в системе сборки Android, Haskell используется для скриптов настолько часто (инструкция), что любители даже PureScript изобрели, чтобы всё это в браузере использовать, Swift тоже можно, было бы желание. Вот Rust да, в последнее время на нём как-то перестали скрипты писать.
Остаётся Lua. Ну а преимущества относительно Lua я перечислил выше.Ну то есть мотивация в стиле “ничего, кроме C и Lua я толком не знаю, но я ж не гений, я не мегагений, я омегагений — ща как создам… все ахнут”.
Таким путём можно создать только какашкоязык. Если вы “попадёте в струю” (как один известный товарищ сумел), то ваш язык, возможно, подхватят другие (как с PHP случилось) и превратят его… ну не в конфетку, конечно, но хотя бы во что-то, от чего при первом взгляде сразу глаза слезиться не будут.
Но это сродни выигрышу в лотерею, вряд ли вы на это рассчитываете.
Вот потому я и пытаюсь понять — зачем?
Этого для начала вполне достаточно.Для начала чего, извините? Чтобы вы сами смогли свой язык использовать? Для этого вообще почти ничего не нужно: вы-то всё про него знаете и “делать странного” не будете.
А вот когда им начнут пользоваться другие… вот тут-то и начинаются чудеса: либо вам приходится составлять талмуды на тысячи страниц с сотнями правил на тему “как правильно держать наш телефон” (C и С++ прекрасные примеры), либо потребуется в ваш язык кому-то вбухать сотни (или, скорее, тысячи) человеко-лет разработки.
Я не вижу просто смысла изобретать ещё один какашкоязык непонятно для чего.
Если бы это была курсовая или даже дипломная работа — это можно было бы понять… хотя нет, всё равно нельзя: там обычно новизна требуется. Но какая цель вообще достигается этим велосипедом? Вроде как заявляется как скриптовый язык, но при этом структуры, совместимые с C, и списки. То есть вроде как что-то простое, но на самом деле нет.
Самое смешное, что я даже не говорю, что это не взлетит. Как раз если не влетит — так ещё полбеды, всё что случится — вы потеряете некое количество времени на бессмысленную работу.
А вот если взлетит — получим ещё несколько тысяч (или десятков тысяч) разработчиков, вынужденных тратить время и силы на то, что уже до них много раз сделали. На других языках.
Цель у этого всего какая? Куда это всё? Что вы умеете делать лучше, чем другие, те же Go, Lua, Haskell или Rust со Swift ом?
А уж если мы ссылаемся на int, который просто будет выкинут на мороз, когда удалится структура — это уже из области ССЗБ.А тогда нафига вообще огород городить, если несмотря на “автоматическое управление памятью” у вас всё равно никаких гарантий ничего нету?
Меня посещало дежавю — полуавтоматическое управление памятью в Delphi.Ну да, масса языков через это проходят: C++, Delphi, всякие Operon'ы.
Обычно всё кончается либо “побитием горшков”, отказом от прямой совместимости с C, и прикручиванием трассирующего GC (с которым потом приходится бороться вечно), либо введением явного понятия “времени жизни” для переменных и развлекухой вокруг этого всего.
Пока только горстка языков прошли путь до конца и добрался до чего-то, на чём не страшно писать программу для управления ядерным реактором: Rust и Swift из больших
Большинство же как Delphi: у вас всё будет отлично… только если не вы не будете писать сложного кода… но для простого-то кода хватает “джентельменского набора” BASICа (классического: числа, строки, массивы… всё, хватит, наслаждайтесь)!
А почему нельзя из адреса поля вычесть размеры предыдущих полей с учетом выравнивания?А откуда у вас возьмётся информация о том, какие там вообще поля имеются? Вот есть у вас ссылка на какой-нибудь int. Ну int и int, как узнать какой структоре он принадлежит?
P.S. А вообще развитие IT идёт, как положено, по спирали… только вот не по той спирали. Каждое следующее поколение умудряется решить ту же задачу, какую решали до них, только хуже и менее эффективно. В большинстве случаев. Впрочем я как-то говорил с математиками, у них та же история: процент людей, изобретающих что-то новое ничтожен, большая часть работ — это то, что было до них, только “с перламутровыми пуговицами”.
Так, стоп, что за паразитирование и в чём оно состоит?В бессмысленной трате ресурсов, очевидно.
Если я из rust-а вызываю системную либу, написанную на сях - это тоже паразитирование?Нет, потому что системная либа, написанная на сях, отработала — и успокоилась.
Если вы фортрановскую либу, дёргаете раз в 5 минут, когда пользователь просит график обновить — то оставшиеся 4 минуты 59 секунд у вас она не тратит вообще никаких ресурсов, а в последнюю секунду — потратит ровно столько, сколько потребуется на один график (даже если перед этим вы их уже оторисовали десять тысяч, но они вам пока не нужны и спокойно хранятся где-то в кеше).
Если есть крутая, уникальная либа под jvm и я её вызываю из языка без gc - это тоже паразитирование?Если вы её вызываете, то тут ещё ладно. А если нет? Загрузили какую-нибудь крутую библиотеку для 3D-спецэффекктов в Protoshop, а пользователь нарисовал кубик и стар обратаывать его в 2D? JVM-runtime у вас всё равно будет “гудеть” производить какую-то бурную деятельность, жрать память и батарейку.
И это пока мы ещё не добавим другой рантайм — тут уже речь пойдёт не о бессмысленной трате ресурсов, а о том, как сделать, чтобы эта конструкция не обрушилась, выжрав всю память.
Любой язык с GC считает, что он в процессе — вамый важный, самый главный, что ради него вообще эту программу писали.
Даже если это крошечная библиотечка на 100 строк. Процитирую себя же самого из поста, на который вы затеяли отвечать:
А теперь давайте рассмотрим такой же вариант, только матбиблиотека у нас будет на C#, модуль на Go, ну и там пара компонент ещё на каком-нибудь V8 и Lisp'е.С чего вы рассматриваете редкий и малоинтересный вариант, когда используются один рантайм, то есть редкие языки?
В Top10 языков с GC сейчас у нас в десятке: Java, Python, C#, VisualBasic, JavaScript. Общий рантайм только у VisualBasic и C#.
А что происходит если программисту на Java предлагают C# или наоборот? Я лучше нативную для моего рантайма поищу — разве не типичный ответ?
Языки с GC предполагают что в мире останется только один рантайм, но этого не просходило в прошлом, не происходит сейчас и не будет происходить в будущем.
При этом все они могут использовать нативные библиотеки (на C, C++, FORTRAN, Rust), а вот их частные библиотеки без их рантайма, увы, использовать невозможно.
Вот об этом паризитировании и речь: всё брать у нормальных языков, но ничего не давать взамен.
P.S. Замечу, что везде, где я пишу про GC нужно читать трассирующий GC. То есть такой, как в C#/Java/Go: “лезущий во все дыры” и требующий знания о том, живы или нет все объекты, в том числе те, которые созданы вообще в других языках, и которые его ну никаким боком касаться не должны. Некоторые бодро объявляют то, что есть в Rust или в Swift (а иногда даже в C++) “разновидностью GC”, но нет, это радикально разные вещи: автоматический подсчёт ссылок в Rust и Swift, всякие std::unique_ptr и std::shared_ptr в C++ действительно позволяют вам не писать вызов деаллокатора руками, но они, в отличие от “настоящего”, “трассирующего” GC не лезут куда их не просят. Для их работы не нужно нарушать инкапсуляцию: Box в Rust будет прекрасно работать независимо от наличия в языке стандартной библиотеки libstdc++. Запросы в неё уйдут только тогда, когда удаляемый Rust-объект будет содержать ссылку на C++-объект. И наоборот. а вот ситуация с GC — совсем иная. Максимум, что вы можете себе позволить - не запускать всю эту бандуру, пока не создадите первый объект. Создали хоть что-нибудь? Всё, теперь вам на “право использования GC” платить вечно (до окончания процесса в смысле… большинство языков с GC даже не предоставляют возможности остановить всё это и выгрузить библиотеку, когда она не нужна).
В рамках одной платформы (runtime-а) языки с GC совмещаются практически без жвачки/скотча/проволокиНу дык я об этом и говорю: хотите GC - выкиньте всё, что вы наробрали для других систем.
Если же в арсенале имеются жвачка/скотч/проволока, то внезапно оказывается, что код под JVM можно совмещать с нативным в обе стороны (при чём, на сколько я помню, даже не один способ есть), код на .NET еще легче чем в java совмещается с нативным (даже писать скотч и проволока не потребуется, надо будет только немного клея написать).Это, собственно, то самое паразитирование, о котором я и пишу.
Аллокация в языках с GC по сложности - O(1), т.е., почти не зависит от объёма памяти.Только при условии, что этой памяти у вас — дофига и больше. Если у вас есть информация, что кто-то где-то изобрёл GC, способный как-то работать в условиях, когда количество “живых” объектов сравнимо с объёмом доступной памяти — поделитесь ссылкой.
Я за этой темой не слежу (в силу бессмысленности), но во времена написания этой статьи ситуация была такая же, как и в прошлом веке: если вы можете выделить для системы с GC в 10 раз больше памяти, чем суммарный объём всех “живых” объектов — то время, затрачиваемое на GC, оказывается приемлемым, если “всего лишь в 4” — начинаются проблемы, при приближении к 2 — получаем катастрофу.
Не получится ли в итоге, что время, теряемое на поиск свободного участка в куче при каждой аллокации, сравнимо по порядку с временем работы GC (я не утверждаю, что оно будт одинаковым - всё-таки, GC еще и перемещать объекты может, да и на поиск тратится время)?Нет, не получится. Описываемый вами эффект действительно может, в теории, наблюдаться (современные аллокаторы, скажем, создают пулы на каждый поток, чтобы память оттуда разрадавать, то есть им тоже нужен некоторый “запас” по памяти).
Однако это начинает происходить в момент, когда аналогичная система с GC уже упёрлась в свои пределы и либо начала тратить 99% времени на сам процесс распределения памяти, либо начала кидать OutOfMemoryError (притом, что память, теоретически, ещё не исчерпана, но найти её уже невозможно).