языки без сборки мусора

С уже выбросил? На машинных кодах все переписал, ну чтобы не ограничить себя не дай бог в чем-то? Реализовал на машкодах все нужные метаязыки?

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

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

что опытный программист реализует нужные ему концепции с помощью отдельной программы-метаязыка.

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

Для сишки нет ничего подобного нет.

Что увеличивает сроки разработки в разы.

Преодолимо? Теоретически да. Практически - на это уйдут годы и на фоне уже работающей жабы первое время все это будет смотреться бледно. И как это продать? Как жабу без ГЦ? Как жабу с низким потреблением памяти? Хз.

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

https://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D0%B5%D0%BF%D1%8B%D0%B5_%D0%B8_%D1%81%D0%BB%D0%BE%D0%BD

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

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

Если ты пишешь систему в 1 000 000 строчек кода минимум, на все выделено меньше года, и где к данным по очереди применяется 500 трансформаций через 30 подсистем, то тебе не ясно зачем психически здоровому человеку управлять памятью во всех 500. Проще бины поподключать через Spring Integration и какой-то bus, а потом лениво профилировать узкие места, и то, по мере надобности

Визуальный ЯП от украинского упоранта уже советовали?

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

И тут ты обделался, целиком и полностью. Все недоязычки, в том числе и говнораст, не имеет каких-либо оптимизаторов - поэтому всё, что там есть - ничего не значит.

Таким образом используя llvm/jvm/ещё что-то - ты попросту всегда переводишь свой код в сишку(в случае с ллвм), либо в ещё более худшее представление в случае с jvm. И теряешь всю хайлевел семантику.

Именно поэтому, маня, говнораст и говно. И ворованный оптимизатор тоже говно.

Если ты пишешь систему в 1 000 000 строчек кода минимум, на все выделено меньше года, и где к данным по очереди применяется 500 трансформаций через 30 подсистем, то тебе не ясно зачем психически здоровому человеку управлять памятью во всех 500. Проще бины поподключать через Spring Integration и какой-то bus, а потом лениво профилировать узкие места, и то, по мере надобности

Опять ты всё перепутал. Жава - это легаси-говно для плебеев. 99% макак там не может писать код(включая тебя) и приходится писать код на xml. Это единственное, что могут осилил макаки.

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

Для сишки нет ничего подобного нет.

хохо, ядро Linux

Что увеличивает сроки разработки в разы.

разработай низкоуровневый драйвер на жабе. Хоть один.

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

хохо, ядро Linux

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

разработай низкоуровневый драйвер на жабе. Хоть один.

Даже пытаться не буду. Жаба это ответ на другие вопросы, она принципиально непригодна для лоулевел.

GC хорош в 99% случаев. А там где он плох, там всё что угодно плохо и отсутствие GC не даёт автоматического решения проблемы.

Давным давно, в незапамятные времена, когда ГЦ только-только показался на свет, один чувак защитил докторскую, в которой показал, что использование ГЦ увеличивает потребляемую память примерно в 5 раз (теоретический предел, можно хуже), на коротких дистанциях и в некоторых кейсах способно увеличивать производительность за счет снижения количества обращений к аллокатору, а на длинных может вызывать проблемы с залипаниями во время сборки мусора, что неизлечимо даже теоретически.

Если эти особенности нас напрочь не напрягают, то ГЦ лучше, потому что меньше кода и пространства для маневра у рукожопов.

Хотя кроме ГЦ, подсчета ссылок и сборки мусора вручную есть и другие стратегии управления памятью. Но они как-то не в тренде, и, насколько мне известно, не реализованы ни в одном ЯП из коробки.

Планканкюль

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

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

один чувак защитил докторскую, в которой показал, что использование ГЦ увеличивает потребляемую память примерно в 5 раз

По сравнению с чем? Чисто теоретически без GC я могу не делать free никогда и любой GC будет лучше чем это.

успело нахерачить человечество

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

И тут ты обделался, целиком и полностью. Все недоязычки, в том числе и говнораст, не имеет каких-либо оптимизаторов - поэтому всё, что там есть - ничего не значит.

Зато Haskell имеет оптимизатор. Поэтому fold f . map g . filter h превращается не в последовательное создание кучи промежуточных списков, а в один цикл с условием и аккумулятором. А если компилятор про списки не знает, то выкинуть создание, например, промежуточных QList он не может.

По сравнению с чем?

Вероятнее всего автор сравнивал ГЦ и ручное управление памятью. Всех деталей не упомнить, дело прошлое.

Чисто теоретически без GC я могу не делать free никогда и любой GC будет лучше чем это.

Чисто теоретически память можно выделять однажды, в начале работы программы, и освобождать в конце, что будет лучше и дешевле любого GC. Хотя почему теоретически, в ембеде распространенный прием.

Мой поинт был в другом - в рандомно взятом бенче написанном рандомными васянами кресты нередко сосут.

Кресты там везде в топе. К тому же, тебя поимела пропаганда. Очевидно, что в ситуации со всеми этими бенчмарками управление памятью вообще ненужно. Зачем тогда вообще ГЦ? Ты сам понимаешь весь уровень нелепости происходящего?

Эти бенчмарки специально подобраны таким образом, что-бы ГЦ не проявлялся, специально подобраным таким образом, что-бы скриптуха не валялась в говне. Эти говнобенчмарки специально собираются каким-то говном в ситуации с С/С++, когда как для всего остального хомячки бегут за последними компиляторами.

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

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

Хомячки куда более активны, нежели адепты нормального языка. Хомячки так же могут писать на «С»/«С++» - именно так и работают все эти бенчмарки говна.

И это всего лишь для какого-то хеловорда.

И чем дальше - тем больше разница между скриптухой и нормальным языком.

Поэтому я останусь при своём мнении, GC хорош в 99% случаев. А там где он плох, там всё что угодно плохо и отсутствие GC не даёт автоматического решения проблемы.

Причём тут ГЦ? Проблема скриптухи не в том, что там есть ГЦ. Проблема скриптухи в том, что она говно. В том же говнорасте нету ГЦ(номинально, на самом деле семантически он там есть), но оно в говне.

В любом случае - все эти бенчмарки мусор нелепый, все эти потуги - мусор нелепый.

Чисто теоретически без GC я могу не делать free никогда

Я вот не понимаю - какое ещё, нахрен, free? free - это бездарное говно для плебеев. Без gc -не значит со free - это тезис твоей пропаганды.

GC будет лучше чем это.

Хейт гц в основном обусловлен набегами раст-биомусора. Буквально пару лет назад - это хомячки, как и ты, вылизывали жопу ГЦ. А правда всегда одна - что то говно, что то. И проблема не в ГЦ.

разработай низкоуровневый драйвер на жабе. Хоть один.

https://github.com/jnode/jnode/blob/master/fs/src/driver/org/jnode/driver/blo...

https://github.com/jnode/jnode/blob/master/fs/src/driver/org/jnode/driver/blo...

https://github.com/jnode/jnode/blob/master/gui/src/driver/org/jnode/driver/vi...

https://github.com/jnode/

так я же не нагуглить просил а разработать

http://www.jnode.org/node/175

Пояснения нужны?

Зато Haskell имеет оптимизатор.

Может ты сможешь написать ленивое умножение матриц, что-бы оно не сливало в 100000 раз C++? Уже не один хаскель-адепт на такой простой задаче обделался, хотя раст-адепт сам её придумал.

К тому же - хаскель не имеет никакого оптимизатора. Хомячки точно так же побежали на llvm.

Поэтому fold f . map g . filter h превращается не в последовательное создание кучи промежуточных списков

Это никак не связано с компилятором, к тому же никак хаскелю это не поможет.

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

По-первых упоминание плебейских списков и особенно qt - это уже позор. Это всё дристня для дошколят.

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

У тебя есть списки говна, но как только возникает реальная задача - оказывается, что тебе нужно идти и воровать нормальные массивы. И тут уже это говно начинает сегфолтится, а так же все твои маня-фантазии про «не в последовательность» превращаются в тыкву.

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

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

Именно поэтому всё это не работает и не будет работать никогда.

Может ты сможешь написать ленивое умножение матриц, что-бы оно не сливало в 100000 раз C++?

Ссылку на C++ пример дашь, чтобы не говорил потом, что я его намеренно плохо написал?

Судя по агентурным данным Царь молодой человек ~25 лет возраста, но читая подобное кажется что ворчит старик под 80 лет.

Без gc -не значит со free

Не значит, но альтернативы либо являются кривым недо-GC на коленке (привет shared_ptr), либо маргинальщиной.

RAII вполне альтернатива.

RAII вполне альтернатива

Вообще ни разу не альтернатива и никакого отношения к проблеме не имеет.

В нормальном С++ приложении большая часть памяти именно через RAII управляется.

Ссылку на C++ пример дашь, чтобы не говорил потом, что я его намеренно плохо написал?

А, ты хочешь написать. Ну давай, напиши и то и то. Это может даже тебе самому будет интересно - сможешь ли ты написать намеренно не плохо.

Если хочешь - можешь и не писать С++-версию. Напиши только хаскель-версию. https://gitlab.com/andalevor/mat_mul_test/blob/master/c_v1.c - вот обычный код, который нужно сделать ленивым. Всё это на лоре, очевидно, уже есть. Но для тебя же челендж - не гуглить.

Вот хеш 15 базовых строк на крестах: f346f017d8b55f669df8804592c74ae7c021e27bb5cba4d11bfd6319504f8348e9db5ac0c73ac0fc71b741affaa41826efebafcc6b71298d6d4300abf6873864

большая часть памяти именно через RAII управляется

Попробуй сделать связный список с помощью RAII.

Односвязный без проблем берем как raii примитив std::unique_ptr и фигачим. Ну и список в С++ (std::list) вполне часть языка и это тоже raii класс.

либо являются кривым недо-GC

У тебя методичка потекла. ГЦ и есть самое дырявое говно, а вот некие вариации локальных автоматизаций - это уже хоть что-то. ГЦ не может работать нормально в общем случае - это изначально сломанная концепция.

привет shared_ptr

Опять сломалась методичка - автоматизация free не отменяет free.

либо маргинальщиной.

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

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

А теперь подумай - почему же и за счёт чего работают value-типы. Неужели без free? А как же - маргинальщина же?

А если бы ты подумал чуть дальше, то ты бы осилил понять, что никакие аллокаторы дерьма(на free), гц и прочая дристня ненужна - она нужна только в крайне редких кейсах. В большинстве случаев же достаточно либо глобальных аллокаций, либо условной автоматической/стековой памяти. Если пойти и расширить этот подход - он и покроет вкупе с глобальной аллокацией почти все запросы.

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

Вот мы и получает, что плебей рожает дерьмо, а компилятор потом пытается это исправить. Очевидно, что такой подход обречён на неудачу. Он работает в ситуаици с хелвордами и именно поэтому и существуют подобные бенчмарки говна.

И в этом проблема. В самом ГЦ ничего плохого нет. Много где используется ГЦ, в том числе и в крестах(да и я сам его там юзаю). Проблема одна в другом - она в мусорном плебейском обобщении. Когда везде и всюду всё пытаются пихать под одну гребёнку. Тем самым ломается всё. Ломается нормальная архитектура, всё переусложняется и тысячи других проблема.

90% сложности обусловлены не задачей, а подходом. Универсальностью. Одни рабы срут говном, вторые это пытаются исправить снизу, другие сбоку, третьи сверху.

Можно плиз на идиоматичном хаскеле?
Строго в рамках Haskell2010/Haskell98: без Unsafe, без хитрых прагм.
Просто я намекаю, что GHC достаточно посредственно оптимизирует.

Попробуй сделать связный список с помощью RAII.

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

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

Поэтому ты будешь обязан вместе со списком таскать его локальный аллокатор. Этот аллокатор 1) не будет подвержен фрагментации. 2) будет обеспечивать максимальную локальность. 3) из-за малого размера - будет куда эффективнее. 4) он будет семантическим.

Четвёртый пункт самый важный. Он позволяет получить аллокатор на-халяву. Если у тебя уже есть список, то внутри списка ты можешь создать ещё один список. И будет у тебя внешний список и внутренний, а аллокация/деаллокация - просто перемещение бошки/хвоста из одного места в другое.

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

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

К тому же - raii тут ненужно. Выше уже правильно пацан сказал - список как контейнер уже берёт на себя управление памятью и тем самым решает проблему. Т.е. по-сути любой контейнер уже умножает тебя на ноль и использует описанный мню подход(пусть и в более убогом виде).

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

он будет семантическим

В мемасы. Царь всегда говорит что что-то «семантично» и этим все сказано. Никто не понимает о чем речь, потому что он сам придумал такое применение слова )

Никто не понимает о чем речь

Парсер, заточенный на ГЦ, распарсить не сможет.

Семантично, в данном контексте, означает максимально близко к определению сущности.

Царевед?

Кстати, это очень интересно:

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

Т.е. тут прослеживается базовое свойство подобных тебе персонажей - вы боты, которые не думая повторяют какую-то херню.

Ведь по-сути я писал о том, о чём и ты. Правда я писал что-то, ат ы просто транслировал тезисы пропаганды.

Дак вот, семантический - это значит, что аллокатор опирается на семантику списки, а список опирается на семантику аллокатора. Это то самое «отсутствие потери информации».

Ядро не работает с БД, с почтой, с дичайшими форматами файлов, уродскими спецификациями и вообще

ты в ерату любого чипа впаяного в современную материнку почитай, окуеешь. а ты про какие то там бд, хехе)

тот же усб3.0 (уёбищная сука блядь) - пиздец полный.

Это было к тому, чтоб ты подсократил свои списки «никто».

ты в ерату любого чипа впаяного в современную материнку почитай

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

Так же как кернел позволяет не думать о дебильных спецификациях железа.

в которой показал, что использование ГЦ увеличивает потребляемую память примерно в 5 раз (теоретический предел, можно хуже)

По-моему это даже звучит тупо. Прямо вот так теоретический предел в 5 раз, бгг

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

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

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

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

И именно в подобных задачах и проявляется сила языка и его экосистемы.

Когда у тебя класс задач - примитивная херня, где новой/уникальной логики ноль

Начинай кричать что авторы Apache Cassandra украли твою сишку с твоей жопой. И в I2P прямо XML на XML

Можно плиз на идиоматичном хаскеле? Строго в рамках Haskell2010/Haskell98: без Unsafe, без хитрых прагм.

Также было бы интересно увидеть версию ленивого умножения матриц на идиоматичном C++98/C++11 без всяких сторонних библиотек типа ranges.

Жаба не жрет, жабоскрипт не кушает, окай. Продолжайте сообщать сообщения.

Уже сообщил вот все прямо как ты сказал.

Правильно ли я пишу на Rust? (комментарий)

Только наоборот. Просто когда кто-то говорит о конкретно числе «5» и называет это теор-пределом для всех GC на планете, то это тупизна. Или в дисере или в твоей интерпретации утверждения

Начинай кричать что авторы Apache Cassandra украли твою сишку с твоей жопой.

Как быстро клоун съехал со своих локальных историй на касандру. А чего мне про свои приключения не расскажешь? Приключения рядовых жабистов.

К тому же, касандра - это примитивная плебеская херня нелепая. Она нихрена из себя не представляет и даже в методичках впаривается лишь интеграцией с жаба-говном и как некая система. Сама по себе она ничего не представляет.

К тому же, нужно понимать, что это легаси-мусор. Это не in-memory - это говно. И чем дальше будут развиваться диски - там в большей жопе это говно будет.

Создано оно лишь как паразит на тему слабости hdd и халявы по производительности, которая началась с коры2( а в нормальных архитектурах халява началась ещё раньше). Но теперь всё это говно идёт на помойку.

Потому что всё жизнь писал хмл.

В жабе из xml только maven, и то опционально. И то это не жаба, а сборщик.

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

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

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