Подскажите перспективный ЯП, которому требуются батарейки

Система в rust похожая на ООП

Ты разбираешься в Расте? Или поковырял для интереса типажи, чтобы посмотреть на реализацию в сравнении с классами типов Хаскелла? В чём типажи упрощены (или наоборот, классы типов усложнены)?

Если разобраться, то нового rust - разве что идея владения объектами и связанная с ней идея использования ссылок.

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

Ты разбираешься в Расте? Или поковырял для интереса типажи, чтобы посмотреть на реализацию в сравнении с классами типов Хаскелла? В чём типажи упрощены (или наоборот, классы типов усложнены)?

Успел заинтересоваться. Язык мне очень понравился. Прочитал вторую редакцию The Rust Programming Language и успел так хорошо потренироваться на типажах, генериках и замыканиях, когда создавал прототип одной своей штуки. Например, мне удалось запрограммировать продолжения с помощью rust, так чтобы их было удобно использовать по типу futures-rs.

Но оказалось, что чем сложнее входная задача, тем аналогичный код на haskell у меня работает быстрее. Можно, конечно, сказать, что я недостаточно еще освоился с rust. У меня там используются RefCell и Rc.clone() в узких по производительности местах. Может быть, еще что-то. Периодически возвращаюсь к этому своему коду, пытаясь понять, ну почему же у меня код на haskell получился быстрее. А с выходом ghc 8.2 отрыв еще больше увеличился!

На самом деле, в тестовых примерах скорости почти одинаковые, что говорит о некоторой эквивалентности. В совсем простом тесте код на rust быстрее. В более сложном, как раз там, где начинаются продолжения - код на haskell быстрее.

Но как я написал, я сразу почувствовал, что окунулся в rust в хорошо знакомую мне по haskell среду программирования. Параллелей очень много.

А чего не хватает в rust, так это higher kinded types. Это когда параметр генерика сам является параметризуемым типом. В некоторых случаях можно как-то выкрутиться через использование типажей в ограничениях, но хотелось бы более общего решения.

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

Можно и транслитом, коли словарь не осилил...

толку от словаря, если dictionary от vocabulary не отличишь?

Rust, в скором будущем — SLang.

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

Кажись, что-то похожее есть

А может он ещё никуда не приходил?

Слабо. Очень слабо.

Отсутствие coding style. Как хочу, так и пишу.

Не заметил.

SimpleString.hpp
_demangle.cpp
backtrace.cpp
fast_division.h

Не заметили?

К качеству кода это не имеет отношения.

А при чём тут качество кода? Я про в целом либу писал.

Почему бесполезно, вы, конечно же, сказать откажетесь.

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

Если вы не видите смысла в шаблонах, это еще не значит, что они бессмысленные.

Ну так распишите, почему в конкретном случае их использование оправдано.

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

Ну и смысл от этого? Убрать один if? Бессмысленная оптимизация на пустом месте.

Ради md5 тащить в свой проект OpenSSL, Botan или Crypto++?

Если бы в С/C++ был ПМ - не было бы жирных либ и фреймворков. Но увы.

откуда уверенность, что сторонняя реализация лучше?

С вероятностью 99% - она будет лучше велосипеда. Если вы, конечно, не царь сишки.

Это претензия к проекту.

У меня была претензия к либе. Не нужно юлить.

И что тут жуткого?

То есть вы считаете это хорошим кодом? 100 строк без форматирования - это для вас хорошо? Надеюсь вы такой же код пишите, да?

К качеству кода и способу использования C++ это вообще не имеет отношения.

Имеет.

Как-то слабовато для «Это эталонный ужас».

Ну так для вас Qt ужас. Кто знает, может вы действительно нормального кода не видели.

higher kinded types

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

А то я как-то в растерянности, вроде все рассказываю как есть, а вы какой-то апломб видите...

Формально не понравилось вот что:

Во фразе «При выборе динамического языка программирования на тормоза насрать в принципе» отсутствуют слова «мне», «иногда» или «чаще всего». Без них - ЛПП ака ∀

Последующее условие «Особенно, если динамический ЯП идет в дополнение к C++ или даже к Java/C#» вообще превращает ∀ в ∃ даже с учётом отсутствия ссылок на себя любимого

К остальному, как и было указано выше, претензий нет

Слабо. Очень слабо.

Боюсь, эта оценка больше говорит о вашем понимании некоторых вещей, чем о моем анализе ваших претензий. Скудоумие, помноженное на узость кругозора, да еще и на уверенность, что вы что-то понимаете в использовании C++ дает страшные плоды.

Не заметили?

Не заметил. Судить о coding conventions и о coding style по регистру в именах файлов — это мощно. Кстати говоря, тут могут быть вполне себе логичные объяснения. Например, нижний регистр может говорит о файлах, которые не должны подключаться пользователями библиотеки напрямую. Можно было бы сделать и лучше (например, за счет подкаталога impl или details), но принципиально это картину не меняет.

А при чём тут качество кода? Я про в целом либу писал.

При том, что в пример код dzidzitop-а был приведен именно как образец более-менее нормального использования C++. Которое не выглядит как говно.

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

assert бесполезен, так как его нельзя отловить, как исключение. Больше всего это мешает при тестировании.

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

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

Ну так распишите, почему в конкретном случае их использование оправдано.

Зачем? Вы сказали: «Код ужасен». Вас спросили «Почему?» Вы отвечаете: «Потому, что не видите смысла». Ну не видите и не видите. Считать это аргументом в пользу вашего тезиса об ужасности кода просто нельзя.

Ну и смысл от этого? Убрать один if? Бессмысленная оптимизация на пустом месте.

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

Если бы в С/C++ был ПМ - не было бы жирных либ и фреймворков. Но увы.

В C++ нет де-факто стандартного пакетного менеджера. Поэтому разработчики живут с тем, что есть. Какие в этих условиях претензии к конкретной реализации md5 в составе конкретной либы? Если претензия сводится к тому, что не как в вашем Rust-е, то такую претензию можно смело продолжать держать в той жопе, из которой вы ее регулярно извлекаете.

С вероятностью 99% - она будет лучше велосипеда.

Да ладно. Что в реализации md5 такого сложного, что нельзя повторить самостоятельно на таком же уровне, как в каком-нибудь POCO или ACE? Особенно, если нет больших требований к производительности.

У меня была претензия к либе.

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

То есть вы считаете это хорошим кодом? 100 строк без форматирования - это для вас хорошо?

Вот уж отсутствия форматирования не заметил. Форматирование там есть, оно может вам не нравится, но все 100 строк при описании конструкторов там выдержаны в одном стиле, насколько я могу судить.

Надеюсь вы такой же код пишите, да?

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

Имеет.

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

Во фразе «При выборе динамического языка программирования на тормоза насрать в принципе» отсутствуют слова «мне», «иногда» или «чаще всего».

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

ЧТД. В очередной раз ЧТД.

Выдаём субъективное мнение за объективное, при этом запрещая окружающим делать тоже самое.

Всю вашу простыну можно описать одной фразой: я прав потому, что я прав.

Если я говорю, что код говно - то я не прав. Если вы говорите что код говно - то вы всегда правы.

Ваша логика ускользает от меня. Наверное из-за скудоумия. Не иначе.

Если я говорю, что код говно - то я не прав.

Если вы говорите «код говно», а подтверждениями является всего лишь:

• разный регистр в именах файлов;
• в коде используется assert, да еще собственный assert;
• не вижу смысла в шаблонах;
• объявления конструкторов классов по 100 строк;
• нет документации;

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

Но виноват в этом я, т.к. в спорах с вами вы всегда признаете правым меня. Ну, OK.

То есть даже приведенный вами список недостаточен?

В этом списке есть только один пункт, который объективен — это отсутствие документации к библиотеке. При этом комментарии в ключевых местах кода присутствуют.

Все остальное — это какой-то детский лепет.

объективен

Воу-воу. Полегче.

Вкусовщина, это когда 40% любят так, а 60% эдак, а когда 90% говорят, что это г-но - это оно.

Всё правильно. STL - это продукт творчества Алекса Степанов, который был включён в стандартный C++ как часть стандартной библиотеки. В кругах программистов на C++ под акронимом STL понимают исключительно это подмножество стандартной библиотеки и никогда - всю стандартную библиотеку. А кому хоть в кино, хоть в красную армию - те понимают по STL что угодно.

Они нужны для того, чтобы

1) избегать копирования, когда в буфере сформировалась нужная строка - из буфера или simplestring забирается строка, и он её перестаёт управлять. Это про detach

2) избегать ненужных проверок времени выполнения на каждый append в буфер.

Эта парочка - условно-безопасные обёртки над null-terminated C string. Без претензий на то, что детали реализации будут скрыты от пользователя.

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

гоу

В C++ нет де-факто стандартного пакетного менеджера. Поэтому разработчики живут с тем, что есть. Какие в этих условиях претензии к конкретной реализации md5 в составе конкретной либы? Если претензия сводится к тому, что не как в вашем Rust-е, то такую претензию можно смело продолжать держать в той жопе, из которой вы ее регулярно извлекаете

Разочарую вас обоих - мой md5 это обёртка над openssl md5 + репрезентация в шестнадцатиричном формате сверху.

Ну тогда вообще претензия мимо кассы. Хотя иметь свою реализацию какого-нибудь crc32, alder32, md5 или sha1, дабы не тащить сторонние зависимости — это вполне нормально в мире C++.

Вполне нормально, не спорю. Хотя под линуксом это не даёт больших преимуществ.