How to become an author
Search
Write a publication
Pull to refresh

Comments 38

Не очень очевидный список. Visual Basic .NET — седьмой (выше JavaScript), и при этом за год поднялся на 6(!) позиций.
Objective С упал с 3 места на 14, но при этом Swift только 15. Не могли же все Apple разработчики пропасть куда-то.
Ну а Rust поздравляю и желаю дальнейших успехов.
Total votes 11: ↑10 and ↓1+9
Если я правильно понимаю, они просто считают сколько было поисковых запросов по языку.
This comment wasn’t rated yet0
То есть если в каком-то языке (назовем его RHR) все двусмысленно и не очевидно, молчаливые ошибки и возвращаемые нули вместо исключений и по нему много гуглят, а в другом языке (назовем его Crypton) все понятно, просто и выразительно, что даже гуглить приходится меньше, последний станет ниже в позициях?
Total votes 9: ↑9 and ↓0+9
Ваш пример хорошо иллюстрируется этим рейтингом:

image

Как видите, популярность Rust скорее «позитивная», чем «негативная».
Total votes 6: ↑6 and ↓0+6
А эти данные в csv, например, есть? Было бы интересно поковыряться. А то картинка тяжело глазами парсится.
Total votes 1: ↑1 and ↓0+1
Что-то тут странное. Больше всего удивили две вещи: отсутствие плюсов на графике и позиция Пролога (думал, на нём вообще почти ничего не пишут).
This comment wasn’t rated yet0
Плюсы наверху между css и питоном.
This comment wasn’t rated yet0
Ох, точно. Спасибо. Прямо слился, не рассмотреть.
This comment wasn’t rated yet0
Все равно непонятно, почему это VB.NET так вырос. Допустим, относительно высокий уровень можно объяснить наличием legacy. Но рост на 40% за 2015 год?
This comment wasn’t rated yet0
Не знаю, лучше ли он, но явно точнее отражает мои интуитивные догадки: Javascript высоко, VB падает, Go выше Rust, Swift быстро растет и т.д.
Total votes 3: ↑3 and ↓0+3
У меня когнитивный диссонанс, Rust руками Go атакует C++.
Total votes 1: ↑1 and ↓0+1
У меня когнитивный диссонанс, C++ использует printf.
Total votes 20: ↑20 and ↓0+20
Хм. Верное замечание. Сработала привычка — я не очень-то люблю std::cout с его перегруженными операторами.
Total votes 1: ↑0 and ↓1-1
Как вас при таких еретичных взглядах коллеги по языку ещё не придали анафеме?
Total votes 2: ↑2 and ↓0+2
Коллеги приветствовали и поддержали.

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

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

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

После года программирования на objective-C, я излечился от желания делать код короче и он сразу стал намного прозрачнее. С желанием всё оптимизировать бороться труднее, но тут помогают архитектурные подходы. Оптимизированный код можно изгнать в специальные резервации фрического кода и тогда с ним будет иметь дело лишь кучка избранных, а обычные программисты будут жить в неведении о таких тайнах, используя лишь няшный интерфейс.
Total votes 2: ↑1 and ↓10
Извините, у вас EXC_BAD_ACCESS отклеился.
Total votes 13: ↑13 and ↓0+13
Ну ржавчина начинает потихоньку проникать в мозги разработчиков C++, уже вовсю обсуждают введение lifetime'ов.
Total votes 1: ↑1 and ↓0+1
Неужели Go такой непопулярный, судя по этому рейтингу…
Total votes 2: ↑2 and ↓0+2
Да, это очень странно, что Go не попал а Rust попал
Total votes 2: ↑1 and ↓10
Так у него := как у паскалей! Если убрать это двоеточие, то язык ждёт успех. Мы недавно не сговариваясь, сидя удалённо решили использовать на новом проекте раст когда все помимо теоритических знаний о языке — посмотрели на синтаксис.
Total votes 6: ↑4 and ↓2+2
Да нет, просто у Роба Пайка нет бороды. Из троих создателей языка только у Кена Томпсона есть.
</irony>
Total votes 3: ↑3 and ↓0+3
Синтаксис очень на любителя, и видимо влияет ваш бекграунд языка с каким-то похожим синтаксисом.
Total votes 2: ↑1 and ↓10
Поддерживаю. После Python/D/C# не могу представить как можно заставить себя читать такой код. Лично мне из совсем новых языков куда больше Nim импонирует, который я еще недавно считал малоперспективным. Как по мне куда лучше чем Rust.
Total votes 2: ↑1 and ↓10
Если верить правилам оценки язык активно используется в реальной работе:
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++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
Total votes 21: ↑21 and ↓0+21
якобы у C++ скоро повиснет указатель
весёлая формулировка :)
А вообще отличный мини-обзор на опыт использования Rust получился, пишите ещё!
Total votes 5: ↑5 and ↓0+5
Тот момент, когда комментарий содержательнее статьи
Total votes 6: ↑6 and ↓0+6
Знание C++ вряд ли серьёзно поможет в изучении, скорее нужен хаскель со штангой.
Да ну, как по мне Rust достаточно далек от абстрактных материй Haskell, и мне в его освоении как раз помогло осознание того, как все это работает «на голом железе».

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

Ну вот к примеру, если в двух типажах есть один и тот же тип Output, как конфликт имен разрешить?
This comment wasn’t rated yet0
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 это не метапрограммирование, а обычный полиморфизм.
Total votes 1: ↑1 and ↓0+1
Это что-то вроде спецификации шаблонов в стиле Rust? Или в Rust есть обычные шаблоны?
This comment wasn’t rated yet0
Есть «обычные шаблоны» (насколько они там могут быть, учитывая что в 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>». Другими словами, вы можете написать шаблонную имплементацию сразу множества интерфейсов для множества структур, связанных каким-то условием.

А в моем комментарии выше вы увидели ассоциированные типы.
Total votes 3: ↑3 and ↓0+3
Ну вот к примеру, если в двух типажах есть один и тот же тип 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
Total votes 1: ↑1 and ↓0+1
Что интерестно, Rust вообще не скомпилирует код, если будет возможен конфликт:

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

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

rustc --explain E0xxx
Total votes 2: ↑2 and ↓0+2
Кстати, если бы в вашем примере типы Output были разные, Rust бы без труда вывел, какую именно из имплементаций ему использовать (если предположить, что у второго типа не будет реализован трейт Display).
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr