Джоэль Якобсон (Joel Jacobson (https://github.com/gluefinance)) выступил с инициативой (https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU... создания варианта СУБД PostgreSQL, переведённого на язык Rust. Порт будет развиваться под именем RustgreSQL. Перевод с Си на Rust планируется полностью автоматизировать и обеспечить трансляцию основной master-ветки PostgreSQL в представление на языке Rust c автоматической конвертацией всех новых коммитов, т.е. код RustgreSQL будет синхронизирован с PostgreSQL.
В качестве мотива создание порта называется избавление от необходимости оглядки на усложнённые детали при работе с памятью на языке Си и возможность задействования средств по обеспечению безопасного программирования, предоставляемых языком Rust. Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.
Джоэль Якобсон занимается поддержанием системы электронных платежей Trustly (https://en.wikipedia.org/wiki/Trustly), охватывающей 52 банка в 7 странах и использующей (https://github.com/trustly/keynotes/raw/master/PgConf%2...для обработки данных и бизнес-логики только СУБД PostgreSQL. Trustly разрабатывает ряд дополнений (https://github.com/trustl) для PostgreSQL, а сам Джоэль является автором входящего в PostgreSQL набора функций и представлений pg_stat_xact_* и также известен работой по обеспечению предсказуемого порядка вывода записей в pg_dump и участием в разработке SQL-расширения PL/PgSQL 2 (https://github.com/trustly/plpgsql2).В сообществе инициатива пока встречена скептически, например, организация автоматической трансляции кода из Си в Rust
сравнивается (https://www.postgresql.org/message-id/7b48680277ff6771e5e7d5... по уровню сложности с разработкой самого PostgreSQL. Переход разработки PostgreSQL с языка Си оценивается как нереалистичный, требующих огромных трудозатрат и лишённый убедительных причин.
URL: https://www.postgresql.org/message-id/CAASwCXdQUiuUnhycdRvrU...
Новость: http://www.opennet.me/opennews/art.shtml?num=45826
А интересная инициатива. Рукопожимаю.
Лучше пожми ему коммиты на гитхабе. А мы посмотрим как вы напишете штуку размером с постгра. И насколько вас хватит на ее майнтенанс.
На гитхабе не отображаются коммиты в приватных репозиториях гитхаба. Также
на гитхабе не отображаются коммиты в репозиториях, которых нет в гитхабе.
> А мы посмотрим как вы напишете штуку размером с постгра. И насколько вас хватит на ее майнтенанс.А "вы" - это кто? Ребята из постгреса или очередные "мы не сеем, мы не пашем, мы на опеннете анонимно языком машем!"?
> А "вы" - это кто? Ребята из постгреса или очередные "мы не
> сеем, мы не пашем, мы на опеннете анонимно языком машем!"?А вы наверное видный представитель клуба? Мы то не сеем и не пашем, потому что не крестьяне нифига.
>> "мы не сеем, мы не пашем, мы на опеннете анонимно языком машем!"?
> А вы наверное видный представитель клуба? Мы то не сеем и не
> пашем, потому что не крестьяне нифига.Т.е. с тем, что ты балабол, ты не споришь?
> Т.е. с тем, что ты балабол, ты не споришь?Ну то-есть вы не отрицаете участие в клубе. А это вовсе и не передерг вашим методом, как бы.
>> Т.е. с тем, что ты балабол, ты не споришь?
> Ну то-есть вы не отрицаете участие в клубе. А это вовсе и
> не передерг вашим методом, как бы.Конечно, ведь даже передерг балаболы опеннета не ослили как надо. Я ведь не отвечал, а только спрашивал, в отличие от.
Кстати, тема "вас" все еще не раскрыта. Так вы ребята и постгреса или просто очередные балаболки опеннета, которые только и могут смотреть, да балаболить?
Отмазывайся теперь. А кто такие мы - по-моему довольно легко догадаться. Ну не думаешь же ты что посетители опеннета будут коммитить? На rust? В форк постгреса? Да скорее они фантомаса в очках на аэроплане изобразят.
Бесплатно -- только руку пожать.
> Бесплатно -- только руку пожать.А это как тебе удобнее, человек. Мне и на postgres индифирентно и на ржавый. Просто мне так кажется что как обычно - объем пиара в этом случае сильно превысит результат.
Тю... Тогда лучше сразу на Haskell переписать, он безопаснее будет.
> Тю... Тогда лучше сразу на Haskell переписать, он безопаснее будет.Си в хаскель автоматически конвертировать не получится. Во-первых система типов слишком различна, можно обломиться на том же соглашении о том, что считать истиной. Во-вторых хаскель чисто функциональный, и императивные алгоритмы на Си придётся конвертировать вручную, что в таком большом проекте как постгра выльется в огроменную работу.
А то я этого не понимаю ;) Моё сообщение было саркастическим т.к. переписывание сабжа на rust сопоставима с переписыванием на haskell, а профит весьма сомнителен.
Да вы упоролись. Исследовали же постгре, там и так дефектов меньше чем где бы то ни было оказалось)
> Да вы упоролись. Исследовали же постгре, там и так дефектов меньше чем
> где бы то ни было оказалось)Мозилла как-то тут вопила что надо просмотрщик пдф на js переписать. Переписали. Мало того что его клинит по 2 минуты при открытии пдф и он жрет сотни памяти, так в нем еще сказочный 0day посадили которому позавидует даже адоб. В общем если програмер макака - никакой ЯП тут не поможет.
> Мозилла как-то тут вопила что надо просмотрщик пдф на js переписать. Переписали.Только новость не о просмотрщике и не о переписывании на жс.
Патологическая ненависть к Мозилле не лечится.
> Патологическая ненависть к Мозилле не лечится.Если заменить мозиллу на обезьян с гранатой, особенно верящих в серебряные пули - станет более похоже на правду. Ты уж прости, но имхо вот лично ты - не напишешь безопасный софт вообще ни на каком ЯП. Если вообще програмер.
> Если заменить мозиллу на обезьян с гранатойТы, наверное, хотел сказать "вэб-макаку с гранатой"?
> Ты, наверное, хотел сказать "вэб-макаку с гранатой"?Пример убунты показал что макаки бывают и не вэб. Ну а кто еще может отгружать нерабочий апдейтер три релиза к ряду? Да, на очень характерном яп используемом мегапрофессионалами. А в go гугл так даже логотип выбрал честно.
Ну так и быть, разжуем лично вам.
Автор имел в виду, что если прога и разрабы кривые, то никакой ЯП не поможет.
> Ну так и быть, разжуем лично вам.
> Автор имел в виду, что если прога и разрабы кривые, то никакой
> ЯП не поможет.При этом приведя в качестве примера cовсем другой продукт - конкретную БД, а не какой-то абстрактный просмотрщик на локалхосте, замененный на ЖСный. Совсем другую компанию с совсем другими задачами и взаимодействием - они пользуются слоном, но никак не впаривают его. И даже не сильно схожей ситуацией - по возможности, автоматически перевести с си на раст, сохранив всю логику и уменьшив количество факапов, которые ударят в первую очередь по ним самим, а не некоторым пользователям и даже если ПРщикам удасться все замять списать на форс-мажор, сильно легче от этого не станет. В отличие от мозилл.
Кстати, если исходить из дефолтов в окошках, то глядя на это
https://www.cvedetails.com/vulnerability-list/vendor_id-53/p...
я даже не знаю, точно ли переход на дырявый JS-viewer для (по умолчанию) пользователей адобов был хуже - в последней сотне дырок только дюжина получила менее 10 балов. Да и вообще, по 30-60 дыр с возможностью исполнения кода в год довольно сложно переплюнуть.
> При этом приведя в качестве примера cовсем другой продукт - конкретную БД,
> а не какой-то абстрактный просмотрщик на локалхосте, замененный на ЖСный. Совсем
> другую компанию с совсем другими задачами и взаимодействиемНу ладно, мазила еще servo написала. И что вы думаете? Оно тормозит еще круче того пюсового монстрика и падает на каждом первом сайте. И это при том что его пилят уже несколько лет. Ну как бы успех переписывания - во все поля. Наверное и с сабжем получится нечто наподобие.
Чушь. Безопасные языки программирования нужны тем, кто программировать не умеет.
Ещё скажи, что статическая типизация нужна тем, кто программировать не умеет.
Скорее наоборот
Высокоуровневые яп нужны тем, кто не может в ассемблер, неправда ли знакомая песня?
> Высокоуровневые яп нужны тем, кто не может в ассемблер, неправда ли знакомая
> песня?А assembly нужен неосиляторам машинных кодов. Которые не в курсе *реноватой оптимизации и опкодогенерации ассемблеров, особенно в части абсолютной и позиционно не зависимой адресации, вкупе с дальностью, прыжков и вызовов - а потом удивляются, почему это код иногда на 5% медленнее работает.
> и опкодогенерации ассемблеров, особенно в части абсолютной и позиционно не зависимой
> адресации, вкупе с дальностью, прыжков и вызовов - а потом
> удивляются, почему это код иногда на 5% медленнее работает.Сразу видно человека который эксперт по ассемблеру. Весьма иллюстративно.
>> и опкодогенерации ассемблеров, особенно в части абсолютной и позиционно не зависимой
>> адресации, вкупе с дальностью, прыжков и вызовов - а потом
>> удивляются, почему это код иногда на 5% медленнее работает.
> Сразу видно человека который эксперт по ассемблеру. Весьма иллюстративно.А вы не стесняйесь, просветите нас.
Начните хотя бы с "ассемблера", того самого, единственно верного, ну и так далее, что вам там почудилось. Потому как единственное, что упоминалось не всерьез, кроме контекста - это шутка про 5%.
Или кроме обобщенных изречений с умным видом ничего не будет? )
> всерьез, кроме контекста - это шутка про 5%.
> Или кроме обобщенных изречений с умным видом ничего не будет? )Кроме всего прочего я еще програмил на парочке ассемблеров, пустяки. Но вы продолжайте про 5% и шутки. Как показали плюсики, хипстеры все-равно асм не видели, но мнение имеют. Крутые програмеры, с крутыми подходами.
> Кроме всего прочего я еще програмил на парочке ассемблеров, пустяки. Но вы
Ой, напужали ежа голой попой! Хелловорлд на асме входит в обязательную программу нормального вуза. Но вы продолжайте давить на илитарность и писать поменьше конкретики.
> продолжайте про 5% и шутки.Только вот кроме 5% упоминается парочка маленьких таких нюансиков, как бы, нивелирующих, вместо тега <йумар>, так сказать. То, что вы их не заметили и решили попедалировать проценты, тоже очень иллюстрирует )
> не видели, но мнение имеют. Крутые програмеры, с крутыми подходами.Что сказать то хотели, крутой вы наш знаток ассемлеров?
> Ой, напужали ежа голой попой! Хелловорлд на асме входит в обязательную программу
> нормального вуза. Но вы продолжайте давить на илитарность и писать поменьше конкретики.Ну так бы и сказал что знаешь асм на уровне хелловорлда для вуза. А я развлекался "mess with the best" на равных. Кроме всего прочего я однажды прикололся и забутявил проц своим копирайтом. Ну как, после включения большинство систем начинают выполнение кода с какой-то фиксированной локации в памяти. Я приколося и туда свой копирайт положил. Который подогнан так что складывался в осмысленные машинные команды. Бонусом его было довольно трудно изменить, т.к. в неинициализированной железяке малейший шаг влево-вправо все обваливает (и удачи в отладке). Так что если ты думаешь что я заценю домашку вуза - извини, не прокатило.
> Только вот кроме 5% упоминается парочка маленьких таких нюансиков,
Юмор - это похвастаться перед любителем хекспика, который бутанул проц копирайтом домашкой вуза.
> То, что вы их не заметили и решили попедалировать проценты, тоже очень иллюстрирует )
А что тут иллюстрировать? Я таки гоготал в голос от таких попыток набить себе цену.
> Что сказать то хотели, крутой вы наш знаток ассемлеров?
Хотел сказать что для того чтобы умничать по поводу ассемблера - надо в нем хоть немного разбираться.
А запасной парашют только тем кто не умеет прыгать с парашютом
> А запасной парашют только тем кто не умеет прыгать с парашютомКак бы это сказать? Если запасной парашют будет добровольно-принудительно выскакивать сам - он может все испортить, когда в результате будет два запутавшихся друг об друга парашюта и один убившийся парашютист.
при чем тут безопасные языки программирования?
> при чем тут безопасные языки программирования?Древняя примета опеннета - чем меньше анонимы знают матчасть, тем красочнее, подробнее и левее аналогии.
Анонимы на опеннете почти никогда не знают матчасть... :(
> Анонимы на опеннете почти никогда не знают матчасть... :(Ну вам то как экспертам анонимовединия виднее. По себе проверяли, тезки?
>> Анонимы на опеннете почти никогда не знают матчасть... :(
> Ну вам то как экспертам анонимовединия виднее. По себе проверяли, тезки?По таким вот как ты. Экспертам аналогий.
> По таким вот как ты. Экспертам аналогий.Про парашюты начал какой-то другой аноним. Нет, аналогия не такая уж плохая, но очень уж упрощено все получилось.
> при чем тут безопасные языки программирования?Безопасный язык программирования - это так круто звучит из уст маркетолого. Но почему-то это не помешало повесить баг ценой в 2 миллиарда долларов из-за которого упал Arian 5. А казалось бы Ada - куда уж безопаснее то?
>> при чем тут безопасные языки программирования?
> Безопасный язык программирования - это так круто звучит из уст маркетолого. Но
> почему-то это не помешало повесить баг ценой в 2 миллиарда долларов
> из-за которого упал Arian 5. А казалось бы Ada - куда
> уж безопаснее то?это потому что язык программирования, безопасный от менеджеров, которые хотят сократить время и подрезать стоимость на тестах, еще не придумали.
> это потому что язык программирования, безопасный от менеджеров, которые хотят сократить
> время и подрезать стоимость на тестах, еще не придумали.Так это, если все делать по фэншую, совсем без constraints по времени и стоимости, да чтоб все баги еще починить - релиз не состоится никогда. Поэтому данный фактор сбросить со счетов могут разве что академики. Блин, даже опенсорсники которых шеф не жмет - и то приучаются релизиться с какй-то периодикой. Ну или проект заваливается в режим abandonware.
>> это потому что язык программирования, безопасный от менеджеров, которые хотят сократить
>> время и подрезать стоимость на тестах, еще не придумали.
> Так это, если все делать по фэншую, совсем без constraints по времени
> и стоимости, да чтоб все баги еще починить - релиз не
> состоится никогда. Поэтому данный фактор сбросить со счетов могут разве что
> академики.
> Блин, даже опенсорсники которых шеф не жмет - и то
> приучаются релизиться с какй-то периодикой. Ну или проект заваливается в режим
> abandonware.правильно. вот в примере про ариан завалилась довольно дорогая железка. в примере про RBS опердень простоял 5 дней. и еще куча примеров.
потому что менеджеры ставили то, что вы называете constraints - выше результата. это чинится публичной маналулой в особо цыничной форме, а не языками программирования.
> правильно. вот в примере про ариан завалилась довольно дорогая железка. в примере
> про RBS опердень простоял 5 дней. и еще куча примеров.Поэтому крут не тот кто пишет идеальный софт, а тот кто все это может вменяемо сбалансировать. О чем хипстота разыскивающая идеальный ЯП который махом решит все их проблемы похоже не догадывается.
> потому что менеджеры ставили то, что вы называете constraints - выше результата.
А это продолб менеджеров уже. И расово верный ЯП от этого ну никак не поможет.
> это чинится публичной маналулой в особо цыничной форме, а не языками программирования.
Так о чем и речь. Хотя вот конкретно космической отрасли жаловаться на constraints не очень уместно: ресурсы и сроки у них здорово выше чем в среднем по отрасли. Поэтому откровенный джамшутинг все-таки от них не ожидается. Они на самом деле просто зажрались непомерно, Маск вон бортовые компьютеры вообще делает из ширпотреба который не rad-hard и с просто линухом, а надежность достигается иными методами. В штатах космос для того и отдали частникам чтобы посмотреть как это может выглядеть если вместо зажравшихся бюджетников будут те кто не может позволить зажироны. Хорошая идея, имхо.
> Так о чем и речь. Хотя вот конкретно космической отрасли жаловаться на
> constraints не очень уместно: ресурсы и сроки у них здорово выше
> чем в среднем по отрасли. Поэтому откровенный джамшутинг все-таки от них
> не ожидается. Они на самом деле просто зажрались непомерно,эм, контролерам Аполлонов не хотите рассказать про зажрались? Тем, которые Apollo 11 на луну посадили только благодаря тестам и тренировкам, тестам и тренировкам. с вполне средними показателями по ресурсам и срокам на тот момент. считая, что за полупроводники с ними конкурировал в этот момент Минитмен, а по срокам было жостко before this decade is out, т.е. отладка закончилась где-то году в 1965-67.
мне что-то кажется, что случай с арианом они отловили бы как отловили error 1201/1202 - исходя из опыта тренировок.
Маск вон
> бортовые компьютеры вообще делает из ширпотреба который не rad-hard и с
> просто линухом, а надежность достигается иными методами. В штатах космос для
> того и отдали частникам чтобы посмотреть как это может выглядеть если
> вместо зажравшихся бюджетников будут те кто не может позволить зажироны. Хорошая
> идея, имхо.не вопрос, если Маск на COTS деталях повторит результаты семерки или nиoнеpов, я первый ему буду аплодировать. ему всего осталась мелочь тaщeмтa, не?
P.S. опеннет, у вас все с головой в порядке, ставить слова "тaщeмтa" и "пиoнep" в блеклист?
> эм, контролерам Аполлонов не хотите рассказать про зажрались?Им Маск расскажет. У него и сроки и стоимость фундаментально другие. Он бортовые компьютеры делает из ширпотреба который не rad-hard и с линухом, а надежность добирает многократным резервированием. Догадайся во сколько раз это дешевле? Для затравки посмотри цены на rad-hard CPU.
> Тем, которые Apollo 11 на луну посадили только благодаря тестам и тренировкам, тестам и тренировкам.
Ничего что в лунную гонку ресурсы реками лили? Раз за историю человечества - можно и так. А регулярные рейсы на орбиту в таком формате - нафиг надо. Для понимания пропасти сравни с затратами на 1 рейс самолета.
> с вполне средними показателями по ресурсам и срокам на тот момент.Боюсь что такие показатели в XXI веке никому не надо ни в софтостроении ни даже в кoсмoнавтике. А зачем нам космос который статусная игрушка? Он должен стать майнстримом, как авиарейсы через океан.
> а по срокам было жостко before this decade is out, т.е.
> отладка закончилась где-то году в 1965-67.Осталось сравнить бджет NASA тогда и сейчас, не забыв пересчитать с учетом изменения покупательной способности тогдашнего доллара. И станет понятно почему NASA взрастило Маска и его конкурентов.
> мне что-то кажется, что случай с арианом они отловили бы как отловили
Понимаешь, человечество не может тратить рекордные ресурсы на регулярные операции.
> не вопрос, если Маск на COTS деталях повторит результаты семерки или nиoнеpов,
> я первый ему буду аплодировать. ему всего осталась мелочь тaщeмтa, не?Он вообще достаточно разумный.
> P.S. опеннет, у вас все с головой в порядке, ставить слова "тaщeмтa"
> и "пиoнep" в блеклист?Они еще и кocмoнавт туда занесли. Жесть как она есть. Оказывается, это ругательство такое. Говоря за себя - я совсем не против чтобы меня так ругали.
"для обработки данных и бизнес-логики только СУБД PostgreSQL"Несерьёзный тип. Бизнеслогика в хранимочках это фуфу. И инициатива смешная, сразу начинаешь прикидывать "чё, первое апреля уже"?
> Бизнеслогика в хранимочках это фуфу.Уже несколько раз вижу (слышу) такое мнение в этих ваших интернетах, но без всяких объяснений. Можете объяснить почему это «фуфу»? Правда, очень интересно, почему-то это плохо.
Ну, как бы жёстко привязывет тебя к определённой БД, сложно поддерживать, плохо масштабируются, проблематично выражать сложные абстракции на столь простых скриптовых языках.
Сложные абстракции в финансах? В бизнес логике?
Внезапно да. Не поверишь сколько всяких не поддающихся пониманию законов/правил/стандартов есть в бухучёте и финансовой сфере, а если помножить на кол-во стран, то вообще крыша может съехать. И вот тебе надо запилить модуль, который готовит ежедневный отчёт для налоговой скажем, но налоговые могут быть в разных странах, и клиент может работать в разных странах и клиентов таких не один, и каждый со своими заморочками, так что сложность бизнес логики может расти экспоненциально.
Так это из практики, или так мысли вслух?
Какие там сложные абстракции, что в PL/Sql не ложатся?
Из практики, 3 года разрабатывал биллинговые системы.
Расскажите нам о своём опыте написания бизнесс-логики на стороне БД.
> Так это из практики, или так мысли вслух?
> Какие там сложные абстракции, что в PL/Sql не ложатся?Сертифицированный ораклист толкает свой вендор-лок из 90-х?
>Сколько всяких не поддающихся пониманию законов/правил/стандартов есть в бухучётеЦифры должны сойтись, а если не сошлись из-за ошибки в прошлом, за которую ужет отчитались, то программист должен что-то придумать.
Вот собственно и все.
Советую глянуть, на каких языках, в PostgreSQL, можно писать хранимки
И? Это всё будет прибито гвоздями к конкретной базе, не?
> И? Это всё будет прибито гвоздями к конкретной базе, не?Как будто что-то плохое.
> Как будто что-то плохое.Когда стартапнешь свой uber - расскажешь нам о хорошем и как это делать правильно. А до тех пор ценность таких мнений понятно какая.
> как бы жёстко привязывет тебя к определённой БД, сложно поддерживать, плохо масштабируютсяКогда стартапнешь свой uber - расскажешь нам о хорошем и как это делать правильно. А до тех пор ценность таких мнений понятно какая.
Странная у тебя логика. То есть опыт uber по перемене бекэнда БД является чем-то исключительно положительным? Почему тогда кроме него существует масса компаний, не нуждающихся в подобных движениях и которые десятилетиями используют одну БД и тюнят ее под свои нужды если требуется?
> Странная у тебя логика. То есть опыт uber по перемене бекэнда БД
> является чем-то исключительно положительным?Опыт uber - это практика хорошего, крутого и современного стартапа. Со всеми граблями и факапами. И вот как раз это очень ценно. Особенно для тех кто хочет попробовать нечто наподобие. Ну понятно что это не про большинство опеннетчиков, но все-таки.
> Почему тогда кроме него существует масса компаний, не нуждающихся в подобных
> движениях и которые десятилетиями используют одну БД и тюнят ее под свои нужды если требуется?ЧСХ за десятилетия такие компании обычно превращаются в печальное болотце, которое уже ни на что не влияет и спасибо если не загибается/скупается/etc. Ну вон яху какой-нибудь - он вроде бы еще не полностью загнулся, но как таковой ни на что не влияет.
Какая разница, из каких сортов гогна лепить велосипед?? База - это ДАННЫЕ, а городить там убогие процедурки на недоязыках (где даже LINQ нет) - нафик не упёрлось. Это не говоря о ТРЕТЬЕМ месте для выполнения кода (помимо клиента и апп.сервера) - вам что, мало в жизни гемороя? Ну так это не та профессия, где нужно усложнять себе жизнь.
> База - это ДАННЫЕНет. База -- это база. А данные -- это данные. База данных, помимо собственно данных, включает в себя определенное поведение по управлению этими самыми данными, начиная со стандартных INSERT/UPDATE... и заканчивая хранимками. Это примерно как путать операционную систему (GNU+Linux, Windows) с ядром (vmlinux, ntoskrnl.dll).
Независимость от БД возможна только на уровне SELECT * FROM gostevuha.
> Независимость от БД возможна только на уровне SELECT * FROM gostevuha.Есть такая тенденция, ставить мегабазу на IBM-Z(сейчас Oracle уже свои машины пиарит) а рядом APP-Server на Java ( в одном зале ).
И к чему этот комментарий? Где такие тенденции?Привязка к БД рано или поздно происходит по вполне понятным причинам: проект развивается, обрастает фичами и все активнее пользуется средствами БД. Глупо было бы как раз вместо этого делать "универсальное решение".
> Привязка к БД рано или поздно происходит по вполне понятным причинам: проект
> развивается, обрастает фичами и все активнее пользуется средствами БД. Глупо было
> бы как раз вместо этого делать "универсальное решение".Только вот uber однажды взял и соскочил с сабюа на мускул. И номер для них таки прокатил. А привяжись они по жесткому на всякие хранимки - что бы они делали? Вообще, все эти заявы про майнфреймы и мега-базы как-то не из этого тысячелетия, чтоли.
А финансы что-то дружно вдарились в блокчейны. Вся оценка гребаных майнфреймов, мегабаз и как весь этот шит работает.
>Только вот uber однажды взял и соскочил с сабюа на мускул. И номер для них таки прокатил. А привяжись они по жесткому на всякие хранимки - что бы они делали?То, что uber не провел изначальный ресеч того, что им нужно в первую очередь от БД ни о чем хорошем не говорит. Скакание с одного БД бекэнда на другой вообще достаточно нетривиальная вещь по себе, а делать это во время работающего бизнеса - круто, че. Молодцы, что получилось. Когда ждать следующий скачок?
> То, что uber не провел изначальный ресеч того, что им нужно в
> первую очередь от БД ни о чем хорошем не говорит.Они по крайней мере вместо восторженных воплей и маркетингового булшита изложили довольно хороший анализ проблематики и подробно расписали в чем проблемы. И когда кто-то лезет критиковать это решение - ему наверное надо бы показать более успешный стартап, который принял другие решения и они сработали еще лучше.
> Скакание с одного БД бекэнда на другой вообще достаточно нетривиальная вещь по себе,
Да вот вы знаете, в этом мире скачущие и адаптивные - грубо натягивают замшелых и заржавелых. Работает он так. Ну то-есть майнфреймы до сих пор в паре замшелых контор как бы есть. Но в конечном итоге все эти майнфреймы ни на что уже почти не влияют и врядли кем-то считаются за перспективное направление с большим будущим.
> а делать это во время работающего бизнеса - круто, че.
> Молодцы, что получилось. Когда ждать следующий скачок?А куда для них будет лучше работать - туда и скаканут. Это ж не ископаемые обладатели майнфреймов а современная компания, на острие направления. Такие как они и меняют мир.
> А финансы что-то дружно вдарились в блокчейны. Вся оценка гребаных майнфреймов, мегабаз
> и как весь этот шит работает.Вы не понимаете сути данных, которые обрабатываются в финансах, все эти блокчейны это просто способ хранения и передачи(подписи).
> Вы не понимаете сути данных, которые обрабатываются в финансах, все эти блокчейны
> это просто способ хранения и передачи(подписи).А хранят блокчейны в большинстве систем в обычном гугловском levelDB. Который и близко не сиквель и уж тем более не страдает хранимыми процедурами.
Да и "репликация" в блокчейне сделана фундаментально иначе. Там вообще не надо сверхнадежных серверов и проч. А в спорных случаях всегда можно посмотреть - проскочила вообще транзакция в систему или нет. Просто фундаментально другой подход к построению систем. У Сатоши по этому поводу в начале блокчейна какой-то весьма забавный комент про канцлеров и банки, чтоли :)
> Только вот uber однажды взял и соскочил с сабюа на мускул.uber соскочил с SQL на собственную реализацию key-value.
> uber соскочил с SQL на собственную реализацию key-value.Я всегда подозревал что они адекватная компания, а они еще себя так спозиционировали что им ПРИДЕТСЯ быть эффективными. Иначе их расплющит собственным весом.
Проблема в том, что Uber как не использовал PostgreSQL как SQL-базу, так и продолжает не использокать MySQL как SQL-базу. Поверх этого MySQL у них работает свой собственный варинат k/v db. С такой вводной SQL-подкладку можно по крону менять раз в квартал.
> Проблема в том, что Uber как не использовал PostgreSQL как SQL-базу, так
> и продолжает не использокать MySQL как SQL-базу. Поверх этого MySQL у
> них работает свой собственный варинат k/v db. С такой вводной SQL-подкладку
> можно по крону менять раз в квартал.А использовать как SQL базу - это как? Поставить чуть ди не майнфреймы и прочие ораклы, равзести gross overengineering который почти невозможно менять под новые требования жизни и переотожранный стафф? А нафига оно такое надо? IBM и так уже есть и у них цать лет форы по времени, поэтому желающим зарубиться на этом поле будет очень нелегко. Туда же и остальные яхи. А гугл вон волей-неволей разработал себе кучу кастомных решений не имеющих ничего общего с вот этим вот.
Ну и чисто по человечески по-моему плохо когда логика размазана по туевой хуче мест. В результате все приходит к тому что система живет своей жизнью, никто не понимает как она работает. И имел я тут удовольствие с банкингом общаться, когда все отделение и даже вышестояшие админы никак не могли переубедить систему перестать блочить мой счет. Никто не понимает почему это случается. Система объявила себя покемоном и живет своей жизнью, а обслуга вообще боится тронуть этот крап лишний раз. Люди утратили понимание как это вообще у них работает. Наверное так и надо писать софт. Но тогда надо Full AI включать в состав софта, без него это кусок головняка получается.
Дай догадаюсь, ты только начал открывать для себя мир программирования и начал это делать по одной из сотен ужасных книг по пыху.
Лишь неопытность внушает иллюзию, будто всё можно написать универсально, без привязки к конкретной БД.
> Лишь неопытность внушает иллюзию, будто всё можно написать универсально, без привязки к
> конкретной БД.Сделать из базы сервер приложений конечно можно. Но как и насколько это работает - показал оракл. Нет, полтора особо упертых энтерпрайзника с особо отожранным стаффом даже осилили это извращение. А по большому счету это выглядит как дефективный паттерн проектирования софта. Логику наверное должна делать все-таки не база и бурный рост всяких редисок тому пример. Не все хотят неповоротливый переросток с которым потом придется плотно сношаться без возможности как-то исправить факап. Об успехе внедрежа postgres можно почитать у uber соскочившего на мускуль. И таки они довольно крупная контора и данных ворочают много.
> А по большому счету это
> выглядит как дефективный паттерн проектирования софта. Логику наверное должна делать все-таки
> не база и бурный рост всяких редисок тому пример. Не все
> хотят неповоротливый переросток с которым потом придется плотно сношаться без возможности
> как-то исправить факап. Об успехе внедрежа postgres можно почитать у uber
> соскочившего на мускуль. И таки они довольно крупная контора и данных
> ворочают много.Данные бывают разные, и требования к их сохранности и консистентности так-же.
> Данные бывают разные, и требования к их сохранности и консистентности так-же.А еще практика показала что упование на один супермеганадажный компонент за дикие деньги или дико сложный - да это булшит. Самые надежные и масштабирующиеся системы делают из недорогих компонентов обычной надежности.
Блокчейн биткоина будет работать до последнего узла способного грузить блоки. А у вас в вашей энтерпрайзятине есть миллион реплик, как у них? А то биткоин даже после ядерной войны продолжит работать, имхо. Да и консистентность - всегда можно посмотреть в распределенной системе: ушла в нее ваша транзакция вообще или нет. Если не ушла - ну значит повторить. Там все это само получается. Просто иначе - оно теперь не к физике стоража привязано а к тому как вас увидели остальные системы гоняющие блокчейн. Это банально "распределенное приложение". Там парадигмы чуть иные.
Изначально это как бы глобальная база транзакций. Но всякие Etherium-образные показали что на основе этого подхода можно и намного больше. А что, умные контракты без централизованного арбитра - звучит достаточно интересно и оригинально.
Есть куча известных проектов, которые способны работать более чем с одной БД. Причем на уровне куда более продвинутом, чем select * from tablename. Для большинства ЯП, включая пых, есть библиотеки для абстрактной работы с реляционной БД.Другое дело, что привязка к конкретной БД позволяет писать несколько более эффективный код. Но это вечный tradeoff не только области работы с БД.
> Есть куча известных проектов, которые способны работать более чем с одной БД.
> Причем на уровне куда более продвинутом, чем select * from tablename.У этих проектов _разный_ код для _разных_ баз данных.
sqlalchemy, orm django из коробки поддерживают несколько баз данных, если не пытаешься писать запросы напрямую, а пользуешься только стандартными возможностями.
> sqlalchemy, orm django из коробки поддерживают несколько баз данных, если не пытаешься
> писать запросы напрямую, а пользуешься только стандартными возможностями.sqlalchemy не поддерживает например COPY http://stackoverflow.com/questions/13125236/sqlalchemy-psyco...
и множество других фич postgres.
И что из этого? Никто не говорил, что слой абстракции работы с БД позволяет максимально эффективно использовать возможности каждой РСУБД. Но слой абстракции по своим возможностям значительно превосходит select * from tablename. И этого достаточно для большинства задач.
> слой абстракции по своим возможностям значительно превосходит select * from tablenameНет :-)
> И этого достаточно для большинства задач.
Нет :-) Это всё субъективно и спорно и зависит от того, что конкретно вы имеете ввиду.
> sqlalchemy, orm django из коробки поддерживают несколько баз данных, если не пытаешьсяdjango это для веб-макак
Ну-ка, расскажи какие бы ты нагородил грабли со своим джанго и универсальностью, если понадобилось бы INSERTs/UPDATEs/DELETEs в чистом(или немного модифицированном) виде в вебсокет кидать со своей универсальностью. Боли ниже пояса не отгребешь. В Postgres есть система простейших нотификаций, которые сработают на ура в данном случае. Особенно с Mojolicious(Perl) вообще шик-блеск.Очень часто всё упирается в гораздо больше, чем просто "чуть более, чем SELECT * FROM users, зато универсально". И дело, как можно заметить, не только в "писать запросы напрямую", а и в от таких вот интересных вещах.
У вас настолько "большой" опыт, что не видите разницы между кодом собственно проекта и кодом библиотеки?
> на уровне куда более продвинутом, чем select * from tablename.Нету таких проектов.
Ну, если сторить систему по принципу "Х..к, х..к, архитектура приложения" то да, а если есть уровни абстракции то не будет проблем переделать уровень доступа к данным что бы работал с другой базой.
> Независимость от БД возможна только на уровне SELECT * FROM gostevuha.Не поверите - именно так и пишу! Фильтры и сортировки - в СУБД, остальное - апп.сервер. И это неплохо работает! А бегать как **у*дак - то поправить хранимку, то пофиксить аппсервер - нафик не надо. Есть ОДНО место для серверной логики - его и надо юзать.
> Есть ОДНО место для серверной логики - его и надо юзатьну я так и понял, что у тебя всё через ОДНО место.
как-то не реалистично звучит.
>> Независимость от БД возможна только на уровне SELECT * FROM gostevuha.
> Не поверите - именно так и пишу! Фильтры и сортировки - в
> СУБД, остальное - апп.сервер. И это неплохо работает! А бегать как
> **у*дак - то поправить хранимку, то пофиксить аппсервер - нафик не
> надо. Есть ОДНО место для серверной логики - его и надо
> юзать.А до главы про триггеры вы ещё не дочитали, понятно.
Ну не совсем так, если не писать бизнес логику напрямую на SQL, а использовать некую прослойку, которая уже будет транслировать в SQL для каждой конкретной СУБД, то можно сделать немного больше фич чем SELECT * FROM gostevuha.Например 1С:Предприятие не даёт писать программисту бизнес-логики (1с-программисту) напрямую SQL-запросы и хранимые процедуры не использует.
Вся бизнес-логика делается на стороне приложения, а запросы 1с-программист пишет на своём сильно урезанном варианте SQL. Этот урезанный SQL уже транслируется в конкретный SQL для конкретной СУБД.
В итоге используется минимум возможностей СУБД и можно с лёгкостью мигрировать между ними, хотя вся эта конструкция адово тормозит потом. :)
Жесткая привязка с СУБД - не аргумент для банка/финтеха. Я вот как раз таки целых две АБС руками щупал: одна полностью на хранимках, другая - до половины. Вот плохая масштабируемость - это да. С моей точки зрения плюсы ХП - бустрая работа и использование фишек БД, а также легкая поддержка, возможность покрутить их на лету и относительно стабильная работа (своими глазами видел 10-ти летние экземпляры, которые пережили 3 мажорных релиза СУБД даже без перекомпиляции). А вот когда нужна интеграция с кучей другого ПО или бизнес доходит до того объема, что купить новый сервер по СУБД уже тупо нельзя (нет предложений за адекватные деньги) тогда ХП с треском сливают. ИМХО, ХП хороши в качестве низкоуровневых примитивов с простой бизнесс-логикой и где идет обработка большого объема данных из СУБД за одну операцию (например, построение отчетности). А вот уже "кудрявую" бизнесс-логику онлай-сервисов и интеграции я бы выносил бы за пределы СУБД. Там, например, можно очереди налипить где оно уместно. А еденственная из виденных мной субд с нормальной поодержкой встроенных очередей это, прости господи, db2 for imb i. Но rpg это ужас.
Почитай, откуда вообще взялись хранимки. Возьми календарь, проверь текущий век. Удивись и больше не вспоминай про этот атавизм.
> Почитай, откуда вообще взялись хранимки. Возьми календарь, проверь текущий век. Удивись
> и больше не вспоминай про этот атавизм.Почитай, откуда вообще взялись у людей ноги. Возьми календарь, проверь текущий век. Удивись и больше не вспоминай про этот атавизм. Ходи на голове.
Капитан Очевидность напоминает, что головы у живых организмов появились значительно раньше, чем ноги. Впрочем, наблюдения показывают, что некоторые люди действительно стараются как можно реже пользоваться этим "атавизмом".
>> лютый жабист__:
>> Бизнеслогика в хранимочках это фуфу....
> Аноним:
> Ну, как бы жёстко привязывет тебя к определённой БД,А жёстко привязаться к одному языку программирования,
к одной платформе, к одной операционке,
это что, хорошо?
Есть страшная правда для боящихся привязаться к БД - если написан запрос сложнее "select * from table1", то вы уже привязаны. И даже не замечаете этого (так может эта привязка не такая уж страшная).> сложно поддерживать,
Одну систему (БД с хранимым кодом) поддерживать сложнее чем две (БД и "сервер с кодом")?
Вы видите, что код у вас никуда не делся, а вот лишний сервер с кучей софта добавился?> плохо масштабируются,
Хранимая процедура масштабируется хуже чем запросы (из той же процедуры ведь логика то одна)
с сервера приложений?> проблематично выражать сложные абстракции на столь простых скриптовых языках.
PL/SQL, Java, C, C++ (я об оракле) это "простые скриптовые языки"?
Какая задача у вас не может быть решена с помощью PL/SQL?
>Есть страшная правда для боящихся привязаться к БД - если написан запрос сложнее "select * from table1", то вы уже привязаны.Это совсем так, у всех диалектов SQL есть гораздо больше общего, чем вы пытаетесь представить. В значительном количестве случаев даже если нельзя один и тот же запрос использовать для разных СУБД, можно использовать вручную оттранслированные с диалекта на диалект запросы. Обычно сделать это довольно легко, т.к. это диалекты одного и того же стандартизированного языка SQL. И только при использовании хранимых процедур, специальных типов полей, триггеров, встроенных функций возникают значительные сложности для перехода с одной БД на другую.
> А жёстко привязаться к одному языку программирования,Это терпимо, ибо профессионалы пишут на одном языке и команда набирается на нём же. Тем более, что нет никаких причин менять язык. А вот менять СУБД - запросто!
> Какая задача у вас не может быть решена с помощью PL/SQL?
Задача "не плодить зоопарк языков, когда даже в основном языке люди далеко не профи" - тут ваш плссыкуль сливает по полной, ибо НЕ НУЖЕН программисту на любом высокоуровневом языке.
> Это терпимо, ибо профессионалы пишут на одном языке и команда набирается на
> нём же. Тем более, что нет никаких причин менять язык. А
> вот менять СУБД - запросто!Бывает переходят с SQL на NoSQL когда понимают что требования другие, или на свой движок как например uber, но что бы между диалектами SQL мигрировать? Приведите какой-нибудь пример кто так делал.
Если рассматривать ситуацию когда разработчики прикладного ПО и те кто его используют это разные люди, то таких примеров можно придумать много.1. Например изначально объём базы маленький и хватает возможностей какого-нибудь sqlite или другой безсерверной СУБД. Это упрощает знакомство с программой, администратору не нужно ставить и настраивать СУБД.
Затем уже, если возможностей этой СУБД не хватает (упираемся в производительность, ограничения по размеру, etc), то переходим на полноценную СУБД.
Такую возможность часто предоставляют всякие сайтовые движки, например Drupal.Подобный подход используется в системе 1С:Предприятие. Там можно начать учёт в файловой (проприетарной) базе не устанавливая СУБД, а затем перейти на MS SQL/PostgreSQL/IBM DB2/Oracle.
2. Так же, иногда выбор СУБД диктуется наличием специалиста по конкретной СУБД в организации (этот человек может быть на худой конец админом). У организации уже может быть развёрнута своя инфраструктура с работающей СУБД (в простейшем случае - есть шаред хостинг с MySQL, но без PostgreSQL).
Если ПО прибито гвоздями к какой-то СУБД, которая в организации не используется, то нужны дополнительные траты и время на обучение, развёртывание и возможно покупку СУБД (если платная).И вообще возможность выбора это хорошо. Вы же не спросите, зачем писать кроссплатформенное ПО, если можно написать только под одну ОС? Или спросите?
>И вообще возможность выбора это хорошо. Вы же не спросите, зачем писать кроссплатформенное ПО, если можно написать только под одну ОС? Или спросите?Для некоторого ПО даже и не спросим. Ибо нечто серверное делать кроссом ныне смысла нет. Онли под линух.
> Задача "не плодить зоопарк языков, когда даже в основном языке люди далеко
> не профи" - тут ваш плссыкуль сливает по полной, ибо НЕ
> НУЖЕН программисту на любом высокоуровневом языке.Программисту на любом высокоуровневом языке и транзакции "не нужны".
> Есть страшная правда для боящихся привязаться к БД - если написан запрос
> сложнее "select * from table1", то вы уже привязаны. И даже
> не замечаете этого (так может эта привязка не такая уж страшная).Продолжу.
Написал
update mytable a
set fld=123
where not exists(select * from othertable b where b.keyfld=a.keyfld)В Оракеле работает, а в МойСкуеле уже хрен.
Можно и более изощеренных примеров накидать.
Именно такой как вы написали работает и в мускуле. Что-то вы утаиваете.
> update mytable a
> set fld=123
> where not exists(select * from othertable b where b.keyfld=a.keyfld)
> В Оракеле работает, а в МойСкуеле уже хрен.
> Можно и более изощеренных примеров накидать.а если попробовать писать на sql?
1. Как часто в проекте вы меняете СУБД?
2. Нормальный DBA будет нормально поддерживать
3. Если уж на уровне СУБД всё плохо масштабируется, как это можно масштабировать лучше до запроса?
4. Зачем нужны сложные абстракции там, где они не нужны? PL/pgSQL мощный инструмент, а для остального есть бекенд
>> Ну, как бы жёстко привязывет тебя к определённой БДА так ты привязываешься к определенным языкам программирования/платформам. Ну, типа, написал систему биллинга на яве (Spring или какая-нибудь разновидность JEE с мордой на JSF или GWT) для JBoss'а (и якобы независимо от базы данных) - но твоя бизнес-логика теперь зависит от явы с сервером приложений и от фреймворка. На дотнет или руби теперь так просто не перепишешь. Если теперь касаться только бизнес-логики (а не морды) - чем это отличается от "сервера-приложений" внутри СУБД в плане поддержки бизнес-процессов? Моднее? Более того, если вся бизнес-логика засунута в базу данных, то теперь морды ты можешь написать к ней на чем угодно, причем (при желании) одновременно. Т.е. одна база, в ней же вся бизнес-логика, а "витрин" (морд) к ней написано сразу несколько на разных языках/фреймворках.
"Можете объяснить почему это «фуфу»"Потому что это убого (сравниваю с полноценными оопшными платформами, читай java EE) и медленно (несколько задач сравнивал - реализация на PLSQL в 50-сотни раз медленнее, чем код на жабе).
Можно конечно откопать несколько юзкейсов, где хранимочки быстрее и выпятить их, но в целом по больнице серверы приложений рулят.
Ложь, наглая ложь и бенчмарки.
Согласен. Сколько себя помню на адекватных для решения средствами БД задачах Java или сливала или это был MyBatis. Может благородный дон видел кривые ХП или задачки, для которых СУБД - нетрадиционно ориентированое решение?
> Можно конечно откопать несколько юзкейсов, где хранимочки быстрее и выпятить их,
> но в целом по больнице серверы приложений рулят.Ты хочешь сказать, что, к примеру, навороченная хранимка, которая сделает тыщу SELECT'ов прямо на SQL-сервере, засереализует все это в объект и отдаст приложению-клиенту, которому останется только распаковать объект, отработает медленее, чем послать эту тыщу запросов из сервера приложений?
По-моему ты мир мирдверьмяч, либо думаешь, что хранимые процедуры пишутся исключительно на PL/SQL.
> Потому что это убого (сравниваю с полноценными оопшными платформами, читай java EE)
> и медленно (несколько задач сравнивал - реализация на PLSQL в 50-сотни
> раз медленнее, чем код на жабе).Хранимая процедура != PL/SQL. Это и Java, и С/С++.
Код внешней процедуры работает быстрее чем хранимой, если он не использует данные из БД.Покажите хотя бы одну из задач, которые вы сравнивали.
> Код внешней процедуры работает быстрее чем хранимой, если он не использует данные
> из БД.Код хранимой процедуры тоже работает быстрее, если не использует данные из БД. А ещё быстрее - если вообще не использует данные.
> Код внешней процедуры работает быстрее чем хранимой, если он не использует данные
> из БД. Покажите хотя бы одну из задач, которые вы сравнивали.Уже писал тут уже не раз. Например есть на сайте ФНС база недействительных паспортов, каждый день новый файл с 100млн строчек. Надо засосать обновления. Если грузить тупо в SQL базу поверх с UNIQUE CONSTRAINT - полчаса. На жабе скачать старую базу в hashset (примерно 60 сек), выделить дельту (40 сек), заинсертить обновления (10 сек).
Более сложные примеры лень писать.
И про скорость разработки... Когда ты несколькими строчками кода с помощью JAXB маршаллишь XML-ку, потом ещё парой строчек сохраняешь с помощью ORM в базу, работаешь с полноценным объектом, и в любой момент можешь поменять СУБД. Это гуд! А церебральный секс с хранимочками это не гуд. 8)
> Например есть на сайте ФНС база недействительных паспортов...Ну и на кой, в задаче которую ты привел, нужен сервер приложений? Что тебе мешает создать этот хеш прямо в хранимой процедуре? Вот они эти 100 млн. записей, прямо на этом SQL-сервере, в таблице рядом с хранимой процедурой. Зачем эти данные гнать по сети на какой-то сервер приложений?
Ты пишешь в теме про PostgreSQL, а не в теме про Oracle. Признаюсь честно, я не специалист по Oracle, но что-то мне подсказывает, что если я могу создавать хеши в PostgreSQL (конкретно я это делал на plperl), то нечто подобное должно быть и в Oracle.
> Ну и на кой, в задаче которую ты привел, нужен сервер приложений?
> Что тебе мешает создать этот хеш прямо в хранимой процедуре? Вот
> они эти 100 млн. записей, прямо на этом SQL-сервере, в таблице
> рядом с хранимой процедурой. Зачем эти данные гнать по сети на
> какой-то сервер приложений?А мешает тут то что потом получается адский монстр, где никто не помнит что, как и почему это работает. Этого монстра невозможно поддерживать и тем более менять под новые требования.
> Уже писал тут уже не раз. Например есть на сайте ФНС база недействительных паспортов,
> каждый день новый файл с 100млн строчек. Надо засосать обновления. Если грузить тупо
> в SQL базу поверх с UNIQUE CONSTRAINT - полчаса. На жабе скачать старую базу в hashset
> (примерно 60 сек), выделить дельту (40 сек), заинсертить обновления (10 сек).1. Загрузить в пустую временную UNLOGGED таблицу
2. Сделать UPSERT из нее в целевую таблицу.
3. TRUNCATE временную таблицу
Теоретик detected. В каком именно SQL-сервере получается 100млн инсертов за 40 секунд? 8)))
Даже через COPY до такой скорости как до луны задом.
Всетаки надо научиться пользоваться СУБД. ТОгда такой ерундой заниматься не придется.
А потом DBA бегает с криком "еж твою мать, какой урод нагенерил этих уродских запросов ?!?!?!"
> А потом DBA бегает с криком "еж твою мать, какой урод нагенерил
> этих уродских запросов ?!?!?!"...после чего ему придется стать девопсом (без увеличения зарплаты) или его уволят в пользу девопса.
Неее - это вечная тема! На каждой планёрке вот уже сколько лет - "кто тормозит?!?!" и пальцем друг в друга DBA и жабщики :)))
> Потому что это убого (сравниваю с полноценными оопшными платформами, читай java EE)
> и медленно (несколько задач сравнивал - реализация на PLSQL в 50-сотни
> раз медленнее, чем код на жабе).Да ладно заливать.
К тому же подобные приложения ограничены скоростью работы с данными, а не производительностью ЯП.
> К тому же подобные приложения ограничены скоростью работы с данными, а не
> производительностью ЯП.Теоретик? В языках для хранимочек нет коллекций, нет сложных библиотек. Предполагается все данные хранить в таблицах. Соответственно, скорость ниже плинтуса на любых операциях.
А сервер приложений это по сути кеш, работающий с некоторым набором данных в ОЗУ. Объем этих данных выбираешь сам, можешь временно хоть всю базу в ОЗУ выбрать на тяжелые задачи, можешь ограничиться горячими данными. Очень гибко и в сотни раз быстрее, чем запросы к СУБД.
Просто большинство не в курсе что такое Java, особенно EE. Слышали звон про "много жрёт". А сами городят костыли из mysql + apache + php + nginx + memcached, хотя это всё делается штатно и кровавоЫнтырпрайзного качества на jEE.
Вообще, смешная тема, учитывая что реляционные СУБД уже практически померли. А тут ещё целый вагон апологетов сидит.
> Теоретик? В языках для хранимочек нет коллекций, нет сложных библиотек.Люди, использующие, к примеру, plperl в PostgreSQL, тебя никогда не поймут. Они просто даже не в курсе, что любители проприетарщины от Oracle, так сильно обделены и им не дали возможность подключать библиотеки, которые им нужны.
Для информации, в Oracle можно писать хранимочки на жабе. Но это очень неправильная жаба, если работал в нормальной IDE в большом проекте (и читал что-нибудь про шаблоны проектирования ПО).Про perl я вообще молчу, бизнеслогику в нём писать... откапывай лучше Oracle с его plsql! 8)
> Теоретик? В языках для хранимочек нет коллекций, нет сложных библиотек. Предполагается
> все данные хранить в таблицах. Соответственно, скорость ниже плинтуса на любых
> операциях.Это не так. В PL\SQL есть коллекции. Но они не особо нужны.
> А сервер приложений это по сути кеш, работающий с некоторым набором данных
> в ОЗУ. Объем этих данных выбираешь сам, можешь временно хоть всю
> базу в ОЗУ выбрать на тяжелые задачи, можешь ограничиться горячими данными.
> Очень гибко и в сотни раз быстрее, чем запросы к СУБД.Надо научиться пользоваться ораклом, если речь иден о нем.
> Вообще, смешная тема, учитывая что реляционные СУБД уже практически померли. А тут
> ещё целый вагон апологетов сидит.Очень смешно.
> Это не так. В PL\SQL есть коллекции. Но они не особо нужны.Ценное замечание про "не нужны". В бложике Тома Кайта видел примеры наследования и полиморфизма на PLSQL. К сожалению, процедура "развидеть" недоступна.
Пока мне не покажут примеры, что встроенный в Слона perl работает так же эффективно как например жабовая библиотека fastutil, я буду считать, что оно непригодно для чего-то серьёзного.Из того что я уже видел, хранимочки это - медленно + убого + монструозно выглядящий код.
Предполагаю, что где-то есть божественно прекрасные DBA, которые творят шедевры в хранимочках, но давайте на землю спускаться, если технология в руках прогера с 3-5 лет опыта не рулит, то нафиг она нужна в 98% случаев?
> Пока мне не покажут примеры, что встроенный в Слона perl работает
> так же эффективно как например жабовая библиотека fastutil,
> я буду считать, что оно непригодно для чего-то серьёзного.Что доказывать то? Что си быстрее жабы, и что си жрет память меньше чем ява? По-моему и так все очевидно.
Ты не учитываешь, что перловики это читеры. Когда перловикам нужна скорость или экономия памяти, они выносят узкое место на C, и оборачивают эти функции в перловый модуль. На CPAN полно либ с таким подходом.
Именно так, например, работает один из самых быстрых сериализаторов в Perl - Sereal.pm, для JSON у них есть JSON::XS и т. д. Оверхед практически ничтожен, скорость на высоте.
Т.е. хранимочки быстрее аппсервера если хранимочки писать на перле с сишными вставками?
При наличии бесконечного количество прогеров и бесконечного времени это действительно лучше, чем аппсервер. 8)Кстати, вот ещё задачка, которая для SQLщика "ну, чисто SQL-ная, щас сделаю", а на аппсервере будет в разы быстрее работать и по времени разработки/сопровождения разорвёт хранимочки:
1. есть список из кадровой системы ФИО, код отдела, код сотрудника (у меня это 40к записей)
2. есть список из AD (десяток полей) (у меня это 20к записей)чёткой связи НЕТ. фио может быть с перестановкой, опечаткой, фио может не быть (не все имеют компы), есть полные тёзки. надо найти всех уволенных и залочить в AD.
т.е. на каждую запись по несколько проверок, включая перестановки И Ф О, поиск коллег, поиск похожих левенштейном итд.Я засасываю за 400 милисекунд оба списка полностью в List-ы и пошёл stream-ами эти проверки делать (маздайщики LINQ заюзают) (короткая строчка кода на каждую). Удачи вам в написании такого запроса 8))))) или написании на си перестановки левенштейна. Я эту задачу за 3 дня сделал и оттестил, а вы за месяц управитесь на всё про всё?
> 40к записей
> 20к записей
> 400 msНа вебе все, что больше 300 ms считается медленным. У мена хранимки на перле выполняют за один запрос из клиента, от 500 до 600 запросов строя всякие деревья, все это с фильтрами, которые приходят в хранимку как JSON, т. е. запросы динамические. Попутно вытягивается всякая дополнительная фигня из других таблиц в каждую ветку дерева. И на все это уходит меньше 100 ms. Веб-серверу остается только десериализовать объект и расставить данные в нужные места страницы. А когда все это выполнялось непосредственно на веб-сервере (читай сервер приложений), то доходило до 1.5-2 секунд. Эта проблема вылезла не сразу, а потому что манагеры каждые месяц подкидывали все новые и новые хотелки. В результате все начало безбожно тормозить и пришлось переходить на хранимые процедуры.
Скажем так, я попробовал обоими способами и выбрал, тот что быстрее. Я не спорю, возможно в кровавом ынтерпрайзе 1.5-2 секунды это нормально, но за сайт, который будет отвечать на запрос больше 500 ms Вам дадут по шее.
600 SQL-запросов за 100мс? Ещё и при не одном клиенте... Свежо питание, да.... 8)Кстати, никто не мешает с аппсервера дергать хранимочки, где это ДЕЙСТВИТЕЛЬНО нужно. А вот наоборот - опаньки-с!
> 600 SQL-запросов за 100мс? Ещё и при не одном клиенте...Да. Речь идет об выборке данных на основании которых строится рекурсивно дерево групп с разным уровнем вложений. Перед вызовом рекурсивной функции создается план запроса к таблице которая содержит информацию о дереве. Это готовый план уже и используется в перловой рекурсивной функции. В дереве порядка тысячи групп, на каждую ветку вызывается SELECT, но так как не все ветки попадают в результат, то в среднем получается по 500-600 селектов.
Я знаю, что деревья можно строить и на самом SQL, т. е. про WITH RECURSIVE я в курсе. Этот вариант тоже был опробован, но он оказался медленнее. Плюc при тупом вызове селектов, попутно можно считать еще кучу всякой фигни, с WITH RECURSIVE такой трюк реализовывать сильно сложнее.
Клиенты с одинаковыми запросами это не проблема. Нагрузка снимается кешированием, так запрос прилетает в хранимую процедуру одним параметром в виде JSON, то по этому JSON высчитывается md5 и результат кешируется на некоторое время в отдельной таблице, опять же все это происходит на SQL-сервере и поэтому происходит очень быстро.
> аппсервера дергать хранимочки.
Спасибо, но мне не нужно лишнее звено, так как PostgreSQL сам по факту аппсервер и к данным он ближе любого другого аппсервера. Плюс все более менее стандартные запросы хранятся в виде готовых планов в глобальном хеше $_SHARED, что знаете ли тоже сильно сказывается на производительности.
>Теоретик? В языках для хранимочек нет коллекций, нет сложных библиотек. Предполагается все данные хранить в таблицах. Соответственно, скорость ниже плинтуса на любых операциях.Не жрите оно, возьмите чё нормальное. оркал или постгрес к примеру.
>А сервер приложений это по сути кеш, работающий с некоторым набором данных в ОЗУЭТО ШЕДЕВР! Лучшего диагноза жабы головного ганглия - поискать ... :-)
До чего же вы жабшики ... как бы это вежливо ... Д,Б! (С) Лавров :-)
PS: СЕРЬЁЗНО! Почитай об архитектуре PostgrSQL - оно в открытом доступе ... опупеешь :-))))
"Несерьёзный тип. Бизнеслогика в хранимочках это фуфу"
Смотрю серьёзные набежали, и как оно у вас в банке?
Смотря каке там хранимочки.Если как ораклячие ПЛ\СКУЭЛ то вполне реализуемо.
Если что-то вроде мойскуэля, то очень трудоемко, на мой взгляд.
> Смотря каке там хранимочки.
> Если как ораклячие ПЛ\СКУЭЛ то вполне реализуемо.
> Если что-то вроде мойскуэля, то очень трудоемко, на мой взгляд.И что? Предлагаешь каждому Джависту, Паскалисту, Шарповоду изучать ещё и проприетарный оракловый пл/скл? ОДНОГО хорошего языка достаточно для любой работы.
> И что? Предлагаешь каждому Джависту, Паскалисту, Шарповоду изучать ещё и проприетарный
> оракловый пл/скл? ОДНОГО хорошего языка достаточно для любой работы.А 640 килобайт хватит всем?
Вообще-то без тех или иных мини-языков или языков разметки сейчас не обойдёшься, программируй ты хоть на чём. Регекспы, форматные строки, SQL, XML, HTML, JSON могут использоваться в одной программе, написанной целиком на одном языке.
> И что? Предлагаешь каждому Джависту, Паскалисту, Шарповоду изучать ещё и проприетарный
> оракловый пл/скл?Крутой кодир почувствовал себя не крутым, потому что ему кто-то на районе из пацанов сказал, что для того чтобы написать хранимку надо знать пл/скл?
Можешь ничего не учить, и всегда оставаться на одном уровне. Твоей любимый быдлoязык PHP? Не сцы чуваг, он тоже поддерживается: https://www.postgresql.org/docs/9.6/static/external-pl.html
> ОДНОГО хорошего языка достаточно для любой работы.конечно же, джаваскрипта.
Если кодир работает с СУБД, то он это обязан знать.
Проще на Rust начать писать SQL сервер с нуля.
брать не будут, а тут пиар бесплатный: мы как postgres, только безопаснее
> брать не будут, а тут пиар бесплатный: мы как postgres, только безопаснееЭтот "пеар" у прогеров не прокатит - все понимают, что помимо циклов/условий есть целая тонна вещей, которая в каждом языке - своя.
> Этот "пеар" у прогеров не прокатитА они и не прогерам это продавать будут, а менеджерам верхнего звена.
> А они и не прогерам это продавать будут, а менеджерам верхнего звена.А менеджерам верхнего звена все это надо? Их интересует как срубить на яхту покруче и новую виллу. Себе и акционерам. А если это не получится, акционеры менеджера уйти могут.
> Их интересует как срубить на яхту покруче и новую виллу."Разработчики RustgreSQL сказали нам, что она написана на более безопасном языке, что позволит нанимать для поддержки более дешёвых программистов, что позволит мне купить виллу раньше, чем я думал. Переходим на Rustgres. И этих, небритых, студентов-сишников давайте тоже заменим на десятиклассников, так ещё дешевле будет."
"Ой, мой сына устроился растопрогером и зарабатывает вдвое больше моего сишного. Пойду тоже на расте писать, благо и мозг уже атрофироваться начал, на си тяжело стало писать, а на расте самое то."
"Ой, что-то после перехода отдела разработки на раст наш софт стал чаще глючить и тормозить. Нет, это не проблемы безопасности. Спросил руководителя отдела, Растова Ванюшку из 8в класса, с чем может быть связано, он сказал, что это нормально и не бывает софта без ошибок".
"Что-то последние два месяца совсем без премии. Наверное, процесс безграмотно выстроен. Пойду в другую компанию куда давно приглашают для перевода своего дорогостоящего си-отдела на раст, там и зп обещают повыше, и процесс наверное будет выстроен грамотно. Вот яхту себе поновее куплю."
Крутые аналогии, бро! Ещё бы матчасть подтянуть, потому как в реальности как раз сишка много проще растов будет.
Хорошо тебе стэк сорвало. Жаль что в этом крахдампе мысль не угадывается.
> Is anyone working on porting PostgreSQL to Rust?
> My motivation is primarily I don't want to learn all the over-complicated details of C, but at the same time I would like to be productive in a safe system language, a category in which Rust seems to be alone.Расходимся, это просто мимокрокодил, который и С-то не знает, а хочет, чтобы кто-то ему транслятор из С в Раст запилил.
>> Is anyone working on porting PostgreSQL to Rust?
>> My motivation is primarily I don't want to learn all the over-complicated details of C, but at the same time I would like to be productive in a safe system language, a category in which Rust seems to be alone.
> Расходимся, это просто мимокрокодил, который и С-то не знает, а хочет, чтобы
> кто-то ему транслятор из С в Раст запилил.А какой объём активов у тех 52 банков? Может и найдут.
(Wikipedia) payments of more than EUR 1.7 billion annually were processed. In 2016
Кроме того, его аккаунт в гитхабе с 0 коммитами за последний год подтверждает качество отборки новостей на опеннете.
> Кроме того, его аккаунт в гитхабе с 0 коммитами за последний годА это уже преступление, не комитить на гитхаб? :-)
> подтверждает качество отборки новостей на опеннете.
Согласен, подача новости совершенно не верная.
> Перевод с Си на Rust планируется полностью автоматизировать
Чувак просто написал в рассылку что ему на новогодних праздниках в голову пришло, а тут это подают как будто он уже проект начал.
> из С в Раст запилилОн уже запилен, на хаскеле там лежит
То есть сейчас имеется код на C в котором есть проблемы с памятью.
Он может быть автоматически переведён на другой язык, а затем скомпилирован в машинный код и проблемы исчезнут?
Было бы неплохо всегда так компилировать.
> То есть сейчас имеется код на C в котором есть проблемы с
> памятью.
> Он может быть автоматически переведён на другой язык, а затем скомпилирован в
> машинный код и проблемы исчезнут?
> Было бы неплохо всегда так компилировать.Есть вариант что не даст откомпилировать, другой вопрос что после этого делать, так как исходя из озвученного, нужно будет поправить C-код, который даёт ошибку при трансляции, а это уже не пахнет автоматизмом.
p.s. В своё время firebird был полностью переписан на C++.
Об этом Якобс не думает, не царское это дело.
> Он может быть автоматически переведён на другой язык, а затем скомпилированДа, на данный момент, исключительно с помощью магии.
https://github.com/jameysharp/corrode
> и проблемы исчезнут?Думаю, имеется ввиду другое. Проблемы не исчезнут. Но проблемы уровня "нас плимели через переполнение буфера" заменятся на проблемы "вчера внезапно возрасла нагрузка с такого-то ip, после чего система упала со стектрейсом в 500 строк".
> Думаю, имеется ввиду другое. Проблемы не исчезнут. Но проблемы уровня "нас плимели
> через переполнение буфера" заменятся на проблемы "вчера внезапно возрасла нагрузка с
> такого-то ip, после чего система упала со стектрейсом в 500 строк".И часто ты видишь поимение серверов через переполнение буфера? Вроде сейчас намного чаще имеют через вебприложения. А то что буфера не переполняются - вебне почему-то не очень помогает.
> Было бы неплохо всегда так компилировать.Так компилируй, с -fsanitize=address и что там тебе еще надо. А то что скорость получится go-образная - сам понимаешь, дополнительные проверки.
> Так компилируй, с -fsanitize=address и что там тебе еще надо. А то
> что скорость получится go-образная - сам понимаешь, дополнительные проверки.А можно использовать наработки в компиляторах за последнии 40 лет и добавить в ЯП фишки, позволяющие делать проверки в компайлтайме. Потому как не только софт за эти годы стал сложнее, но и железо мощнее и как-то глупо пользоваться этими мощностями только для проверок во время выполнения.
Сразу видно человека, который не компилировал бустопроги.
> Сразу видно человека, который не компилировал бустопроги.Что сказать-то хотел? Что плюсы не используют наработки в компиляторах? Что туда не добавляют фичи? Правда, легаси и в плюсах дает себя знать, но вообще-то речь шла о сишке.
Ну так почему C++ так долго компилируется - вот поэтому.
В С++14 можно создать даже класс с конструктором, который будет выполняться во время компиляции.
> в ЯП фишки, позволяющие делать проверки в компайлтайме.Я конечно понимаю что CS у россиян не в почете, но до того как умничать - наверное азы типа halting problem стоит почитать? Полный анализ поведения программы выполнить невозможно. Тюринг предствил математическое доказательство, взяв для примера довольно простой случай, изучающий завершится ли программа за конечное время. Поэтому если кто-то верит в всемогущесть статического анализа - он, простите, нуб и ламак, который не соизволил читануть азы по минимуму, но мнение имеет.
> Потому как не только софт за эти годы стал сложнее, но и железо мощнее
> и как-то глупо пользоваться этими мощностями только для проверок во время выполнения.У проверок во время выполнения есть определенная фича. Их Тюринг не жмет. Ну то-есть если вы видите фактический доступ к адресу памяти который за границей массива - это одно. А попытки в статике проанализировать может ли в принципе эта программа взять 101-й элемент массива при том что их всего 100, при всех мыслимых манипуляциях - то же самое что halting problem, вид сбоку. Поэтому таки или будут проерки в рантайме что индекс от нуля до сотни и они сожрут время, или проверок таки не будет и можно будет сунуться в 101-й элемент и даже что-то получить. А какие еще варианты есть???
> Поэтому если кто-то верит в всемогущесть статического анализа - он, простите, нуб и ламак, который не соизволил читануть азы по минимуму, но мнение имеет.Убрать все обычные циклы, оставить только foreach (range-based for loop) и добавить гибридные циклы с условием и параметрами обхода. И тогда не получится залезть в 101 элемент + можно добавить автоматические оптимизации, ведь компилятор будет значть что хочет программист. Статический анализ может и не всемогущ, но при правильном проектировании можно избежать всех ошибок в комплтайме.
> Убрать все обычные циклы, оставить только foreach (range-based for loop) и добавить
> гибридные циклы с условием и параметрами обхода.И все бы ничего, но это уронит скорость выполнения. Примерно настолько же насколько и явный bounds checking в рантайме. Догадаешься с трех раз почему? Проверки на вшивость в рантайме или есть или нет. Третьего не дано. Понимаешь, у CPU нет такого понятия как foreach. Он вообще другими сущностями оперирует. И ты (или твой компилер/рантайм) или таки провалидируете что вы не лезете в левую память или таки есть шансы поиметь проблем. Халявная по скорости защита памяти на уровне железа - работает с гранулярностью страницы, и то заточено на защиту ОС от софта и процессов друг от друга. А части процесса друг от друга так защищать уже несколько накладно.
>> в ЯП фишки, позволяющие делать проверки в компайлтайме.
> Я конечно понимаю что CS у россиян не в почете, но до
> того как умничать - наверное азы типа halting problem стоит почитать?Что, кроме тюринга ничего больше не знаешь? А моежт еще стоит, до того как влезать с тюрингом где можно и нельзя, азы компайлостроения почитать?
> Полный анализ поведения программы выполнить невозможно.Где ты увидел "полный анализ", болезный? Ну и следуя твоей логике, вообще никакие проверки не нужны, ведь они не полные.
> Тюринг предствил математическое
> доказательство, взяв для примера довольно простой случай, изучающий завершится ли программа
> за конечное время.Ну давай, сформулируй для частного случая анализа, я хоть посмеюсь.
> Поэтому если кто-то верит в всемогущесть статического анализа
> - он, простите, нуб и ламак, который не соизволил читануть азы
> по минимуму, но мнение имеет.А ты самокритичен, этого не отнять.
> А попытки в статике проанализировать
> может ли в принципе эта программа взять 101-й элемент массива при
> том что их всего 100, при всех мыслимых манипуляциях - то
> же самое что halting problem, вид сбоку.Cпасибо, давно так не смеялся.
> У проверок во время выполнения есть определенная фича. Их Тюринг не жмет.
Ну и сиди на своем питоне и прочих базиках, как раз для таких экспертов и знатоков.
> Что, кроме тюринга ничего больше не знаешь? А моежт еще стоит, до
> того как влезать с тюрингом где можно и нельзя, азы компайлостроения почитать?А что, кто-то смог сотворить чудо и сделать bounds checking без просадок скорости?
Ну вот смотри, есть у меня массив записей, число записей задается на основе внешних данных. Значит на фазе компиляции это никак невозможно просчитать, а всякие foreach будут вынуждены делать тот же bounds checking вид в профиль. Или его можно будет нае...ть, на выбоо.
> Где ты увидел "полный анализ", болезный? Ну и следуя твоей логике, вообще
> никакие проверки не нужны, ведь они не полные.Я просто к тому что напирание на безопасность в этом случае как-то излишне оптимистично. Статические анализаторы штука хорошая, но и близко не панацея. К тому же вебмакаки показали много чудных способов как позволить разломать сервер вообще не пуская хакеров в управление памятью. Да и Bobby Tables любителям сабжа приветы передавал.
> Ну давай, сформулируй для частного случая анализа, я хоть посмеюсь.
ИМХО, невозможно заранее статически полностью проанализировать конструкции которые динамически выделяются в рантайме, например на основе входных данных. А потуги сделать нечто типа foreach уронят скорость, потому что это более не будет лобовым доступом к памяти без дополнительных приседаний.
> А ты самокритичен, этого не отнять.
И это тоже. Правда я не верю в всемогущесть статического анализа.
> Cпасибо, давно так не смеялся.
Ну это несомненно был мощный технический аргумент вашей правоты.
> Ну и сиди на своем питоне и прочих базиках, как раз для
> таких экспертов и знатоков.А в этом месте смеялся уже я. Васик я видел где-то в конце 80-х чтоли.
1. Если программист написал настолько сложную программу, что он сам для себя даже примерно не может сказать, как она поведёт себя (остановится или нет, где может упасть), то зачем он её вообще писал? Если на практике мы чаще всего имеем дело с программами, написанными людьми и читаемые людьми, то почему сразу вспоминают Тьюринга и какие-то сферические в вакууме программы?2. Для многих алгоритмически неразрешимых задач и задач с экспоненциальной сложностью давно уже разрабатывались эвристические методы, чтобы хоть как-то приближённо решать эти задачи. Даже проблему остановки можно попытаться решить с некоторой степенью глубины анализа. Трансляция из языка в язык - тоже довольно реальная задача для программ, встречающихся на практике (написанных и понимаемых людьми).
> то почему сразу вспоминают Тьюринга и какие-то сферические
> в вакууме программы?При этом еще благополучно забывают (после того как не знают, такое вот у них отличное качество преподавания СS в Не Этой Стане :) ), что все это применимо в первую очередь к невозможности создания _одной универсальной_ машины для анализа _всех возможных_ машин со _всеми возможными_ вводами.
А то, что все возможные вводы в реальном мире не нужны и их можно хорошо так отсечь, да и при анализе, если что, выдать "этот вариант проанализировать не могу, прошу уточнений, правки или оверрайда!", так для этого хоть что-то понимать надо, а не повторять мантры.
Тот же примерчик с индексом отлично показывает "понимание" темы данным индивидом. Потому как на самом деле такие левые индексы прилетают не по либастралу, а с вводом пользователя, либы и т.д. И их придется проверять по-любому.
Только в отличие от "best-practice" проверок по два-три раза подряд, как в том же системды, можно ограничиться одной проверкой и воплями компилятора при отсутсвии оной.И вообще, анализизируют обычно не все возможные варианты, а только возможность отклонений от сценария, описанного програмистом. Т.е. достаточно найти место, где может прилететь тот же левый индекс неопределенной величины и выдать предупреждение, а не пытаться почему-то представить себе все мыслимые манипуляции.
Только все это метание бисера - данный индивид или объявит, что "вы усе врети!" или что он, такой велики и неповторимый, все это на самом деле уже знал и просто так своебразно троллил )
>> то почему сразу вспоминают Тьюринга и какие-то сферические
>> в вакууме программы?(:1)
> в первую очередь к невозможности создания _одной универсальной_ машины для анализа _всех возможных_ машин со _всеми возможными_ вводами.
[[Я не распарсил длинного последовавшего текста. Наверное, с сарказмотэгами опять непроходимость где-то, поэтому применю сию----^^^ строку к длиннотам ниже. Хотите считайте продолжением глумления над предыдущим оратором, хотите -- над обоими (новооткрытый тэг ниже именно про это).]]
> том же системды, можно ограничиться одной проверкой и воплями компилятора при
> отсутсвии оной.
> И вообще, анализизируют обычно не все возможные варианты, а только возможность
> отклонений от сценария, описанного програмистом. Т.е. достаточно найти место, где можетВы назовёте уже изнывающей публике универсальный ЯП [с транслятором, понятно], таки проверяющий Ваш "возможный сценарий" для _своих_ входных данных (всех и любых програм на нём, языке) -- чтоб все коды, что "собрались" уже-таки были "безошибочны, мамой клянусь", да?
---Вы прочитали применение (:1) для познания рекурсии.
...Объявляю тэг(*2) #форумная-ЦС (*3) Открытым! ура.(*2) #форумная-криптография, в продолжение, да:
http://www.opennet.me/openforum/vsluhforumID3/109852.html#45
http://www.opennet.me/openforum/vsluhforumID3/109704.html#6
http://www.opennet.me/openforum/vsluhforumID3/106299.html#14
...итдпттптптптпт
(*3) Как это по-русски-то правильно, кстати... Не "программирование" же!?> Только все это метание бисера - данный индивид или объявит, что "вы
> усе врети!" или что он, такой велики и неповторимый, все это
> на самом деле уже знал и просто так своебразно троллил )Форумное "толкачём в ступе". Тэг не нужен, оно везде.
>> в ЯП фишки, позволяющие делать проверки в компайлтайме.
> Я конечно понимаю что CS у россиян не в почете, но до
> того как умничать - наверное азы типа halting problem стоит почитать?
> Полный анализ поведения программы выполнить невозможно. Тюринг предствил математическое
> доказательство, взяв для примера довольно простой случай, изучающий завершится ли программаСуществует такая вещь, как SMT-solver'ы. Они могут проверить граничные условия, заданные для какой-то функции и её частей.
Язык Ada Spark https://en.wikipedia.org/wiki/SPARK_(programming_language) такое может
и пример проекта http://blog.adacore.com/tetris-in-spark-on-arm-cortex-m4Для языка Си давно уже существует Frama-C https://en.wikipedia.org/wiki/Frama-C который точно так же позволяет гарантировать некие условия, выполняющиеся функцией.
Эти вещи не применяются в разработке массового ПО, в том числе опенсорцного потому, что господа сишные хакеры в большинстве своём малограмотны в CS и не "заточены" под долгую кропотливую работу, дающую корректный результат. Также, Frama-C предполагает, что в некоторых случаях разработчик будет пользоваться Coq, а это уже очень требует очень высокий уровня владения довольно специфичной математикой.
Военного происхождения Ada Spark - простой, как кирпич и ничего такого не требует, хотя он и менее мощен, чем научная французская Frama-C, зато язык Ada гораздо более стандартизирован, чем Си, и от него не стоит ждать неожиданностей. Но с ним другая беда - во-первых, он не си, а паскаль, там видите ли begin и end, от вида которых у байтогрызиков начинается фрустрация. Во-вторых, в бесплатном виде он распространяется только под GPL, а большая часть проектов имеет двойное лицензирование - если они хоть кому-то будут продаваться за деньги. Коммерческий же Spark стоит дорого, примерно как четыре колеса от джипа, но у байтогрызов зачастую нет не то, что джипа, а даже и тоёты, они на велосипедах ездят, с зеркалками, интересные проекты делают. Денег у них нет.
Поэтому пользователи OSS так и будут ловить CVE, к ним будет лезть NSA и все прочие кибержулики. Потому что во главу ими была поставлена хакерская скорость разработки, а не промышленная надежность. Пришёл упорный инженегр Линус, быренько наrовнякал реализацию Posix, раньше Столлман доделал своё, и теперь нам всем с этим жить, мода задана на много лет вперёд. 12309! Я думаю, что финскому жирному пингвину помогли придти к успеху те самые люди, про которых Сноуден рассказывал. Чем больше дыр и ненадёжного софта - тем лучше для этих. Люди работают, понимать надо.
Более того, поскольку программистская культура в общем-то едина, те же самые скоростные багоделы пишут и коммерческий софт. Это модно.
PS: доказанное ядро на Ada Spark, https://muen.sk/
Понимаете ли, на паскале с пред- и пост- условиями написали ядро, без дырок.PPS: по бенчмаркам на https://benchmarksgame.alioth.debian.org/u64q/ada.html Ada работает примерно со скоростью Си и иногда обгоняет С++, причём Ada у них старая, 2005, а не 2012
В БД, отличительно от прикладной программы, одной из основных подсистем это работа с памятью. И насколько хорошо она сделана зависит и производительность самой БД.
клоун:
1. речь он ведёт не про производительность, а про безопасность
2. я не припомню ошибок Postgre из-за ошибок работы с памятью. А вы? Зачем чинить то, что не сломано?
3. (моё любимое) вы написали полностью правильные слова, которые совершено не относятся к обсуждаемой теме.
> 1.
> 3.
> В качестве мотива создание порта называется избавление от необходимости оглядки на усложнённые детали при работе с памятью на языке СиПро память как раз в первую очередь сказано.
А на счет безопасности: бд как правило не реализует View потому находится где-то внутри проекта, в DMZ. Безопасность конечно хорошо, но реального профита все равно маловато будет.
> 2.
Я тоже не припомню. Мне постгря нравиться в текущем виде.
Вы меня просто не так поняли.
> 2. я не припомню ошибок Postgre из-за ошибок работы с памятью. А
> вы? Зачем чинить то, что не сломано?Как же не чинить? Весь раст придуман для решения одной на самом деле не существующей проблеммы плюсов. и что теперь, им делать ?
>Весь раст придуман для решения одной на самом
> деле не существующей проблеммы плюсов. и что теперь, им делать ?Монетизировать? "Выходить в деньги"? Как это у них там, при разводе кроликов называется-то?... Забой после отстоя пены?-----апризыбудут
Согласен. И нормальный программист сделает её намного лучше, чем всякие автоматические сборщики и т. п.
> В БД, отличительно от прикладной программы, одной из основных подсистем это работа
> с памятью.Что-то мне тоже подсказывает, что одним GC тут не обойтись. Как вариант, _может_быть_ можно как-то отконфигурить автопамять ближе к задачам СУБД, т.е. работа с громадными блоками, поменьше перевыделений, пореже сборка мусора... мож и получится что путное!
> Что-то мне тоже подсказывает, что одним GC тут не обойтись. Как вариант,
> _может_быть_ можно как-то отконфигурить автопамятьКазалось бы, причем тут GC?
Мне кажется он хочет понять, насколько реально сделать СУБД без ручного управления память. Так не яве же есть.
Не хватало ещё тормозов.
> Не хватало ещё тормозов.Ну вот, ты пришёл - теперь хватает.
Rust - язык, ориентированный на безопасность, но с сохранением, а в некоторых случаях и увеличением производительности относительно с++. Проектировщики языка это подчеркивают постоянно.
Подчёркивают, иначе им ничего не светит супротив c++. Только это буллшит, как показывает практика. В реальной работе - нужен unsafe, и раст превращается в очередного "убийцу с++" с ЕЩЁ БОЛЕЕ вырвиглазным синтаксисом, чем c++, и лишь немного менее многословным чем жаба.Ах да, вам нужна специфическая библиотека? Будьте готовы или писать её с нуля, или писать биндинги к "небезопасной" сишечке, бгг.
т.е. у него нет перспектив? Я читал что из-за повсеместного применения указателей в c++ проблемотичны некоторые оптимизации. В rust подобные ситуации легко поддаются анализу компилятором.
Ну как нету. В 2010м всё переписывали на руби, даже небо, даже аллаха. Это было модно. И где это руби теперь? Да всё там же! Пускалкой для рельс оно было, ей и осталось.На Окамле вон тоже до сих пор пишут, хотя тоже позиционировалось как убийца всего на свете.
Началось! Скоро всё начнут с С/С++ на раст переписывать
Да погоди ты. Еще на Go, Ruby и JavaScript не все переписали!
> Да погоди ты. Еще на Go, Ruby и JavaScript не все переписали!Нене... "переписывалы" обычно приходят с самыми @е6и/\ьными вариантами: переписать всё на JS(который они не знают), потом на PHP(на котором они кодят 2-страничные сайты), затем на языке, который они сами вчера услышали (Go/Rust) и только лет в 40-50 до них дойдёт язык Ди. :)
My motivation is primarily I don't want to learn all the over-complicated
details of C,
but at the same time I would like to be productive in a safe system
language,
a category in which Rust seems to be alone.это в принципе все, что следует знать об этой идее.
шо-та дофига сложные эти ваши мануалы, запилите мне кто-нибудь роликов на ютубе.
Память освободил уже?
Вообще конечно все к этому и идет: удобство и скорость разработки в ущерб производительности.Но тут надо понимать задачи и уровни. Производительности БД как правило всегда не хватает, а значит и писать ее еще очень долго будут языках пониже уровнем, с ручным управлением памятью и проца.
А прикладники уже давно положили: то на питонах гуи пишут, то на js, то на QML.
> А прикладники уже давно положили: то на питонах гуи пишут, то на
> js, то на QML.Ну вообще-то не прямо на питонах и js. Код на них только вызывает библиотечные функции/методы объектов, написанные на C/C++. А QML - это вообще язык разметки, он не императивный. Это как JSON-объекты считать программами на JS.
Если уж на то пошло, то вы вообще не забывайте, что сейчас в вебе вместо растровых картинок большей частью распространён декларативный код с на HTML, CSS. А использование императивных языков для разметки текста вообще имеет давние корни в виде языка PostScript, который дал начало современному PDF и всё ещё продолжает использоваться внутри него.
> Вообще конечно все к этому и идет: удобство и скорость разработки в
> ущерб производительности.Дык сильно тебе нужна бд или что там еще с достоинством "зато разработчики не напрягались"? Скайп с своим новым киентом уже вон и то отвадил половину хомяков.
>Вообще конечно все к этому и идет: удобство и скорость разработки в ущерб производительности.единственный "ущерб производительности", который есть в rust по сравнению с C/C++ - туда пока не добавили явную поддержку SIMD-расширений. В остальном все то же самое, имеется арифметика указателей и т.п.
QML лёгкий, быстрый и гибкий. Отрисовывается на OpenGL. Вручную так быстро рисовать не получится.
> QML лёгкий, быстрый и гибкий. Отрисовывается на OpenGL. Вручную так быстро рисовать
> не получится.Ты знаешь, компьютеры уже в конце 80-х рисовали быстрее чем вручную, так что сомнительное достоинство :)
"Выступил с инициативой...", лол. Чувак просто спросил в списке рассылки "насколько это реально". А тут "с инициативой"! "Выступил"!
Вот, между прочим, про то, что Эрик Раймонд заявил[1], что они там серьёзно думают NTPsec переписать либо на Go, либо на Rust -- об этом умолчали. А вот всякую хрень тут постят.
> Вот, между прочим, про то, что Эрик Раймонд заявил[1], что они там
> серьёзно думают NTPsec переписать либо на Go, либо на Rust --
> об этом умолчали. А вот всякую хрень тут постят.
> 1) https://blog.ntpsec.org/2017/01/03/getting-past-c.htmlТочняк, тоже видел сообщение Эрика, надо сделать новость (мне лень), сделаешь?
> Вот, между прочим, про то, что Эрик Раймонд заявил[1], что они там
> серьёзно думают NTPsec переписать либо на Go, либо на Rust --
> об этом умолчали. А вот всякую хрень тут постят.
> 1) https://blog.ntpsec.org/2017/01/03/getting-past-c.htmlна яве пусть сразу переписывают. еще GC в NTP сервер затащить осталось и хорош.
> серьёзно думают NTPsec переписать либо на Go, либо на Rust --Сразу видно по прожЭкту собираемому какой-то WAFлей что это Серьезная Штука. Не то что какой-нибудь openntpd, который просто работает.
У раста, как я понял, из-за безопасного программирования порог выше. В остальном он ни чем не уступает c++?
Кто минус поставил, мог бы и ответить
> Кто минус поставил, мог бы и ответитьОтписать что? Что у плюсов порог входжения на троих хипстеров с rust и go хватит? Так это и так все кто всерьез пользовался плюсами знают. А хипстеров не любят за характерный антипаттерн: ни в чем не разбираться, но мнение иметь.
Ну все же вы больные люди…
> Ну все же вы больные люди…Я вообще не плюсовик, всего лишь сишник. А вот знакомые плюсовики - в массе своей очень крутые ребята. И один плюсовик легко обставит троих хипстеров. Написав что-нибудь крутое, сложное, быстрое, алгоритмически интересное и вообще - state of art. В отличие от сайтов-однодневок и каких там еще наколенных прототипов программ.
Иногда попадаются откровенные жгуны, типа забредающего сюда иногда deadfood'а. Этот вообще написал помесь DE с файлокачалкой. Оно еще и работает, хоть нужность этого именно вот в таком виде и не очевидна. И как угодно но это все-таки что-то рабочее. А не какая-то сферическая ОС в вакууме, нерабочий браузерный движок и теоретически-крутая файлуха без единственного пользователя.
>> Кто минус поставил, мог бы и ответить
> Отписать что? Что у плюсов порог входжения на троих хипстеров с rust
> и go хватит? Так это и так все кто всерьез пользовался
> плюсами знают. А хипстеров не любят за характерный антипаттерн: ни в
> чем не разбираться, но мнение иметь.По-моему в с++ только щаблоны сложны, остальное осваивается быстро и безболезненно. С rust вообще не знаком и серьезных сравнительных обзоров пока я не видел, но судя по общей картине с++ уступает rust'у во всём. Но его пока вытягивает обилие готовых отлаженных библиотек типа boost, Qt и т.д.
Так это... даже сишник может сделать питониста по скорости написания программ, если возьмет готовые библы там где другой чувак будет велики изобретать. А приколись, если ты хочешь спроектировать компьютер, начинать с технологий добычи медной руды может быть не совсем удобно и оптимально.
У Rust'а есть сильные стороны по отношению к С++, но всё же десятилетия форы дают себя знать.
Для него ещё нет подборки вайна "$feature considered harmful". Перспективные темы: "unsafe or speed: choose one", "rust has no libs", "compatibility is broken again".
Сначала должны появляться инструменты, а потом продукты. Лучше бы в Qt поддержку запилили...
А я предлагаю переписать ядро Linux на JS, давайте тоже обсуждать.
Я тоже думаю жс быть не должно , вспомнити npm leftpad и Nan =! Nan, а еще вспомнити 0.1 + 0.2 = 0.300000000000000004 , а еще вспомнити атом а еще вспомнити как он тормазит
опять ты тут вылез со своим 0.1 + 0.2? я же тебя уже ткнул носом, что ты не прав. иди обратно в школу
> Nan =! Nan, а еще вспомнити 0.1 + 0.2 = 0.300000000000000004Это особенность арифметики с плавающей запятой, эта арифметика во всех языках одинаковая, т.к. в конечном счёте реализуется за счёт аппаратных возможностей процессора.
клоун: ты бы хоть объяснил человеку в чём именно он не прав.NaN (Not a Number, "не число") - это результат операции, приведшей к переполнению или невозможности выполнения. Прибавим к максимальному значению 1, получим NaN. Затем вычтем из минимального возможного значения 1, получим NaN. Отсюда понятно что NaN не равен другому NaN.
Компьютер хранит не абсолютные значения, а степени двойки. Поэтому 0.1 в его представлении это не 1/10, а аппроксимация запаянной в него экспоненциальной функции. И, как любая аппроксимация, она редко бывает в точности равна искомому значению.
> Компьютер хранит не абсолютные значения, а степени двойки. Поэтому 0.1 в его представлении это не 1/10Как будто кто-то мешает хранить "как надо":
?- {X =:= 1/10 + 2/10, Y =:= 15/100 + 15/100, X=Y, Z =:= 2/3 + 1/3}, format('~g\n~g\n~g', [X,Y,Z]).
0.3
0.3
1
или
>>> 0.1 + 0.2 == 0.15 + 0.15, 0.1 + 0.2(False, 0.30000000000000004)
>>> from fractions import Fraction as frac
>>> x,y,z = frac('1/10'), frac('2/10'), frac('15/100') + frac('15/100')
>>> x+y == z, map(float, [x,y,z])(True, [0.1, 0.2, 0.3])
> клоун: ты бы хоть объяснил человеку в чём именно он не прав.Это ты клоун, я не про NaN говорил, а про 0.1 + 0.2 = 0.300000000000000004. Это в любом языке так.
>> Nan =! Nan, а еще вспомнити 0.1 + 0.2 = 0.300000000000000004
> Это особенность арифметики с плавающей запятой, эта арифметика во всех языках одинаковая,
> т.к. в конечном счёте реализуется за счёт аппаратных возможностей процессора.- Вот для этого в нормальных языках есть строгая типизация.
> А я предлагаю переписать ядро Linux на JS, давайте тоже обсуждать.Фабрис Беллард уже сделал. Неплохо обсуждали вроде.
>> А я предлагаю переписать ядро Linux на JS, давайте тоже обсуждать.
> Фабрис Беллард уже сделал. Неплохо обсуждали вроде.Т.е. сделать эмулятор == переписать? Ох уж эти жабоскриптеры.
> Т.е. сделать эмулятор == переписать? Ох уж эти жабоскриптеры.Еще есть такое извращение как emscripten. Но наверное кернел им перегнать утомительно будет.
Больше удивляет, что пациент работает CTO крупной конторы из 100 человек, при этом настолько мимо реальности.
Вот как раз совершенно не удивляет.
Такое сплошь и рядом. Прожекты делать - это не продукт
Отличная новость. Скоро всё перепишут на Rust.
В какой реальности живете? PostgreSQL, kernel linux и прочее как разрабатывали на C, C++ с вставками из asm, так и будут их писать на них же. Такие проекты невозможно переписать на другой язык, затраты в человека*часах и финансовые вливания никто не осилит, да и смысла нет.
> Отличная новость. Скоро всё перепишут на Rust.Не раньше переезда столицы в Нью-Васюки.
>> Отличная новость. Скоро всё перепишут на Rust.
> Не раньше переезда столицы в Нью-Васюки.Значит уже очень скоро.
Почему не на питоне-то?
Начали бы с переписывания ОС под это дело. Потом над ней уже Postgres, а там заодно nginx и php :)Вопрос только - сколько лет каждый из этих шагов займет, кто платит, и кому через столько лет нужен будет полусовместимый по фичам с сегодняшним Postgres некий продукт?
А че так спорите? Пусть пробует, ведь он и единомышленники свои силы и время тратят на это и в итоге возможно получится или наработки будут полезны. PostgeSQL как был и останется, воспринимайте как будто форк PostgreSQL появился :)
ZFS уже начали писать на Rust.
https://github.com/ticki/tfs
> https://github.com/ticki/tfsС нетерпением ждем когда эти мегапрограмеры начнут пользоваться своей ОС, браузером и ФС. Для начала.
Билеты на это шоу уже продают? Я за вами буду.
>> https://github.com/ticki/tfs
> С нетерпением ждем когда эти мегапрограмеры начнут пользоваться своей ОС, браузером и
> ФС. Для начала.О, уважаемый разработчик ядра, btrfs и хрома в придачу в треде? Или очередной болтунишка?
> О, уважаемый разработчик ядра, btrfs и хрома в придачу в треде? Или
> очередной болтунишка?А ты наверное ярый фанат реактоса. В перерывах между фапами на hurd и minix.
>ZFS уже начали писать на Rust.Да чё там ... пусть свой супер браузер на расте сначала покажут, пейсатели :)
> Да чё там ... пусть свой супер браузер на расте сначала покажут, пейсатели :)Достойный конкурент реактосу растет.
Ну вот после окончания проекта и тестов похороникса будет сразу видно внесёт ли раст большую производительность нежели плюсы, в каких случаях и на сколько.
Бгг. Ну удачи. С redox'ом уже обосpались, с servo тоже. Пилите, шура, пилите.> Джоэль Якобсон занимается поддержанием системы электронных платежей Trustly
Чёт я не вижу у него contributions с 2012го года по нынешнее время. Разжирел на поддержке, потерял скилл и повёлся на хайп. Бывает.
> С redox'ом уже обосpалисьНу да, запилили PoC, работающий лучше рек^Hакт ОСи (т.е. на реальном железе, не падая!), но неосилили в одно рыло хоть как-то догнать пингвина - значит обо*рались!
... сжирая гиг памяти только на голое ядро, которому до пингвина - как до пекина раком. Я считаю да - обосpались с присвистом.
> ... сжирая гиг памяти только на голое ядро, которому до пингвина -
> как до пекина раком. Я считаю да - обосpались с присвистом.Так о том и речь, сидеть на сишной системе и софте рассказывая о крутизне раст-о-манов как-то криво, чтоли. Вон Торвальдс за считанные месяцы накидал скелетон которого хватило для работы редактора, выкинул миникс на свалку а дальше у него выбора уже не оставалось и он сделал ЗБС. Как минимум себе. Оказалось что довольно много кому тоже ЗБС и они подключились. А вот эти мегапрограмеры - пишут ОС, браузеры и что там еще сколько там лет. И почему-то это начинает напоминать историю реактоса. Где было 17 лет историй успеха демок на виртуалке и показательных загрузок на 5 минут времени, с разработчиками в максималке и вьюжлстудиях.
> И почему-то это начинает напоминать историю реактоса.
> Где было 17 лет историй успеха демок на
> виртуалке и показательных загрузок на 5 минут времени, с разработчиками в
> максималке и вьюжлстудиях.Мусье в курсе, что эта самая tfs собирается пока что только из под самого редокса? Как-то не тянет на разработку в вижуалстудии и максималочке, да и с 5 минутами времени работы заманаешься перезагружаться.
> Мусье в курсе, что эта самая tfs собирается пока что только из
> под самого редокса? Как-то не тянет на разработку в вижуалстудии и максималочкеНачало уже хорошее. Относительно реактоса. А теперь посмотрим хватит ли разработчиков пользоваться своим редоксом для чего-нибудь практического.
> да и с 5 минутами времени работы заманаешься перезагружаться.
Зато можно позволить себе переписать кернел вот три раза. Объяснив двум предыдущим группам неудачников что они очень хорошо поработали на мусорный бак. В редоксе вроде этот почетный почин подхватили и ядро уже успели переписть, не?
>> ... сжирая гиг памяти только на голое ядро, которому до пингвина -
>> как до пекина раком. Я считаю да - обосpались с присвистом.
> Так о том и речь, сидеть на сишной системе и софте рассказывая
> о крутизне раст-о-манов как-то криво, чтоли. Вон Торвальдс за считанные месяцы
> накидал скелетон которого хватило для работы редактора, выкинул миникс на свалку
> а дальше у него выбора уже не оставалось и он сделал
> ЗБС. Как минимум себе.Да, и теперь вас до скончания времён будут иметь Люди В Погонах через уязвимости в быстром и грязном коде на сишечке. Направление задано.
> которому до пингвина - как до пекина раком.А теперь почитай прикидки, cколько десятков миллионов человекочасов ушло в пингвина и попробуй использовать то, во что ешь, тем более сравнивая теплое с мягким, да еще и микроядерным^W фиолетовым.
> Я считаю да - обосpались с присвистом.
Считальщик в курсе, что пилилась это ось почти в одно рыло? Считальщик уже ходил на тот же http://wiki.osdev.org/Projects, подсчитывал, сколько "фейлов" было на всевозможных языках (да-да, в том числе и сишечке) и делал из этого соответствующие выводы?
> А теперь почитай прикидки, cколько десятков миллионов человекочасов ушло в пингвинаДля того чтобы пингвин стал чем-то юзабельным потребовался один студень и несколько месяцев. Дальше это начало обслуживать нужды студня, как минимум.
И таки да, с этими миллионами часов у студня неслабая такая фора. Миллионы часов туда бахали не потому что это круто, а потому что worksforme для толпени народа, и стало быть в их интересах.
>> Я считаю да - обосpались с присвистом.
> Считальщик в курсе, что пилилась это ось почти в одно рыло?Про присвист был какой-то другой кадр, но если на то пошло, Linux тоже изначально таки был написан торвальдсом в одно рыло. А сотни корпорасов набежали сильно потом. Когда оно делом доказало что работает и обслуживает немало народа. Ну а редокс вот это самое делом пока не доказал вроде. Как и его файлуха. Как мозильский недобраузер. И вот такие фееричные прожекты. Да блин, скорее Маск обоснует поселение на марсе.
> Да блин, скорее Маск обоснует поселение на марсеЭто ты просто в курсе ситуации с языками и не в курсе - с космическими разработками. Над маском те кто в курсе ржут так же, как местные сишники над редоксом.
> Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера.Вот зачем тут это написано?
Избавляет разработчика на _RUST_!Что сделает транслятор, если увидит int *foo = malloc (...)?
> Вот зачем тут это написано?
> Избавляет разработчика на _RUST_!
> Что сделает транслятор, если увидит int *foo = malloc (...)?Избавляет != делает невозможным.
Это все же не жаба или питон. Хотя да, скорее всего будет куча ансейфов, которые придется переписывать.
Ваш КО
Тормозить будет всего лишь в 2 раза, к разработке подключатся масса школьников?(Ну а че, язык же безопасный, предотвращающий ошибки).
Чуть оффтопа. Парни, а можно соединить Лисп и идею шитого кода?
Лично я не против.
Это просто пиар ход. Переписать слона они вряд ли смогут, но лишнее упоминания яп для девочек только подтвердит его репутацию в холиварах. Могли бы переписать что то более простое и массовое, нгинкс, например, тогда у языка бы хоть кейс появился, а пока это сферический конь в вакууме.
Извините за неровный почерк, но жопа в огне!
Что-то мне говорит, "банальный" SQLite будет не так-то просто взять и переписать.
Джоэль Якобсон очень удачно пропиарил свою систему.
Казалось бы, хрень полная, но вброс-то годный оказался.