LINUX.ORG.RU

Rust 1.6

 ,


2

3

Команда разработчиков Rust рада представить первый в этом году релиз Rust — 1.6. Rust — это системный язык программирования, при разработке которого внимание сосредоточено на безопасности, скорости и параллелизме. Как обычно, вы можете установить Rust 1.6 с соответствующей страницы на официальном сайте, а также посмотреть примечания к выпуску на GitHub. Выпуск включает в себя около 1100 патчей и содержит ряд небольших улучшений, одно важное изменение, а также изменение на Crates.io.

Стабилизация libcore

Самым большим нововведением в 1.6 является стабилизация libcore. Стандартная библиотека Rust состоит из двух уровней: небольшая базовая библиотека libcore и полная стандартная библиотека libstd, которая построена на основе libcore. libcore является полностью платформонезависимой, и требует только горстку внешних функций. libstd строится на основе libcore, добавляя поддержку выделения памяти, операций ввода-вывода и параллелизма. При использовании Rust во встраиваемых средах и при написании операционных систем, разработчики часто избегают libstd, используя только libcore.

Стабилизация libcore являтся важным шагом к возможности писать самое низкоуровневое ПО, используя стабильный Rust. Это позволит развиваться экосистеме библиотек вокруг libcore, но приложения пока полностью не поддерживаются. Ожидайте изменения в этой области в будущих релизах.

Стабилизации библиотеки

Около 30 библиотечных функций и методов теперь являются стабильными в 1.6. Заметные улучшения включают в себя:

  • Семейство функций drain() для коллекций. Эти методы позволяют перемещать элементы из коллекций, сохраняя память, в которой они размещены, тем самым снижая выделение памяти в некоторых ситуациях.
  • Ряд реализаций типажа From для конвертирования между типами стандартной библиотеки, в основном между целочисленными типами и числами с плавающей точкой.
  • Наконец, Vec::extend_from_slice(), ранее известный как push_all(). Этот метод существенно быстрее, чем более общий метод extend().

Crates.io запрещает использование масок в версиях зависимостей

Если вы являетесь мейнтейнером контейнера на Crates.io, возможно вы видели следующее предупреждение:

новые контейнеры более не могут использовать маски при описании зависимостей.

Другими словами, это запрещено:

[dependencies]
regex = "*"

Вместо этого вы должны указать конкретную версию или диапазон версий, используя одну из опций: ^, ~, или =.

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

>>> Официальный анонс

★★★★★

Проверено: Klymedy ()
Последнее исправление: Klymedy (всего исправлений: 6)

Ответ на: комментарий от anonymous

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

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

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

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

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

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

shkolnick-kun ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 :-)

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

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

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

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

Нормальное решение для осей с сишным интерфейсом и рантаймом. Если бы была лиспоось, писали бы на лиспе для «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.» :-)

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

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

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

anonymous
()

Тут возникло некоторое непонимание. Я говорил о том, что аналитика больших данных переходит на С++. Прозвучало название 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.

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

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

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

С++, Rust и D.

:-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

KDE

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

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

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

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

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

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

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

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

eao197 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.