О бедном Crystal замолвите слово

Ну там мудрые зубы внутри были, один обычный удалил - вылез мудрый. Сдвинулось всё так, что это как замена седьмому работает уже лет 10.

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

Что предстказуемого-то? Предсказуемо чудовищно медленный GC? На Go сотни гигов тестировали, но там есть серьезное отличие — базовые контейнеры реализованы нативно, это один или небольшое количество объектов GC, потому сложность сборки мусора смешная.

А так, для больших данных в том числе питоновые расширения применяют — короче говоря, почти весь мейнстрим, кроме может быть JS (и то не факт) и всяких там PHP прекрасно работают с сотнями ГБ.

Не то что в системе, а у каждого проекта свой virtual environment. При установке пакета с помощью pip он устанавливается в env активированный в данном шелле.

Да, это если ты запустишь пип, который будет ассоциировать себя с этим venv, а не с черт пойми чем. И здесь вылазит наружу прошлое питона в виде башезаменителя, который хочет запускать всех и вся, и при этом запускаться другими как единственная опция, вроде утилит sed или grep, которые обычно не бывают версий 2.7 и 3.5 одновременно на одной машине. Самое смешное то, что в такой роли питон уже давно не выступает, но наследие «архитектурной задумки» (или её отсутствия) осталось.

Что предстказуемого-то? Предсказуемо чудовищно медленный GC?

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

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

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

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

И естественно что никто из обычных заказчиков не вытащит из широких штанин пару ярдов баксов чтобы повторить пусть Sun или IBM.

Отвечать собственной жопой за кластер с 200Гб динамических данных в heap space я готов только с джавой, увы.

Если же у нас небольшой проект, разрабатываемый одиночкой или даже крошечной командой, то нужен более «народный» язык. И тут сейчас выбор небольшой. Вероятно, только си, tcl и FreePascal (или Pascal ABC). И то я не уверен.

Я в упор не могу понять, почему TCL и FreePascal лучше для маленькой команды, чем Питон или JS. Может у тебя какие-то очень свои критерии.

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

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

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

Как правило это уже во вторую очередь, в первую очередь идет наличие готовых решений под задачу. Вот посмотрите на питон: языка толком нет, а готовые решения уже есть. Под ваш лисп нет готовых решений для датамайнинга? Извините, мы предпочтем питон, даже если вы — Пол Грэм (особенно если Пол Грэм).

Если нету дома кластера и нет возможности работать с очень большими данными, то придется доверять готовым решениям от вендоров, у которых все это есть.
Отвечать собственной жопой за кластер с 200Гб динамических данных в heap space я готов только с джавой, увы.

Ты так и не ответил на пример про Go.

И естественно что никто из обычных заказчиков не вытащит из широких штанин пару ярдов баксов чтобы повторить пусть Sun или IBM.

Серверы с 128 ГБ оперативы — это МАССОВЫЙ продукт. Какие еще ядры баксов? Больше оперативы не ставят только потому, что это не ускоряет работу одной программы, кладущей 200 ГБ данных в эту память — привет когерентным кэшам и единственной шине (для одной программы уже нет разницы, будет ли у тебя физически одна шина контроллера памяти или interconnect меж NUMA узлами).

Ты так и не ответил на пример про Go.

Разработка на golang пошла по стандартному пути нищеброда: быстрый запуск и дальше вечная работа в докере или еще каком контейнере.

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

Серверы с 128 ГБ оперативы — это МАССОВЫЙ продукт.

Который затем не менее массово нарезают на контейнеры и см выше про golang.

Я в упор не могу понять, почему TCL и FreePascal лучше для маленькой команды, чем Питон или JS.

Питон или JS сейчас нормально подходят. Но есть определённые тенденции в их развитии, которые могут сделать их ненадёжными инструментами, если проект должен жить долго. Тут два критерия ненадёжности:

1. Большая изменчивость синтаксиса и библиотек.
2. Зависимость от одной корпорации.

Теоретически, TCL и FreePascal по консерватизму близки к си. У Питона же стандартная библиотека даже внутри 3-й версии сильно меняется. JS постепенно может перейти в полную зависимость от Google. Кроме того, у JS узкая область применения. Хотя может я и ошибаюсь - не имел дела с серверным JS и с электроном.

Нужда есть — это необходимость обработки кучи иных событий в браузере.

Да я понимаю. Асинхронность - вещь неплохая. Просто синхронный код при этом выглядит избыточно, например:

loadScript("script1.js").onload = function(){
  loadScript("script2.js").onload = function(){
    mainRoutine();
  }
};  

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

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

Отсюда ясно, что решения плана «200 ГБ данных в памяти» вызваны не необходимостью эффективной утилизации железа, а тем, что по другому просто никак не получится. «Ну где-то хранить» 200 ГБ можно на NVMe накопителях, 5 штук которых имеют пропускную способность как у многопроцессорной NUMA системы между узлами — проблема у них лишь в задержке, которая где-то в 1000 раз выше.

Так что ж получается, у тебя причина и следствие перепутаны?

Более того, я даже не знаю, зачем это делать на жаве

А ты подумай.

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

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

Плюс накладные расходы на обслуживание всего этого цирка.

Горизонтальное масштабирование это гарантированное решение любой проблемы производительности «в лоб».

«Горизонтальное масштабирование», которое на самом деле вертикальное — это возможность проблему не решать. То, что было в статье про Facebook, когда они использовали хранилище со строгой констистентностью так, будто у него бесконечная масштабируемость, а по итогу уткнулись именно в это хранилище и им нужно было увеличить производительность эдак в два раза чтобы еще на два года отложить решение проблемы. Я оценил этот цирк и попытался передать его атмосферу людям далеким от распределенных БД.

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

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

По моим впечатлением этим всё и заканчивается в большинстве случаев — невыносимые тормоза временно сменяются чуть более выносимыми.

Кластеризация и любое горизонтальное масштабирование на самом деле плохо... Можно получить масштабирование а можно и обломаться

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

Эта проблема на самом деле проявляется уже на доступе к дискам, как примитивной модели удаленного неатомарного хранилища, но старперы упорно продолжают игнорировать проблему, отмахиваясь в духе «нам операционная система усё абстрагирует». Когда речь идет про распределенное хранилище на нескольких машинах — та же история «нам СУБД усё абстрагирует».

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

Теоретически, TCL и FreePascal по консерватизму близки к си.

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

У Питона же стандартная библиотека даже внутри 3-й версии сильно меняется.

Да, но нет. Если руки из жопы и доки не читать, то можно завязаться на минорный релиз — на гиттхабе валом примеров от «писателей софта», которым я, наверное, завидую, поскольку не клепаю горы помойных опенсорсных хобби-проектов.

JS постепенно может перейти в полную зависимость от Google.

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

у JS узкая область применения. Хотя может я и ошибаюсь - не имел дела с серверным JS и с электроном.

Современная индус-трия сует JS во все дыры, тут не так давно тусовался девопсо-архитектор, у которого куча сервисов на ноде крутилась.

Асинхронность - вещь неплохая. Просто синхронный код при этом выглядит избыточно
loadScript(«script1.js»).onload = function()

Так уже давно никто не пишет, даже на ноде:

const fs = require('fs').promises;

async function rename(from, to) {
  try {
    await fs.rename(from, to);
    const stats = await fs.stat(to);
    console.log(`stats: ${JSON.stringify(stats)}`);
  } catch (error) {
    console.error('there was an error:', error.message);
  }
}

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

«Горизонтальное масштабирование», которое на самом деле вертикальное — это возможность проблему не решать.

Да, спасибо что заметил. Разумеется я писал про вертикальное.

То, что было в статье про Facebook,

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

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

У меня еще аналогичным образом горил жопа от микросервисников, которые на эту самую консистентную БД полагаются так,

Как думаешь, сколько раз за жизнь я видел микросервисную систему без единой базы данных? Аж целых ноль раз.

SAP HANA сделали для того самого вертиального масштабирования,

Жаль до внедрения в РФ так и не дошло дело, интересная штука.

По моим впечатлением этим всё и заканчивается в большинстве случаев — невыносимые тормоза временно сменяются чуть более выносимыми.

Да, это и есть самое четкое определение вертикального масштабирования )

глобальная консистентность-атомарность крайне дорого стоит.

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

Ничего страшного не случится если потеряется лайк или пост в ленте или затрется выдача для какого-то сайта. Даже для сотни или тысячи.

Это принципиально другой подход к данным - как к чему-то неважному и ненужному. Как к говну вообщем.

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

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

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

SAP HANA сделали для того самого вертиального масштабирования,

Жаль до внедрения в РФ так и не дошло дело, интересная штука.

SAP HANA является далеко не единственной in-memory колоночной СУБД, но среди всех подобных является наиболее упоротой в плане совместимости с неадекватными устаревшими способами работы с данными, вроде людейше сложных join-ов.

Ничего страшного не случится если потеряется лайк или пост в ленте или затрется выдача для какого-то сайта. Даже для сотни или тысячи.

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

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

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

Для современных БД несогласованность данных — это не менее важная информация, чем сами данные: ее передают, ее обрабатывают, ее запоминают. Например, не обязательно выполнять операцию над наиболее актуальной глобально версией данных — достаточно знать, какие куски данных с разных шардов имели какую версию, и далее на основании этой информации можно упорядочивать транзакции на уровне шардов, без необходимости глобального упорядочивания. В наиболее колхозном варианте несогласованность обрабатывается тупо на уровне клиента ad-hoc алгоритмами, уникальными для каждой сущности.

Еще раз, иными словами: для современно распределенной СУБД несогласованность является признаком того, что система работает. Если в ней данные полностью согласовались на нескольких узлах — это значит, что в системе произошел очень крупный сбой. И это разительно контрастирует с ACID, в которой рассогласованность данных, наоборот, является критерием сбоя.

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

А можно пример такого дистра. Я знаю только RHEL7 где так можно сделать (из за scl), а в остальных только python2 и python3.

Или вы про тех деятелей что сами собирают python ?

вроде людейше сложных join-ов.

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

Поэтому их в итоге добавили даже в MongoDB. В ту самую MongoDB которая флагман NoSQL движения и «убийца SQL».

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

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

А помнишь историю на британской почте, где Horizon не мог свести дебет с кредитом и выдавал ложные обвинения в растрате?

Не помню конкретно этот случай, но могу сказать что в РФ ситуация куда лучше в банковской сфере, у нас вообще наверное сейчас банковский софт лучший на планете.

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

История банковского софта в РФ началась сразу с полноценных СУБД с транзакциями и нормальных надежных языков, фактически вначале была связка Delphi - Oracle DB, затем Java - Oracle DB, которая сейчас и остается ключевой.

Никакого легаси на Си, никаких «Job Security» с самопальными «фреймворками» на С++ и никакого COBOL - все это говно обошло стороной, за редкими, очень редкими исключениями.

что есть какие-то там важные данные, которые ходят со строгой согласованностью и атомарностью (аля ACID),

Например те самые финансовые транзакции (сюрприз)

ACID не является адекватным критерием надежности хранилища уже лет так 30

Речь была не про надежность а про саму суть этих данных. Мусору не нужен ACID, мусору не нужна надежность вообще.

Еще раз, иными словами: для современно распределенной СУБД несогласованность является признаком того, что система работает.

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

Поэтому их в итоге добавили даже в MongoDB. В ту самую MongoDB которая флагман NoSQL движения и «убийца SQL».

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

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

Я через интернет-банкинг этим занимаюсь, там по ту сторону вроде как сидит цепной домовёнок и жонглирует байтами.

История банковского софта в РФ началась сразу с полноценных СУБД с транзакциями и нормальных надежных языков
Никакого легаси на Си, никаких «Job Security» с самопальными «фреймворками» на С++ и никакого COBOL - все это говно обошло стороной, за редкими, очень редкими исключениями.

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

что есть какие-то там важные данные, которые ходят со строгой согласованностью и атомарностью (аля ACID),

Например те самые финансовые транзакции (сюрприз)

В распределенном хранилище атомарное одномоментное применение изменений физически НЕВОЗМОЖНО. То есть, либо у тебя вся БД на одном сервере, в лучшем случае с fallback сервером, либо у тебя нет строгой согласованности и атомарности. Потому банковские транзакции, по крайней мере между банками, происходят неатомарно и поэтапно.

Речь была не про надежность а про саму суть этих данных. Мусору не нужен ACID, мусору не нужна надежность вообще.

Это правда, но также правда в том, что в хранилищах без ACID гарантий хранят очень важные данные, потеря которых недопустима. Выше Kogrom отослал к нашей беседе с aist1, который тоже втирал про «начинаем со строго сериализированного хранилища, от него приходим к распределенному» — но это тупик, старт из смирительной рубашки с надеждой когда-то развязать рукава и получить хоть какую-то свободу действий, вроде режима асинхронной записи в постгресе, которая по сути вычеркивает из гарантий букву D (durability).

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

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

Еще раз по тому же тезису: ты так пишешь, будто вся надежность висит на одном только Oracle, и нет больше путей надежно хранить данные. А вот я могу сохранить инфу в таком высокотехнологичном формате, как «текстовый файлик на двух компьютерах» — и получить отказоустойчивое хранилище, которое не сильно отличается по гарантиям от Oracle, по крайней мере для тех данных, которые можно сформировать в виде текстового файлика.

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

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

Условный Оракл да, на практике уже больше Постгрес. Вендор не так важен как само решение - все та же реляционная СУБД.

которое не сильно отличается по гарантиям от Oracle, по крайней мере для тех данных, которые можно сформировать в виде текстового файлика.

Не нужен никому просто файлик, был бы нужен - до сих пор рулили бы MUMPS какие-нибудь.

Оракл создал индустрию реляционных СУБД и определил для них стандарты качества и границы применимости. Получилось далеко не сразу и поверь сами создатели всегда понимали что SQL и реляционная модель это набор компромиссов со своими издержками.

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

Кстати у всех новых решений есть серьезная проблема позиционирования - до сих пор нет 100% понимания необходимости ни «искусственного интеллекта» ни Big Data ни NoSQL для энтерпрайза, те их каждый раз продавливают так или иначе.

А можно пример такого дистра.

У коллеги в Астре был Питон 3.5 (по умолчанию) и 3.7 (можно установить).

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

Кобол и Ада от корпораций и для корпораций. У Кобола ещё и узкое применение, насколько я знаю. Слово «корпорация» говорю для пафоса. Подразумеваю любую крупнаю компанию и даже гос. организацию.

Кроме того, не могу вспомнить опенсорсного проекта на этих языках. На фри паскале полно.

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

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

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

Условный Оракл да, на практике уже больше Постгрес. Вендор не так важен как само решение - все та же реляционная СУБД.

Реляционная СУБД с массивами и JSON в полях? Отличные истории. На самом деле эти СУБД давно стали подобием C++ от мира БД: «мы засунем туда всё на свете, а там дальше уже сами решайте, что из этого вам нужно». Даже полнотекстовый поиск засунули, хотя, казалось бы, полнотекстовый поиск — это во-первых key-value фундамент, а во-вторых записей в индексе бесконечно больше, чем этих самых записей key-value, то есть, это БД состоящая из одних индексов.

Не нужен никому просто файлик, был бы нужен - до сих пор рулили бы MUMPS какие-нибудь.

Почему ты считаешь, что построенная на хранимых процедурах БД оракла — это не аналог MUMPS? Да, это не текстовые файлики, тут соглашусь.

Оракл создал индустрию реляционных СУБД и определил для них стандарты качества и границы применимости. Получилось далеко не сразу и поверь сами создатели всегда понимали что SQL и реляционная модель это набор компромиссов со своими издержками.

Стандарт ANSI SQL писался под IBM DB2, там не было ни слова про снимки — «стандарты качества и границы применимости» говоришь? В частности, ни один из уровней изоляции ANSI SQL не имеет смысла для MVCC СУБД (read uncommitted и serializable просто не применяются, а то, что применяется, в ANSI SQL не описано).

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

Опять телега впереди лошади. Oracle делал универсальное решение, которое можно было бы продавать большинству компаний на планете. И таки сделал. Ну, или хотя бы продал. Причем, еще постарался закатать в асфальт тот же InnoDB, и таки довольно сильно тормознул его развитие, но в конце-концов и его заменили на XtraDB.

Кстати у всех новых решений есть серьезная проблема позиционирования - до сих пор нет 100% понимания необходимости ни «искусственного интеллекта» ни Big Data ни NoSQL для энтерпрайза, те их каждый раз продавливают так или иначе.

С маркетингом у альтернатив действительно сложно, правда, это не относится к техническим особенностям работы с ИИ, Big Data, или NoSQL.

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

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

Кобол и Ада от корпораций и для корпораций. У Кобола ещё и узкое применение, насколько я знаю.

Это всратые by-design языки, под которые батарейки есть только для банковских и военных нужд соответственно. Как и в случае с питоном — ЯП несостоятелен, но играет минимальную роль.

Кроме того, не могу вспомнить опенсорсного проекта на этих языках. На фри паскале полно.

Я не знаю ни одного полезного массового проекта на FreePascal. Кроме самого Lazarus, который IDE для разработки на этом ненужном языке.

ActionScript3, например, тоже не подходит, хоть и хороший язык

Очередной клон жавы, что в нем хорошего?

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

JS ­— язык без дизайна, но его современное подмножество настолько простое, что это само по себе является преимуществом — ты можешь натягивать язык на любую задачу, в которой прокатит асинхронная однопоточная обработка (средства многопоточной разработки для node.js несостоятельны).

Глянул ну ок.

Вообще это по неграмотности там по альтернативе переключается на какой то 1 (python3), а вообще если знать Python то 3ка переваливается на 3.6 из за анотаций … ну и ладно.

Как путаться в этом не совсем понятно так как вызов идет или python3.5 или python3.7

P.S. Это загон Убубнты, в Дебиане такого нет.

Это всратые by-design языки, под которые батарейки есть только для банковских и военных нужд соответственно. Как и в случае с питоном — ЯП несостоятелен, но играет минимальную роль.

JS ­— язык без дизайна

Да назови ты уже хорошие языки. На чем надо писать? Что использовать?

назови ты уже хорошие языки. На чем надо писать? Что использовать?

’Cause I’m PHP, I’m dynamite
PHP, and I’ll win the fight
PHP, I’m a power load
PHP, watch me explode!

На самом деле эти СУБД давно стали подобием C++ от мира БД: «мы засунем туда всё на свете, а там дальше уже сами решайте, что из этого вам нужно».

Не «все на свете» а то что требуют пользователи для решения их рабочих задач. Это же коммерческий софт, который продается за деньги. Wayland и скинов там например нет и не будет.

Даже полнотекстовый поиск засунули,

Чем ближе к данным тем лучше. Вспоминай встроенные в СУБД индексы каждый раз когда тебе надо сделать SELECT * из базы и запихать в какой-нибудь Elasticsearch, передавая данные по сети.

Причем, еще постарался закатать в асфальт тот же InnoDB, и таки довольно сильно тормознул его развитие, но в конце-концов и его заменили на XtraDB.

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

Но лично я думаю что покупка MySQL была ради создания внутренней конкуренции между разными командами разработки - основной продукт Oracle DMBS в какой-то момент сильно «завшивел», шли постоянные жалобы на качество. Видимо думали что параллельная разработка другой СУБД внутри компании отрезвит основных разработчиков.

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

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

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

Еще законы маркетинга никто не отменял: товар должен быть привлекательным чтобы его купили.

Да назови ты уже хорошие языки. На чем надо писать? Что использовать?

Пишут и используют сейчас уже не языки а наборы технологий. Знание языка «петон» в совершенстве тебе мало поможет в разработке на какой-нибудь django.

Поэтому все эти философские споры о том чей синтаксис круче к реальной работе отношения не имеют.

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

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

Чем ближе к данным тем лучше. Вспоминай встроенные в СУБД индексы каждый раз когда тебе надо сделать SELECT * из базы и запихать в какой-нибудь Elasticsearch, передавая данные по сети.

Ты поаккуратнее, а то глазом не успеешь моргнуть, как станешь фанатом Berkley DB.

основной продукт Oracle DMBS в какой-то момент сильно «завшивел», шли постоянные жалобы на качество. Видимо думали что параллельная разработка другой СУБД внутри компании отрезвит основных разработчиков.

Я не заметил, чтобы он «развшивел» с тех пор. Зато я заметил, что MySQL скатился в полное говно настолько, что его пришлось форкать, и то же случилось с InnoDB->XtraDB. Потому лично мне очевидно, что они выкупили и уничтожили конкурента. Причем, если бы у них получилось то же провернуть с постгрессом, то результат был бы волшебным.

Помимо технической стороны есть еще стороны. Ты же не покупаешь машину в разборе или ориентируясь исключительно на мощь двигателя?
у продукта есть качество, которое не заканчивается только на технических характеристиках. Важно ведь и сопровождение: техподдержка, документация, обучение в конце концов.

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

Еще законы маркетинга никто не отменял: товар должен быть привлекательным чтобы его купили.

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

Я не заметил, чтобы он «развшивел» с тех пор.

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

Зато я заметил, что MySQL скатился в полное говно настолько, что его пришлось форкать,

MariaDb появилась чуть ли не на следующий день после новостей о покупке MySQL Ораклом. Так что скатывание это уже последствия а не причина.

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

За исключением IBM и наверное Microsoft которые окружили себя «партнерами-прокладками» и не работают с конечными клиентами напрямую, все остальные B2B-компании со своими продуктами как раз стараются сами обеспечивать и качество и обучение. Так что это общий подход, не исключение.

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

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

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

Да, я из вторых рук знаю. Когда не так давно я лично захотел прикоснуться к этому чуду, то даже не смог запустить сервер. По рассказам там legacy уложено в сотню этажей, и таки да, просто запустить сервер — на самом деле не просто, а тайна ее администрирования передается из поколения в поколение.

MariaDb появилась чуть ли не на следующий день после новостей о покупке MySQL Ораклом. Так что скатывание это уже последствия а не причина.

Да, причем, люди правильно расчитали последствия приобретения.

За исключением IBM и наверное Microsoft которые окружили себя «партнерами-прокладками» и не работают с конечными клиентами напрямую, все остальные B2B-компании со своими продуктами как раз стараются сами обеспечивать и качество и обучение.

Зачем далеко ходить — ­возьми 1С. Некая компания может быть единственной, обеспечивающей поддержку своих продуктов, если кроме нее этим в принципе никто не может заниматься, например, из-за отсутствия соответствующей документации — фактически вендор лок.

Альтернатива может быть разве что если производитель совсем не предоставляет услуги, но эти услуги востребованы. Например, сименс не ремонтирует поломанные узлы, а только заменяет их целиком — есть знакомые моих знакомых, которые занимаются ремонтом оборудования сименс. Или MS перестал выпускать обновления для старой версии винды — возникли люди, которые бэкпортируют бинарные патчи.

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

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

Да назови ты уже хорошие языки. На чем надо писать? Что использовать?

Среди массовых я хороших не знаю. Я имею в виду ЯП+стандартная библиотека. Есть лишь плохие и совершенно омерзительные. Хорошие ЯП были в разных стадиях производства, но так или иначе не были приняты индустрией, а без массовости не будет готовых решений и конечному потребителю не важно, что там «могло бы быть». Каноничный пример — MS Office, который сожрал более адекватные альтернативы. Оно бы и дальше жрало всех по направлению автоматизации бизнеса через VBA, но внезапно сдохло.

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

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

Зачем далеко ходить — ­возьми 1С.

Ну нет, 1С как раз с самого начала выстраивал партнерскую сеть франчайзы и долгие годы учил их всех. Редкий пример действительно большого корпоративного софта.

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

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

Среди массовых я хороших не знаю. Я имею в виду ЯП+стандартная библиотека. Есть лишь плохие и совершенно омерзительные. Хорошие ЯП были в разных стадиях производства, но так или иначе не были приняты индустрией, а без массовости не будет готовых решений и конечному потребителю не важно, что там «могло бы быть»

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

их всех колбасит от «мне все должны» и «падите ниц, грязное быдло» и до «я бедный и убогий, зато умный».

Какое мне дело до «всех». Вот всех пусть и колбасит, а ты со мной общаешься.

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

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

хороший язык

паскаль

И чего в нём такого хорошего и особенного? Кроме nil, который, очевидно, отсылка к благодати лиспа.

Обычный императивный PLOP-язык, каких сотни.

Обычный императивный PLOP-язык, каких сотни.

Сейчас? Да. Другое дело, что статически компилируемые ЯП без сборщика мусора доросли до вложенных функций где-то так к нулевым годам, где-то к 90-м годам до строк с хранением их длины, опять же в начале-середине 90-х в Java реализовалась идея машинонезависимой VM, которая была в паскаля уже в середине 70-х. То есть, паскаль опередил индустрию примерно на 20 лет. По скорости компиляции в машинные коды его подвиг смог повторить только Zig (2016). Да, спустя 50 лет можно смеяться над его отсталостью, но, пардон, прошло 50 лет, язык слабо развивался, его передовые на тот момент фичи со временем были скопированы в другие ЯП и стандартные библиотеки, сам же язык скатился в говно тупым копированием худших фич C++.

А еще я до сих пор офигеваю с того факта, что индустрия на полном серьезе использует знак равенства в роли оператора присвоения.

я-то в советское время ууу

А, так ты айтишный аналог капитана Гаттераса — наяриваешь на первенство. Ну это нормально, каждый наяривает на что хочет; с другой стороны, его судьба должна настораживать последователей.

Но чем Паскаль сегодня-то хорош? Какие у него практические преимущества?

я до сих пор офигеваю с того факта, что индустрия на полном серьезе использует знак равенства в роли оператора присвоения

А я офигеваю с того факта, что индустрия на полном серьёзе вообще использует неконтролируемое присваивание. Мы не одинаковые %)

А, так ты айтишный аналог капитана Гаттераса — наяриваешь на первенство

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

Но чем Паскаль сегодня-то хорош? Какие у него практические преимущества?

«Сегодня» паскаль просто устарел, я это уже написал.

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

Что такое «неконтролируемые присваивания»?

«Сегодня» паскаль просто устарел

Единственный был хороший язык, и тот устарел. Какая жаль. А из современных-то, из современных какой хороший?

Что такое «неконтролируемые присваивания»?

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

Ближе всего был паскаль.

Неожиданно для себя соглашусь с тобой.

разве golang не вернул пиши-компиляй-сообществу прелесть «мгновенной» сборки со своим выкотом?

чё zig реально быстрее быстрого собирает. прям быстрей golang’а?

https://www.youtube.com/@contextfree/videos

Какое мне дело до «всех».

Ходи тогда голым как Хармс. Или прибей себя за мошонку к Красной площади, чего мелочиться.

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

Ближе всего был паскаль.

Серьезно? Наезжать на ООП и классы и считать иделалом процедурный устаревший язык?

Ладно, я давно хотел написать по Free Pascal обзорную статью, видел что есть под него некое подобие RESTful стека и можно попробовать написать типичный современный вебсервис.

Будет иллюстрированное описание с картинками на тему почему паскаль вам не поможет.

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

Это не так работает. Есть общество, есть реальный сектор, который это общество кормит и обслуживает: банки, производство, телеком - вот это все. И есть ИТ, которое само по-себе ничего не производит а лишь обслуживает другие отрасли.

Если для обслуживания интересов «вечного ребенка» жителя крупного мегаполиса надо изобрести вебсокеты и протоколы стиминга - их изобретут.

Но менеджеры крупных корпораций тут лишь посредники.

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

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

Жаба с гадюкой петоном в этом смысле олицетворяют собой прогресс, тащат его на себе. Однажды го, питон и жаба везти с поклажей воз взялись… (тм) это мы вычеркнем.

А паскаль? Не то чтобы. Редкая птица по нынешним временам.

golang какой то странный. (То что нет классов это понятно его +, и все другое подобное).

Но я например ни как не могу на нем собрать прогу с динамической линковкой. Да и скорость работы у него какая то подозрительная … (может это виноват встроенный сборщик мусора или хз еще что)

Единственный был хороший язык, и тот устарел. Какая жаль. А из современных-то, из современных какой хороший?

Ты предлагаешь мне поискать наименее говеный из современных? Ну давай пусть будут Go (в своих узких нишах), Clojure без Java, Rust до эффективных манагеров.

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

Как я понимаю, ты это пишешь к намеку на многопоточность/асинхронность. У меня более фундаментальная позиция: современная доминирующая модель машины тьюринга со строго пошаговым выполнением и бесплатным атомарным состоянием делает недопустимо ненадежными или бесполезными любые попытки многопоточности-многозадачности даже несмотря на всякие Arc<AtomicUsize> и Mutex<T>, Sync и Send.

Для решения проблемы нужны новые методики, заменяющие глобально детерминированное состояние машины тюринга на локально детерминированное, которое при помощи описания причинно-следственных связей оперирует глобально недетерминированным состоянием (простейший пример — map-filter-reduce), а также поддержка событий, которую вроде как пытаются делать каналами в Go, но это лишь робкий маленький шажочек от мейнстрима, который говорит, что в машине Тьюринга событий не бывает, все реакции происходят явным опросом детерминированного глобального состояния.

На самом деле в ИИ уже в значительной степени применяются оба метода, но они там применяются в неумелом подражании живым организмам, а не в попытке реализовать алгоритм с предсказуемым результатом. Ну типа никому не нужна БД на нейросетях, которая может быть запомнит записанную в нее инфу — именно потому нейросетки допустимо применять только там, где результат ее работы не важен (вроде ChatGPT).