Rust 1.6

А вы как думали, в сказку попали?

Конечно нет, ведь ради цепепе нужно положить много своих драгоценных нерв :-) Вот, например, можно взглянуть это http://www.youtube.com/watch?v=Puio5dly9N8 :-) Как-то беспокойно там :-) Видно, не до сказок :-)

ААА! Прекрати! Что ты делаешь!

Я нашел твою абстрактную фабрику кластеров метапарадигм!

Конечно нет, ведь ради цепепе нужно положить много своих драгоценных нерв

Я тя умоляю! Ну зачем такие жертвы? Не трогай С++. Если хочешь язык чисто для души и чтобы системненько, то пиши на Rust. Хочешь своё творчество показывать на выставке математических шедевров, пиши на Haskell. Хочешь, чтобы и батарейки были, и чтобы не марганальщина, пиши на Scala. Тут тебе и энтерпрайз с Java под капотом, и денюжку хорошую платят, и глаза не красные, и девочки любят.

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

А С++, он для суровых мазохистов

И на троллинг не поведутся, гады

Вот троллинг получше: mpm покидает проект.

А С++, он для суровых мазохистов

Городские легенды. Да, сейчас за С++ меньше платят, чем за Java/Scala. Причем заметно меньше в пересчете на необходимую квалификацию. Но, С++14 != С++. Парадигма уже сильно другая. А С++17 будет вообще няшечкой.

Ниша С++ — это хранение и тяжеловесная обработка больших массивов данных. Коих будет становиться всё больше и больше, и обработка всё сложнее и сложнее. И библиотеки такие есть в разработке.

Вот есть такой язык R, который внезапно из никому не известного инструмента штатного статистика стал основным инстументом в data science. Язык ужасный, но за него очень хорошо платят. А потому его учат. С Python сравнивают, сильные стороны находят, на курсы записываются.

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

А С++, он для унылых программистов, которые знают, что хотят трудностей :-) Вот как надо говорить :-)

Вот троллинг получше: mpm покидает проект.

Где и когда он об этом заявил?

Парадигма уже сильно другая.

Стоп :-) Какая именно, ведь цепепе же мульти-парадигменный язык программирования :-)

А С++17 будет вообще няшечкой.

А стандарт уже будет 1300 + 500 = 1800 страниц? :-)

Ниша С++ — это хранение и тяжеловесная обработка больших массивов данных. Коих будет становиться всё больше и больше, и обработка всё сложнее и сложнее. И библиотеки такие есть в разработке.

Ого! :-) Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++ :-)

Вот есть такой язык R, который внезапно из никому не известного инструмента штатного статистика стал основным инстументом в data science.

В R нет маразматической системы типов, которая выкручивает руки :-) (Цепепешники любят термит «компилятор бьёт по рукам» и думают, что это круто.) :-) Поэтому он и пользуется популярностью как простой и полезный инструмент, который помогает делать что-то полезное, а не строчить концепты с шаблонами, с трэйтсами и перегрузками операторов >> << :-)

Язык ужасный, но за него очень хорошо платят. А потому его учат.

Печально, что приходится учить ужасные языки ради бабла :-)

А С++, он для унылых программистов, которые знают, что хотят трудностей :-) Вот как надо говорить :-)

Не трудностей, а хорошего результата. Без трудностей этого не бывает. Нет идеальных языков.

https://www.mercurial-scm.org/wiki/mpm/transition

Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++

Они в курсе, и сами про это периодически пишут. А большинство СУБДшников вовсе не связывается ни со скобками 60-х, ни с недоассемблерами 70-х.

Стоп :-) Какая именно, ведь цепепе же мульти-парадигменный язык программирования :-)

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

А стандарт уже будет 1300 + 500 = 1800 страниц? :-)

Может и больше даже. И что? Прикладным программистам он весь — не нужен. Он весь нужен только разработчикам компиляторов.

Ого! :-) Срочно пиши хакерам PostgreSQL, чтобы переводили Postgres с C на C++ :-)

А ты внутренности PostgreSQL видел? Знаешь, какие там внутренние структуры данных? Там метапрограммирование бы очень сильно всё упростило. А обобщение структур данных позволило бы расширять систему гораздо меньшими усилиями. Но никто ничего переписывать не будет, проще написать новый Посгрес. И они пишутся. Тяжелая Big Data переезжает на С++. А та, что остается в Java, бежит из heap в offheap.

Печально, что приходится учить ужасные языки ради бабла :-)

Такая суровая жизнь, я тебя понимаю)

Жаль. Ну, я надеюсь, вместо Мэтта будет коллективный Мэтт.

здорово упростившееся метапрограммирование позволит его применять гораздо чаще, чем раньше. А это качественно изменит облик самих программ.
Может и больше даже. И что? Прикладным программистам он весь — не нужен. Он весь нужен только разработчикам компиляторов.

Т.е. метапрограммировать в цепепе-14 можно чаще, но учить для этого «упростившееся метапрограммирование» по стандарту не нужно :-) Гг :-)

Тяжелая Big Data переезжает на С++.

Покажи хоть одну СУБД на C++, которая хоть как-нибудь себя хорошо зарекомендовала среди просто люда? :-) Ну есть, например, SciDb. Но кто её использует? :-)

Покажи хоть одну СУБД на C++, которая хоть как-нибудь себя хорошо зарекомендовала

Шутите что ли? Первые две вспомнившиеся.

https://www.rethinkdb.com/

https://www.mongodb.org

+ Oracle, MySQL, MSSQL (источник)

+ Couchbase

https://www.rethinkdb.com/

Это новинка :-) Где данные об использовании по ней? :-) Кстати, если кто не знал, вот что однажды сказал её со-основатель: «We don't use Lisp, but much of our software is built on ideas borrowed from Lisp. We don't use it because we needed low level control — most of the code is written in C++, even with some bits of assembly. But we've borrowed an enormous number of ideas from Lisp. In fact, if we weren't Lispers, we would have built a very different (and I think significantly more inferior) product.» отсюда

https://www.mongodb.org

Ок :-) Но в PostgreSQL есть jsonb :-)

We don't use it because we needed low level control

Нормальное решение для осей с сишным интерфейсом и рантаймом. Если бы была лиспоось, писали бы на лиспе для «we needed low level control».

Нормальное решение для осей с сишным интерфейсом и рантаймом. Если бы была лиспоось, писали бы на лиспе для «we needed low level control».

Но суть то «But we've borrowed an enormous number of ideas from Lisp. In fact, if we weren't Lispers, we would have built a very different (and I think significantly more inferior) product.» :-)

большинство СУБДшников вовсе не связывается ни со скобками 60-х, ни с недоассемблерами 70-х

А какая разница на чем реализована СУБД? Аналитику ты пишешь всяко на SQL+расширения. Дергать запросы и хранимки можно хоть из перла. Вообще не вижу каким боком тут C++. Или суровый программист сначала реализует свою СУБД, и без этого бигдата не считается?

Тут возникло некоторое непонимание. Я говорил о том, что аналитика больших данных переходит на С++. Прозвучало название PostgreSQL, и я сказал, что ему тоже будет полезен переход на С++. И дальше мы заговорили за СУБД. Тут мне надо пояснить, чтобы все понимали, о чем мы говорим.

В базах данных есть два больших направления — это OLTP и аналитика. Направления очень различных. И, хотя на выходе один и тот же SQL/JDBC, пот капотом используются совсем разные решения. Например, построчное хранение в OLTP и поколоночное в аналитике. Динамичные структуры данных в OLTP и статичные в аналитике и т.д.

Далее. Были несколько периодов развития баз данных, на каждом из которых возможности аппаратных средств определяли программную архитектуру. То, что мы называем традиционными СУБД, а это MySQL, PostgreSQL, MSSQL, Oracle, DB2 и т.д. — это всё решения, которые возникли и развились тогда, когда БД была надстройкой над медленным диском, поэтому подсистема ввода-вывода решала всё. В этом случае не так уж важно, с какой скоростью обрабатывается отдельный элемент данных, если потом мы ждем следующую страницу индекса с диска «целую вечность». Поэтому интерпретируемый SQL рулил. Поэтому Java-middleware взлетело.

Но ситуация изменилась. Во-первых, оперативной памяти стало достаточно много, чтобы датасеты помещались в ней целиком и сразу существующая архитектура стала поперек горла. Сначала стали отказываться от SQL-надстройки, а затем, под горячую руку, и от транзакций. Появились высокоскоростные in-memory БД, в которых скорость обработки данных в памяти уже имеет решающее значение. И SQL стал компилируемым: так делают MemSQL и Apache Spark. Но вылезла другая проблема...

Сейчас ввод-вывод больше не является узким местом. SSD-шки успешно штурмуют второй GBps. Датацентры дают 10Gbps сетку и пичкают машины SSD-шками. Народ, работающий со Spark/Hadoop внезапно обнаружил, что узким местом стала сериализация данных при переходе от диска к памяти и обратно. Когда данные представлены в виде объектов на куче (а как же еще?), сериализацию невозможно сделать достаточно быстрой, чтобы использовать все возможности современного IO. Но это еще не вся беда...

Сейчас быстрой памяти относительно много. На сервера ставят 256GB и более. 512 не редкость, да и конфигурации с 1TB уже не экзотика. А за этим терабайтом памяти стоит SSD-массив на 10-100TB. Классические кучи на таких объемах становятся катастрофически медленными. Как оказалось, классическая куча для объектов на основе ссылок оказалась немасштабируемой абстракцией. И, если дизайн языка прибит гвоздями к куче, как это сделано в Java, Haskell и OCaml, при переходе к ручному управлению памятью мы теряем все «батарейки». Такой язык нам больше ничего не может предложить. Тут нужен язык, в котором абстракции памяти являются гражданами первого класса. Это С++, Rust и D.

СУБД, которые адресуют эту проблему, называют себя NewSQL. Они хотят соединить OLTP и аналитику в рамках одного решения и сразу создаются с учетом возможности работы в большой памяти и распределенном режиме (предполагающем интенсивный IO). PostgreSQL, при всем моем уважении к нему, в текущем виде на этот поезд не вспрыгнет. MongoDB совсем не в этой категории, как и RethinkDB. Последнюю можно было бы смело писать на лиспе, как и сделал автор Datomic.

Прозвучало название PostgreSQL, и я сказал, что ему тоже будет полезен переход на С++.
Тут нужен язык, в котором абстракции памяти являются гражданами первого класса.

Так это же чистый C, а не

С++, Rust и D.

:-)

Так это же чистый C, а не

Смотри сюда, и далее по треду.

Смотри сюда, и далее по треду.

Спасибо, посмотрел :-) Но ведь там речь идёт о метапрограммировании, а здесь - об абстракциях памяти, являющихся first class citizens :-) Указатели в C - это как раз они :-) Или при помощи метапрограммирования можно и без них теперь обойтись? :-)

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

Так это же чистый C, а не

А, я не сразу распарсил. Извини. Да, чистый С дает прямой доступ к памяти. Но никаких батареек в виде возможности делать типизированные раскладки данных по памяти. Т.е. всё ручками, ручками. Компилятор не будет инлайнить код, нельзя делать специфичные для типов специализации. Не, конечно, можно придумать продвинутый DSL над C специально для таких дело. Но зачем, если можно просто писать на С++ как на С только с шаблонами и пространствами имен?

MongoDB совсем не в этой категории, как и RethinkDB.

А кто «совсем в этой»?

Но ведь там речь идёт о метапрограммировании, а здесь - об абстракциях памяти, являющихся first class citizens :-) Указатели в C - это как раз они :-)

Чтобы было понятней, на примере:

template <typename T>
stuct Container {
    T value_; // Как значение, а не где-то там в куче

    void doDomething() {
        //Этот код уже знает, какой у value_ тип
        //и как с ним работать оптимально 
    }
}

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

Но зачем, если можно просто писать на С++ как на С только с шаблонами и пространствами имен?

Вот, это уже ближе к теме :-) Пространства имён - это ни разу не проблема для тех, кто не знает правила Кёнинга и не пытается играть в перегрузку и обобщённые шаблоны функций :-) От того, что ф-я будет называться my_namespace_my_function() или My_namespace::my_function() никому из практиков ни жарко, ни холодно :-) Ну а после ужоса от беглого прочтения Boost.Hana мне очень трудно поверить, что кто-то в команде Постргеса решится использовать такие вот техники метапрограммирования :-) Разработчику, по-мимо того, чтоб выучить концепты ручного управления памятью, теорию БД, ещё нужно будет овладеть выносящими мозг техниками метапрограммирования на цепепе, как и самим цепепе :-) Кто на это пойдёт? :-)

А кто «совсем в этой»?

Ну вот здесь есть небольшой список. Характерный признак — это ориентация на работу в оперативной памяти и большой спектр поддерживаемых структур данных/индексов и т.п. Т.е. документ-ориентированные БД, а так же всякие K/V-хранилища сюда не попадают, даже если запускаются на машине с большой памятью. Дизайн не тот.

Чтобы предупредить PostgreSQL, который в эту категорию, как может показаться, так и просится. PostgreSQL — это старое клиент-серверное ориентированное на диск решение, которое волею разработчиков накопило богатый набор батареек под капотом. И их, этих батареек, хватит еще лет на 10, если начать тягаться с NewSQL, как постгресмены успешно пытаются делать. Т.е. можно туда прикрутить и большие объемы памяти, и более-менее дружелюбыне к сериализации аллокаторы для промежуточных данных. Много чего можно и делается. Но рано или поздно момент относительно СУБД на С++/Rust будет потерян, так как будет очень много ручной работы по разработке и сопровождению новых стрруктур данных, необходымих для AI и аналитики. По мне, так лет через 10 максимум.

Кто на это пойдёт

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

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

Т.е. ты хочешь сказать, что в скором времени PostgreSQL может сдать позиции какому-то решению, которое будет на C++, в котором будут тонны метапрограмм, если не перейдут на C++/Rust/D? :-)

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

декларативно за счет метапрограммирования, переопределив стратегии

Декларативно? На цепепе? Ты ничего не путаешь? :-) Не мог бы ты показать, как это делается? :-) Про паттерн «Стратегия» я в курсе, но это не декларативно, это называется «использование аргумента шаблона для выбора алгоритма» :-)

Ну вот здесь есть небольшой список.

Можешь сразу отсеять проприетарщину, раз ты в теме? Тогда оставшееся посмотрим и сравним с постгресом. Есть все основания считать, что 10 лет этим новинкам только в догонялки играть. И то, раньше они завязнут в клубке метапрограмм и зафейлятся. Я вообще не верю в успех большого распределенного опен-сорс проекта на C++. Даже мозилла вон не осиливает. Для C++ нужны крутые архитекторы и суровые сеньоры с плетками. Теперь это ещё более актуально с лавиной новых фич (в комплекте со старыми граблями).

Про паттерн «Стратегия» я в курсе, но это не декларативно, это называется «использование аргумента шаблона для выбора алгоритма» :-)

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

Но рано или поздно момент относительно СУБД на С++/Rust будет потерян

Можно пример СУБД на Rust? Пусть даже совсем игрушечной.

Система типов С++ полна по Тьюрингу

Это и есть декларативное программирование.

А генерации строчки текста в компайл-тайме так и нет, лол.

А генерации строчки текста в компайл-тайме так и нет, лол.

Список статически-типизированных языков, в которых это возможно, предоставите?

Я вообще не верю в успех большого распределенного опен-сорс проекта на C++. Даже мозилла вон не осиливает.

Да, блин, какая-то альтернативная реальность... Если для вас Mozilla, Chromium и KDE — это не успех, то что тогда успех и что тогда неудача?

Система типов С++ полна по Тьюрингу

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

Можешь сразу отсеять проприетарщину, раз ты в теме?

Я бы не стал ничего отсеивать. То, что сейчас есть проприетарщина, может завтра исчезнуть вообще с горизонта, как это произошло с FoundationDB, которую купил Apple, и — с концами. Сообщество просто кинули. А еще проприетарщена может быть отпущена под пермиссивной лицензией, если инвесторы решат, что пора «убивать» конкуррентов. В людбом случае в этой области (oltp + аналитика) за последний десяток+ лет не появилось ни одного проприетарного решения, которое смогло бы захватить значительную нишу. Многое новое в итоге опенсорсится, потому что индустрия переходит от модели владения (большим) кодом к модели владения (большими) данными.

Насчет 10 лет и новинок, это, действительно, спорно. Дело в том, что батарейки С++ сейчас в массе своей используется ограниченно, как С с классами и чуть-чуть шаблонов. Можно почитать стайлгайд Google для примера или залянуть во внутренности того же RethinkDB. Тут анонмусы надо мною посмеиваются на тему метапрограммирования и, в какой-то мере они правы. Это всё еще экзотика и людям не в теме совсем не понятно, а выстрелит ли оно. Т.е. пока еще Постгресу ничего реально не угрожает, но ситуация может измениться радикально и в один день. Как с ИИ было, когда еще всера это был удел фриков, а сегодня уже все кому ни лень его успешно делают.

Я вообще не верю в успех большого распределенного опен-сорс проекта на C++... Для C++ нужны крутые архитекторы и суровые сеньоры с плетками.

Здесь ты совершенно прав, это — Проблема. Но ведь нам не обязательно делать весь проект на С++. На нем будут только storage и самый тяжелый processing. А всё остальное будет вынесено на Scala/Python/по вкусу, где ему самое место. Кроме того, стали востребованы языки на базе продукций и вероятностные языки, потому что возникновение событий в кластере — это очень нелинейный, и, к тому же еще и вероятностный процесс (ошибки). С++ тут ника не поможет от слова вообще.

«Дата-платформа моей мечты» сейчас выглядит примерно как набор сервисов, реализованных поверх Apache Mesos/Helix/Docker. Ну и, в общем-то, вся индустрия сейчас движется именно в этом направлении.

А генерации строчки текста в компайл-тайме так и нет, лол.

Ну не так уж и нет. Непривычно и не так удобно. Но есть.

Да, блин, какая-то альтернативная реальность... Если для вас Mozilla, Chromium и KDE — это не успех, то что тогда успех и что тогда неудача?

Ну и? Мозилла - корпорация с унаследованным проприетарным кодом, которая вот-вот зафейлится, и вообще давно хочет от С++ убежать. Хромиум - продукт корпорации. KDE - это фейл. Третий раз уже его переписывают чуть не с нуля, с каждой итерацией это всё более монструозный и забагованный продукт, от которого бегут и пользователи, и разработчики. Ещё примеры?

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

Совершенно верно. Есть даже специальный термин для этого — трясина Тьюринга (Turing tar pit). Когда язык хоть и формально полон по тьюрингу, но совершенно непригоден для использования человеком. Шаблоны С++03 как раз из этой оперы, к сожалению. С++14 уже няшечка и, в целом, с Hana они уже перестают быть трясиной. Хотя до зависимыхх типов им еще очень далеко, но уже можно юзать.

которая вот-вот зафейлится
KDE - это фейл

Очередной неадекват.

А ты адекват? Не замечаешь проблемы мозиллы и откуда ноги растут у нашего срача? Может ты ещё и кедофан? Чё там, плазма не падает, потерь нет?

KDE

Понимаешь, если база данных (БД — это «наше всё») будет работать так же, как Firefox или KDE, то мы все умрем. А кто таки выживет, те позавидуют мертвым.

Не замечаешь проблемы мозиллы

И какие же у Mozilla проблемы? Неужели финансовые?

и откуда ноги растут у нашего срача?

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

Может ты ещё и кедофан?

Нет. Но точно знаю, что вы никогда не поднимите проект масштаба KDE. В любом качестве.