• Занятное мини-интервью с основными контрибьюторами PHP 8
    +1

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

  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    +6

    В Rust две мутабельные (исключительные) ссылки на одно и то же — не могут быть валидным кодом. И попытка их создать — это всегда UB. Поэтому нет смысла и в ослаблении ошибки до предупреждения.

  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    +5

    Ну, я ещё добавлю.
    impl<T> — это объявление переменной типа. В этом контексте для Bar<T> — используется переменная, созданная в этом объявлении.
    Но точно так же мы можем написать impl Foo for Bar<T> — это такая же легальная реализация, только для конкретного типа T.
    Если мы заставим компилятор догадываться "здесь подразумевалась переменная, которую решили не указывать, или конкретный тип, который забыли импортировать" — это в итоге создаст сильно больше проблем, чем решит их. Хотя подобные предложения были и рассматривались в рамках обсуждения по улучшению эргономики языка.

  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    +7

    В принципе, в Rust не с потолка все языковые фичи, в том числе и эти "закорючки" берутся — всё это проходит свою эволюцию через обсуждение с комьюнити. Часть "закорючек", к слову в процессе развития языка таки убрали.


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


    Так что всё зависит от того, кто смотрит на код, и даже восприятие одного человека — не постоянно, и со временем меняется.

  • C++ быстрее и безопаснее Rust, Yandex сделала замеры
    +7

    Именно после этого — можно утверждать, что в Rust — всё на порядок проще с этим. Потому что небезразличный человек, буквально со стороны, — пробежался по ансейфам и нашёл этот баг.
    Люди совершают ошибки. Это не случайность, это — норма.
    Rust — язык созданный для упрощения борьбы с ошибками и в этом вся его прелесть. Хотя компилятор по прежнему не может думать за человека, но довольно таки большую часть работы он с человека снимает. Остаётся выполнить свою часть.

  • Выпуск Rust 1.37.0: Profile-Guided Optimization, неименованные константы и cargo vendor
    0

    Стандартные линки можно опознавать и исправлять соответственно новой адресации — это не должно оказаться сложной задачей.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +1

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +3

    Гонки бывают разные.
    Гонки данных — лишь частный случай.
    Rust не может исключить те же dead-lock'и на мьютексах, например. Но Rust не позволит просто так взять и забыть освободить мьютекс. И Rust не позволит иметь ссылку на данные, защищённые мьютексом, после его освобождения.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +3

    Нет, результат — можно отследить как он был вычислен.
    UB, приведшее к невидимой поломке кода, не проявляющейся в отладочной сборке — сильно сложнее обнаружить.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +5
    Статический анализ не способен отследить перемещения ссылок для объектов которых еще не существует на момент компиляции

    Статический анализ при наличии соответствующих деклараций может гарантировать исключительность ссылок или их иммутабельность. Там, где он не может гарантировать — Вы не сможете использовать бесплатный механизм заимствования в таком виде, и Вам придётся использовать "платные" механизмы доступа/синхронизации в runtime. Цена "платных" механизмов тоже может существенно различаться и у программиста есть выбор. Но это совершенно не значит, что, если в каком-то месте пришлось задействовать runtime, то его придётся использовать везде, как в языках с GC. Механизм заимствований продолжает приносить пользу для всего кода между обращениями к runtime-механизмам.


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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +2
    И вместо SIGFAULT вы получите некорректный результат.

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    0

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    0

    Согласен, это более простой случай — если программа успешно собирается, то с ней уже можно как-то работать. IntelliJ строит виртуальное AST и работает с ним, в том числе, и для упомянутого автокомплита, так же как позволяет и полностью развернуть сгенерированный макросами код (без этого вообще очень многое не работало, поскольку в библиотеках Rust очень много сгенерированного кода).
    Однако это пока совершенно не касается процедурных макросов. Хотя для Rust и есть практически официальный интерпретатор, который уже используется для некоторых задач в компиляторе, вроде вычисления значений константных функций. Полагаю, со временем, по мере развития, он будет более плотно использоваться.
    Всё это в каком-то виде будет переиспользовано и в RLS 2.0, поскольку он в значительной мере пишется с оглядкой на опыт, получаемый с IntelliJ, но я плохо представляю, как с этим будут взаимодействовать другие IDE.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +1

    Время работы скрипта между несколькими запросами — порядка десятков миллисекунд (спасибо высокоуровневым ORM решающим уйму вопросов небесплатными абстракциями "просто для удобства").
    Время работы скомпилированного кода на Rust с теми же запросами — порядка нескольких миллисекунд.
    Этой разницы на порядок в скорости завершения транзакций достаточно, чтобы базе вообще нужно было гораздо меньше вовлекать механизм блокировок.
    Хранимые процедуры — да, полезный компромис, но он сложнее в поддержке и имеет немало ограничений. Сам встроенный язык хранимых процедур — не так богат по возможностям. Если приходится думать о таких оптимизациях, база — уже бутылочное горлышко, и нагружать её исполнением интерпретируемого кода — не всегда подходящее решение. Если же это компилируемый код — мы вернулись к выгодам от компилируемого эффективного языка в среднем звене (клиент базы) и как следствие коротких транзакций, в противовес сложности обновления и поддержки хранимых процедур в самой базе и проблеме бутылочного горлышка.
    Я не буду спорить с тем, что в предложенном Вами подходе есть рациональное зерно и я сам бы так поступал во многих случаях. Но это скорее вопрос целесообразности и обстоятельств в каждом конкретном случае.


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

    Ошибку, всё-же, можно обнаружить и исправить. Скорость же работы клиента — это скорее фундаментальное ограничение, исправить которое будет очень дорого.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +6
    Если компилятор не нашёл в вашей программе ошибку, обратитесь к системному программисту, чтобы он исправил ошибку в компиляторе ©

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    0

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +6
    Чем метапрограммирование хуже?

    Сложностью. Взрывообразным ростом сложности. Специфика IDE в том, что она, в отличие от компилятора, должна большую часть своего времени работать с некорректным кодом, как-то догадываясь, что там программист сейчас наживо пишет. При этом помогать программисту нужно с кодом до преобразования, как-то предполагая, что будет в результате преобразования при том, что точного совпадения с правилами преобразования прямо сейчас нет. И это действительно нетривиальная задача по сравнению с "поработать обозревателем преобразований в готовом корректном коде", а тем более, подсказывать исходя из проработанной модели языка, где всё на своих местах.
    Собственно, для Rust сейчас эту задачу пытаются решать в IntelliJ и Ferrous Systems. Но уже очевидно, что она — не всегда (или исключительно непросто) решаема.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +9

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

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +8

    Одна из ниш, где Rust уверенно завоёвывает себе место под солнцем — HFT. Как раз по причине того, что нужно максимум скорости, при этом действительно надёжно и без эзотерических багов как в C/С++. Ибо бизнес в случае чего теряет столько, что мало не покажется. До последнего времени здесь доминировала Java.

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +4

    Это далеко не так. Большая часть кода вполне хорошо себя чувствует в безопасном подмножестве.
    Unsafes in Redox

  • Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?
    +3

    Как сказать "присматриваются".
    Например, один из локомотивов асинхронного Rust — Actix — творение рук одного из сотрудников Microsoft: есть сведения, что очень даже активно используется ин-продакшн. Есть и другие примеры.

  • OSDay 19 или почему еще жив язык Си
    0

    Ну, так можно жаловаться на то, что все люди как люди, говорят на простом и понятном английском, а нативные носители английского — на каком-то инопланетном английском. Это язык. Как и любой другой язык, чтобы им полноценно пользоваться — его нужно знать. Иначе будет непонятно.


    Ещё есть интересная особенность, касающаяся любого языка: когда у языка появляется новое свойство, большинство, с этим свойством не знакомые, желают более "вербозный" синтаксис. Опытные же пользователи, привыкшие к этому свойству, желают его записывать покомпактней. Этот вопрос регулярно всплывает, когда обсуждается будущий дизайн новых свойств Rust (весь процесс, кстати, происходит открыто и с участием всех желающих).

  • OSDay 19 или почему еще жив язык Си
    0

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

  • OSDay 19 или почему еще жив язык Си
    +4

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


    На примере в несколько строчек эта полезность не так заметна и выглядит несколько странно. В крупном же и важном проекте, над которым работает немаленькая команда — можно только молиться на компилятор, который избавляет тебя от сегфолтов и прочих очень неприятных недоразумений, которые можно часами ловить в отладчике, или вообще до часа X не догадываться об их существовании.


    Потому что, когда такой час X "пробивает", обычно остаётся только устраивать сеанс спиритизма в три часа ночи, чтобы понять, ГДЕ этот чёртов косяк, из-за которого всё внезапно начало падать или почему остатки на счетах превратились в тыкву, и как это побыстрее исправить, ибо бизнес несёт убытки.


    Это, конечно, не серебряная пуля и не избавляет от всех багов вообще, но за то, от чего избавляет — это не такая уж и высокая цена писать всё чуть более многословно. Тем более, разработчики языка постарались насколько это возможно многословность нивелировать синтаксическим сахаром.


    Я бы даже добавил, что когда получается слишком раздутый код — в Rust это примета того, что "что-то пошло не так" и используется не лучшее архитектурное решение. Это особенно актуально для новичков, которые пытаются натягивать на Rust привычный стиль написания программ из других языков.

  • OSDay 19 или почему еще жив язык Си
    0
    Это звучит очень странно, учитывая, что свойство буквально содержится в корне слова

    Это не переменные, это — биндинги. В большинстве случаев переменные не нужны. Поэтому и let mut, чтобы ленивые люди предпочитали не использовать мутабельность там, где она не нужна.


    К слову, в Rust вплоне можно перекрывать старое значение с тем же именем: let x = x + 1. Кроме того время жизни биндингов ограничено блоками, где они объявлены. И это тоже позволяет часто обходиться без мутабельности.

  • Comment from a drafted post.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Comment from a drafted post.
  • Коренные микробы влагалища
    0

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

  • Субъективное видение идеального языка программирования
    0

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


    Посмотрите в сторону PyPy — они активно работают именно в этом направлении, начиная с того, что сам PyPy пишется на RPython — типизированном подмножестве Python, заканчивая тем, что их JIT-компилятор умеет в векторизацию и как итог numPyPy способна конкурировать с numpy по производительности. Хотя я давненько уже не следил за их прогрессом, не знаю, насколько это "готово в продакшн".

  • Уроки украинского
    0

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

  • Уроки украинского
    0

    Кстати, интересно отметить, что язык, по этому авторитетному источнику, соответственно родственен обоим: и language, и tongue.

  • Уроки украинского
    0

    Тогда ударение на "а" не нормально "ни тут, ни там".

  • Уроки украинского
    0

    Вроде бы должно быть наоборот?
    Россияне тяготеют к ударению на а, украинцы — на и?

  • Уроки украинского
    0

    Вы заменили слово Украина на "окраина". Вы уточнили, что придаёте именно этот смысл. Разумеется украинцы не довольны. Ну примерно так, как русские недовольны, когда Россию называют "Московией, присвоившей название россия", "Ордой" или другими обидными штуками, заканчивающимися на "-стан".

  • Уроки украинского
    0

    Совершенно не очевидно. То есть смысл вполне себе может быть не "границ", а каких-то конкретных "территорий". Что вполне себе прослеживается по некоторым другим применениям слова в летописях, особенно "и всъ краин русские от Вильна аж до жродел Неманов" — это стольный-то град "окраина"?


    Так же не очевидно, что применение этого слова с таким смыслом отрицает применение его с другим смыслом (ну примерно как в современном русском край чего-то не отрицает край-территорию или точно с теми же двумя смыслами слово "сторона"/"страна").


    Применение вполне себе аналогичное русскому слову "предел", которое тоже может означать и границу, и территорию.


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

  • Уроки украинского
    0

    Да, действительно, корректней было сказать просто про общее происхождение.


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

  • Уроки украинского
    0

    Претензии ко всем, кто называет. Особенно в контексте территориальных претензий.


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

  • Уроки украинского
    +2

    Оба слова употребляются равноправно. И оба в мужском роде.