Rust и двусвязный список

ну это совсем не то, чем когда жрать нечего или все кругом бандиты и ты рискуешь, просто выходя на улицу. Достаточно просто не страдать хернёй, а радоваться (умеренно), что мы относимся к жирной прослойке.

Если ЯП рассматривать как инструмент добывания пропитания (решения задач), то проблемантика его дизайна меняется кардинально.

Прямо свет в конце тоннеля. Пойти, что ли, выучить С++?

Допустим, что у меня завышенные ожидания что она чистая, а она на самом деле вся в пыли.

Ещё лучше можно сказать: есть автомобиль, колесо, гайки на нём. Можно открутить ручным ключом, можно пневматическим, можно на сервисе заплатить, можно пользоваться каршерингом. Дальнейшие оптимизации недостижимы. А в ЯП они кажутся достижимыми, в этом и засада.

не только кажутся, но и на самом деле достижимы, но инфраструктуры для этого пока что нет

те же автомобили кстати тюнят и дейтелят направо и налево, разве что самолет из них не делают

Допустим, что у меня завышенные ожидания что она чистая,

Это не завышенные ожидания, а несоответствие ожиданий реальности. Вполне нормальная рабочая ситуация.

Завышенные ожидания – это когда ты думал, что сможешь написать b-tree за неделю, а это заняло полгода. Нереалистичные ожидания – это когда закладываешься на что-то, что физически невозможно (но об этом или по какой-то причине не известно, или просто не верится). Например, на то, что может существовать язык, на котором любая программа становится «простой и понятной» (вариант: «все ошибки – это ошибки типизации»). Страдание приносит то, что человек или тратит силы нерационально, или вообще – впустую.

Прямо свет в конце тоннеля. Пойти, что ли, выучить С++?

Только если у тебя есть для него задачи. Иначе ты потратишь силы впустую.

Вот у меня задачи для С++ есть. И не то, что я этот язык прям так любою. У меня с ним классический love/hate relationship. Просто этот язык хорошо(х) вписывается в проблематику решаемых задач. А там, где он не вписывается, можно ситуацию исправить.

(х) т.е. позволяет решать задачу имеющимися в наличии силами

С++ не надо «исправлять».

Дык, это не я предлагаю. Зачем со мной спорить? (:

Если на то пошло, то считаю, что любой (живой) язык со временем распухает от фич и сахара. Плюс начинают вылезать последствия принятых решений, которые уже не исправить. С другой стороны, накапливается кодовая база и инфраструктура, поэтому новуму языку надо предлагать что-то заметно лучшее чтобы взлететь. Ну или его может пропихнуть корпорация.

и вот уже в рамках тулинга можно код тщательно обвешать аннотациями и санитайзерами на основе аннотаций

Это не решит все проблемы.

UB в целых можно исправлять разными способами — и при этом, как мне кажется, не сломается вообще ничего.

Может быть. Мне смутно припоминает предложение запретить неинициализированные переменные в С++. Просто так предложение, естественно, не прошло бы - деградирует производительность. Но даже предложение явно помечать «вот это инициализировать мы специально не будем» всё равно не прошло. Я к тому, что даже на очевидно полезные и безобидные изменения могут найтись возражения.

Если на то пошло, то считаю, что любой (живой) язык со временем распухает от фич и сахара.

Вот-вот. Соответственно любой разумный проектировщик нового языка должен заранее решить, что он противопоставит этому.

А между тем люди продолжают проектировать языки так, будто они с самого начала будут идеальными, гы-гы-гы.

Соответственно любой разумный проектировщик нового языка должен заранее решить, что он противопоставит этому.

А что, у кого-то получилось?

Тут ведь попахивает требованием уметь предсказывать будущее.

Вот, к примеру, go — название такое, что не гуглится. Закапывать рано, но оценку снижаем на 20%.

Для этого давно придумали костыли - добавляем суффикс «lang» и всё гуглится нормально. «Снижать оценку» из-за этого не выглядит разумным.

Отсутствуют дженерики — оценку снижаем в 3…4 раза.

Смешно тут, что пока в Go отсутствовали дженерики, множество любителей языка объявляли это фичей. Потом пришлось переобуваться и то встречал заявления, что добавлять дженерики было ошибкой.

Я, знаете ли, немного могу предсказывать. Через пару часов у меня тут будет темно, а через полгода начнется зима. И даже знаю, что я противопоставлю зиме — теплую одежду!

Вот я какой предсказамус! Не то что там какие-то дизайнеры языков.

Вот-вот. Соответственно любой разумный проектировщик нового языка должен заранее решить, что он противопоставит этому.

Тебя не смущает, что раз до сих пор не придумали хорошего способа с этим бороться, то не всё так просто?

Ну а вообще что-то пытаются придумывать. В расте вон редакции есть.

Тебя не смущает, что раз до сих пор не придумали хорошего способа с этим бороться, то не всё так просто?

А кто-то вообще думал на эту тему до проектирования языка (или во время)?

Ну или хотя бы написал, что он думал и в каком ключе?

Мне кажется, что все происходящее вполне укладывается в рамки «и вот опять неожиданно наступила зима».

Я, знаете ли, немного могу предсказывать. Через пару часов у меня тут будет темно, а через полгода начнется зима. И даже знаю, что я противопоставлю зиме — теплую одежду!

Давай тогда ближе к теме: предскажи, что будет с программированием лет через десять и что с этим надо делать уже сейчас. Если действительно хороший предсказатель, то можешь начинать пилить «язык-убийцу». Как раз к тому времени что-то рабочее должно быть, а существующие языки окончательно погрязнут под гнётом костылей.

Опять же, если взять С++, то 30 лет назад было сложновато закладывать, скажем, асинхронное программирование в язык. А если бы это и сделали, то очень может быть, что язык не взлетел как как народ не понял бы нафига такое.

Давай тогда ближе к теме: предскажи, что будет с программированием лет через десять и что с этим надо делать уже сейчас.

Это очень хороший вопрос, но я подхожу к делу гораздо проще и абстрактнее. Не важно, КУДА язык будет расти — важно то, что с его ожирением придется бороться, и надо заранее знать как.

А по твоему вопросу (правда в разрезе DB) люди работают, и я видел картинку, но она у меня на смартфоне сейчас.

Ну или хотя бы написал, что он думал и в каком ключе?

Мне гуглом поработать или что? В контексте С++ есть «дизайн и эволюция», про раст мне только разрозненные материалы попадались, но можно почитать RFC.

Это не решит все проблемы.

Это решить частично некоторую часть проблем.

Например, я, тщательно обмазавшись санитайзерами clang, смог за несколько недель разработать и отладить многопоточный кэширующий storage backend для облака. Оно все в процессе выглядело совсем не так изящно и стерильно, как в «правильных» языках, но в итоге работало, не текло и не падало. Вообще. Что мне, в конечном итоге, и надо.

Это все раздумья на тему «как добавить жира». А можешь ты хоть одно раздумье вспомнить на тему «как сделать липосакцию»? А чтобы оно еще было сделано до дизайна языка?!

Я, кстати, даже не знаю по каким словам такое гуглить.

вот кстати не то что я видел, а слегка в тему https://www.dynacentrix.com/en/2019-gartner-datascience-machine-learning-the-...

предсказание из 2019 на 2022

Не важно, КУДА язык будет расти — важно то, что с его ожирением придется бороться, и надо заранее знать как.

Дык, предложи хоть какое-то решение. «Сбрасывать вес» можно только выкидывая фичи, а на это идти ой как не хотят. И по вполне очевидным причинам. Причём выжидать и не спешить «обжираться фичами» тоже плохой вариант: и С++ и джаву во времена застоя как раз начали теснить и оба языка в итоге ускорили развитие.

Повторюсь: в расте решили ввести редакции. Это когда код помечается как относящийся к одной из них и компилятор умеет собирать любые редакции. То есть, можно писать приложение пользуясь 2018 редакцией и спокойно подключая библиотеки как из 2015, так и из 2021. Но и это решение не назовёшь беспроблемным: если активно бороться с «ожирением», то может оказаться так, что заглянув в старую библиотеку ты просто ничего не поймёшь.

Ещё интересно было бы посмотреть на минималистичный и расширяемый язык, но таких хотя бы относительно популярных я не знаю. Поэтому и сложно судить насколько с этой проблемой справляется условный Racket.

Дык, предложи хоть какое-то решение

Решение пока что обдумывается, но важно что я этот вопрос хотя бы ставлю.

А можешь ты хоть одно раздумье вспомнить на тему «как сделать липосакцию»?

А я хз, что тут вообще можно придумать кроме депрекейта фич. Кажется, что размышлять тут есть смысл только о том стоит ли оно того или нет.

Решение пока что обдумывается, но важно что я этот вопрос хотя бы ставлю.

Можно, конечно, тешить себя мыслью, что ты первый, кто до этого додумался, но я как-то очень сомневаюсь. (:

Дык, предложи хоть какое-то решение.

Нужны Copilot-подобные помощники, которые будут снижать видимую программисту описательную сложность программ.

Можно, конечно, тешить себя мыслью, что ты первый, кто до этого додумался, но я как-то очень сомневаюсь. (:

Ты так разговариваешь, как будто дизайнеры недоязчков типа go вообще думают. Ты видел limbo? Ну вот Пайк слепил че-то очень похожее на привычное ему limbo, но со вкусом гугля. Оно и взлетело, так как было (сильно?) лучше питона для гуглезадач при похожей на питон сложности для мартышки.

У меня вообще не уверен что есть задачи. Но они есть у других людей и эти другие люди за них платят.

поэтому новуму языку надо предлагать что-то заметно лучшее чтобы взлететь. Ну или его может пропихнуть корпорация.

Не «или», а «и».

Да что угодно на самом деле. Можно тупо завести счётчик дыр и при достижении им порога вызвать операцию упаковки

И сделать свой маллок-велосипед. Тут я - мастер костылей а не ты. Скройся XD

компилятор умеет собирать любые редакции

Мрак, как сказала бы Эллочка-людоедка.

Если у тебя разбросано 10 ссылок на ноды, то рано или поздно одну из этих нод удалят

И что? И объекты иногда удаляют. Какая трагедия, кто-то free сделал. Можешь вообще free никогда не делать, запилить пул переиспользовать структуры проверяя и зачищая все поля, как шиз. Но стоп, у тебя же так получится почти что жабка с велогц, oh shi..!

Если тебе нужен язык «для души», то С++ прекрасно подойдет, если душа склонна к низкоуровневому системному full-stack инжинирингу. Если бы я сейчас выходил на пенсию и отходил о дел, я бы занялся дизайном акселераторов для ИИ. Или, чем-то таким. Последний, кстати, Латтнером(x) в SiFive делается.

(x) который llvm и clang сделал.

если к описанной тобой картинке добавить одну косвенную адресацию и gc в рамках твоего пула, то получится может даже и прилично — правда я не знаю, насколько тут раст поможет, а насколько будет мешать (подозреваю что в gc будет unsafe во все поля)

Нужны Copilot-подобные помощники, которые будут снижать видимую программисту описательную сложность программ.

Честно говоря, не представляю как это должно выглядеть.

Не «или», а «и».

Да, но не совсем. Вот скажем, Swift - его эпл делали изначально для себя и у тебя особо и выбора нет, если хочешь писать приложения под их инфраструктуру. С Go уже чуть иначе. Да, бейджик «язык от гугла» даёт большой бонус к пиару, но люди-то его добровольно берут. А скалу кто пропихивает? Можно, конечно, поспорить взлетел ли язык, но работу на нём найти можно. Ну или тот же раст - изначально это был проект одного чувака, потом его взяла под крыло мозилла. Но этy контору даже в лучшие времена и близко не поставишь в один ряд с гуглом, эплом и прочими. Сейчас вот амазон с растом заигрывает, но реального пропихивания, как по мне нет. Только всякие дурацкие рекламные статьи иногда постят. И то с этим «сообщество» лучше справляется.

Мрак, как сказала бы Эллочка-людоедка.

Обоснуй что ли.

Нужны Copilot-подобные помощники, которые будут снижать видимую программисту описательную сложность программ.

Это следующий или после-следующий уровень. И я не вижу, как он снизит ожирение языков.

При этом видимую сложность ты для всех не снизишь (а для остальных сложность будет снижена и без ИИ). Ты сможешь упростить, ускорить, и сделать более комфортной работу с имеющейся сложностью. Упростить работу, а не видимую сложность.

Впрочем, можно по-разному толковать слово «видимую». В одном из вариантов толкования я соглашусь с твоим мнением.

Да, бейджик «язык от гугла» даёт большой бонус к пиару, но люди-то его добровольно берут.

Потому что задачи как у гугла достаточно распространены.

Это называется автоматическое программирование. Ты создаешь спецификацию, по этой спецификации создается код, который ты потом руками «дорабатываешь». Языковые модели позволили вывести процесс на качественно новый уровень по сравнению с тем, что было раньше, но пока что это всё же еще демки/игрушки. Тем не менее, оно развивается быстрее, чем ожидали пессимисты и в будущем трансформируется в AI-assisted programming. Что изменит как workflow, так и дизайн самих языков. Последние будут оптимизироваться в сторону повышения практической эффективности ИИ (тех же языковых моделей). Например, в сторону меньшего дорабатывания потом кода «руками».

Впрочем, можно по-разному толковать слово «видимую». В одном из вариантов толкования я соглашусь с твоим мнением.

Можно понимать, как эффективную размерность. Размерность ассемблерного кода выше, чем размерность эквивалентного С-кода.

Мне C++ не подойдёт. Потому что очень уродлив во всём, начиная с синтаксиса. После лиспа, тикля, Оберона, Го на этот ужас просто невозможно смотреть без слёз. Для души почти более-менее подходит Оберон. Если бы не этические заморочки, уххх я бы из него конфетку сделал.

ну это довольно просто - количество взаимосвязей, которые нужно учитывать в компиляторе, велико и будет расти со временем. На это будет уходить всё большая доля ресурса разработчиков, плюс могут возникнуть непреодолимые трудности, которые помешают добавлять в язык новые фичи из-за старых. Плюс из-за наличия старого кода не будут достигнуты какие-то целевые показатели.

Возможно, есть и исключения из правила. Так-то создать язык не то, чтобы прям слишком дорого, по сравнению с иными приложениями. Но, как правило, за успехами ЯП стоит та или иная сила.

разработать и отладить многопоточный кэширующий storage backend для облака

У вас там что, какой-то жесткий lock-free был во все поля?

Ну или тот же раст - изначально это был проект одного чувака, потом его взяла под крыло мозилла. Но этy контору даже в лучшие времена и близко не поставишь в один ряд с гуглом, эплом и прочими.

Если говорить про одного чувака, то на ум приходит Уолтер Брайт с D. Вот там да, долго все на одном чуваке без поддержки корпораций держалось.

А Mozilla среди разработчиков известная компания была, так что буст хайпу обеспечить смогла. Особенно с учетом того, что предлагалась реальная замена C++.

Хвала небесам, обошлись fine-grained locks.

т.е. на std::thread/mutex/condition_variable?

Мне C++ не подойдёт. Потому что очень уродлив во всём, начиная с синтаксиса.

Это ты еще наверно не видел синтаксис исключений в списках инициализации конструкторов с++. На ночь лучше не смотреть.

Если бы не этические заморочки, уххх я бы из него конфетку сделал.

а написать «что такое конфетка» (ну там фичи, goals, not goals) тебе этические заморочки позволяют?

Да, на них.

Да это всё уже давно делали, сделали вылизали и переделали 10 раз. И тут приходит растер и такой, ололо, ничего не нужно, структуры с ссылками не нужны, вектора хватит всем, раст - крута, гц - говно, а вы все - мудаки. А потом предлагает делать точно такие же, по сути, вещи, но велики с костылями и на руст. Ну чисто адепт. Царь был прав. Всегда был прав.