Rust
Comments 38
+9
Не очень очевидный список. Visual Basic .NET — седьмой (выше JavaScript), и при этом за год поднялся на 6(!) позиций.
Objective С упал с 3 места на 14, но при этом Swift только 15. Не могли же все Apple разработчики пропасть куда-то.
Ну а Rust поздравляю и желаю дальнейших успехов.
0
Если я правильно понимаю, они просто считают сколько было поисковых запросов по языку.
+9
То есть если в каком-то языке (назовем его RHR) все двусмысленно и не очевидно, молчаливые ошибки и возвращаемые нули вместо исключений и по нему много гуглят, а в другом языке (назовем его Crypton) все понятно, просто и выразительно, что даже гуглить приходится меньше, последний станет ниже в позициях?
+6
Ваш пример хорошо иллюстрируется этим рейтингом:

image

Как видите, популярность Rust скорее «позитивная», чем «негативная».
+1
А эти данные в csv, например, есть? Было бы интересно поковыряться. А то картинка тяжело глазами парсится.
0
Что-то тут странное. Больше всего удивили две вещи: отсутствие плюсов на графике и позиция Пролога (думал, на нём вообще почти ничего не пишут).
0
Все равно непонятно, почему это VB.NET так вырос. Допустим, относительно высокий уровень можно объяснить наличием legacy. Но рост на 40% за 2015 год?
+3
Не знаю, лучше ли он, но явно точнее отражает мои интуитивные догадки: Javascript высоко, VB падает, Go выше Rust, Swift быстро растет и т.д.
-1
Хм. Верное замечание. Сработала привычка — я не очень-то люблю std::cout с его перегруженными операторами.
+2
Как вас при таких еретичных взглядах коллеги по языку ещё не придали анафеме?
0
Коллеги приветствовали и поддержали.

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

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

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

После года программирования на objective-C, я излечился от желания делать код короче и он сразу стал намного прозрачнее. С желанием всё оптимизировать бороться труднее, но тут помогают архитектурные подходы. Оптимизированный код можно изгнать в специальные резервации фрического кода и тогда с ним будет иметь дело лишь кучка избранных, а обычные программисты будут жить в неведении о таких тайнах, используя лишь няшный интерфейс.
+1
Ну ржавчина начинает потихоньку проникать в мозги разработчиков C++, уже вовсю обсуждают введение lifetime'ов.
+2
Так у него := как у паскалей! Если убрать это двоеточие, то язык ждёт успех. Мы недавно не сговариваясь, сидя удалённо решили использовать на новом проекте раст когда все помимо теоритических знаний о языке — посмотрели на синтаксис.
0
Синтаксис очень на любителя, и видимо влияет ваш бекграунд языка с каким-то похожим синтаксисом.
0
Поддерживаю. После Python/D/C# не могу представить как можно заставить себя читать такой код. Лично мне из совсем новых языков куда больше Nim импонирует, который я еще недавно считал малоперспективным. Как по мне куда лучше чем Rust.
+21
Если верить правилам оценки язык активно используется в реальной работе:
The TIOBE Programming Community index is an indicator of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings. It is important to note that the TIOBE index is not about the best programming language or the language in which most lines of code have been written.

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

Но даже когда чего-то не хватает, я просто затягиваю форк и одной командой собираю тот же проект с бенчмарками, тестами. Это позволяет мне его «подпилить» и вернуть как PR назад на github. Это очень круто ускоряет разработку на языке, который по-сути системный.

Или когда я сталкивался отсутствием какого-то биндинга, я просто из голого Rust вызывал нужный мне нативный метод (требовался HDF5 и Lua, хотя их уже покрыли удобными обёртками). Не бывает, в принципе, такого, что библиотека с трудом собирается под Win. Как это бывает в том же Python. Переносимость просто отличная.

При этом компилятор очень хитромудрый, чувствую что пишу на OCaml, если программа скомпилировалась, она на 99% правильно работает. В этом, конечно, помогает монадная обработка ошибок, отсутствие исключений. Ошибки чисто технически нельзя оставить «на потом». Есть, конечно, unwrap, но на нём не уедешь, далеко, и почти сразу его приходится заменить на человеческий код.

В итоге, комфорт и удобство в работе вынуждают меня генерировать море рабочего кода, которым иногда удаётся поделиться, отправив PR. Язык просто лёг к рукам, хотя до этого я очень долго себя убеждал, что люблю сусликов и Go, наклеечки везде клеил…

Что касается убийцы всех и вся, и что якобы у C++ скоро повиснет указатель, то тут очень трудно что-то прогнозировать. Я люблю Rust больше, но по сути это OCaml, в который добавили фигурные скобочки, чтобы народ мог похоливарить. Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
+5
якобы у C++ скоро повиснет указатель
весёлая формулировка :)
А вообще отличный мини-обзор на опыт использования Rust получился, пишите ещё!
+6
Тот момент, когда комментарий содержательнее статьи
+1
Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
Да ну, как по мне Rust достаточно далек от абстрактных материй Haskell, и мне в его освоении как раз помогло осознание того, как все это работает «на голом железе».

Единственное, чем сильно мешал прошлый опыт C/C++, это тот факт, что &foo в Rust означает совсем не тоже самое, что в С/C++, хотя на первый взгляд как-будто одно и тоже.
0
Но у Раста пока чуть слабовато с метапрограммированием. Или я просто после плюсом не понимаю что делать.

Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?
+1
trait Trait1 {
    type Output;
}

trait Trait2 {
    type Output;
}

impl Trait1 for Foo {
   type Output = Bar;
}

impl Trait2 for Foo {
   type Output = Baz;
}

<Foo as Trait1>::Output // Bar
<Foo as Trait2>::Output // Baz


И в терминологии Rust это не метапрограммирование, а обычный полиморфизм.
0
Это что-то вроде спецификации шаблонов в стиле Rust? Или в Rust есть обычные шаблоны?
+3
Есть «обычные шаблоны» (насколько они там могут быть, учитывая что в Rust нет понятия класса):

// Полиморфная структура
struct Decorator<T> {
   item: T
}

// Полиморфный трейт
trait From<T> {
    fn from(x: T) -> Self;
}


С имплементациями все еще интересней, поскольку можно писать что-то вроде:

impl<T, U> Foo<U> for T where T: Bar<U> {
    ...
}


Что можно прочесть как «Для каждой пары типов T и U реализовать трейт Foo<U> для типа T, если тип T реализует трейт Bar<U>». Другими словами, вы можете написать шаблонную имплементацию сразу множества интерфейсов для множества структур, связанных каким-то условием.

А в моем комментарии выше вы увидели ассоциированные типы.
+1
Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?

Если правильно понял проблему, такие конфликты разрешаются через Universal Function Call Syntax.

Пример (положил в playground):
trait First {
    type Output;
    fn conflict(&self) -> Self::Output;
}

trait Second {
    type Output;
    fn conflict(&self) -> Self::Output;
}

struct Both;

impl First for Both {
    type Output = String;
    fn conflict(&self) -> Self::Output {
        "First<Output=String>".to_owned()
    }
}

impl Second for Both {
    type Output = String;
    fn conflict(&self) -> Self::Output {
        "Second<Output=String>".to_owned()
    }
}

fn main() {
    let its_both = Both;
    println!("{}", First::conflict(&its_both));
    println!("{}", Second::conflict(&its_both));
}

Внутренние типы в примере вполне могут быть разными. А если нужно узнать сам внутренний тип реализации, то так:

<Both as Second>::Output
+2
Что интерестно, Rust вообще не скомпилирует код, если будет возможен конфликт:

<anon>:29:29  error: multiple applicable items in scope [E0034]
<anon>:29     println!("{}", its_both.conflict());
                                      ^~~~~~~~~~

И сразу предложит почитать в чем суть ошибки и как ее избежать: E0034
+2
Всё верно. Для удобства компилятор даже носит подсказки с собой, их всегда можно посмотреть командой:

rustc --explain E0xxx
0
Кстати, если бы в вашем примере типы Output были разные, Rust бы без труда вывел, какую именно из имплементаций ему использовать (если предположить, что у второго типа не будет реализован трейт Display).
Only those users with full accounts are able to leave comments. , please.