LINUX.ORG.RU

Rust 1.26

 


5

11

Команда разработчиков языка Rust рада представить новую версию Rust 1.26.0. Rust — системный язык программирования, ориентированный на безопасность, скорость и параллельность.

Обновить Rust можно с помощью команды:

curl https://sh.rustup.rs -sSf | sh # если у вас еще не установлен rustup
rustup update stable

Основные изменения:

  • Вторая редакция книги «The Rust Programming Language» (почти) готова, и теперь рекомендована по умолчанию для ознакомления вместо первой версии. Также готовится к выходу бумажное издание книги.
  • impl Trait в заголовках функций

    Стало возможно указывать Trait в заголовке функции в качестве типа возвращаемого значения:

    fn foo() -> impl Iterator<Item = i32> {
        // ...
    }
    
    Это позволяет не указывать полный тип в заголовке функции, если с точки зрения API конкретный тип не имеет значения. Такой синтаксис подразумевает статическую диспетчеризацию, в отличие от Box<Trait>.

    Также эта возможность удобна для использования с замыканиями (closures):

    fn foo() -> impl Fn(i32) -> i32 {
        |x| x + 1
    }
    

    Новый синтаксис теперь можно использовать и для типов аргументов фунции:

    // раньше нужно было писать так:
    fn foo<T: Trait>(x: T) {
    
    // сейчас можно так:
    fn foo(x: impl Trait) {
    

  • Неявное разыменование ссылок в сопоставлении с образцом (match, if let, ...)

    Теперь следующий код больше не вызывает ошибку компиляции:

    fn hello(arg: &Option<String>) {
        match arg {
            Some(name) => println!("Hello {}!", name),
            None => println!("I don't know who you are."),
        }
    }
    
    и эквивалентен такому:
    fn hello(arg: &Option<String>) {
        match arg {
            &Some(ref name) => println!("Hello {}!", name),
            &None => println!("I don't know who you are."),
        }
    }
    
    То же работает и для &mut + ref mut.

  • Раскрытие срезов (slice) в сопоставлении с образцом
    fn foo(s: &[u8]) {
        match s {
            [a, b] => (),
            [1, _, _] => (),
            _ => (),
        }
    }
    
  • Закрытые интервалы вида 0..=4, включающие обе границы в диапазон перечисления
        for i in 0..=4 {
            println!("i: {}", i); // выведет 0, 1, 2, 3 и 4
        }
    
  • Новые целочисленные типы i128 и u128
  • Функция main() теперь может возвращать тип Result
    use std::fs::File;
    
    fn main() -> Result<(), std::io::Error> {
        let f = File::open("bar.txt")?;
    
        Ok(())
    }
    
  • Ускорения в работе компилятора
  • Стабилизирована функция std::fs::read_to_string
  • При форматировании через trait Debug теперь можно выводить целочисленные значения в шестнадцатеричном виде:
    assert!(format!("{:02x?}", b"Foo\0") == "[46, 6f, 6f, 00]")
    
  • Номер версии Cargo, начиная с этого релиза, изменяется синхронно с номером версии Rust

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: tailgunner (всего исправлений: 22)
Ответ на: комментарий от anonymous

У тебя мания величия?

гы-гы-гы

какое такое величие можно пытаться демонстрировать с помощью знания пхп, да еще и на уровне того примера, что я запостил?

а откуда инфа что mersinvald пхп-шник? судя про профилю, он эмбедом занимается

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

даже если и так, то, судя по твоему ответу, ты уже выпил недостающее для полного отрыва от реальности

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 4)
Ответ на: комментарий от www_linux_org_ru

а о яве с целью «за короткие срок REST API прицепить к какой-нибудь бизнес-ориентированной херне»; с виду тут фреймворки совсем не нужны

И давно вы на голой Java REST API делали, без сторонних фреймворков?

да и именно из-за checked exceptions тут ява сильно выигрывает — поди уследи за этими говнокодерами, че они там делают с кодами возврата,

Бы-гы-гы. Вы как будто в какой-то другой вселенной живете. В Go народ уже на автомате пишет в стиле:

r, err := openSomeResource()
if err != nil {
  return 0, err
}
И ничего хитрого там не выдумывают. В код уже упоминавшегося выше titus-executor-а загляните, там такое на каждом шагу. И, что важно, народу этот подход очень нравится. Даже Rust-оманам, поскольку они для облегчения работы с Result-ами у себя даже специальный синтаксис ? сделали. Это же ж не спроста, а потому, что для определенного контингента исключения — это слишком сложно и непредсказуемо.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

И давно вы на голой Java REST API делали, без сторонних фреймворков?

бесконечно давно (максимум пустого множества чисел — это минус бесконечность); но все же давай различать: одно дело класс, который надо тупо отнаследовать для создания веб-сервера c rest api, и совсем другое — фреймворк типа гибернейта

return 0, err

ну и как ты предлагаешь убедиться, на целом проекте, что они этот err точно проверяют, а не забыли проверить в 100500-м случае?

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 4)
Ответ на: комментарий от eao197

И, что важно, народу этот подход очень нравится. Даже Rust-оманам

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

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

но все же давай различать: одно дело класс, который надо тупо отнаследовать для создания веб-сервера c rest api, и совсем другое — фреймворк типа гибернейта

Насколько я наслышан, сейчас в Java подобные вещи (т.е. REST API) делаются буквально в несколько строчек посредством аннотаций (пример). Ничего особо наследовать не нужно. Но вот иметь представление о том, что такое аннотации и пр. требуха — желательно.

ну и как ты предлагаешь убедиться, на целом проекте, что они этот err точно проверяют, а не забыли проверить в 100500-м случае?

Во-первых, а разве для Go каких-то linter-ов нет, которые подобные вещи проверяют.

Во-вторых, как убедиться, что в Java проекте люди код в finally корректно реализуют и не преобразуют исключения в RuntimeException дабы удовлетворить механизму checked exception?

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

Во-первых, это вранье;

Это было бы враньем, если бы я не сталкивался с таким мнением. А оно имеет место быть: Go-феры не в восторге от написания подобных if-ов, но все равно говорят, что так им гораздо проще понимать код, чем с наличием исключений.

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

И в чем же принципиальная разница?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Насколько я наслышан, сейчас в Java подобные вещи (т.е. REST API) делаются буквально в несколько строчек посредством аннотаций (пример).

мы о чем говорим? о пороге вхождения в яву для бывшего (или нынешнего) студента и о знании фреймворков для успешной работы для него же

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

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 2)
Ответ на: комментарий от www_linux_org_ru

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

anonymous
()
Ответ на: комментарий от anonymous

не шучу (хотя конечно зарплата будет соответствующая)

более того, 2 сеньора, хорошо знающие фреймворки и пишущие свои — это как 2 медведя в 1 берлоге

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 4)
Ответ на: комментарий от eao197

И, что важно, народу этот подход очень нравится. Даже Rust-оманам

Во-первых, это вранье;

Это было бы враньем, если бы я не сталкивался с таким мнением.

Каким «таким»? Возврат двух значений и возврат значения ADT - это не одно и то же. В Rust никогда не было возврата двух значений, это не могло нравится растоманам.

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

И в чем же принципиальная разница?

Принципиальная - в том, что возвращается всегда одно значение. В Go - два и оба можно попытаться использовать. Но важнее техническая разница - в Rust возвращается настоящее значение со всем фаршем и поверх него можно строить вещи вроде https://docs.rs/error-chain/0.11.0/error_chain/ и https://docs.rs/failure/0.1.1/failure/

tailgunner ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

anonymous
()
Ответ на: комментарий от tailgunner

Каким «таким»?

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

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

eao197 ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

мы о чем говорим?

О пороге входа. В Java новичку нужно знать и сам язык (все эти class, extends, implements, static, final, private и пр.), и иметь представление о фреймворке.

Тогда как в Go кроме языка особо то и знать ничего не нужно.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

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

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Хватит шланговать. Релевантно оно будет если мы начнем обсуждать достоинства подхода Go и достоинства подхода Rust, в которых канонично сообщать об ошибках через возвращаемые значения.

А в обсуждении коды возврата vs исключения различия в подходах Go и Rust-а нерелевантны.

думаю, тебе понравится Go.

Не исключено, что о Go у меня более адекватные представления, чем у тебя.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

система информирования об ошибках на базе возвращаемых значений

1. должна обязательно быть

2. должна легко выбираться вместо системы на базе исключений

3. должна удобно сопрягаться с системой на базе исключений

но то, как это сделано в го, ничего, кроме фейспальма не вызывает

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от eao197

Хватит шланговать.

Так и не шлангуй.

Релевантно оно будет если мы начнем обсуждать достоинства подхода Go и достоинства подхода Rust

Я именно это и обсуждал.

Не исключено, что о Go у меня более адекватные представления, чем у тебя.

Наверняка. Мне Go перестал быть интересен сразу после того, как я прошел его туториал.

tailgunner ★★★★★
()
Ответ на: комментарий от eao197

Result ты по-любому протаскиваешь по стеку, либо делаешь явный unwrap, который громко вопиет. А из двух значений что-то может легко потеряться по дороге, можно вообще тихо и незаметно забить на ошибки. Хотя я в любом случае предпочел бы исключения всей этой ботве.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

но то, как это сделано в го, ничего, кроме фейспальма не вызывает

Это ваше личное мнение. Но востребованность Go говорит о том, что большому количеству народа Go-шный подход подошел на все 146%.

Тутошние критики Go забывают, что Go создавался как сугубо практический инструмент. Люди в Google посмотрели на то, что даже тщательно отобранные со всего мира разработчики косячат и срывают сроки при разработке на C++ и Java. Более того, масштабные разработки на этих языках даже в Google оказываются слишком сложными.

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

И это, нужно признать, сработало. Как в самом Google, так и за его пределами.

Так что можно тешить свое ЧСВ тем, что уж для нас-то, матерых, много чего повидавших, этот ваш Go говно и убожество, уж мы-то, вооруженные самыми последними достижениями... А для всех остальных Go оказался вполне себе нормальным инструментом в современных условиях и для современных задач.

eao197 ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

тупой студент на чистом го переплюнет по производительности и качеству кода сеньора на яве

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

anonymous
()
Ответ на: комментарий от eao197

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

Это всего лишь компромисс, на который нас вынуждает идти жизнь. Но компромисс - он на то и компромисс, чтобы быть оптимальным только при определенных условиях. Все идет к тому, если уже не пришло, что в разных ситуациях будут применяться разные языки. У меня есть проекты где без метапрограммирования просто никуда. И Го тут в пролете. Но это не значит, что Го - отстой. Просто он мне не подходит. Ну и Раст туда не подходит тоже, кстати. По другой причине правда.

anonymous
()
Ответ на: комментарий от tailgunner

Я именно это и обсуждал.

А я нет.

Если ты хочешь мое мнение именно по этой проблеме, то я бы предпочел иметь в Go аналог Rust-овского Result-а, из которого можно было бы взять либо одно, либо другое.

Но не могу не отметить две вещи, которые в Go несколько снижают актуальность данной проблемы.

Во-первых, рекомендованный стиль написания кода. Когда все и всегда пишут именно так:

r, err := ...
if err != nil {
  return ...
}
то получается почти такой же эффект, как в Rust-е с match-ем или if let. Т.е. в 99% случаев ошибку не игнорируют.

Во-вторых, Go - это язык таки со сборкой мусора. Поэтому там в качестве err ты можешь возвратить указатель на какой-то объект с достаточной информацией об ошибке. А потом этот указатель поместить в другой объект. И т.д. В этом плане в Go нет нужды иметь обобщенный тип Result<T, E>, тем более в вариациях Result<T, Box<E>>.

Так что подход Rust-а более удобный для меня лично, но в Go ситуация не так плоха на практике, как это кажется со стороны.

eao197 ★★★★★
()
Ответ на: комментарий от eao197

И это, нужно признать, сработало. Как в самом Google, так и за его пределами.

не вижу ничего сработавшего *с точки зрения корпораций*, кроме может быть большого количества знающих го (и возможно библиотек), что обесценивается низким качеством этого языка

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

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

неа

по той причине, что этих достижений в общем-то и нет, разве что вот https://www.fstar-lang.org/ но я его еще не изучил с точки зрения «как управлять говнокодерами»

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

не вижу ничего сработавшего *с точки зрения корпораций*, кроме может быть большого количества знающих го (и возможно библиотек), что обесценивается низким качеством этого языка

Боюсь, что здесь как в ДМБ: «ты суслика видишь?»...

а вот ява действительно позволяет 1 сеньору

Так ведь сеньоры эти нарасхват, да и стоят недешево.

Потому и появляются инструменты, которые требуют гораздо более низкую квалификацию.

eao197 ★★★★★
()
Ответ на: комментарий от tailgunner

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

anonymous
()
Ответ на: комментарий от www_linux_org_ru

Профиль старый, но к вебне я действительно отношения совсем не имею)

А у анона манямирок «где НИКТО не импользует шаблонизаторы»

mersinvald ★★★★★
()
Ответ на: комментарий от eao197

Checked Exceptions это как раз легко и предсказуемо)

Проблема в том что в чистом виде их толком нигде нет: в C++ вообще нет (или уже есть?), в Java может и unchecked непойми откуда прилететь.

В питоне всё еще хуже

mersinvald ★★★★★
()
Ответ на: комментарий от mersinvald

Checked Exceptions это

не взлетевшая нигде больше хрень, которая засирает мозги и отвлекает от работы, провоцируя различные нехорошие вещи в коде (например, «проглатывание» исключений). А для обобщенного программирования так еще и вредная. Не зря же от них отказались во всех вменяемых языках для JVM (Scala, Gosu, Ceylon, Kotlin).

eao197 ★★★★★
()
Ответ на: комментарий от eao197

не взлетевшая нигде больше хрень

Увы

которая засирает мозги и отвлекает от работы

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

провоцируя различные нехорошие вещи в коде (например, «проглатывание» исключений)

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

А для обобщенного программирования так еще и вредная

Недостаток конкретной реализации, возможность параметризовать checked exception решила бы эту проблему

mersinvald ★★★★★
()
Последнее исправление: mersinvald (всего исправлений: 1)
Ответ на: комментарий от www_linux_org_ru

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

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

DRVTiny ★★★★★
()

Кто-нибудь подскажет, с точки зрения практической пользы Rust позволяет ли не создавать примитивы синхронизации для общего доступа потоков к данным, разруливая такой доступ чудесным образом на этапе компиляции? Ну или хотя бы автоматически создавая связанные с обобщёнными переменными примитивы синхронизации (mutexes, semaphores) ? Вообще за счёт чего там прирост производительности должен наблюдаться, помимо отсутствия сборщика мусора? (тот же Crystal со сборщиком мусора работает в одном потоке даже побыстрее чуток).

DRVTiny ★★★★★
()
Ответ на: комментарий от DRVTiny

тот же Crystal со сборщиком мусора работает в одном потоке даже побыстрее чуток

Даже быстрее Сишки, даже асма. Инфа 146%.

RazrFalcon ★★★★★
()
Ответ на: комментарий от DRVTiny

Rust позволяет ли не создавать примитивы синхронизации для общего доступа потоков к данным, разруливая такой доступ чудесным образом на этапе компиляции?

Нет.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

anonymous
()
Ответ на: комментарий от DRVTiny

Вообще за счёт чего там прирост производительности должен наблюдаться, помимо отсутствия сборщика мусора?

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

anonymous
()
Ответ на: комментарий от anonymous

При одинаковом количестве человеко-часов на разработку, на Расте не придётся печально отлавливать...

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

З.Ы. чуток утрировал конечно, но суть вы должны уловить))

anonymous
()
Ответ на: комментарий от anonymous

а) Корректный код на Раст - это примерно то же самое, что описано, в частности, в гайдлайнах по современному С++ и best practices в целом, только еще и компилятор следит за их исполнением. б) Написание кода - это даже не четверть времени при разработке софта. Если код писать на 25% сложнее, но на 25% же процентов проще искать тупые ошибки, то уже есть выигрыш. в) «Поиск глобального экстренума» - это конкретный алгоритм, который и будет целью для оптимизации, скорее всего на каком-нибудь ассемблере или вообще GPU. А если у тебя программа состоит из одного алгоритма,то, скорее всего, тебя и скорость колыхать не будет и проще запилить говноскрипт на Питоне.

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

А как это выяснить, если мы не знаем, что то, что мы написали, вообще делает то, что задумывалось, до полного тестирования?

anonymous
()
Ответ на: комментарий от AntonyRF

О лайфтаймах перестаёшь думать на второй месяц использования Rust, так что твой аргумент, не аргумент.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Ты действующий программист на Rust?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Прямая аналогия, правильно? Но однако народ все равно предпочитает автомат.

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

bread
()
Ответ на: комментарий от tailgunner

Ты действующий программист на Rust?

На самом деле - правильный вопрос. И нет, я не действующий программист на Расте. Но как это меняет суть? Если бы я был действующий программист, я бы не думал о требованиях языка? Но я действующий программист в целом и я озвучиваю реальную проблему с которой сталкиваюсь - язык должен позволять выражать решаемую задачу как можно проще. И не требовать от меня знать каких-то особенностей реализации. Питон взлетел именно поэтому. Т.о (ИМХО, конечно же) Раст будет эффективен там, где решаемая задача близка к самому языку, т.е. на низком уровне - переписать какую-нить криптолибу например. Это нишевый язык и в своей нише он блистает.

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

anonymous
()
Ответ на: комментарий от bread

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

Правильно. Для всего есть свой оптимальный инструмент. И Раст тоже оптимален для определенного круга задач. А для других задач - не подходит от слова совсем. Не будет больше в этом мире универсального языка для всего.

anonymous
()
Ответ на: комментарий от anonymous

И нет, я не действующий программист на Расте. Но как это меняет суть?

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

Раст будет эффективен там, где решаемая задача близка к самому языку, т.е. на низком уровне

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Так я же и пишу - ИМХО.

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

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

На мой взгляд Раст близок к идеалу для криптобиблиотек а-ля ssl. Не помню уже деталей, но я где-то в рассылке видел жалобы людей на то, что одна из реализаций openssl (могу ошибиться, но не суть) - полный отстой, она сложна как в использовании, так и в поддержке, но эти же люди пишут, что браться за ее переписывание очень сложная задача так как либа уже отлажена кровью и потом и работает, а отлаживать новую либу будет очень дорого во всех смыслах. И здесь гарантии языка, которые дает Раст (имхо) снижают стоимость разработки, потому что ошибки криворуких разработчиков будут сведены к минимуму и остануться только ошибки разработчиков криптоалгоритмов. Вот здесь платить высоким порогом входа, временем компиляции и прочим более чем разумно.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.