Блог

Web server go vs rust

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

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

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

А уникальная ссылка, конечно же, может быть только одна. Но тут возникает две проблемы: А значит мы скорее всего получим кучу ошибок компиляции "владелец умер, когда кто-то ссылался на его данные", потому как dangling pointers раст не допускает.

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

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

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

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

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

Если вы не знали про его существование, то ошибка компиляции снабдит вас информацией для размышления "А может стоит добавить реализацию этого трейта?

Вообще, раст для меня первый язык, в котором есть compiler-driven development. Вы просто запускаете компиляцию, если что-то не работает, язык просто скажет вам "хмм, что-то не сходится.

работает на 1с битрикс причина

Я думаю, проблема в Х. Попробуй добавить вот этот код, и всё заработает". Типовой пример, допустим мы написали две функции, и забыли добавить ограничение на генерик:. Копипастим where T: Copy из сообщения об ошибке, компилируем, всё готовопоехали в прод! Это очень помогает при кросс-платформенной разработке, когда у вас локально всё собирается, а на некоторой матрице на CI сервере где-то что-то падает из-за условной компиляции.

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

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

Звучит смешно, особенно для людей с динамических ЯП, но для меня это был серьезный прогресс. А еще за всё время работы с растом я дебаг включал ровно два раза. Растовый код у меня либо работал правильно, либо не собирался. В случае с C у меня уверенность сильно ниже, я все время думаю "а не придет ли тут null", "а не будет ли тут KeyNotFoundException", "правильно ли я синхронизировал доступ к этим переменным из многих потоков", и.

Go vs. Rust — Development — Форум

Ну а в случае с JS когда я фуллстечил и писал фронт в том числе после каждого изменения следовала обязательная проверка в браузере, что там изменилось. Это не значит, что в коде нет багов, это значит, что все баги связаны с логикой приложения. У вас нет неожиданных нуллов, несихнронизированного доступа, buffer overflow и так далее.

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

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

Попробуйте написать приложение на расте. Если у вас не получается пройти борроучекер, проверьте ваши структуры данных и их взаимосвязи, потому что я постепенно начал понимать, что борроучекер это не просто механизм, отвечающий за возможность освобождения памяти, но и отличный детектор правильности архитектуры приложения, из разряда "хей, а почему это объект Х зависит от У, я этого не предполагал!

1с битрикс 1с бухгалтерия

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

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

Я действительно считаю, что раст форсится исключительно как "Better C", который "такой же быстрый, но безопасный". И совершенно игнорируют тот факт, что это хороший язык общего назначения, на котором и микросервисы серверлесные можно делать, и другие интересные штуки. Все знают, что крутую распределенную систему можно быстро и удобно сделать на Akka, а вот что есть точно такой же фреймворк для раста actixв котором точно так же удобно можно всё сделать на расте — уже.

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

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

После некоторой практики на расте можно писать с той же скоростью, что и на Cно получать намного более серьезные гарантии корректности.

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

Спасибо, почитал! Я так понял, что концепта UnitOfWork там нет? Хотя вот это — огонь: Есть макрос stringify! И есть крейт nameof на его основе, делающий примерно то же, что и nameof. А группировка изменений по нескольким сущностям обеспечивается явной транзакцией.

В противовес DbContext. Да, вы правы. Беру паузу на размышление: Подглядел в крейт nameof, чтобы посмотреть, как они это сделали. Собственно, так же, как и я, только с гвардом, который как-то использует переменную: Там ничего не написано про "макросы в расте такие же как в С". И я предложил бы вам вежливее отзываться о ваших коллегах-программистах. Но в момент вызова макроса мы этот идентификатор и создаем.

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

Можно ли считать Golang убийцей Node.js?

Раст позволит объявить функцию сложения, которая на самом деле вычитает. И ничего не скажет. Спасибо, эту функцию я и писал. И да, unsafe это вещь, которой можно пользоваться. Если код помечен этим словом, это не означает, что тут ужос ужос и надо всё выкидывать. Макрос принимает просто токены. Если вы эти токены внутри макроса игнорируете, как элементы синтаксиса, то никакой ошибки компиляции не будет и быть не.

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

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

Три дня на го. И я хотел бы написать то же на расте, но с картинками как-то все сложно, с API к GCS тоже, ну вот и все — интерес кончился, надо чтоб работало. С этим трудно поспорить. Я полгода потратил на написание cv-rs биниднги к opencvчтобы мой бот мог картинки анализировать. Было бы намного проще, если бы это кто-то сделал до.

Для специфики могут быть свои нюансы. Таким образом можно взять любой из 8 языков где код будет просто работать из коробки — вопрос конвертации картинок я опускаю, но в каждом из восьми есть либа котора умеет делать ресайз и сохранять в webp. В rust есть набор костылей объективно — тот же порт grpc не умеет несколько вещей которые мне нужны и конструктор "сделай лего сам".

Вчера писал калькулятор на расте. Я сделал это по привычке на ООП: Сделал структуры с этим трейтом самы структуры получились пустыми, в них нет состояния и положил их в словарь в виде трейт объектов, которые дергаются по требованию.

У меня, однако, есть подозрение что это не идиоматично для раста. Я думал использовать функции вместо трейта, но это будет работать лишь в этом частном случае, поскольку у операций нет состояния. Если нужно будет сохранять состояние все равно придется делать структуры, поскольку раст не поддерживает каррирование.

Ну, полагаю, rust-way более функциональный в данном случае. Там, где в ООП вы делаете абстрактный класс и кучу наследников, в ФП вы делаете один энум и матчите его в тех местах, где вам. Где-то это дает выигрыш, где-то нет, это известная проблема выражения. И для раста это выходит более естественно, чем прямой перенос ООП опыта.

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

У вашего варианта есть фатальный недостаток. Что если вам понадобятся унарные или тринарные операции? В функциональных языках есть один очень популярный паттерн — интерпретатор. Реализуется он обычно либо при помощи tagless final кодирования выражений, либо при помощи GADT.

GADT в Rust нету, а вот простенький tagless final мы можем сделать используя трейты. И сделать для него конкретные реализации, каждая реализация будет конкретным интерпретатором. Например одна реализация будет возвращать строку для вывода, вторая считать результат выражения, третья просто дублировать значение для того, что-бы одно выражение превратить в два выражения, с разными типами.

Для расширения Expression можно использовать "наследование" трейтов хотя в большинстве случаев будет проще и лучше запихать операцию в изначальный трейт:.

Это моя первая программа на расте. Я не знаю ни языка, ни библиотеки. Думаю, писать стековую машину или дерево выражений слишком круто для первого раза. Я просто знакомился с трейтами. Хорошая статья. Правда я придерживаюсь мнения, что язык, скорее системный, и мне проще и в пяток раз быстрее делать сервисы на го, а в раст выносить криптографию, системные вещи.

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

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

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

Почему вы акцентируете внимание на скорости, когда это не самое главное? Да, Rust чертовски быстр, и может быть быстрее C, но это не важно.

Вы же понимаете, что люди пишут программы не для компьютера, а для других людей? Когда мне надо наговнякать хоум страничку для друга, на которую никто не будет заходить — я выбираю PHP. Когда мне надо в браузере работать с UI — я выбираю JS. Когда мне надо набросать функциональщину для проверки гипотезы — я выбираю Haskell. Когда мне нужен самый простой язык в мире, у которого 3 разных типа обработки исключений — нет, не выбираю: И когда мне нужен безопасный язык с предсказуемым поведением, который может поддерживать разработчик-июнь за USD, я выбираю Пикачу Rust, а не тот язык, поддержка которого стоит k USD в месяц и то не предел.

Как план с junior должен сработать? Через какое время на rust он сможет полноценно закрывать задачи? И если мы начинаем говорить про программы для людей, то нужен инструмент с кодом, который можно быстро читать. Древние свитки говорят о двух месяцах. После чего люди коммитят в сложные участки компилятора или пишут фреймворки, которые обгоняют существующие решения по производительности.

Давно открывали код gcc, который поддерживают 9 анонимусов в мире? Долгой им жизни Код надо не быстро читать, а понимать правильно и корректно. И инструменты должны давать по рукам, если человек неправильно понял.

А в статье у автора ушел год и только простые сниппеты с первого раза выходят… И это опытный разработчик. Что-то не так в свитках А вы мой изначальный комментарий? Если говорить не голословно, то пока я видел одну неудачную миграцию на rust, которая сильно увеличила сроки проекта и поставила его под вопрос. Сейчас очень хочу узнать не об опыте крутых, без всякого сомнения, одиночек, а о больших и долгих проектах.

И, повторюсь, вопрос долгой поддержки. Мне лично неясна ниша языка, пока мы не увидели проекты в долгой перспективе. У нас уже есть клевые scala, haskell, но которые слишком дороги в поддержке. Мне хотелось бы, чтобы rust не повторил эту судьбу. Статистику тут обычно смотрю https: Судьба parity мне не понятна пока, но тут скорее вопрос не в языке, а том, что товарищи время от времени мержат в мастер по несколько сот строк кода без ревью и тестов.

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

Маленькие команды очень опытный спецов — это точно сработает и работает. Увидим ли мы большие команды — вопрос. Увидем ли мы переход от системного языка к общему — тоже вопрос.

Я извиняюсь если вопрос покажется некорректным. Но мне правда интересно. Вы бы стали писать на Golang если бы за ним не стоял Гугл?

И что произойдёт если гипотетически Гугл скажет "голанг неудачен, пилим всё на тайпскрипт"? Озвученная вами проблема — извечная проблема курицы и яйца. Никто не хочет писать на новом языке так как на нём не пишут толстые корпорации — которые на нём не пишут так как пишет мало кто, goto 1. Вы круты, бесспорно, но это разговор о нравится-не нравится пошел. Мне он мало интересен, в отличие от инженерных задач и подходов к.

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

Мы вроде как задачи решать должны в поставленные сроки и с заданными условиями, а не про вкус и цвет. У меня есть в команде разработчик: На нем удобно сравнивать. На нем и сравниваем. Задачи на го идут шустрее в разы. Просто я помню. Net 2.

Но по драфту и текущему обсуждению его генерики не убьют старый год. Там скорее вопрос в том, что тогда надо стандартную библиотеку на генерики переписывать. А я знаю пример, когда разработчик "въехал" и начал нормально писать на расте за пару недель. До этого он писал на го и скале. Dlang — сурово. Вы второй человек, которого я встречаю, кто на нем программирует. Удачи вам с ним, уж не знаю, что за задачи у. Мне изначально код раста казался очень даже читаемым, и постепенно это чувство только крепнет.

Ну вот возьмем например мою версию телеграм-клиента. Он очень простой, умеет вызывать несколько методов удаленного сервера, и держать соединения. Какие конкретно места по-вашему тут трудночитаемые? И ведь подумал, что надо дописать: А зря: То есть вы испытали дискомфорт от того, что не смогли понять исходник на Rust, не зная его синтаксиса?

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

Я не знаю причины по которым вы говорите то, что говорите. Ведь вы же измеряли цпу-время разных решений Ведь вы же НЕ измеряли цпу-время разных решений. Кто смелый — кто сможет аргументировать за минусы? А то получается странно. Минусы есть, а ответов. Почему вы поступаете так несправедливо? Но из прикладных соображений — я представляю решение на пхп в проде, но с epoll 0 уже нет, даже банально по ssh туда влезть не удастся.

Я не минусил и не умею. Это не ответ. Было определено два тезиса: Что из этого следует? Мною были выдвинуты контрпримеры — на что последовало молчания. Если не можете в аргументацию своих тезисов, то зачем это вообще начинать?

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

Всё остальное — отношения к делу не имеет. Вы можете начать рассуждать о том, что рабсила дороже электричества, как какие-то иные критерии дороже. За это решение покупается производительность. Точно так же, как в пхп покупается что-то другое. Не верно. Епул долбит не во всех потоках одновременно, а даже если во всех — есть планировщик. Никакой ссш у вас не сломается. Ну и вообще, кто вас сказал о том, что epoll 0 заканчивается на захардкоренном нуле? Ничего вам не мешает считать время проведённое в обработчике и на основе данной статистике рулить этим аргументом.

Я не минусил и не умею ; Я говорю не про вас, а про тех, кто минусует без аргументации. Это не я отвечал если. Мой тезис был такой — epoll 0 это хак. И конечно это хак! Смотрите — одно и то же решение: Это по вашему филигранная работа и особенности?

Мдмашка в чистом виде. Тут и комментировать нечего. Конечно применимы, в реальных хайлод все это сплошь и. Во всех где вызываешь epoll 0 а это все ядра, иначе зачем он вам вообще нужен в любом виде в реальном проде? И вообще вы какой-то нервенный… Судя по нику — из-за расклада с PHP в highloadcup-е?

Ну так там и нода утерлась, не переживайте вы. Это неважно. Вы отвечаете в том контексте, которые определили до после вас. В нём же отвечал и. Менять условия. Ну дак перечитайте то — на что я отвечал и кому. Зачем менять условия? Вам не нравится одна строчка? Ну что поделать. Это не работа — это знание особенной того окружения, в котором работаете. Тогда это решение точно так же применимо в хайлоаде. Профит даёт. Ну и не понятно так. Всё это соответствует критериям, которые определили выше.

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

Не из-за. Я уже описал причины. TargetSan 21 сентября в Я знаю о том, что произойдёт при epoll 0. Хотя формулировка не верна — кол-во событий на ожидание не влияет — любой событие будет епул.

Дяди Васи? Что конкурирует с епуллом по ЦПУ? Неужели обработчик евентов в том же треде как это делается во всех реализация, что я видел? Какие ваши доказательства? Служебные программы. Например, мониторинг.

Или уже упомянутый тут ssh. А еще процессор может уменьшить свое энергопотребление если никто не крутит его в вечном цикле. Какие такие операции и в каких таких потоках?

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

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

Хотя опять же, данная ситуация — ваши выдумки. Это свойство не epell 0а отдельных реализация. И я уже говорил. Есть нюансы. Потому что в реальных задачах epoll 0 Это мой промах. Забыл вас спросить о том, что такое epoll 0 для того, чтобы защитить себя от подобного. Дело в том, что из epoll 0 следует именно epoll 0. Вы говорили именно об epoll 0а не захардкоривании там нуля. И это очень просто доказывается, в частности, этим: Но — без всех тех свойств, которые вы приписывали epoll 0.

Это мат. Именно результат вы определили за хак, именно то, что позволяет его добиться — вы определили за хак. Позволяет не ноль, не реализация, а именно epoll 0. Реализация — это нюансы. И теперь, когда я на это вышел — вы переобулись, но это неправильно и некрасиво. Если вы не определяете контекст — он экспортируется из ветки выше. Такие правила. Так это не работает. Я отвечал в рамках. Вы отвечали точно так же в рамках него и никак. Если проще.

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

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

Это и есть хак. Про алгоритм выбора таймаута речи и не идёт.

бесплатные vps сервера список

Точно так же они могли узнать про что угодно. Ваши обвинения были в чём? В неприменимости нулевого таймаута — это не. Нулевой таймаут не является хаком. И результат не является хаком. Я так же об этом писал с ссылками на инициатора ветки. И вы сами же этому вторили своими заявлениями про неработоспособность нулевого таймаута. Это подмена понятий. Нулевой таймаут — не хак. Нулевой таймаут — оптимизация. Нулевой таймаут не ограничивается захардкоренным нулём. Вы выше это повторили.

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

Люди создавали решения в рамках конкретных условий. И я уже доказал то, что реализовать это и для ваших условий труда не составляло. С тем же результатом. Что есть "чистый"? Моя ж гошка на 11 месте. В финале твоя на 11, без вопросов. Ах вон оно. Я уже как-то не слежу. Надо будет глянуть, что там за хак. Автор — молодец, нашёл ошибку там, где другие и не заметили.

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

Bonart 20 сентября в Если иметь это в виду, то разница, которую вы получили с исправлением, никак не влияет на наш выбор Go Это утверждение с помощью статьи проверить нельзя в статье ранжирование в первую очередь по производительности очевидно, методики расчета общего рейтинга неттак что тоже дезинформация.

как запустить mw3 dedicated server

Тем более что если бы такие оценки не учитывались, то по критериям, указанным выше, результат остался бы прежним. UA3MQJ 20 сентября в Вы свое решение уже приняли. Тут, видимо, вопрос о тех, кто только решает, что выбрать. PSIAlt 20 сентября в Выходит, человек поделившись своим трудом нанес ущерб сообществу Rust и навредил тем, кто решает что выбрать, я правильно понял?

Crandel 20 сентября в Не драматизируйте. Это больше похоже на баг. Который кстати никто не заметил, что характеризует размер и активность сообщества rust.

Про хайп не знаю, я не спец в. Вряд ли хайп помог бы автору починить проблему на проде. Про баги — там могло не быть детских багов по двум причинам: Ну да, круто засовывать всё в main и утверждать, что Go не допускает глупых ошибок. Про ущерб сообществу это просто смешно. Оно слабое, в том числе по этой причине выбор был сделан правильно. Так вот, это сообщество нашло эту кажется простую ошибку спустя только 2 года.

Выходит, проблема была и до статьи, что только добавляет очков к Go. Очень поддерживаю что перегиб по эмоциям. Вы ошибаетесь. JDTamerlan 26 сентября в Скорее всего, Вы недооцениваете важность и значимость самого процесса оценивания. Akdmeh 20 сентября в Вы бы все же сделали бенчмарк обновленных версий — интересно посмотреть, как поменялась производительность. Ну и все же о Node и Scala не забывайте. Да я неудачно выразился. Скорее синтаксис и возможности. И тут к обоим языкам огромное количество притензий Про вопросы бизнеса, для которого это все делается, тоже забывать не стоит: Ждем от mail.

Вроде бы это pprof. А то, что Go на hello world http показывает высокий RPS все уже и так знают. Antervis 20 сентября в Претензий по части синтаксиса и к их конкурентам системные яп. Системный язык — это то, на чём пишется система феноменально, да? И, собственно, системный язый язык у нас тут один — это Rust.

Будут ли их реально на Rust писать? Хороший вопрос — поживём, увидим. Но ни на Scala, ни на Go их написать. Go в этом смысле немного похож на пресловутые Лисп-машины: Система — это не только ядро и библиотеки, это еще и системная оболочка, системные утилиты, а также средства разработки. Которые могут быть написаны практически на любом языке. Есть чёткое определение: В отличие от прикладного программного обеспечениясистемное не решает конкретные практические задачи, а лишь обеспечивает работу других программ, предоставляя им сервисные функции, абстрагирующие детали аппаратной и микропрограммной реализации вычислительной системы, управляет аппаратными ресурсами вычислительной системы.

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

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

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

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

В английской версии написано более аккуратно: Удивительного ничего нет: Здесь же указано: Потому что если их включать, то становится непонятно что вообще туда не будет попадать Браузер, при помощи которого мы с вами общаемся. Текстовый редактор, музыкальный проигрыватель и так далее. Все прикладное ПО. Браузер, при помощи которого мы с вами общаемся.

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

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

Go vs Rust

А потом ещё отменим разделение на тёплые и холодные цвета, твёрдые и мягкие предметы и вообще — отменим все прилагательные нафиг. Кто-то ж перепутать может! Хороший вопрос — поживём, увидим Знаю по крайней мере про этот обучающий? Это их проблемы. Для того, чтобы Go можно было назвать системным языком нужно дать такое определение, которое было бы 1. Не, ну если во всем тексте выбирать ключевые слова, тогда конечно Так я не аналитик.

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

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

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

В этом отношении он уникален, самый что ни на есть правильный язык: Это же здорово! Ну да, там провал в одном тесте, но это с недоделанной библиотекой длинной арифметики связанно, так что черт с.

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

Anchous Drive Recruitment Москва. Все вакансии. DrAndyHunter 26 декабря в Модули же завезли с 1. С этим есть нюансы. Некоторые утилиты для go generate и средства работы с кодом для IDE до сих пор в некоторых случаях работают не так хорошо, как с пакетами в GOPATHа то и вовсе не работают. С этим постепенно справляются, но тем не менее.

Не слишком понятно, почему требуется "v" в начале имени тега. Возможно, только у меня, но принудительный вендоринг иногда выкидывает поддиректории из репозиториев, из которых подключается несколько библиотек например, если из github. В вышеприведенном коде нет обработки ошибок, только их переброс наверх. Подход Go подталкивает к обработке ошибок, а не на отсылку их выше в надежде, что кто-нибудь разберется. Есть понятие ошибки и есть понятие исключительных ситуаций. Их следует четко различать: Ошибки логически ожидаются, и их как правило стараются обработать тут.

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

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

И я не считаю неопытных программистов быдлокодерами. TheShock 28 декабря в Слишком глуп, чтобы придумать вменяемый аргумент? Аппелируй к возрасту! Смысл фразы во второй части предложения, а не в возрасте. Глупое предположение. Как можно апеллировать к авторитету в интернете? Такой софт живет десятки лет и переживает смену многих программистов. Для такого софта тотальная огороженность и упрощенность Go очень подходит.

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

Вы сказали две вещи: Первое — апелляция к возрасту, второе — к авторитету. Ни одного конструктивного аргумента вы не предъявили. DexterHD 26 декабря в Я ничего и не говорил про как и что правильно использовать.

Я лишь пояснил автору комментария выше что в Go есть механизмы для обработки разного типа ошибок. PsyHaSTe 27 декабря в Исключения нужны не столько для оповещения вышестоящего кода, сколько для корректного выхода сразу из нескольких функций вверх по стеку, с корректным вызовом деструкторов, финализаторов и вот этого. Crandel 11 января в Типа Option не будет, пока не будет generics. Потому что без них он мало осмысленный. Допустим вы пишете класс, описывающий конфиг приложения.

Конфиг должен быть. Что делать, если файл конфига есть, но прочитать его не получатеся? Вот тут был мой пример из очень старого проектика. Как раз про конфиг. Уронить приложение из-за невозможности прочитать файл?

Пользователи скажут спасибо. Паника — это штатный механизм, который можно обработать. И что вы предлагаете делать, если конфиг не читается? Загружать пустой дефолтный и пытаться работать? Ну вариант конечно, но на мой взгляд совсем не. Я бы лично в такой ситуации выкидывал панику с записью в лог или консоль если это консольное приложение. Глобальный хэндлер паники, конечно же, можно настроить, но как правило он просто залоггирует что-то потому что контекста сделать что-то полезное у него тупо.

И если после этого он не упадет и оставит программу в потенциально некорректном состоянии, то это даже хуже, чем молчаливые падения. Паника — это что-то вроде глобального исключения, которое можно поймать и обработать. Штатный механизм для исключительных ситуаций. И что же может сделать вызывающий код, в обсуждаемом случае? Выкинуть панику? When a function encounters a panic, its execution is stopped, any deferred functions are executed and then the control returns to its caller.

This process continues until all the functions of the current goroutine have returned at which point the program prints the panic message, followed by the stack trace and then terminates. Recover is useful only when called inside deferred functions.

Executing a call to recover inside a deferred function stops the panicking sequence by restoring normal execution and retrieves the error value passed to the call of panic. If recover is called outside the deferred function, it will not stop a panicking sequence. А почему это нельзя сделать в том месте, где и произошла ошибка? Не смогли прочитать файл конфига? Заполняем там же структуру дефолтными значениями например. И все же: Если у нас был код типа db. Update reading: Ну это и есть "молчаливое" поведение, о чем в статье выше расписано.

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

TheShock 27 декабря в Деньги упали на счет клиента — пишем в базу.

Go быстрее Rust, happyforum.info Group сделала замеры / Хабр

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

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

Возвращаясь в контекст го — вот типовой пример — golang. Если что-то не так — то ListenAndServe вернет ошибку, и типовая сферическая инициализация выглядит как-то так: Second, WriteTimeout: Second, MaxHeaderBytes: Fatal s. ListenAndServe Т.

лор такой лор

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

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

Все кейсы в подробностях мы можем и не знать на этапе начала разработки, но все довольно быстро проясняется. Или я не понял о чем мы вообще дискутируем? Эм, вообще-то знаю: Например в случае конфига какого-нибудь сервиса — надо падать, если мы не можем его получить или он кривой. Потому, что без конфига или с кривым конфигом работать этому сервису будет как-то сложно. Или же мы можем навернуть тут абстракцию, и сначала попытаться загрузить конфиг с локального ресурса, потом посмотреть, например, в какой-нибудь etcd, или еще что-то.

Но в любом случае, конфиг нам нужен. Другой пример — ну скажем, условный s3cmd. Мы можем посмотреть на типовые локации конфига, и если там ничего нет — используем дефолт.

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

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

Вся остальная логика в вызывающем коде. Можно еще навернуть там таймауты и попытки повторного запроса, но это уже опционально. А зачем так делать? Ну а как тут сделаешь атомарной, если там паника. Даже если какой-нибудь try finally блок делать, он по идее не выполнится. Так смысл именно про стейт. Мы взяли, обновили стейт, пошли читать файл, после этого стейт нужно снова обновить. А тут паника. Что делать? Ну я вот спрашиваю про конкретную ситуацию, что делать предлагается.

Ситуацию вы вполне знаете, требования простые: Открыли файл, прочитали его или его блок если файл большойзаписали в базу. Ну в самом деле, это такие элементарные вещи, что как-то даже странно не знать. Какой стейт и зачем? Опишите кейс более подробно. Плюс в CLI еще, возможно, добавил бы опцию для генерации дефолтного конфига. В ситуации чисто десктопного GUI приложения — да, выкидывать окошко с ошибкой. Как не будет? В данном случае БД.

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

Но это видимо не go-way? И почему это может вызвать проблемы? Открываем — не открывается — по деферу сбрасываем флажок.

В базу ничего не попадает. Посмотрите вот тут — github. Я вас где-то заставляю делать так? Делайте как вам. Открываем — не открывается" по деферу сбрасываем флажок. Дефер будет вызван в случае паники? Ок, а что будет в случае другой паники во время обработки этого дефера? А вы погуглить не пробовали? По первой же ссылке все написано. Да, конечно, defer вызывается при любом выходе из функции, хоть return хоть panic. Ну. Чуть раньше было про конфиг, ага. Ну да ладно, Г-дь вам судья. Понимаете, тут все несколько проще: Читает файл, закрывает файл освобождает ресурс.

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

Не понимаю, в общем, ваших стенаний. PsyHaSTe 28 декабря в Мы уже разобрали, что с defer доступ в базу закроется. В таком случае данный пример не имеет смысла, го его разруливает достаточно адекватно.

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

Тогда я согласен в сами, и не согласен с автором исходного утверждения а транзитивно — вы тоже с ним не согласны. В таком случае подождем его ответа, либо обсуждение исчерпано. Спасибо за диалог. В случае, если ошибка с чтением произошла на этапе чтения конфига, очевидно, надо срать в лог и крашиться. Edison 27 декабря в Зависит от того, насколько критичен конфиг. Eсли не можете загрузить конфиг, можно использовать дефолтный конфиг и WARN в лог или stderr вывести.

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

Если конфиг файл не был определен — использую дефолтный конфиг. Если конфиг файл определен — читаю конфиг файл и переписываю дефолтный конфиг тот, что был создан сначала.

Если, когда конфиг файл определен, но что-то идет не так — файла нету, он не читаемый или конфиг не валидный — останавливаю сервис. Тогда упадет только один инстанс, а все другие будут раниться с правильной конфигурацией пропагация деплоймента остановится. Jsoncfg4j и все прочее… Если, когда конфиг файл определен, но что-то идет не так — файла нету, он не читаемый или конфиг не валидный — останавливаю сервис.

Ну так вдруг не надо падать, а просто сообщение куда-то вывести. Падать на любой чих это. Json, cfg4j и все прочее Ах интерпрайз. IMO, библиотека должна работать с конфигурационным объектом, а не файлом. Для юзер приложений это может и лучше, для backend — лучше падать. Ах интерпрайз. А объект откуда возмьется? Ну мое мнение, что нужно прокидывать наверх до тех пор, пока не встретится код, который знает, что делать с ошибкой. С конфиг файла, но тут уже вы решите что делать с нечитаемым файлом или его отсутствием, а не полагаться на разработчика библиотеки вернет ли он ошибку или панику?

Кстати, вот тут ваше мнение расходиться со второй репликой про прокидование на верх. Второе, чем больше библиотек, тем больше конфиг файлов? А потом еще разный формат — один хочет yaml, второй toml, третий ini. Если библиотека бросает панику — то надо руки такому разработчику вынимать. Json, Microsoft. Xml, Microsoft. New some. DefaultConfigmylog, mydb. Ну хорошо, так и. Теперь мы ей передали строковую константу, файл такой есть, а она его открыть не. Defaultconfig if err!

Fatal можно log. Fatalf "failed to load config: New someConfig, log, db. Если мы прокидываем это в том или ином виде — то это то, чего я хочу, но это противоречит Подход Go подталкивает к обработке ошибок, а не на отсылку их выше. Только библиотека знает, валидный ли файл конфига или. Edison 28 декабря в Ладно, попробую объяснить на пальцах, без кода: Тем не менее, хочется избежать создания жёсткой связи между библиотекой, которая может оказаться частью любого приложения выполняющегося в любых условиях, и конкретным конфиг-файлом на диске.

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

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