• Как может вызваться никогда не вызываемая функция?
    +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 пытались убедить разработчиков. Не вышло.

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


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

  • Почему вам стоит изучить Go?
    0
    но это не делает его языком выбора, не смотря на все его достоинства и няшность.

    Почему? Если в каком-то определённом случае достоинства перевешивают недостатки, то как по мне, язык вполне можно рассматривать


    Ну в общем хвалиться не прикольно.

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

  • Почему вам стоит изучить Go?
    +1
    Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).

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


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


    С видением проект у создателей Раста явно какие-то проблемы

    Не очень согласен, но безотносительно этого: как по мне, лучше пусть будет много экспериментов до релиза, чем потом будет язык из стороны в сторону бросать. Интересно было бы послушать если ли какие-то претензии к языку в этом плане после версии 1.0.


    Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL.

    Ну положим они больше пруф оф концепт делали, чем конечную (современную) реализацию.


    А еще вот всопмнился язык D — его тоже одиночки поднимали.

    Вот мне кажется, что все эти метания с D1/D2 и фобос/деймос, в немалой степени, тому причина. И если бы они подольше подержали язык в "дорелизном" состоянии, то этого, возможно, удалось бы избежать.

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

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

  • Почему вам стоит изучить Go?
    +1
    говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво

    А кто говорит о суперуспешности? Изначальное утверждение звучало совсем не так. Я просто хочу сказать, что на расте работу найти реально. Да, её (очень) мало, но тот самый "продакшен" имеется.


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

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

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


    когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)

    А это к чему? С версии 1.0 совместимость вполне обеспечивается. Есть конкретные претензии или это просто сотрясание воздуха?

  • Почему вам стоит изучить Go?
    +2
    Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)

    Учитывая постоянные передёргивания, на нормальный ответ не надёюсь, но всё-таки. Про C# пишут, что в январе 1999 была уже сформирована команда, которая занималась языком. Причём мне что-то подсказывает, что видение конечного результата было уже сформировано. Раст же начинался как проект одного человека, язык прошёл через множество экспериментов до того как окончательно оформился. Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.


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

  • Передача намерений
    0

    Я не знаю как ответить, чтобы не вызвать флейм. На языке вертится "примерно затем же, зачем нужна статическая типизация", но очевидно, такой ответ не устроит. (:


    Можно поискать аргументацию зачем explicit был добавлен (причём в стандарте 11 года его действие расширили и на операторы). Сильно убедительных примеров у меня нет, могу только повторить, что меня вполне устраивает когда ситуация когда неявных приведений вообще нет в языке. Одна из причин — сделать создание "дорогого" объекта более явным.

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

    Дык, изначально речь шла о том, что вообще никто кроме мозиллы не использует? Рад, что мы достигли взаимопонимания, что это неправда.