LINUX.ORG.RU

Ada в 2024

 , ,


0

5

Привет, ЛОР!

В тредах про Rust и сишечку периодически всплывает пример языка Ada в качестве аргумента, что Rust, дескать, не нужен.

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

Про Ada Core, SPARK и Alire я в курсе. Хочу историй типа «у нас было три килограмма говнокода на C, мы его выкинули и переписали на Ada, и теперь багов стало с 8 раз меньше, а девки стали давать в 5 раз чаще».

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

★★★★★

Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

вот такие умники как ты, они вообще понимают что такое GC? Как оно работает? Что современные GC на порядки лучше malloc, по всем параметрам? Как работают объекты в языках с GC? Что MS написало на Sing#, это такой вариант C#, даже операционную систему, то есть вот ядро даже? Что в SBCL можно писать вообще хоть на встроенном ассемблере, а массивы и структурки спокойно аллоцировать на стеке?

lovesan ★★★
()
Ответ на: комментарий от lovesan

Что MS написало на Sing#, это такой вариант C#, даже операционную систему, то есть вот ядро даже?

Да и посрать? Наколеночная ОС на хачкелле тоже была, а толку-то?

Кстати, на чём написан рантайм этого самого Sing# и, в частности, GC? Неужели на сишечке?

Что в SBCL можно писать вообще хоть на встроенном ассемблере, а массивы и структурки спокойно аллоцировать на стеке?

Круто. А зачем тут, собственно, SBCL? И почему рантайм этого самого SBCL написан на C?

https://github.com/sbcl/sbcl/tree/master/src/runtime

hateyoufeel ★★★★★
() автор топика
Последнее исправление: hateyoufeel (всего исправлений: 6)
Ответ на: комментарий от hateyoufeel

Да по блядь очень простой причине он на Си написан. Че такое рантайм вообще? Это связка с ОС, в основном. Треды ОС запускать, еще какие-то там API ОС вызывать, типа выделения памяти да че. Из glibc, или вон из WinAPI.

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

lovesan ★★★
()
Ответ на: комментарий от hateyoufeel

Да и посрать? Наколеночная ОС на хачкелле тоже была, а толку-то?

Вот именно что наколеночная. На хаскеле вообще всё делается наколеночное, там ниче нормального нет сколько я на него не смотрел. Один xmonad вон на нем написали, и тот говно невыносимое. Это язык для прикола, чтобы перед аутистами писюном меряться, кто лучше монады знает. И гранты еще выбивать на «R&D». Больше он ни для чего не годится.

Кстати, на чём написан рантайм этого самого Sing# и, в частности, GC? Неужели на сишечке?

В Singularity, рантайм и даже GC написаны на Sing#

Там загрузчик и еще чето, на сишечке и ассемблере, ну наверное они просто посчитали что так удобнее. Никаких проблем и это написать на Sing# не было по сути.

lovesan ★★★
()
Ответ на: комментарий от lovesan

Что современные GC на порядки лучше malloc, по всем параметрам?

GC по любому обходит аллокированные обьекты. и его сложность есть O(от числа алокированных) и меньше быть не может.

формальный malloc хранит только деаалокированные куски, сливая их, и при нормальной имплементации его сложность O(1).

дальше сравнивай сложности и думай сам, к чему это ведет.

alysnix ★★★
()
Ответ на: комментарий от lovesan

Да по блядь очень простой причине он на Си написан. Че такое рантайм вообще? Это связка с ОС, в основном. Треды ОС запускать, еще какие-то там API ОС вызывать, типа выделения памяти да че. Из glibc, или вон из WinAPI.

Или GC написать.

Короче, там и запишем: лишперы не осилили написать GC на самом лишпе, им пришлось сишника звать. Наверняка со стороны. Остаётся только догадываться, как они с ним потом расплачивались.

https://github.com/sbcl/sbcl/blob/master/src/runtime/gencgc.c

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от alysnix

GC по любому обходит аллокированные обьекты. и его сложность есть O(от числа алокированных) и меньше быть не может.

В SBCL и в Sing# да и еще много где, у тебя есть возможность писать без всякого использования GC. Особенно низкоуровневые вещи, где он не нужен.

формальный malloc хранит только деаалокированные куски, сливая их, и при нормальной имплементации его сложность O(1).

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

lovesan ★★★
()
Ответ на: комментарий от hateyoufeel

Короче, там и запишем: лишперы не осилили написать GC на самом лишпе, им пришлось сишника звать.

Я еще раз говорю, на SBCL как минимум точно, это все делается спокойно и без GC. Даже сама реализация GC.

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

lovesan ★★★
()
Ответ на: комментарий от lovesan

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

или по твоему, если все нагрузились быстрыми GC, никто не грузился быстрым хипменеджером? вот прям GC быстрый сочинить можно, а обычный хипменеджер нет. докажи.

alysnix ★★★
()
Ответ на: комментарий от lovesan

Даже сама реализация GC.

И не только GC, естественно. Я вон абсолютно на лиспе, в своей то библиотеке, сигналы ковыряю какие-нибудь.

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

lovesan ★★★
()
Ответ на: комментарий от alysnix

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

lovesan ★★★
()
Ответ на: комментарий от lovesan

Я еще раз говорю, на SBCL как минимум точно, это все делается спокойно и без GC. Даже сама реализация GC.

Тогда почему реализация GC для SBCL написана на C, а не на лишпе?

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Повторяю еще раз - так проще.

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

lovesan ★★★
()
Ответ на: комментарий от lovesan

понятно. по делу ничего нет. ты и по GC плаваешь небось…

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

или в твоей эффективной алгоритмистике обьекты двигаются, а указатели так и смотрят в уже пустое место?

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 2)
Ответ на: комментарий от alysnix

В GC у тебя константная сложность выделения памяти. Ну типа, инкремент указателя, в базовом случае вообще.

А вот про удаление? Какова вообще сложность free? Какова сложность вообще работы с этими списками свободных блоков в маллоке?

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

А в GC стратегии щас делаются крайне эффективные, вон как mark-region, в SBCL или в JVM

lovesan ★★★
()
Ответ на: комментарий от lovesan

А в GC стратегии щас делаются крайне эффективные, вон как mark-region, в SBCL или в JVM

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от vM

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

lovesan ★★★
()

мы его выкинули и переписали на

Так почти никто не делает. Все просто начинают новую функциональность на новом языке. Через н лет начинают новый проект ибо никто не хочет разбираться в этом зоопарке из 3х-4х языков.

ya-betmen ★★★★★
()
Ответ на: комментарий от lovesan

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

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

если ведется бинарное дерево кусков свободной памяти - то логарифм. если таблица списков - то констатная.

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

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от Dr64h

я в принципе уверен, что аналогичная хрому система на C# или лиспе, будет работать быстрее и лучше, по куче причин, но начнем с того, что крестолюбцы обмазываются всякими intrusive_ptr и прочими ComPtr, когда дело доходит до чего-то сложного, которые мало что невероятно тормозные, так еще и текут

lovesan ★★★
()
Ответ на: комментарий от alysnix

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

я же говорю, тебе на бейсике писать надо.

Она недетерминированная, вообще при любом раскладе.

lovesan ★★★
()
Ответ на: комментарий от quantum-troll

Господи да куча ОС было на лиспе, прямо на железе.

Да и щас есть, просто по приколу https://github.com/froggey/Mezzano

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

lovesan ★★★
()
Ответ на: комментарий от alysnix

Она недетерминированная, вообще при любом раскладе.

на, просветисьhttps://caxapa.ru/thumbs/716101/tlsf.pdf

TLSF класненький. Я его использовал. Только это не то, что используется в glibc и прочих.

Что впрочем не отменяет того, что лавсан как всегда обожрался скобочек и бредит.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Алгоритмика идет от N. Но что такое N? N идет от размера допустим блоков, выделенных, от количества блоков. Но это неприменимо к твоей программе, потому что ты это не контролируешь. Это контролирует аллокатор.

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

lovesan ★★★
()
Последнее исправление: lovesan (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

А и кстати про TLSF да.

Очень смешное как это сравнивают с GC.

Потому как они там говорят, дескать, ну вот аллокатор работает за O(1). Так аллокация в любом практически GC это тоже O(1). Вопрос то про сборку мусора.

И теперь подумайте, почему если это такой шикарный аллокатор, он не используется в glibc?

GC в общем случае всегда работает лучше чем любой malloc.

А касательно специализированных арен, или еще какого говна - будто что-то мешает делать пулы объектов в языках с GC.

lovesan ★★★
()
Ответ на: комментарий от lovesan

И теперь подумайте, почему если это такой шикарный аллокатор, он не используется в glibc?

Давай вспомним что per-cpu slab в glibc появился всего-то шесть лет назад, до этого там был жирный мьютекс и нормальным делом было линковаться с какой-нибудь jemalloc чтобы перестать в это упираться. То что в glibc творится — это даже близко не state of the art.

cumvillain
()
Ответ на: комментарий от cumvillain

Все идиоты, одни дрочеры на говно типа C++ умные.(нет)

Фишка в том, что в реальности, GC намного быстрее чем malloc, и реально добиться производительности GC, или обогнать ее, можно только тогда, когда код на крестах тех же, будет в нули задроченный, чего просто никто никогда не делает вообще! даже в эмбеддеде, это отлично описано у Реймонда Чена в статьях https://learn.microsoft.com/en-us/archive/blogs/ricom/performance-quiz-6-chineseenglish-dictionary-reader

И тут еще встает интересный момент - да дело в том что в современных реализациях лиспа, или даже в некоторых других языках «с GC», все эти оптимизации ТАКЖЕ возможны. Поэтому никакое дрочево на C++ смысла не имеет вообще. От слова совсем.

lovesan ★★★
()
Последнее исправление: lovesan (всего исправлений: 1)
Ответ на: комментарий от lovesan

Фишка в том, что в реальности, GC намного быстрее чем malloc, и реально добиться производительности GC, или обогнать ее, можно только тогда, когда код на крестах тех же, будет в нули задроченный, чего просто никто никогда не делает вообще!

Какое все это отношение имеет к тому, что оценивать аллокаторы по признаку «похоже на то что в glibc» – плохая идея? Ты хоть читай на что отвечаешь перед тем как начинать на лиспы дрочить.

cumvillain
()
Ответ на: комментарий от lovesan

И тут еще встает интересный момент - да дело в том что в современных реализациях лиспа, или даже в некоторых других языках «с GC», все эти оптимизации ТАКЖЕ возможны. Поэтому никакое дрочево на C++ смысла не имеет вообще. От слова совсем.

Конечно дрочево на C++ смысла не имеет, ведь есть Rust.

cumvillain
()
Ответ на: комментарий от cumvillain

Rust такой же бессмысленный. Язык буквально сделанный для людей которые не понимают в этом нашем ойти, нихрена вообще. Удивительно как оболванивание вообще вот этим вот, работает. Они еще потом добавки просят.

lovesan ★★★
()
Ответ на: комментарий от lovesan

Rust такой же бессмысленный. Язык буквально сделанный для людей которые не понимают в этом нашем ойти, нихрена вообще. Удивительно как оболванивание вообще вот этим вот, работает. Они еще потом добавки просят.

Ну так удобно же. Тип написал, derive сделал, все работает. А те вот это вот пердолево со скобочками.

cumvillain
()
Ответ на: комментарий от cumvillain

Нет, конечно, неудобно, и тут уже упоминали даже двусвязный список. Это язык для дрочеров, которые дрочат на какую-то выдуманную вещь вообще, нахер по сути не нужную. Ну типа на хероту уровня AbstractSingletonProxyFactoryBean только в профиль.

lovesan ★★★
()
Ответ на: комментарий от lovesan

Нет, конечно, неудобно, и тут уже упоминали даже двусвязный список.

Я эти мантру про двухсвязный список слышу сколько Rust существует. Как часто за это время мне потребовалось сделать двусвязный список руками? Правильно, ни разу.

cumvillain
()