• Rust vs. C++ на алгоритмических задачах
    +6
    и городить приходится не «хитрый» код, а именно правильный код с точки зрения всех возможных проблем.

    Всё-таки над non-lexical lifetimes не зря работают. Иногда borrow checker действительно заставляет делать "дополнительные приседания", хотя, как по мне, это не особо страшно.

  • Релиз CLion 2017.3: существенные улучшения поддержки C++, интеграция с Valgrind Memcheck и Boost.Test и многое другое
    0

    Приятно слышать. Надеюсь, что растовый плагин когда-нибудь дорастёт и до полноценной отдельной IDE.

  • Релиз CLion 2017.3: существенные улучшения поддержки C++, интеграция с Valgrind Memcheck и Boost.Test и многое другое
    +1
    Сейчас начнём потихоньку отвязывать CLion от CMake

    Ура. Для С++ меня CMake вполне устраивает, но отвязка от него крайне полезна для других языковых плагинов (в первую очередь, заинтересован в этом).

  • Восемь возможностей C++17, которые должен применять каждый разработчик
    +1

    Если мне не изменяет память, то это всё-таки работает (работало?) не везде. Возможно, для "путей" реестра, хотя это, конечно, не совсем про filesystem.

  • Встречайте GoLand 2017.3 — новая Go IDE от JetBrains
    +1

    Подозреваю, что в курсе, но: https://intellij-rust.github.io/
    Официально разрабатывается людьми из JetBrains.


    Я бы с удовольствием купил, если была бы коммерческая версия. Пока что приходится довольствоваться связкой CLion + IntelliJ Rust и мириться с CMake неудобствами .

  • Выпуск Rust 1.22 (и 1.22.1)
    +1

    Спасибо, стало понятнее. Собственно, понятно всё, кроме последнего пункта:


    Disallow constant expressions which would result in the destructor being called (if the code were run at runtime).

    Может есть пример?

  • Выпуск Rust 1.22 (и 1.22.1)
    +3

    Очень интересно (но не настолько чтобы рыться в обсуждениях) насчёт static/cost Drop: как оно работать будет?

  • Изучение Go путём портирования небольшого Python веб-бекенда
    +2

    Kолёса у самолётов (не у всех, впрочем) всё-таки есть, а шасси — это слегка другое. (:


    Мне тоже кажется, что языки, которые постулируют "отказ от исключений" не совсем честны в этом плане.

  • Как может вызваться никогда не вызываемая функция?
    +1

    Только такое видел, но при беглом просмотре не нашёл ничего про "заточенность на С".

  • Как может вызваться никогда не вызываемая функция?
    +5

    А фундаментально и "не надо". Вон в Java можно сишный код вызывать, но почему-то никто не срывает покровы заявляя, что гарантии джавы ничего не стоят.


    Тем более, что выше речь шла о том, что от языка не зависит. Ещё как зависит.

  • Concurrency паттерны в Rust из Java
    +2
    кастомные низкоуровневые синхронизационные примитивы стоит писать полностью в unsafe, ради производительности

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

  • Go, go, go… Первые впечатления
    +1

    Вот только Ruby я знаю ещё меньше чем D, а код всё равно понятен. (:


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

  • Go, go, go… Первые впечатления
    +1

    Ну я вот D не знаю совершенно, а код справа вполне понятен.

  • Типы struct, union и enum в Modern C++
    0

    Кому и чем мешают нововведения?

  • Пятничная дискуссия
    0

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

  • Пятничная дискуссия
    0

    Не то чтобы я хочу ругать C#, но стандартная библиотека — это всё-таки больше "инфраструктура", а не часть языка, если мы говорим о "фичах".
    Опять же, Java весьма консервативная и сравнение с ней не особо показательно.

  • Правда ли, что люди пишут безумный код с перекрывающимися побочными эффектами, сохраняя при этом невозмутимость?
    0

    Ну в "reference" языка данное требование прописано, но я затрудняюсь судить какой статус будет у реализации (частично) игнорирующей такие требования.

  • Правда ли, что люди пишут безумный код с перекрывающимися побочными эффектами, сохраняя при этом невозмутимость?
    0
    В release-сборке поведение при этом, как минимум, implementation specific, хотя, скорее всего, будет близко к UB из Си

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

  • Выпуск Rust 1.19
    0

    Да меня тоже дефолтный вариант вполне устраивает, а вот rustfmt_skip как раз не особо нравится: его на целую функцию вешать придётся. Можно, конечно, вынести создание массива в отдельную функцию, но это уже много лишних действий. Да и есть опция array_horizontal_layout_threshold, но пока только в "ночном" формате.

  • Выпуск Rust 1.19
    +1

    Мы тоже форматом пользуемся, хотя по поводу форматирования массивов были жаркиe споры.

  • Почему вам стоит изучить Go?
    0

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


    Ну и не думаю, что раст и го прямые конкуренты. Кое в чём они, конечно, близки, но местами разница очень значительна: и в деталях реализации и в "философии".

  • Работа с гетерогенными контейнерами с C++17
    0

    Вот эта строчка должна напугать? Можно было бы что-то "пострашнее" найти.

  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    0
    Использовать типизацию проше чем писать тесты.

    Сторонники динамической типизации будут спорить. (:


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

    Зависит от того насколько удобно это реализовано в языке.

  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    +1

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

  • Почему стоит полностью переходить на Ceylon или Kotlin (часть 1)
    0

    _

  • Dlang Tour переведен на русский язык
    0
    И там уже не важно, какие возможности у языка, какие фишки — если «не моё», то всё остальное отходит на второй план.

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

  • Выпуск Rust 1.18
    +2

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

  • Почему следует полностью переходить на Kotlin
    +3
    Delphi-style объявления переменных — зачем оно так делать, непонятно

    Это как раз понятно: так не будет неоднозначности, учитывая то, что указание типов не обязательно.


    Интересно есть ли какие-то аргументы против помимо "непривычности"...

  • Почему следует полностью переходить на Kotlin
    0
    В Rust Option тип может быть любым. Т.е. обычно у тебя возвращает String, а в случае проблема некий Error тип с произвольным содержимым.

    Нет, в раст Option<T> — это или конкретное значение T или ничего. Значение или ошибка — это Result<T, E>.

  • Функциональный Rust: Готовим говядину
    +1
    не помню, есть ли в Rust про это какой-то стандарт, а в C это называлось бы UB

    Стандарта у раста (пока) в принципе нет, но сейчас поведение определено следующим образом: в дебаге переполнения паникуют, в релизе поведение определено как "two's complement".

  • Лекции Техносферы: Программирование на Go
    +1

    А что раст? Там тоже "нет исключений". Просто перестроится сложно и не всегда понятное даёт ли это хоть какие-то преимущества. Люди привыкли жить с исключениями и находят в этом определённое удобство. Тут надо показать преимущества другого подхода, а не просто предлагать забыть о предыдущем опыте.

  • Шесть парадигм программирования, которые изменят ваш взгляд на код
    +2
    поменял свои вгляды на программирование ШЕСТЬ раз. И предлагает читателям последовать его интеллектуальным метаниям, так как вполне вероятно это далеко не предел и его взгляды еще поменяются не раз.

    Как будто что-то плохое. Конечно же, догматизм и синдром утёнка лучше.


    Короче, статья — рекламный мусор.

    Надо было ещё добавить проплаченный рекламный мусор, ну так для полноты картины. (:

  • Современный подход к сборке мусора
    0

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

  • Современный подход к сборке мусора
    0
    На то, чтобы работать быстрее C… нет — на это rust не претендует.

    Есть принципиальные причины почему раст не может быть, пусть не быстрее, но не медленнее? Ну кроме того, что в оптимизацию ещё надо усилия вкладывать.

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    0
    Судя по лицензии, есть только один честный способ использования демо-версии — попробовать перед покупкой.

    Зачем нужна такая демо-версия, которая обязует к покупке? (:

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    +3
    Я надеялся, что вы опровергните это мнение. Но увы, видимо не получится.

    Да, не получится.


    Более того: если посмотреть на факты, то мы легко к соглашению придём. Вот только выводы делаем разные.


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

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    0
    Легко представляю. Просто не надо стремиться к лишней точности.

    Ну да, так что-то посчитать можно, но у меня вызывает сомнение полезность таких грубых прикидок. В любом случае, временный ключ авторы выдают по запросу, если очень интересно, то можно и посмотреть на своём проекте. Или вы хотите чтобы это кто-то другой для вас сделал? (:


    А вы оглянитесь вокруг себя. Микроволновка, стиральная машина, лифт, кодовый замок…

    Дык, я не говорю, что осциллограф бесполезен всем. Хотя всё-таки кажется, что если считать "проекты" или, тем более, строки кода, то железячных проектов окажется меньше.


    Если сильно нужно — найду ссылки, где об этом написано.

    Тоже что-то такое припоминаю и возражений нет — звучит вполне логично. Если это ваш случай, ну что ж, не нужен инструмент и ладно.

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    +3
    Хотя и ожидал услышать конкретные цифры...

    Как вы себе это представляете? Даже если бы кто-то и решился на такой эксперимент, то как обеспечить объективность? Ведь нельзя дважды написать одинаковый код одинаковыми людьми в одинаковых обстоятельствах, но в одном случае использовать статический анализатор.


    потому что командную строку пишем мы сами...

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


    Вы осциллограф себе для отладки купили? А ведь он полезен! Вот только для вас он полезен абстрактно, а для нас — конкретно.

    Передёргивание. Осциллограф полезен для ограниченного числа ситуаций/проектов, статический анализатор — практически для любого кода. Размер этой пользы (и "стоимость") можно обсуждать, но отрицать её целиком мне кажется странным.


    Ну и уточню ещё один момент касательно "стоимости": если у нас на проекте (условно) два человека, то да, это всё дорого, сложно и некогда. А если под сотню, то анализатор стоит копейки относительно всех затрат.

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    +2
    Насколько увеличились продажи?

    Повторюсь: (к счастью) это не моя задача.


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


    Мой опыт такой, что если цейтнот постоянно, то что-то делается неправильно и страдать будет как качество, так и такая "эфемерная" штука "удовольствие от работы" (ну или "уровень стресса"). В итоге сотрудники будут перегорать и разбегаться. Ну это если аргумент про "некогда точить, пилить надо!" не принимается. А если периодически выделяется время на разгребание накопившихся проблем и прочий рефакторинг, то найдётся и на то чтобы прикрутить анализатор и задавить имеющиеся предупреждения. Что касается цены, так на прошлом месте работы выбирали между PVS и Coverity и надо сказать, что второй инструмент стоит на порядок дороже.


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


    Аргумент про ошибки в ТЗ мне совершенно не понятен. В том плане, что серебряной пули не бывает и все проблемы не решит ни один инструмент, но из этого никак не следует бесполезность этих самых инструментов.

  • Как используя PVS-Studio можно улучшить Visual C++ 2017 Libraries
    +1
    Они лет 7 пытались убедить разработчиков. Не вышло.

    Да ладно? Мне вот польза (подчёркиваю: польза, а не "панацея") статического анализатора очевидна. Аналогично с тестами, ревью, "континюес интегрейшн" и прочими валгриндами. Знакомые программисты мнение разделяют.


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