Пример — C# взлетает начиная с конца 1990-х годов, и до сих пор в нём ещё дорабатываются решения простейших задач и дописывается документация.
Если прямо сейчас начинать вкладывать свои усилия в Rust, то придётся лично заниматься развитием той экосистемы, и проходить по всем граблям, которые в Си уже проёдены, решены и задокументированы.
Если нужен коммерчески-успешный продукт — никаких растов!
Взлетает, ибо значительно лучше С/С++, и альтернатив особо и нет.
BE>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
А это вряд ли, поскольку никто не бросится переписывать системный софт. Rust будет появляться в новых проектах, но в системном софте это встречается нечасто.
Rust хорош если вы сами начинаете такой проект.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Микрософт тоже хвалит Раст. Я вот тут подумал, ведь если они в следующем апдейте винды поставят ядро и сервисы, написанные на Расте, это что же получится — они все проблемы с безопасностью из-за багов пофиксят? И нафига тогда нужна будет Микрософт пользователю после покупки компа с Windows10, если все основные баги уже прочекал компилятор Раста с его супер-безопасной системой типов? И что делать толпам программистов, занятых фиксингом багов? А если там unsafe код будет, то шило на мыло...
Здравствуйте, student__, Вы писали:
__>Микрософт тоже хвалит Раст. Я вот тут подумал, ведь если они в следующем апдейте винды поставят ядро и сервисы, написанные на Расте, это что же получится — они все проблемы с безопасностью из-за багов пофиксят?
Здравствуйте, D. Mon, Вы писали: DM>Не все, только 70%. Они считали статистику.
Ну хорошо пусть 70%, но все равно, вот жил себе индус, не тужил, фиксил по багу в день (условно), а с Растом хренак! — и будет только треть багов от предыдущего объема. И что, теперь индусу будут платить треть зарплаты?
Ах да, там же надо будет писать кучу новых книг, вести всякие бложики, участвовать в конфах. И самое главное — кому-то надо будет переписывать терабайты легаси кода и писать новые революционные версии. Тогда все нормально, можно не паниковать, главное креативить побольше. Вот у специалистов по UI из Микрософта надо креативщине учиться, у них каждую новую версию Windows новый GUI можно лепить, каждый следующий еще более бесполезный, чем предыдущий, но при этом каждый раз революция. Жалко, что с системным программированием сложнее. Если это не IDE, то там нет пользовательского интерфейса.
Здравствуйте, student__, Вы писали:
__>Микрософт тоже хвалит Раст. Я вот тут подумал, ведь если они в следующем апдейте винды поставят ядро и сервисы, написанные на Расте, это что же получится — они все проблемы с безопасностью из-за багов пофиксят? И нафига тогда нужна будет Микрософт пользователю после покупки компа с Windows10
Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше.
Здравствуйте, vorona, Вы писали: V>https://www.opennet.ru/opennews/art.shtml?num=51475
Хм... драйвер писали для юзерспейс, чтобы натянут сову на гло... в смысле, чтобы можно было вообще вкрячить в эксперимент managed-языки, я уж молчу про питон... Типа, возникла идея "давайте ка сбацаем эксперимент с разработкой сетевого драйвера. Но нужно непременно заюзать в т.ч. шарп и жабу! Но стоп, обычно такие вещи выполняются в kernel-space... Тем хуже для kernel-space!"
V>>https://www.opennet.ru/opennews/art.shtml?num=51475 __>Хм... драйвер писали для юзерспейс, чтобы натянут сову на гло... в смысле, чтобы можно было вообще вкрячить в эксперимент managed-языки, я уж молчу про питон... Типа, возникла идея "давайте ка сбацаем эксперимент с разработкой сетевого драйвера. Но нужно непременно заюзать в т.ч. шарп и жабу! Но стоп, обычно такие вещи выполняются в kernel-space... Тем хуже для kernel-space!"
Называется «смотрел в результаты, нифига не понял, решил прикинуться Шериданом».
Много ты языков без GC среди популярных и относительно популярных знаешь?
Авторы взяли ровно то, что и нужно для сравнения языков — не синтетическое говно типа alt.debian.shootout, а полноценное законченное приложение (ну или в данном случае драйвер). Взяты популярные среди технарей [1] на данный момент языки программирования.
— Без GC: C, Rust
— С GC: Go, C#, Java, OCaml, Haskell, Javascript, Python
— C reference counting: Swift
Для каждого языка написана полноценная реализация, проведены полноценные бенчмарки, для половины полностью описано, какая работа была проведена (thesis), для Java дополнительно проведено сравнение разных GC, для Rust'а описано сравнение с C. Проведена масса полезной для холиваров XvsY работы.
Как тут можно увидеть «нужно непременно заюзать в т.ч. шарп и жабу, тем хуже для кернел спейс», непонятно.
[1] Как популярные по количеству использования, так и популярные по количеству фапания на том же Hacker News.
Здравствуйте, Mamut, Вы писали: M>Авторы взяли...
Авторы провели экспериментальное исследование по типу "что будет если порш панамера и фольксваген пенсионерской комплектации начнут соревноваться друг с другом." Выяснилось, что в разгоне после светофора фв сливает по полной поршу, но поскольку в городе кроме них тоже есть люди, а за городом не везде можно давать 260км/ч, моща порша не всем нужна, и иногда достаточно пенсионерского фв. Такие исследования можно проводить и без гальванизации интернета репозиторияму и тезисами, просто открыв ТТХ обеих тачек и сравнивая их моментально прийти к правильному выводу. M>[1] Как популярные по количеству использования, так и популярные по количеству фапания на том же Hacker News.
О да, фапание на Hacker News однозначно прибавляет весу наукообразию данного эксперимента, выводя его на новый инновационный уровень. Один этот факт покрывает все потребности необходимой писанины о охрененной актуальности исследования.
Погладил себе ЧСВ? Молодец. Как показала практика, люди срравнивать ЯП не умеют, от слова совсем. А тут наглядный пример. Но, как оказалось, даже наглядный пример у некоторых вызывает неиллюзорную боль.
Здравствуйте, student__, Вы писали:
__>Здравствуйте, Mamut, Вы писали: M>>Авторы взяли... __>Авторы провели экспериментальное исследование по типу "что будет если порш панамера и фольксваген пенсионерской комплектации начнут соревноваться друг с другом." Выяснилось, что в разгоне после светофора фв сливает по полной поршу, но поскольку в городе кроме них тоже есть люди, а за городом не везде можно давать 260км/ч, моща порша не всем нужна, и иногда достаточно пенсионерского фв. Такие исследования можно проводить и без гальванизации интернета репозиторияму и тезисами, просто открыв ТТХ обеих тачек и сравнивая их моментально прийти к правильному выводу.
А где можно посмотреть TTX си шарпа, джавы и си ? Давай сравним без эксперименитов.
Здравствуйте, student__, Вы писали:
__>Здравствуйте, D. Mon, Вы писали: DM>>Не все, только 70%. Они считали статистику.
__>Ну хорошо пусть 70%, но все равно, вот жил себе индус, не тужил, фиксил по багу в день (условно), а с Растом хренак! — и будет только треть багов от предыдущего объема. И что, теперь индусу будут платить треть зарплаты?
Думаю ты недооцениваешь индусов из Микрософта. Ты не надейся, они там совсем не дураки, я думаю индусы быстро поймут, что к чему, почитают разные умные книжки и блоги, освоят новые методологии. Если необходимо, создадут новые идиомы, паттерны и парадигмы программирования специально под Раст. После освоения снова выйдут уже на Расте на нужное среднее соотношение багв на строчку кода, и все у них будет хорошо.
Здравствуйте, BlackEric, Вы писали:
BE>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
Получается, что надо: "Обновление гипервизоров Intel Cloud Hypervisor 0.3 и Amazon Firecracker 0.19, написанных на Rust."
Развивающая Firecracker компания Amazon также объявила об оказании спонсорской поддержки разработчиков языка программирования Rust. Отмечается, что Rust всё чаще используется в проектах компании и разработки на нём уже внедрены в таких службах, как Lambda, EC2 и S3. Amazon предоставил проекту Rust инфраструктуру для хранения выпусков и сборок в S3, запуска регрессивных тестов в EC2 и поддержания сайта docs.rs с документацией для всех пакетов из репозитория crates.io.
Здравствуйте, student__, Вы писали:
__>Авторы провели экспериментальное исследование по типу "что будет если порш панамера и фольксваген пенсионерской комплектации начнут соревноваться друг с другом." Выяснилось, что в разгоне после светофора фв сливает по полной поршу
Не, выяснилось что сливает только на очень длинных участках, а на светофорах разницы не обнаружено.
и т.п. Можно писать системный софт на разных языках(не только на расте).
Раст поставил во главу угла безопасность работы с памятью, но тот же ним дает разумную безопасность
и простоту программирования. Я за корректность работы программы, но не все же определяет низкоуровневые вещи, иногда нужно что-то еще — чистота кода, чтобы глаза не утоли в лесе синтаксических конструкций. Просто это язык за которым стоит крупная успешная организация.
BE>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
Надо просто быть открытым ко всему новому. А то у людей есть склонность закрываться(ой, зачем мне это? какая от этого выгода? мой сисярп достаточно хорош и т.д.). Попробуйте, быть может это станет для вас лебединой песней?
Здравствуйте, Nikita123, Вы писали:
N>По моему мнению, пока для этого Раста не будет нормальной IDE типа Visual Studio, он никуда не взлетит.
Плагин к идее недостаточно нормален?
Здравствуйте, DarkEld3r, Вы писали:
DE>Здравствуйте, Nikita123, Вы писали:
N>>По моему мнению, пока для этого Раста не будет нормальной IDE типа Visual Studio, он никуда не взлетит. DE>Плагин к идее недостаточно нормален?
Здравствуйте, kov_serg, Вы писали:
BE>>Получается пора его изучать, хотя бы для возможности читать исходники системного софта? _>Что стабильный бинарный интерфейс подвезли?
В С++ тоже нет (и похоже уже и не будет) стабильного и стандартного бинарного интерфейса,
а системный и около системный код на нем успешно пишут, и вполне си ABI обходятся, или
лепят свое, как тот же com в windows который там фактически уже везде.
Rust же си ABI не хуже чем С++ может поддерживать.
Ну и для того же com ms уже сделал минимальную поддержку https://github.com/microsoft/com-rs
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше.
Здравствуйте, varenikAA, Вы писали:
AA>nimkernel
AA>OS written in D
AA>и т.п. Можно писать системный софт на разных языках(не только на расте).
У D и Nim есть большой недостаток для таких применений — GC.
Он даже при написании всяких минимальных библиотек (с си ABI) уже мешает.
D пытается как-то из ситуации выйти со своим BetterC у нима ничего похожего не видел.
Так что из "новых" языков в эту нишу еще только Zig может претендовать.
AA>Раст поставил во главу угла безопасность работы с памятью, но тот же ним дает разумную безопасность AA>и простоту программирования. Я за корректность работы программы, но не все же определяет низкоуровневые вещи, иногда нужно что-то еще — чистота кода, чтобы глаза не утоли в лесе синтаксических конструкций. Просто это язык за которым стоит крупная успешная организация.
Nim вообще очень красивый и читабельный, но вряд-ли уже взлетит.
Здравствуйте, Somescout, Вы писали:
НС>>Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше. S>Это такая мантра? Ом мани падме вин?
Не, это наблюдаемый факт. Терри выпнули, департмент уменьшили.
Здравствуйте, kov_serg, Вы писали:
BE>>Получается пора его изучать, хотя бы для возможности читать исходники системного софта? _>Что стабильный бинарный интерфейс подвезли?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше. S>>Это такая мантра? Ом мани падме вин?
НС>Не, это наблюдаемый факт. Терри выпнули, департмент уменьшили.
И? Учитывая что они сняли с поддержки все версии, кроме десятки — вполне ожидаемо что стало меньше людей требоваться (относительно недавно, напоминаю, у них на поддержке находились одновременно Win7, Win8, Win8.1, XP и, кажется, Vista). А основной доход в любом случае всегда был не от десктопной винды.
Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, BlackEric, Вы писали:
BE>>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
N>Verona от Microsoft: N>
N>Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.
Я, наверное, чего-то не понимаю, но лучше бы они сделали нативный компилятор шарпа.
N>Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.
Ну да, все верно. Главная проблема Rust в том, что он сделан не в МС
N>>Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.
KP>Ну да, все верно. Главная проблема Rust в том, что он сделан не в МС
N>Компания Microsoft в рамках экспериментального проекта Verona развивает новый язык программирования, основанный на языке Rust и ориентированный на разработку защищённых приложений, не подверженных типовым проблемам с безопасностью. Исходные тексты текущих наработок, связанных с проектом, в ближайшее время планируется открыть под лицензией Apache 2.0.
Нихрена он не основан на Rust, у них только кое-какие идеи общие (но сильно отличаются). Жураналисты как обычно спешат все переврать.
the new project has nothing to do with Rust apart from being another memory-safe language based on advanced ownership model. In this case Microsoft is experimenting with a different ownership model that they think better reflects how people deal with data
Seriously, this is a terrible article. I listened to the talk they pulled all this from -- really interesting talk. But the article is filled with inaccuracies so bad they feel purposeful. Anyone who thinks this involves anything at all approaching a Rust fork really needs to listen to the talk (or even read the article at a bare minimum) before commenting.
The article claims MS is "creating a new Rust-based programming language." The speaker only mentions Rust a bare handful of times. Nowhere does he say anything about basing their project on Rust. In fact, he mentions Rust to contrast its ownership model with Verona's.
The article claims Mads Torgensen is "supporting the project." In the introduction, the speaker merely says "Mads has shared a few ideas with us about how to do language design."
The language itself has a completely different ownership model than Rust, like you quote. Verona's is based on what they're calling linear regions. It's more than "groups of objects." A program will be subdivided into a number of regions, each of which has only one entrypoint (hence the word 'linear'). Additionally, they are achieving memory safety by guaranteeing that no more than one thread can access a given region at any point in time.
But it goes beyond that. He talks about designating an unsafe C++ library as its own region, allowing you to completely sandbox legacy code.
Мне современный С++ напоминает старую проститутку которая решила снова выйти на панель и нанесла на себя все виды косметики которые только продавались.
Здравствуйте, BlackEric, Вы писали:
BE>Получается пора его изучать, хотя бы для возможности читать исходники системного софта?
Заинтересовался вопросом...
Почитал, поизучал, поставил компилятор, написал несколько тестовых примеров.
Потом еще раз почитал.
Вывод такой.
Для системного — очень даже может быть.
Но как замена C#, Java и тд — тупизм чистейшей воды.
С тем же примерно успехом можно на чистый С перейти.
А жаль, мне очень понравилось что идентификаторы пишутся так как я люблю — с "_" для разделения слов.
Здравствуйте, vl690001x2, Вы писали:
V>Но как замена C#, Java и тд — тупизм чистейшей воды. V>С тем же примерно успехом можно на чистый С перейти.
Я бы сказал, что трудности есть, но это не такая безумная идея, как кажется на первый взгляд. Мы примерно так Rust и используем.
Есть вещи, которые позволяют Rust быть более высокоуровневым, чем Java (более мощная система типов, макросы).
Разница с C -- небо и земля, не согласен с таким сравнением. Я бы даже сказал, с C++ нельзя сравнивать -- с C++ будет трудно и опасно писать промышленный код после, скажем, буткампа и 2х недель JavaScript или сразу после ВУЗа. А Rust -- можно (говорю с позиции опыта), хотя свои сложности, конечно, есть.
Здравствуйте, Иван Дубров, Вы писали:
ИД>Разница с C -- небо и земля, не согласен с таким сравнением. Я бы даже сказал, с C++ нельзя сравнивать -- с C++ будет трудно и опасно писать промышленный код после, скажем, буткампа и 2х недель JavaScript или сразу после ВУЗа. А Rust -- можно (говорю с позиции опыта), хотя свои сложности, конечно, есть.
С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться. Если уж совсем неофит, то можно и попроще инструменты брать типа Go, там даже самый тепой безопасен и оперативно профит приносит.
Здравствуйте, kaa.python, Вы писали:
KP>С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться. Если уж совсем неофит, то можно и попроще инструменты брать типа Go, там даже самый тепой безопасен и оперативно профит приносит.
Какого осознавать, что ты пишешь на бейсике? Скучно же.
Здравствуйте, Nuzhny, Вы писали:
N>Какого осознавать, что ты пишешь на бейсике? Скучно же.
Я этот этап давно прошел. Интересно — это сделать легко поддерживаемое, расширяемое решение в срок и с ожидаемым качеством. И вот в таком случае конкурентов у Go почти нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Микрософту винда то уже не особо нужна, особенно десктопная, и ее потихоньку задвигают. Так что чем меньше она будет жрать ресурсов, тем лучше.
Капец? Ну наконец-то!
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Nuzhny, Вы писали:
BE>>Я, наверное, чего-то не понимаю, но лучше бы они сделали нативный компилятор шарпа.
N>Сборка мусора для системного языка недопустима.
Вовсе нет. Идеально было бы, если можно было бы в критическом пути использовать некую специальную аллокацию, с ручным управлением памятью, а в остальных местах — GC. Ну скажи мне, зачем нужно ручное управление памятью при разборке конфигов, возне с SSL-сертификатами, управлении логами и т.п.? А это, между прочем, изрядный кусок кода. Собственно, доля кода, где GC вредит, будет в тепичном проекте — процентов 10-20.
Пайк, если кто не в курсе, из числа тех ребят, которые в интервале между вымиранием динозавров и вымиранием мамонтов сделали UNIX. Тогда все крутили пальцем у виска, и говорили, что нормальные люди пишут операционные системы на ассемблере, а ни как уж на Сях и прочих алголах-фортранах. На что авторы юникса отвечали, что Си, он по производительности и потреблению ресурсов практически, как ассемблер. И это было ложью, потому что сишнте компиляторы тех времен проигрывали ассемблеру раза в два.
Я к тому, что Пайк тот еще говорун. Его слова надо с осторожностью воспринимать. Но он очень хорош, как дизайнер языков программирования.
N>Какого осознавать, что ты пишешь на бейсике? Скучно же.
Здравствуйте, L.K., Вы писали:
LK>Как я понимаю, взлетает не Rust, а Verona.
LK>тынц
Там довольно интересный момент есть:
Как указывает ZDnet со ссылкой на Мэтта Миллера, специалиста Microsoft по безопасности, около 70% всех уязвимостей, которые были обнаружены в продуктах Microsoft в последние годы, были связаны с ошибками управления памятью.
Интересен он в первую очередь тем, что из этих 70% уязвимостей основная масса приходится на код-в-стиле-Си (массивы, управление памятью, форматирование и т.д.), который находится в файле с расширением cpp. Но да, конечно, тут C++ виноват
Здравствуйте, kaa.python, Вы писали:
KP>С C++ густо обвешанным санитайзерами сравнивать очень даже можно, та же хрень, по большому счету, но меньше с системой типов мудохаться.
Для меня вопрос стоит очень просто. По моему опыту, включая некоторый опыт C++, я бы не расчитывал, что команда начинающих разработчиков (под руководством более опытных) сможет на нём писать достаточно большую систему без внимательного анализа каждого изменения.
Доказать не могу, т.к такого опыта с C++ в масштабе у меня нет, просто такое ощущение. Я вроде как сам не дурак, но помню мои "эксперименты" с попыткой оседлать move семантику -- код, который выглядел, ну как любой другой код на C++, падал с какими-то ошибками. Ну чо-то там где-то не туда передвинул, наверное, может, случайно ссылку получил на объект на стеке вместо перемещения и вернулся из функции. Не знаю. Шаблоны были.
И дело не в том, что опытные товарищи там прям баги какие-то нашли бы (скорее всего, я чего-то глупое сделал, да), а в том, что в Rust покажешь направление -- менее опытные разработчики выкопают канаву -- и если она скомпилировалась, то и падать не будет (понятно, что бывают и переполнения стека и так далее).
А если взять библиотеки, которые cargo вытащит и соберет без всякий приседаний (CMake... уффф...), то вообще песня. Надо че-нить распараллелить, например, ускорить запуск? rayon, пара строк кода и система типов обеспечит правильную синхронизацию (ну или укажет, где сломается). CLI? clap+structopt, типизированные структуры из параметров командной строки. И так далее.
Много библиотек, конечно, не хватает ещё, например, вся "взрослая" XML инфраструктура отсутствует (XML Schema, XPath).
Здравствуйте, Иван Дубров, Вы писали:
ИД>Доказать не могу, т.к такого опыта с C++ в масштабе у меня нет, просто такое ощущение. Я вроде как сам не дурак, но помню мои "эксперименты" с попыткой оседлать move семантику -- код, который выглядел, ну как любой другой код на C++, падал с какими-то ошибками. Ну чо-то там где-то не туда передвинул, наверное, может, случайно ссылку получил на объект на стеке вместо перемещения и вернулся из функции. Не знаю. Шаблоны были.
Так на C++ можно писать без шаблонов и уж тем более move-семантики. Полагаю, что основная масса проектов так и сделана по сей день
ИД>И дело не в том, что опытные товарищи там прям баги какие-то нашли бы (скорее всего, я чего-то глупое сделал, да), а в том, что в Rust покажешь направление -- менее опытные разработчики выкопают канаву -- и если она скомпилировалась, то и падать не будет (понятно, что бывают и переполнения стека и так далее).
А при таком варианте реально встает вопрос – а зачем все эти приседания? Чем-то GC плох? Java/Go – ну ведь явно можно быстрее будет ту же систему написать, если нет необходимости удовлетворять компилятор.
ИД>А если взять библиотеки, которые cargo вытащит и соберет без всякий приседаний (CMake... уффф...), то вообще песня. Надо че-нить распараллелить, например, ускорить запуск? rayon, пара строк кода и система типов обеспечит правильную синхронизацию (ну или укажет, где сломается). CLI? clap+structopt, типизированные структуры из параметров командной строки. И так далее.
Да, тут я на 100% согласен – CMake это та еще адища.
ИД>Много библиотек, конечно, не хватает ещё, например, вся "взрослая" XML инфраструктура отсутствует (XML Schema, XPath).
Но ведь и нормальный манеджер пакетов и зрелый набор библиотек есть в Java/Go/C#. Это я к тому, что если уж говорить про Rust, то, наверное, для тех случаев когда каждая миллисекунда на счету, но описываемый случай явно не такой.
Здравствуйте, so5team, Вы писали:
S>Интересно, а можно где-то посмотреть на примеры простого, легко поддерживаемого и расширяемого кода на Go?
Ну, как ты понимаешь, показать код который был у нас я не могу, тут придется просто поверить на слово, что было проще, легче и понятнее чем в случае с C++... но вполне можно глянуть в какой-нибудь активный проект и, при желании, найти там как подтверждение моим словам, так и что-то не читабельное и сказать что я вру
Здравствуйте, kaa.python, Вы писали:
KP>Но ведь и нормальный манеджер пакетов и зрелый набор библиотек есть в Java/Go/C#. Это я к тому, что если уж говорить про Rust, то, наверное, для тех случаев когда каждая миллисекунда на счету, но описываемый случай явно не такой.
Да, если перевести разговор в русло "почему не Java/Go/C#", то у меня нет хорошего ответа. Я первое время за Java агитировал.
Мне кажется, что Rust нам позволит делать интересные штуки, но я слишком люблю Rust, чтобы адекватно оценивать . Посмотрим, как пойдёт.
Здравствуйте, kaa.python, Вы писали:
KP>Ну, как ты понимаешь, показать код который был у нас я не могу, тут придется просто поверить на слово, что было проще, легче и понятнее чем в случае с C++... но вполне можно глянуть в какой-нибудь активный проект и, при желании, найти там как подтверждение моим словам, так и что-то не читабельное и сказать что я вру
Так вопрос как раз в том, чтобы сразу погрузиться в код, который считается хорошим примером Go-шного кода, а не рыскать по непонятно чему.
Здравствуйте, so5team, Вы писали:
S>Так вопрос как раз в том, чтобы сразу погрузиться в код, который считается хорошим примером Go-шного кода, а не рыскать по непонятно чему.
Хорошо, самое просто – компилятор, само собой там своя специфика. Как-то я смотрел реализацию Raft в Etcd, на мой взгляд довольно хорошее качество у проекта в целом.
Здравствуйте, kaa.python, Вы писали:
S>>Так вопрос как раз в том, чтобы сразу погрузиться в код, который считается хорошим примером Go-шного кода, а не рыскать по непонятно чему.
KP>Как-то я смотрел реализацию Raft в Etcd, на мой взгляд довольно хорошее качество у проекта в целом.
Упс. Ошибочка. Приведенный в первой версии ответа пример оказался сгенерирован
Здравствуйте, so5team, Вы писали:
S>Упс. Ошибочка. Приведенный в первой версии ответа пример оказался сгенерирован
Да, это же Protobuf, он и для C++ кучу кода генерит. Но вообще, в Go очень много генерированного кода (я и сам генерил) так как, с одной стороны нет шаблонов, а с другой стороны поддержка построения и манипуляций с AST встроена в стандартную библиотеку, да и язык крайне простой, так что код генерировать очень просто.
А в целом-то как ощущения? Я по началу, после C++ очень плевался от Go, но сейчас мне скорее C++ кажется переусложенным (да еще и без каналов и зеленых потов, что вообще фи).
KP>А в целом-то как ощущения? Я по началу, после C++ очень плевался от Go, но сейчас мне скорее C++ кажется переусложенным (да еще и без каналов и зеленых потов, что вообще фи).
Смотря с чем сравнивать. Любой язык с GC и лаконичным синтаксисом будет восприниматься проще чем C++. Тут скорее другое интересует: в каких таких областях Go и C++ конкурируют? Если речь о том, что были тоны говнокода на "Си с классами" родом из 90-х, над которыми в течении многих лет надругались толпы "индусов" всех национальностей, и о качестве/производительности речи нет, тогда понятно в чем преимущество Go. Но если брать более нормальные условия?
Если же сравнивать с языками с GC, с каким-нибудь D, то вообще непонятно, в чем преимущества Go. Писать код вида:
func (c *Config) Clone() Config {
clone := func(m map[uint64]struct{}) map[uint64]struct{} {
if m == nil {
return nil
}
mm := make(map[uint64]struct{}, len(m))
for k := range m {
mm[k] = struct{}{}
}
return mm
}
return Config{
Voters: quorum.JointConfig{clone(c.Voters[0]), clone(c.Voters[1])},
Learners: clone(c.Learners),
LearnersNext: clone(c.LearnersNext),
}
}
можно на любом современном языке. И на каком-нибудь Rust-е это будет даже получше делать, т.к. там меньше проверок на nil нужно выполнять.
Здравствуйте, so5team, Вы писали:
S> Смотря с чем сравнивать. Любой язык с GC и лаконичным синтаксисом будет восприниматься проще чем C++. Тут скорее другое интересует: в каких таких областях Go и C++ конкурируют?
Мы на Go помимо бэкенда (где он ожидаем) написали кросплатформенный сервис и несколько утилит для командной строки. В принципе, это когда-то была зона ответственности C++
S> Если речь о том, что были тоны говнокода на "Си с классами" родом из 90-х, над которыми в течении многих лет надругались толпы "индусов" всех национальностей, и о качестве/производительности речи нет, тогда понятно в чем преимущество Go. Но если брать более нормальные условия?
Не только "индусов", а для обычного кода, который спокойно переживет ±1мс в вопросе производительности, но при этом хочется получить хорошую читабельность (Gо про "удобно читать", а не "удобно писать").
Здравствуйте, kaa.python, Вы писали:
KP>Мы на Go помимо бэкенда (где он ожидаем) написали кросплатформенный сервис и несколько утилит для командной строки. В принципе, это когда-то была зона ответственности C++
Это расплывчатые понятия, ибо такие вещи некоторые люди принципиально продолжают писать исключительно на чистом Си, а другие вполне себе успешно делают это на Perl/Python/Ruby уже несколько десятков лет как.
KP>Не только "индусов", а для обычного кода, который спокойно переживет ±1мс в вопросе производительности, но при этом хочется получить хорошую читабельность (Gо про "удобно читать", а не "удобно писать").
±1мс -- это для каких вещей? Перекодирования изображений или выполнения системных вызовов типа epoll/accept/read/write?
Ну и по читабельности хотелось бы таки увидеть примеры, на которых эта читабельность была бы видна. Пока что внимание привлекает только лаконичный синтаксис для получения слайса вектора, типа a[:n].
Здравствуйте, so5team, Вы
S>Это расплывчатые понятия, ибо такие вещи некоторые люди принципиально продолжают писать исключительно на чистом Си, а другие вполне себе успешно делают это на Perl/Python/Ruby уже несколько десятков лет как.
У нас было много логики включая встроенный Web-сервер. Да и как-то не очень идея ставить приложение в виде исходников на машину пользователя.
S>±1мс -- это для каких вещей? Перекодирования изображений или выполнения системных вызовов типа epoll/accept/read/write?
Мелкие тормоза из-за посредственного оптимизатора и пауз GC.
S>Ну и по читабельности хотелось бы таки увидеть примеры, на которых эта читабельность была бы видна. Пока что внимание привлекает только лаконичный синтаксис для получения слайса вектора, типа a[:n].
Ну, думаю что рассказывать о прелестях не-C++ заядлому C++-нику я дальше не буду. Пример простого и читабельного кода я привёл, можешь открыть сравнимое на C++ да сравнить. Всяко убедить не выйдет, пробовать надо.
Здравствуйте, kaa.python, Вы писали:
KP>У нас было много логики включая встроенный Web-сервер. Да и как-то не очень идея ставить приложение в виде исходников на машину пользователя.
Речь о другом: какие именно задачи решали эти утилиты командной строки? Преобразование форматов данных? Запрос информации через Web? Проверка каких-то параметров машины пользователя?
S>>±1мс -- это для каких вещей? Перекодирования изображений или выполнения системных вызовов типа epoll/accept/read/write?
KP>Мелкие тормоза из-за посредственного оптимизатора и пауз GC.
Но все-таки на каких именно задачах тестировалась производительность? У вас было перекодирование изображений, математические расчеты, обслуживание сетевых соединений?
KP>Пример простого и читабельного кода я привёл, можешь открыть сравнимое на C++ да сравнить.
Ну так как-то с примерами простого, расширяемого и поддерживаемого кода что-то пока не задается. Можно показать пальцем: вот, мол, здесь всего 10 строк, а на менее выразительном языке это бы потребовало больше усилий?
Здравствуйте, kaa.python, Вы писали: KP>Я этот этап давно прошел. Интересно — это сделать легко поддерживаемое, расширяемое решение в срок и с ожидаемым качеством. И вот в таком случае конкурентов у Go почти нет.
Оффтоп про Go — программист на Go ратует за дальнейшее упрощение языка: убрать else, против generic и т.д.
Здравствуйте, Nuzhny, Вы писали: N>Оффтоп про Go — программист на Go ратует за дальнейшее упрощение языка: убрать else, против generic и т.д. N>
Видео
N>
А в Го сообществе много странненьких. Я в Го слэках сижу (русский, английский), иногда волосы шевелятся от того бреда что они несут. Особенно в русском слэке
