LINUX.ORG.RU

Rust 1.18

 


1

10

Команда Rust анонсирует релиз 1.18.

Обновление предыдущей версии легко:

$ rustup update stable

Сам rustup можно установить здесь.

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

Одно из главных изменений - новая версия «The Rust Programming Language», официального учебника по Rust. Он пишется открыто на Github, и имеет более ста авторов. В этом релизе включен черновик второй версии книги, имеющий 19 из 20 глав; двадцатая глава будет готова к релизу 1.19. Купить бумажную версию можно через No Starch Press. Новая версия книги полностью переписана и учитывает последние два года нашего опыта обучения Rust. Вы найдете новые объяснения основных принципов Rust, новые проекты и прочее.

В самом языке улучшено ключевое слово pub. По умолчанию, в Rust объекты приватны; можно использовать pub чтобы сделать их публичными. В Rust 1.18, pub имеет новый вариант:

pub(crate) bar;

Слово в скобках - ограничение, контролирующее степень публичности объекта. Если указанно pub(crate), то bar будет публичным для всего крейта (пакета), но не вне него. Это позволяет декларировать интерфейсы, «внутренне публичные» для пакета, но не доступные для внешних пользователей.

Также можно указать путь, например:

pub(in a::b::c) foo;

Это значит «доступно в иерархии a::b::c, но не в прочих местах».

Для пользователей Windows Rust 1.18 имеет новый атрибут, #![windows_subsystem]. Он работает так:

#![windows_subsystem(console)]
#![windows_subsystem(windows)]

Он контролирует флаг /SUBSYSTEM в компоновщике. На текущий момент доступны только console и windows. Если вы разрабатываете графическое приложение, и не указываете windows, в момент пуска программы всплывет окно консоли. С атрибутом windows этого не произойдет.

Далее, в Rust кортежи, варианты перечисляемых типов и структуры (без атрибута #[repr]) всегда имели неопределенное расположение в памяти. Мы включили автоматическое упорядочивание, которое может привести к уменьшению потребления памяти путем уменьшения необходимого выравнивания. Например:

struct Suboptimal(u8, u16, u8);

В прежних версиях Rust на платформе x86_64 эта структура имела бы размер в шесть байтов. Но согласно исходному коду, ей достаточно должно быть четырех. Остальные два байта - результат выравнивания. Поскольку мы имеем u16, он требует двух байтов. Но в данном случае, он был смещен на один байт из-за предыдущего u8. Для последнего же u8 требуется еще один байт выравнивая. В итоге, мы имеем 1 + 1 (пусто) + 2 + 1 + 1 (пусто) = 6 байтов.

Но что если структура выглядит так?

struct Optimal(u8, u8, u16);

Эта структура оптимально выравнена; u16 находится на рубеже двух байтов, как и остальная структура. Выравнивание не требуется. Это дает нам 1 + 1 + 2 = 4 байта.

При дизайне Rust мы оставили физическое расположение данных в памяти неопределенным как-раз по этой причине; любой safe-код (не следующий по «сырым» указателям) не будет затронут подобной оптимизацией. Благодаря этому, мы можем научить компилятор оптимизировать Suboptimal в Optimal автоматически. В Rust 1.18 обе структуры занимают в памяти размер в четыре байта.

Мы долго планировали это изменение; оно было и ранее в нестабильной версии Rust, но некоторые программисты писали unsafe-код, который предполагал определенное расположение данных в памяти. Если вам необходима гарантия, что физическое расположение в памяти в точности совпадает с расположением вариантов в исходном коде (например, при обращению к оболочкам Cи-кода), пометьте вашу структуру с атрибутом #[repr(C)].

Напоследок, улучшено время компиляции; например, компиляция самого rustc теперь на 15%-20% быстрее.

Стабилизированы следующие библиотеки:

  • Child::try_wait, неблокирующая форма Child::wait.
  • HashMap::retain и HashSet::retain - версия существующего retain от Vec<T> теперь и у этих двух структур.
  • PeekMut::pop позволяет взять ранее прочитанный верхний элемент от BinaryHeap<T> без необходимости повторно упорядочивать кучу.
  • TcpStream::peek, UdpSocket::peek, UdpSocket::peek_from позволяют прочесть крайний элемент у потока или сокета.

Новый функционал Cargo

Cargo добавил поддержку системы управления версиями Pijul, который написан на Rust:

cargo new my-awesome-project --vcs=pijul

У Cargo несколько новых флагов, дополняющих --all: --bins, --examples, --tests и --benches позволяют собрать все программы указанных типов.

И наконец, Cargo теперь поддерживает Haiku и Android.

Подробнее об изменениях написано здесь.

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



Проверено: Shaman007 ()
Последнее исправление: cetjs2 (всего исправлений: 7)
Ответ на: комментарий от eao197

Это избыточная запись, можно просто написать так:

struct Point {
    x: f64, 
    y: f64
}

fn get_x(p: &Point) -> &f64 { 
   &p.x 
}

Отступы и индентация кстати тоже решают проблему с читаемостью, rustfmt бы это исправил.
Если это пример реального кода с GH, дайте ссылку, я товарищу PR зашлю.

Я согласен что код читать сложнее чем на, например, Go, где синтаксис очень простой, но там и прочитать надо будет намного больше текста.

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

Если это пример реального кода с GH, дайте ссылку, я товарищу PR зашлю.

Это пример из документации: https://doc.rust-lang.org/0.12.0/guide-lifetimes.html

Я согласен что код читать сложнее чем на, например, Go, где синтаксис очень простой

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

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

Это пример из документации

Версии 0.12? Вот текущая: https://doc.rust-lang.org/nomicon/lifetimes.html

Ну, в Go тоже любители лаконичной записи

Ну у него тоже все не просто, даже несмотря на примитивность языка. К примеру:

func (l *List) insertValue(v interface{}, at *Element) *Element {
Я вообще хз, что тут происходит.

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

Версии 0.12? Вот текущая: https://doc.rust-lang.org/nomicon/lifetimes.html

Полагаю, в документации к версии 0.12 мне нагло соврали? А в новой-то лепота и благолепие:

'a: {
    let mut data: Vec<i32> = vec![1, 2, 3];
    'b: {
        // 'b is as big as we need this borrow to be
        // (just need to get to `println!`)
        let x: &'b i32 = Index::index::<'b>(&'b data, 0);
        'c: {
            // Temporary scope because we don't need the
            // &mut to last any longer.
            Vec::push(&'c mut data, 4);
        }
        println!("{}", x);
    }
}

Я вообще хз, что тут происходит.

Странно, про синдром утенка у других вам это не мешает говорить.

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

А в новой-то лепота и благолепие:

Это искусственный пример. Такой код не соберётся.

Странно, про синдром утенка у других вам это не мешает говорить.

Каким боком вы это тут увидели? Я о том, что не зная языка - все новые конструкции будут непонятны. И rust тут не исключение.

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

Вы хоть читайте что написано прежде чем куски невалидного кода выдергивать

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

Полагаю, в документации к версии 0.12 мне нагло соврали? А в новой-то лепота и благолепие

Это пример неработающего кода с подробными объяснениями, почему он не работает, и полным desugaring'ом. В настоящем коде это выглядело бы так (и всё равно бы не работало):

let mut data = vec![1, 2, 3];
let x = data[0];
data.push(4);
println!("{}", x);
anonymous
()
Ответ на: комментарий от anonymous

Там

let mut data = vec![1, 2, 3];
let x = &data[0];
data.push(4);
println!("{}", x);

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

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

Это искусственный пример. Такой код не соберётся.

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

Ну, давайте еще один пример из документации:

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
Количество одно-двух-трехсимвольных значимых символов вам кажется нормальным?

Каким боком вы это тут увидели?

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

Я о том, что не зная языка - все новые конструкции будут непонятны. И rust тут не исключение.

Спасибо, Кэп. Объясните мне пожалуйста, почему знакомясь с Go, Ceylon, Kotlin, Eiffel и пр. языками, после беглого знакомства с описанием языка, код на этих языках оказывается вполне себе понятным и читабельным, а вот при чтении Rust-а приходится запинаться на каждом апострофе?

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

Объясните мне пожалуйста, почему знакомясь с Go, Ceylon, Kotlin, Eiffel и пр. языками

Потому что это языки с GC. Ваш Кэп.

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {

Ок, предложи твой синтаксис для этой строчки

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

Тем не менее, такой пример дают тем, кто изучает Rust для того

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

Количество одно-двух-трехсимвольных значимых символов вам кажется нормальным?

Не имею никаких претензий. В других языках тоже полно коротких ключевых слов. Даже в вашем любимом C++: int, char, struct, decltype.

код на этих языках оказывается вполне себе понятным и читабельным

Я уже 10 раз сказал - это языки с GC. Им нет необходимости указывать время жизни объекта. Или ваш кругозор не позволяет до этого догадаться?

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

Потому что это языки с GC. Ваш Кэп.

Блин, ну возьмите древнюю Ada, Object Pascal/Delphi, современный Swift. Языки без GC.

Ок, предложи твой синтаксис для этой строчки

Это ничего не изменит.

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

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

при чтении Rust-а приходится запинаться на каждом апострофе

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

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

Не понятно другое

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

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

Swift. Языки без GC

там ARC гвоздями прибит, и Swift - не системный язык, если тебе нужен перфоманс на iOs/OSX ты пишешь на плюсах или си, такие дела да

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

Даже в вашем любимом C++: int, char, struct, decltype.

С тех пор, как популярность C превысила популярность наследников Algol-а, int, char и struct стали де-факто стандартами, потеснив integer, character и record.

Но нашлись те, кто решил, что int32_t — это слишком длинно, поэтому нужно i32.

Или ваш кругозор не позволяет до этого догадаться?

Мой кругозор не в курсе границ вашего скудоумия. Давайте добавим к списку такие языки без GC, как Ada, Object Pascal и новый Swift. В Swift-е закорючек тоже хватает, но там это как-то вменяемо умудрились сделать.

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

В Swift есть GC. Своеобразный, но GC. Заботится о памяти там не нужно.

В паскале вообще глобальные переменные и нет указателей и ссылок (насколько я помню).

почему, когда кто-то говорит, что ему не нравится в Rust-е и что ему мешает в Rust-е, так сразу же Rust-оманы как с цепи срываются?

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

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

В паскале вообще глобальные переменные и нет указателей и ссылок (насколько я помню).

Вы бы это, поосторожнее с демонстрацией своих познаний вне мира Rust-а. А то у вас то исключения из конструкторов в C++ оставляют объект наполовину инициализированным, то указателей в Pascal нет.

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

Я последний раз на паскале в универе писал. Могу ошибаться, о чём и упомянул.

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

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

При беглом просмотре кода хорошо было бы более четко видеть границы функций. fn этому не сильно помогает.

При внимательном прочтении кода выясняется, что куча одно-двух буквенных вещей имеют важное значение. Например, &'a или &mut вместо &.

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

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

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

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

Ну назовите какой-нибудь современный системный или околосистемный язык. А то вспомнается только какая-то древность, вроде Ada, Pascal и Modula-2, в которых читабельность все равно была повыше.

Да и разве ниша системного программирования обрекает язык на уродский синтаксис?

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

При беглом просмотре кода хорошо было бы более четко видеть границы функций.

Не выдумывайте. Никому не мешает, а Вам мешает. Может сначала стоит выучить Rust хотя бы на базовом уровне, прежде чем читать код?
Да и какой сакральный смысл читать код на незнакомом языке?

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

Ваше мнение давно «понятно и не интересно».

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

Никому не мешает, а Вам мешает.

Ну вы поспрашивайте, всем ли нравится синтаксис Rust-а, может я не один такой.

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

Допустим учу, заглядываю в реальный код на Rust-е, чтобы набраться опыта и https://github.com/mersinvald/backontime/blob/master/src/backup_entity.rs#L68

|| -> Result<()> {
вижу очередное доказательство неплохой такой плотности спецсимволов на строку.

Понятно, что привыкнуть к этому можно. Понятно так же, что в процессе привыкания нужно будет приспособиться к тому, что значат || в произвольном месте текста. Что значат <()> и т.д.

Может у вас процесс привыкания был быст, но так не обязательно должно быть у всех.

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

Вы удивительный человек, выкопали самый страшный костыль в прототипном коде :)
Спасибо что напомнили, надо это убрать нафиг, когда do-нотация приземлится.

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

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

Что значат <()>

() — пустой тип, пример ZST как раз, здесь используется потому что в Result не должны возвращаться данные, только ошибка.

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

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

Я согласен что код читать сложнее чем на, например, Go, где синтаксис очень простой, но там и прочитать надо будет намного больше текста.

Ну так Go до параметрического полиморфизма и не дорос.

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

Ну назовите какой-нибудь современный системный или околосистемный язык.

из «современных» только Rust и есть, все что выходило недавно не является системными языками уж явно

Да и разве ниша системного программирования обрекает язык на уродский синтаксис?

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

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

Понятно, что мое мнение ничего не меняет, но все-таки не понятно, например, почему:

- люди отказались от уже устоявшихся к 2010-му году имен типов int32, uint32, int64, uint64 и т.д.;

- выбрали fn вместо func или function, равно как pub вместо public;

- используют mut вместо mutable;

- имеют & и ref;

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

Повторюсь, это уже ничего не меняет. Но осадочек...

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

- имеют & и ref;

Они для разного предназначены. При паттерн-матчинге & и ref дают разный результат.

Еще забыли Vec, &str, #[cfg()], mod, Err, impl.

С другой стороны это сильно растянет текст по ширине:

pub fn add_two(a: &mut i32) -> i32 {
// vs
public function add_two(a: mutable reference int32) -> int32 {

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

выбрали fn вместо func или function, равно как pub вместо public

первое - от ФуНах, второе - призыв вПаб.

используют mut вместо mutable

от mutt - собака. вероятно женского пола

остальное лень придумывать

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

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

Сделали мой вечер. Вам нужна подсказка, как закрыть вкладку с обсуждением и не тратить время? ;-) Или силы воли не хватает?

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

Но нашлись те, кто решил, что int32_t — это слишком длинно, поэтому нужно i32.

Ну вообще это действительно длинно. Суффикс _t вообще в новом языке смысла не имеет, да и в С я не совсем понимаю, зачем нужен. Почему i32, а не int32? Ну во-первых к C претензий нет, ведь, что там int, а не integer, например, т.е. 3 буквы это вполне себе читабельно, во-вторых int32/uint32 смотрится уже не так красиво, как i32/u32 (длина не одинаковая). По-моему вполне разумное решение, если бы я над этим вопросом думал, скорее всего я бы пришёл к таким же наименованиям. Можно, конечно, и подлинней сделать, может оно и лучше было бы. Всё же мне кажется, что при чтении и небольшом опыте все эти лайфтаймы будут просто отфильтровываться, всё же на логику они не влияют и интересовать они могут редко. Синтаксис у них достаточно выделяющийся, чтобы отфильтровывать его на автомате.

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

Ну вот в .NET-е используются Int32 и UInt32. И привычно (легко узнается на базе C-шного опыта), и нет унаследованного из C суффикса.

По поводу i32. Вам, наверное, мало приходилось видеть кода от хардкорных математиков. Когда они реализуют сложные вычисления, там полно i, ii, j, jj, kk, i1, i4, i12, j24, k30 и тому подобных имен переменных. Причем, что интересно, далеко не всегда такие названия можно заменить на что-то осмысленное.

В общем, к чему я это: есть «правило наименьшего удивления» (least surprise principle), которое разработчиками Rust-а было нарушено при выборе имен вида i32/u32.

int32/uint32 смотрится уже не так красиво, как i32/u32 (длина не одинаковая)

Зачем вам одинаковая длина для имен типов? Практический смысл в этом какой?

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

По поводу i32. Вам, наверное, мало приходилось видеть кода от хардкорных математиков. Когда они реализуют сложные вычисления, там полно i, ii, j, jj, kk, i1, i4, i12, j24, k30 и тому подобных имен переменных.

Нахрен они мне в моём раст-коммунити? Пускай дальше говнокодят на матлабе.

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

Зачем вам одинаковая длина для имен типов? Практический смысл в этом какой?

Симметрия, минимализм.

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

вижу очередное доказательство неплохой такой плотности спецсимволов на строку.

|| -> Result<()> {

Элементарно Ватсон, в самой первой книжке о синтаксисе говориться, что

  • || - это замыкание
  • -> - эти знаки указывают, что замыкание возвращает следующее значение
  • Result<()> - это Enum включающий в себя обобщённый тип

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

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

В общем, к чему я это: есть «правило наименьшего удивления» (least surprise principle), которое разработчиками Rust-а было нарушено при выборе имен вида i32/u32.

Как-то натянуто получается. i32/u32 - это то, что используется всегда, после прочтения 2х хелллоуворлдов новичок уже знает значение этих слов. Да и без объяснения, догадаться что есть i32 несложно. Наименьшее удивление - это когда ты вроде уже всё знаешь, а потом в каком-нибудь малоизвестном случае действуешь в соответствии с привычкой и получаешь что-то сильно нелогичное.

i32 - это как до современных потомков плюсов докопаться, что у них массив не int array[], а int[] array.

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

Во-первых, я понимаю, как это работает. Блого, раст не первый язык с лямбдами.

Во-вторых, не вижу как ваше пояснение отменяет факт высокой плотности спецсимволов на строку кода.

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

- люди отказались от уже устоявшихся к 2010-му году имен типов int32, uint32, int64, uint64 и т.д.;

А в LLVM числа тоже имеют наименование i32, u32 и т.д. Это тоже устоявшиеся значения и что теперь?

- выбрали fn вместо func или function, равно как pub вместо public;

Это совсем субъективно, мне нравиться fn и pub и вообще не понимаю зачем полные и длинные имена нужны?

- используют mut вместо mutable;

ЗАЧЕМ?! Просто представьте какой ужас станет с кодом

 public function backup(&mutable self, path: &mutable String) -> Result<()> {
Вот уж точно ужас, два параметра на половину экрана, другое дело:
 pub fn backup(&mut self, path: &mut String) -> Result<()> {
Очевидно, что второй вариант легче читается и уж точно быстрее написать

- имеют & и ref;

Ну тут хрен знает, может кто-то подскажет?

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

Не вижу ни чего плохо

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

Во-вторых, не вижу как ваше пояснение отменяет факт высокой плотности спецсимволов на строку кода.

Это субъективное восприятие, мне, например, после прочтения документации не вызывало жжения от синтаксиса. Если для Вас понимание оного не меняет его восприятия, то думаю, что ни кто Вам не поможет ¯\_(ツ)_/¯

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

Это субъективное восприятие, мне, например, после прочтения документации не вызывало жжения от синтаксиса.

Конечно субъективное. Мне читать Rust-овый код тяжелее, чем код на других языках. Я пояснил почему. Очевидно, что никто не обязан разделять мою точку зрения.

Мне интересно другое: в чем Rust-оманы пытаются меня убедить?

В том, что у Rust-а хороший и приятный синтаксис? Это не так.

В том, что к синтаксису Rust-а можно привыкнуть? Так в этом нет сомнения.

Привычка, однако, не отменяет того, что синтаксис у Rust-а корявый и придумывали его те, кто хочет экономить на спичках и писать:

pub fn backup(&mut self, path: &mut String) -> Result<()>
вместо
public func backup(self mutable ref, path mutable ref String) Result<_, Err>

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

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

Смущает. Без лидирующих квадратных скобочек хотелось бы обойтись. А вот ()-> в принципе согласуется с синтаксисом лямбд в других языках.

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

Непонятно зачем вообще мешать типизацию и сами аргументы. Наверное стоит типизацию отдельно, а аргументы отдельно.

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

Наверное стоит типизацию отдельно, а аргументы отдельно.

Это в стиле C от Кернигана и Ричи?

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

В каких языках, кстати? Если не брать всякую экзотику, лямбды появились в C++, C#, Java и Rust примерно одновременно. Глупо подстраиваться под подход, который в другом языке экспериментальный, равно как и менять свой синтаксис потому что в соседнем языке фича стабилизировалась раньше. Ну и на тему least surprise: вас почему-то смущают квадратные скобки, которые нужны, но плохо, потому что оно не так как принято в других языках, но не смущает ->double, которое не так, как принято в этом языке. Если уж бороться за чистоту и least surprise, то пусть бы оно было [] double() {...}

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

лямбды появились в C++, C#, Java и Rust примерно одновременно

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

Ну или вот очень похожий на Rust синтаксис лямбд в Ruby, но там лямбды обрамляются:

do |a, b| ... end
{ |a,b| ...}
И как по мне, так это гораздо лучше |a, b| ...

но не смущает ->double, которое не так, как принято в этом языке

Вы, вероятно, не в курсе синтаксиса auto f() -> R.

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

Ну и по поводу C#:

Lambda expressions provide a concise way to write first-class anonymous function values. Compare the following C# 2.0 snippet:

listOfFoo.Where(delegate(Foo x) { return x.Size > 10; });
with this C# 3.0 equivalent:
listOfFoo.Where(x => x.Size > 10);

С# 3.0 — это 2007-ой год. Ни C++11, ни Rust еще нет на горизонте.

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

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

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

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

очередное доказательство неплохой такой плотности спецсимволов на строку.

У вас от этого болит? Приведите пример популярного языка без спец. символов.

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

И как тогда выглядит захват вне метода?

Это что?

let add_one = |x| x + 1;

Полагаю, что так:

Func<int, int> add_one = x => x+1;

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

У вас от этого болит?

В очередной раз повторяю: мне это затрудняет чтение Rust-овского кода.

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

Не нужно подменять понятия: в Rust-е плотность спец. символов слишком большая. Есть языки, где она намного меньше. Например, C#.

И да, меня мало волнует, что C# — это язык с GC.

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

Мне интересно другое: в чем Rust-оманы пытаются меня убедить?

Моё мнение было основано на неверном представление о том, что Вам не понятно значение синтаксиса.

у Rust-а корявый и придумывали его те, кто хочет экономить на спичках и писать:

Ну покажите уж эталонный синтаксис? Назовите тот волшебный язык =) Нет его? Как так?

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

На работе мне приходиться частенько писать на делфи, где синтаксического сахара просто море, там и ваши public и function\procedure, но удобства или читаемости кода это не добавляет. По этому мне приятнее когда можно «экономить на спичках».

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

Нет его? Как так?

Кто сказал, что его нет. Вот у Eiffel-я очень продуманный синтаксис, например. Код на C# и на Kotlin читается хорошо. Первые версии D были вполне себе хорошим исправлением наследия C и C++.

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

Нет его? Как так?

Ну или вот еще забавное вспомнилось. Где-то в районе 2009-2010-х годов, рядышком с анонсом Go, появилась информация о разработке языка Zimbu. Его делает основной разработчик Vim-а.

Синтаксис у Zimbu представляет из себя вообще гремучую смесь. Но въезжаешь в него очень быстро.

http://www.zimbu.org/Home/highlights — тут можно примеры посмотреть.

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

Кто сказал, что его нет. Вот у Eiffel-я очень продуманный синтаксис, например.

Мужик ты издеваешься????

note
   description: "Программа Здравствуй,мир!" 
   author: "Elizabeth W. Brown"
class 
  HELLO 
create 
  make
feature
  make
    -- Напечатать простое сообщение.
    do      
      print ("Hello World%N")
    end
end

Код на C# и на Kotlin читается хорошо

Большие классы на C# вызывают жгучую анальную боль, про Kotlin и D просто не знаю.

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

Мужик ты издеваешься????

Я, вообще-то, говорил про «продуманный синтаксис». Что в синтаксисе Eiffel-я вам кажется непродуманным?

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

Что в синтаксисе Eiffel-я вам кажется непродуманным?

ну он выглядит как говно, например.

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

Отсутствие читабельности напрочь

Т.е. вам обвинять Eiffel в плохой читаемости можно, хотя вы его вообще не знаете. А мне тоже самое в адрес Rust-а сказать нельзя?

Rust-оманы такие Rust-оманы :)

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

eao197 В общем, я понял Вашу позицию, но обед и работа требуют моего присутствия =)

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

Т.е. вам обвинять Eiffel в плохой читаемости можно, хотя вы его вообще не знаете. А мне тоже самое в адрес Rust-а сказать нельзя?

Как контр-аргумент Eiffel выглядит не убедительно (= Вот и всё

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

Мне не интересно ваше мнение.

А это тогда как понимать?

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

Мое мнение вам настолько не интересно, что вы не перестаете задавать мне вопросы.

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

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

Так я и написал: не брать всякую экзотику. Походить имеет смысл только на язык, который хотя бы 30% периодически использует.

Вообще, учитывая, что раст не сильно старается походить синтаксисом на C++, претензии к нему за другие лямбды следует выдвигать после того, как лямбды станут одинаковыми в плюсах, жабе, шарпе и Д.

Вы, вероятно, не в курсе синтаксиса auto f() -> R.

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

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

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

Так я и написал: не брать всякую экзотику.

Что-то в отношении Rust-а у вас другая логика.

Походить имеет смысл только на язык, который хотя бы 30% периодически использует.

Опять же, в отношении Rust-а у вас другая логика.

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

Посконный подход не работал с шаблонными функциями вида:

template<class T, class U>
? add(T a, U b) { return a+b; }
Поэтому и появился другой синтаксис. А лямбды уже использовали ту же нотацию.

Позволю себе так же заметить, что я не говорил, что в C++ синтаксис лямбд сильно лучше, чем оный в Rust-е. Код с C++ными лямбдами так же не самый удобный для чтения. Так что с какого хера вы уцепились за C++ные лямбды для меня загадка.

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

Какой вы умный! Может объясните, почему разработчики Rust-а так не сделали?

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

С# 3.0 — это 2007-ой год. Ни C++11, ни Rust еще нет на горизонте.

В плюсах о планах на лямбды я где-то в начале 2000х читал, так что, скорее всего, текущий синтаксис году к 2005му более-менее устаканился.

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

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

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

В плюсах о планах на лямбды я где-то в начале 2000х читал, так что, скорее всего, текущий синтаксис году к 2005му более-менее устаканился.

У меня нет причин верить вам на слово. В 2003-ом году был принят корректирующий стандарт C++03, в котором никаких лямбд не было. После чего наступила пауза в развитии C++ на несколько лет.

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

Что-то в отношении Rust-а у вас другая логика.

Э? Ещё раз: не оглядываться в вопросе «так принято» на всякую экзотику. Видите ли, делать можно «как лучше» и «как все». Вам же хотелось лямбды «как везде»? Так вот, этого «везде» не было. Ферштейн? Соответственно, сделали как удобно себе. И в плюсах и в расте и в шарпе. В жабе, видимо, принципиально другую стрелку заюзали, чтоб не как в шарпе.

Посконный подход не работал с шаблонными функциями вида

Насколько я помню, это с помощью decltype решалось, не?

Код с C++ными лямбдами так же не самый удобный для чтения. Так что с какого хера вы уцепились за C++ные лямбды для меня загадка.

Просто за тем, чтоб обратить ваше внимание, что никаких общих лямбд не существует. Даже языки, мимикрирующие под C++, реализовали лямбды вразнобой. Соответственно к Расту, авторы которого сознательно решили не тащить с собой синтаксис C претензии на не похожий синтаксис вообще неприменимы.

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

Вам же хотелось лямбды «как везде»? Так вот, этого «везде» не было. Ферштейн?

Это вам так кажется. Синтаксис лямбд в C# оказался очень похож на синтаксис лямб в Scala. Потом почти такой же оказался в Java.

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

Так что Rust-оделы отчебучили очередную отсебятину, как с fn, mut, i32 и пр.

Насколько я помню, это с помощью decltype решалось, не?

Вы неправильно помните. decltype появился в C++11. Вместе с новым синтаксисом для функций и лямбдами.

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

goatse в коде? Оригинально...

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

У меня нет причин верить вам на слово. В 2003-ом году был принят корректирующий стандарт C++03, в котором никаких лямбд не было.

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

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

Во-первых, 2003й - это вполне себе начало 2000х, во вторых отсутствие там лямбд не значит, что работа не велась.

Ну так дайте ссылку на пропозал для добавления лямб в C++ от начала 2000-х, делов-то.

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

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

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

Почему на любителя?

Потому что:

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

Вам такое нравится, мне нет. Поэтому и на любителя.

Судя по восстребованности Haskell-я любителей не так уж и много.

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

Синтаксис у Zimbu представляет из себя вообще гремучую смесь. Но въезжаешь в него очень быстро.
http://www.zimbu.org/Home/highlights — тут можно примеры посмотреть.

Moolenar - известный наркоман. ОДНА закрывающая «}» для блока. Одна, Карл! Просто потому, что некоторые не могут выбрать где её ставить - на той же строке или на следующей.

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

Это вам так кажется. Синтаксис лямбд в C# оказался очень похож на синтаксис лямб в Scala. Потом почти такой же оказался в Java

Ну это, положим, неправда: в Java сделали совершенно безумную замену => на ->. Смысла никакого, зато не как у всех.

Так что Rust-оделы отчебучили очередную отсебятину, как с fn, mut, i32 и пр

Т. е. можно всем, кроме раста?

Вы неправильно помните. decltype появился в C++11. Вместе с новым синтаксисом для функций и лямбдами.

Обсуждения были гораздо раньше. В принципе могли обойтись decltype. Если лень писать выражение, могли бы сделать decltype f(A a, B b) {return a+b;}, или decltype(auto) f(A a, B b) {return a+b;}

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

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

Ну это, положим, неправда: в Java сделали совершенно безумную замену => на ->.

Нда, различие между => и -> это вовсе не «почти такой же». Растоманы, бл*дь.

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

С++11 уже формировался на основе опубликованных в Интернете пропозалов. Если настаиваете на своей точке зрения, то покажите соответствующие пропозалы.

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

Moolenar - известный наркоман.

Да, синтаксис тот еще. Но читается легко после беглого знакомства с языком.

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

Ну так дайте ссылку на пропозал для добавления лямб в C++ от начала 2000-х, делов-то.

Что ещё вам дать? Я ориентируюсь по своей памяти, на плюсы я забил в 2005м, статьи на тему «куда дальше плюсам податься» читал до этого.

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

Я ориентируюсь по своей памяти

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

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

Нда, различие между => и -> это вовсе не «почти такой же». Растоманы, бл*дь.

Нет. Это «хоть как, лишь бы по-другому». Чтоб проклятые шарписты и скалисты на каждой лямбде запинались.

С++11 уже формировался на основе опубликованных в Интернете пропозалов. Если настаиваете на своей точке зрения, то покажите соответствующие пропозалы.

Ваш идиотизм меня достал. Пропозал, видимо, Вася за день до публикации на коленке сварганил. Ни с кем не обсуждая, без сложившегося консенсуса на тему «неплохо бы этакое иметь», верно?

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

Пропозал, видимо, Вася за день до публикации на коленке сварганил.

Ну так покажите этот пропозал, делов-то.

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

Ну так покажите этот пропозал, делов-то.

Последняя попытка.

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

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

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

У меня нет оснований доверять вашим словам о том, что это все оформилось в районе 2005 года. Запросто могло быть и в районе 2007, и в районе 2009.

eao197 ★★★★★
()
Ответ на: комментарий от AntonyRF
public function backup(&mutable self, path: &mutable String) -> Result<()> {
pub fn backup(&mut self, path: &mut String) -> Result<()> {

Очевидно, что второй вариант легче читается

Вовсе не очевидно. Мне, например, первый вариант прочитать легче, чем второй.

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

Смысл? Я с вами не первый раз общаюсь, верить вам на слово не вижу причин. Так что ваши слова о 2005-ом годе не заслуживают никакого доверия, если им не найдется документальное подтверждение.

Мне искать это подтверждение не нужно.

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

Меня напрягает другое - сигнатура &mut String а не mut &String, ведь индикатор среза относится к типу, а не к переменной. В версии без mut так и пишется слитно, &String.

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

Лихо вы сравнили. Часть выражения из Rust-а с полным выражением из C#. Адекватненько. LOR-овские Rust-оманы в своем стиле.

Хватит делить на ноль

Мне вот интересно, кто-нибудь и защищающих Rust-овый синтаксис сможет ответить на мои вопросы: Rust 1.18 (комментарий) ?

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

Мне вот интересно, кто-нибудь и защищающих Rust-овый синтаксис сможет ответить на мои вопросы: Rust 1.18 (комментарий) ?

Тебе уже ответили, но поменять твоё мнение и субъективное восприятие ни кто не будет даже пытаться

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

Вовсе не очевидно. Мне, например, первый вариант прочитать легче, чем второй.

Просто посоветую Delphi =)

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

Я не вижу там никакого вопроса кроме перемывания вашей вкусовщины и закостенелых привычек старого C++ника. Отвечать не на что.

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

Ну тогда еще раз, для совсем тупых: мне, лично мне, синтаксис раста не нравиться и я объяснил почему. Что растоманы пытаются мне доказать? Что вам синтаксис раста нравиться или что у раста хороший и удобный синтаксис?

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

Что нас синтаксис раста устраивает и что он не вызывает никаких проблем при разработке и чтении кода после изучения языка.

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

Давайте считать спецсимволы. Семь у C#, три у Rust.
eao197, еще есть что сказать про плотность спецсимволов и «непривычные» лямбды?

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

Уже три страницы не волнует. А вас лично мое мнение настолько не волнует, что вы не перестаете со мной общаться.

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

Отвечаю на вопросы, если вы еще не заметили.

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

При беглом просмотре кода хорошо было бы более четко видеть границы функций. fn этому не сильно помогает.

Хм... честно говоря, не совсем понимаю проблему. Если код выглядит как-то так, то тут ключевое слово любой длины не поможет:

function...
...........
...........
...........
function...
...........
В нормальном коде всё-таки будут пустые строки между функциями и закрывающие скобки. В идеале - ещё и комментарии:
/// Performs some calculation...
fn foo() {
    ...........
    ...........
}

/// Performs some other calculation...
fn bar() {
    ...........
    ...........
}

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

А с mut'ом что не так?

mutable гораздо очевиднее и лучше в глаза бросается.

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

Суффикс _t вообще в новом языке смысла не имеет, да и в С я не совсем понимаю, зачем нужен.

Суффикс _t определён в стандарте POSIX затем, что в C пространство имён - глобальное. Типы, определённые в POSIX заканчиваются на _t чтобы они не пересекались со встроенными типами C и типами, определёнными конечным разработчиком.

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

есть «правило наименьшего удивления» (least surprise principle), которое разработчиками Rust-а было нарушено при выборе имен вида i32/u32.

Тут ещё такой момент: растовые имена типов могут в виде суффиксов использоваться:

let a: i32 = 0;
let b = 0i32;
Эти записи эквивалентны. Длинные имена типов тут уже смотрелись бы коряво. А так удобно, что иметь две разные формы.

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

let b = 0i32;

Если уж стремиться к очевидности, то лучше уж let b = Int32(0);. Тем же самым grep-ом затем Int32 искать проще будет.

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

Ещё литералы удобны

let a: i32 = 1000000;
let b = 1_000_000i32;

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

И функции короткие, и комментарии. Все как надо.

Ну... это всё-таки не библиотека. (:

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

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

Что мешает сделать так?

fn Int32(val: i32) -> i32 { val }
...
let b = Int32(0);

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

Если уж стремиться к очевидности, то лучше уж let b = Int32(0);. Тем же самым grep-ом затем Int32 искать проще будет.

В реальном коде, скорее всего, такое явное указание типа и не потребуется (выведется из использования). Если же мы всё-таки решим сделать на это акцент, то как быть с возвращаемым значением из функции? let b = Int32(foo(0));?

А почему i32 грепать сложнее должно быть?

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

Ну... это всё-таки не библиотека. (:

А что, в Rust-е можно смотреть только на stdlib?

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

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

А почему i32 грепать сложнее должно быть?

Так ведь в литерале i32 будет только частью последовательности. Если грепать по \<i32\>, то литералы не будут в результат поиска попадать.

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

на самом деле проблема в том, что вы хотите код в виде текста иметь. то есть ТОЛЬКО в виде текста. отсюда все проблемы и растут.

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

А что, в Rust-е можно смотреть только на stdlib?

Откуда такой вывод?

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

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

то есть ТОЛЬКО в виде текста. отсюда все проблемы и растут.

Раскрой мысль.

Если что, я с удовольствием пользуюсь той же подсветкой синтаксиса в виде ИДЕ и аргумент про «писать код в блокноте» серьёзным не кажется. С другой стороны, читать код много где приходится.

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

То что я пишу пока что для себя, в формате прототипа и в стол вас волновать не должно.

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

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

Это да, паскалевский (алголовский) синтаксис намного читабельнее сишного.

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

public func backup(self mutable ref, path mutable ref String) Result<_, Err>

Забавно, что ты сам предлагаешь использовать сокращение вместо полного function.

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

В общем, не хочу сказать, что синтаксис идеальный, но альтернативные варианты не особо лучше.

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

или с утилитой, которая сейчас работает в проде

Что в глаза с ходу бросилось. Мне, помнится, кто-то рассказывал, что unwrap() - это для всяких там поделок, а в проде, мол, нужно ошибки обрабатывать честно. Нет, оказывается. Или установки поменялись?

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

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

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

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

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

unwrap() - это для всяких там поделок, а в проде, мол, нужно ошибки обрабатывать честно. Нет, оказывается. Или установки поменялись?

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

Асинхронный резолвер... на куче потоков!

Вы хоть код почитайте сначала, запустите там например.
Асинхронных резолвер не на куче потоков. А на NCPU потоков планируется M/NCPU асинхронных задач.

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

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

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

Вы хоть код почитайте сначала, запустите там например.
Асинхронных резолвер не на куче потоков. А на NCPU потоков планируется M/NCPU асинхронных задач.

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

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

Смысл в том, что такие вещи правильно делать на сопрограммах

По вашему futures и tokio не достаточно асинхронны? А то что у них epoll(kqueue) под капотом тоже не считается?

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

По вашему futures и tokio не достаточно асинхронны? А то что у них epoll(kqueue) под капотом тоже не считается?

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

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

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

В Rust так и есть. Паника это те же исключения, как бы они от них не отнекивались.

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

отсутствия обобщенного механизма для этих вещей на уровне библиотеки/языка.

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

код просто переусложнен

Ну и что тут переусложненого в этом асинхронном коде:

let future = future.map(move |msg| msg.extract_answer(query_type))
            .then(move |rv| rv.report_status(&name, status_tx))
            .then(move |rv| rv.partial_ok());

Box::new(future)
Тебе надо слово «async» написать чтобы понятно стало?

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

https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

«It is not recommended to use this function for a general try/catch mechanism. The Result type is more appropriate to use for functions that can fail on a regular basis. Additionally, this function is not guaranteed to catch all panics, see the „Notes“ section below.»

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

Для относительной эргономичности есть волшебный костыль: ?.

gene1
() автор топика
Ответ на: комментарий от pftBest

Ну и что тут переусложненого в этом асинхронном коде:

Переусложненного то, что код разбросан по разным местам, да и это далеко не весь код, который относится к нужным вычислениям. Вот там дальше появляются какие-то TriggerTimers, всё это начинает друг с другом связываться, в итоге что там при каких условиях вызывается сам черт не разберет. В общем, конечно, чтобы всё это привести в понятный вид нужна кооперативная многозадачность (fibers).

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

Я по наивности думал, что вам хочется чего-то выяснить, а вам лишь бы хоть что-то возразить, после того, как не смогли внятно объяснить, зачем расту синтаксис лямбд как у шарпа/скалы (вы пытались немного приврать, назвав это «как у всех»), если весь остальной синтаксис у него «не как у всех».

Что до вашей последней соломинки, ок, я погуглил. Нашёл 2 разных пропозала про лямбды, поданных почти одновременно и за полтора года до выхода 3го шарпа. Доказать, что читал статью с фантазиями «что ждать от следующих плюсов» до 2005го я не могу, но для того, чтоб подтвердить, что до начала обсуждения лямбд в плюсах никакого общепринятого синтаксиса лямбд в си подобных языках не было этого достаточно.

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

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

В языках с исключениями можно не ронять всю библиотеку

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

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

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

Это не библиотека, это утилита. Если бы я все задачи выполнял асинхронно в одном потоке, вас бы это успокоило?
Успокоились? А теперь подумайте в чем разница между запуском асинхронных задач на одном планировщике и на NCPU планировщиков? (подскажу, скорость ~ в NCPU раз выше)

А так же чтобы не несли подобный бред про сопрограммы, почитайте что такое futures-rs и какую задачу эта библиотека выполняет.

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

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

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

Я по наивности думал, что вам хочется чего-то выяснить

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

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

У меня не было цели объяснять зачем Rust-у синтаксис лямб из Scala/C#. Речь о том, что синтаксис лямбд Rust-а не похож на синтаксис лямбд из других языков.

Это вы, кстати, зачем-то уменьшили множество до C++/Rust/Java/C#. Добавьте к этому списку Scala, Python, Ruby, Haskell, OCaml, Erlang и пр. Для меня вовсе не принципиально, чтобы лямбды Rust-а были похожи на лямбды из Scala/C#. Хоть бы они вообще на что-то знакомое были похожи (таки да, least surprise principle).

Нашёл 2 разных пропозала про лямбды, поданных почти одновременно и за полтора года до выхода 3го шарпа. Доказать, что читал статью с фантазиями «что ждать от следующих плюсов» до 2005го я не могу

Важно, что вы не можете доказать вот это:

В плюсах о планах на лямбды я где-то в начале 2000х читал, так что, скорее всего, текущий синтаксис году к 2005му более-менее устаканился.

Если в 2005-2006 было два разных пропозала, значит тезис об «более-менее устаканился» не подтвердился. В чем я и не сомневался.

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

Какие здесь растоманы нежные. Кому-то не нравится синтаксис Python-а, кому-то не нравится синтаксис Ruby, кому-то не нравится синтаксис C++, кому-то не нравится синтаксис Eiffel-я. Вообще-то это нормально. Мне вот не нравится синтаксис Rust-а. Только это, внезапно, «просто свинство».

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

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

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

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

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

/0

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

В каждой строчке провокация... Да Вам Батенька в политику надо, а не к раст-оманам =)

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

Ну а ты как человек с гигантским кругозором, наверное можешь указать нам с высоты на лучшую альтернативу?

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

Подожди, где здесь библиотека?

Здесь https://github.com/mersinvald/batch_resolve/tree/master/src/resolve ?

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

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

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

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

pub fn thread_main(mut self, dns_list: Vec<SocketAddr>) {
        let duration_second = Duration::from_secs(1);

        while self.triggered.get() < self.tasks_cnt {
            let start = Instant::now();
            self.trigger_qps(&dns_list);
            let end = Instant::now();

            let diff = end - start;
            if diff < duration_second {
                thread::sleep(duration_second - diff);
            }
        }
    }
asaw ★★★★★
()
Ответ на: комментарий от mersinvald

А теперь подумайте в чем разница между запуском асинхронных задач на одном планировщике и на NCPU планировщиков? (подскажу, скорость ~ в NCPU раз выше)

Вообще-то она может легко быть в ~NCPU раз ниже только из-за накладных расходов. При условии, что асинхронный код написан правильно, конечно.

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

наверное можешь указать нам с высоты на лучшую альтернативу?

Ну вот как с вами общаться?

Вот, например, AntonyRF и ckotinko в этой теме сказали, что у Eiffel-я синтаксис говно. Ну OK. Люди вообще не знают Eiffel-я, но высказать свое мнение по поводу его синтаксиса считают возможным.

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

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

Вот нахрена это все? Ну не нравится какому-то чуваку синтаксис, ну и что это изменит? Ведь ничего.

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

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

Имхо (ИМХО, блин), будь Rust более похож на C++ или на Haskell или на любой другой язык, к которому уже привыкли, проникновение Rust-а в индустрию шло бы более быстрыми темпами.

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

Только вот местным растоманам же нельзя это имхо просто проигнорировать. Нужно возбудиться. Причем возбудиться нужно каким-то маргиналам, вроде RazrFalcon, который регулярно несет бред про C++, а в данной теме отметился эпическим высказыванием про отсутствие указателей в Паскале. Или AntonyRF, который всерьез утверждает, что ООП — это отстой, хотя явно мало что знает про ООП и его применимость в тех или иных отраслях.

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

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

Потому, что, на мой взгляд, Rust сильно отличается от мейнстрима

Я сейчас на свифте программирую. Тоже отличается от c++, java и прочего «старого» мейнстрима. Но ничего, все привыкли. Мейнстрим - это такая изменчивая штука.

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

Это вы, кстати, зачем-то уменьшили множество до C++/Rust/Java/C#. Добавьте к этому списку Scala, Python, Ruby, Haskell, OCaml, Erlang и пр.

Зачем? Как я уже объяснил, копировать синтаксис другого языка имеет смысл либо если он хорош, либо если он привычен целевой аудитории. Кому вообще привычен синтаксис Скалы? Полутора человекам? Много ли народу перейдут на раст с питона или руби? Если и перейдут, им придётся кардинально привычки менять, другой синтаксис лямбд будет меньшей из их проблем.

Если в 2005-2006 было два разных пропозала, значит тезис об «более-менее устаканился» не подтвердился. В чем я и не сомневался.

Синтаксис в одном из пропозалов (внезапно: Страуструп среди авторов) отличается от текущего только типом начальных скобок. Если для вас лямбды жабы такие же как в шарпе, то вы должны признать, что таки устаканился. Ну, если не считать, что синтаксис из пропозала за 5 минут до подачи придумали. Даже в этой мелочи, не имеющей отношения к основному тезису, вы зря себе правоту приписали.

Какие здесь растоманы нежные. Кому-то не нравится синтаксис Python-а, кому-то не нравится синтаксис Ruby, кому-то не нравится синтаксис C++, кому-то не нравится синтаксис Eiffel-я.

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

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

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

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

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

Хотите продолжать доказывать, что код на Расте сложно читать - аргументируйте

Дяденька, вы дурак? Когда кто-то говорит, что ему тяжело пешком подниматься на 5-й этаж, ему нужно доказывать это аргументированно? Мол, пульс такой-то, давление такое-то, количество мышечных спазмов такое-то, уровень болей в суставах такой-то?

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

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

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

Например некоторым не нравится знак `=>` в match. Они хотят чтобы было `:` как в сишке. Но смысл то у них разный. Если будет си подобный синтаксис, то кто-нибудь обязательно напишет такое:

fn main() {
    let FOO: u8 = 10;
    let BAR: u8 = 13;

    switch (13) {
        FOO:
            println!("FOO");
        BAR:
            println!("BAR");
        _:
            println!("Other");
    }
}
И будет очень удивлен что этот код выводит «FOO»

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

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

Емнип в ruby несколько похожий синтаксис.

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

вообще проблема спецсимволов в эпоху юникода - это скорее проблема клавиатур. ну вот посмотрите на неё: сколько там символов можно набить за 1-2 клавиши? ага.

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

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

По поводу i32. Вам, наверное, мало приходилось видеть кода от хардкорных математиков

Пускай они хороши как математики(хотя не факт), но как программисты они говнокодеры.

Причем, что интересно, далеко не всегда такие названия можно заменить на что-то осмысленное.

Это блок из 100500 строк? В 5 строках даже по одной букве понятно что где, просто по тому что они у тебя перед глазами.

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

Емнип в ruby несколько похожий синтаксис.

Я уже здесь показывал синтаксис лямбд из Ruby. Он лучше Rust-ового тем, что рам есть либо открывающая do, либо открывающая {.

В Rust-е же когда сталкиваешься с || -> Result<()>, то слегка офигеваешь. Равно как и вот в таких случаях:

rayon::join(|| qsort(less),
   || qsort(greater));
Как-то не сразу приходит понимание, что здесь две(!) лямбды без параметров. В каком-нибудь другом синтаксисе это было бы для меня более очевидно:
rayon.join(() => qsort(less), () => qsort(greater))
или
Rayon::join lambda {qsort(less)}, lambda {qsort(greater)}

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

Пускай они хороши как математики(хотя не факт), но как программисты они говнокодеры.

Это так. Но то, что делают они, ни вы, ни я не запрограммировали бы.

Это блок из 100500 строк?

Да, бывает, что большие формулы из нескольких десятков составляющих разбивают на отдельные части, вычисляют их, а потом объединяют в единое целое.

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

Это ваша личная точка зрения. Я с ней просто не согласен.

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

Дяденька, вы дурак? Когда кто-то говорит, что ему тяжело пешком подниматься на 5-й этаж, ему нужно доказывать это аргументированно?

Вот видите, вы опять врёте. Доказать, что на 5й этаж подниматься тяжело очень даже можно. Одышкой, пульсом и так далее. Можно доказать и научно, посчитать там, например, энергию, сравнить с дневной нормой и т.п. Не доказывают, потому что всем это очевидно, даже тем, кому лично не так тяжело. У нас тут иначе, всем пофиг, никто толком не может понять, чего в этом синтаксисе сложного и даже вы ничего внятного придумать не можете.

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

А мне насрать на ваше согласие.

Тогда зачем вы продолжаете мне отвечать?

Вот видите, вы опять врёте.

Да вы и вправду дурак.

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

Вот, например, AntonyRF и ckotinko в этой теме сказали, что у Eiffel-я синтаксис говно. Ну OK
Мне нет смысла доказывать им, что у меня другое мнение на этот счет.

Ну а почему у нам не может быть плохого мнения о Eiffel-е? =) Я своё виденье тоже не навязываю.

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

Ну вообще-то, что ООП отстой я не говорил. Я сказал, что по скорости разработки между процедурным стилем и ООП нет и, кстати, я работаю с проектом овер 800kloc напичканным ООП. В аргумент я приводил внутреннее исследование IBM, (которое было для IBM, а не для срача) что разницы в скорости разработки нет. Но Вы сказали, что это исследование не достоверное. После я предположил, что IBM не авторитетная шарашка для Вас и решил не продолжать этот спор =)

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

Ну а почему у наC

очепятка

процедурным стилем и ООП нет

разницы

Пардон за очепятки, спешу, бегу, но срачь не утихает =)

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

Ну а почему у нам не может быть плохого мнения о Eiffel-е?

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

Ну вообще-то, что ООП отстой я не говорил.

Да, впрямую вы так не говорили. Но достаточно было разузнать у вас, какое у вас представление об ООП.

кстати, я работаю с проектом овер 800kloc напичканным ООП.

Перепишите его с помощью процедурного подхода, может мнение об исследованиях IBM для аж 19-ти проектов, у вас и поменяется.

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

Во-вторых, не вижу как ваше пояснение отменяет факт высокой плотности спецсимволов на строку кода.

Тебе что, на планшете это клавиатуре набирать?

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

Тогда зачем вы продолжаете мне отвечать?

Затем, чтоб продемонстрировать слабость вашей позиции. 3 сообщения назад, чтоб увидеть её беспомощность нужно было читать, вникать. Сейчас вот очевидно и так.

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

В очередной раз повторяю: мне это затрудняет чтение Rust-овского кода.

Данный код просто интуитивно понятен. Вот просто наверняка что это записано именно замыкание, при этом указан возвращаемый тип.

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

где синтаксического сахара просто море, там и ваши public и function\procedure

С каких пор полное ключевое слово стало сахаром?

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

Данный код просто интуитивно понятен.

С учетом того, что || в Rust это и OR, и начало лямбды без аргументов, мне так не показалось.

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

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

fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
Ок, предложи твой синтаксис для этой строчки

fn longest(x: &'a str, y: &'a str) &'a str {

Вот это <'a> как будто бы ненужно, -> тоже

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

Здесь

Нет, там нету, вы ошиблись.

Значит получается, что сложно на расте писать такой код, который будет одинаково хорошо обрабатывать ошибки как для библиотек, так и для утилит

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

Выглядят они как навелосипеженный планировщик

Это и есть он, хорошо работающий в конктерном случае, в конкретной утилите.

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

С каких пор полное ключевое слово стало сахаром?

Само наличие слов function\procedure является синтаксическим сахаром, например в Си нет ключевых слов которые говорили бы о начале функции, сразу пишется возвращаемый тип и её имя с параметрами. Ну вы поняли.

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

Вообще-то она может легко быть в ~NCPU раз ниже только из-за накладных расходов. При условии, что асинхронный код написан правильно, конечно.

А я, конечно же, просто так это сделал, без профилировки и бенчмарков, по вашему?)
Ну загляните в историю коммитов чтоли

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

Само наличие слов function\procedure является синтаксическим сахаром

Не является, почитай что такое сахар.

например в Си нет ключевых слов которые говорили бы о начале функции

А в питоне фигурные скобки не нужны, однако они - не сахар.

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

Только такой вариант не будет работать.

<'a> - определение, &'a - использование

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

-> тоже

Это сломает описание предикатов:

fn stuff<P>(p: P) -> bool
    where P: Fn() -> bool

fn stuff<P: Fn() -> bool>(p: P) -> bool

///

fn stuff<P>(p: P) bool
    where P: Fn() bool

fn stuff<P: Fn() bool>(p: P) bool
Намного проще читается? Я сомневаюсь.

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

Он лучше Rust-ового тем, что рам есть либо открывающая do, либо открывающая {.

Для однострочных лямбд открывающие скобки ненужны.

Как-то не сразу приходит понимание, что здесь две(!) лямбды без параметров

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

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

Но то, что делают они, ни вы, ни я не запрограммировали бы.

Если уж так часто надо копаться в их говнокоде, то этот говногод и причесать можно.

Да, бывает, что большие формулы из нескольких десятков составляющих разбивают на отдельные части, вычисляют их, а потом объединяют в единое целое.

Ну и зачем тебе лазить по определению формулы? Или платят тебе, а пишут за тебя?

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

С учетом того, что || в Rust это и OR, и начало лямбды без аргументов, мне так не показалось.

Ты принял это за логическое утверждение?

дочитать тему до конца

Если мне будут платить за время проведённое тут, то да.

что уже давным-давно обсудили?

Я не имею права высказать своё мнение?

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

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

Аргументный аргумент. Т.е. чтобы сказать нравиться мне синтаксис или нет - мне надо выучить весь язык? Но Вы то с Растом так не поступили -_-

Да, впрямую вы так не говорили. Но достаточно было разузнать у вас, какое у вас представление об ООП.

Ну ок, пусть будет ООП-отстой. Хоть я про это и не сказал.

Перепишите его с помощью процедурного подхода, может мнение об исследованиях IBM для аж 19-ти проектов, у вас и поменяется.

Нельзя переписать ПРОСТО любой код. Даже с ООП на ООП. Даже без ООП на другой язык программирования без ООП. Примеров навалом, GTK-doc когда переписывали с perl на python выкатили свои страдания в статье. Даже с того же самого языка на тот же самый язык проект не переписать просто, потому что само по себе переписывание будет занимать много сил, у же не говоря что будут трудности в конвертации представлений из ООП в процедурщену. Но и в обратную сторону код с процедурного стиля переписать в ООП тоже сложно будет. Проблема не в том, что какая-то сторона ущербна, а в том что они разные и всё.

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

Аргументный аргумент. Т.е. чтобы сказать нравиться мне синтаксис или нет - мне надо выучить весь язык? Но Вы то с Растом так не поступили

Есть у меня ощущение, что про Rust я знаю, скажем так, в разы больше, чем вы про Eiffel. И документацию по Rust-у я читал (не штудировал, но читал), и hello_world на Rust я запускал, и с lifetimes и borrow checker-ом разбирался.

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

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

Ты принял это за логическое утверждение?

Скажем так, был сильно удивлен сочетанию || и ->, поскольку раньше с таким не сталкивался.

Я не имею права высказать своё мнение?

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

Ну и на счет синтаксиса лямбд в Ruby, я знаю про три из них:

{ |args| body }
do |args] body end
->(args) { body }
Хотя про последний узнал совсем недавно. Можете привести пример лямбды в Ruby без окружающих ее {} или do-end?

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

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

Что ты опровергаешь? Ты же только подтверждаешь мои «домыслы».

Это и есть он, хорошо работающий в конктерном случае, в конкретной утилите.

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

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

А я, конечно же, просто так это сделал, без профилировки и бенчмарков, по вашему?)

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

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

https://habrahabr.ru/post/322256/

Смешно же во всей этой чепухе вокруг null то, что это не работает. Я уже почти смирился с писаниной бездарной клинописи в своем коде с надеждой, что «зато когда-нибудь это спасет».

Ага, щаз.

Java

public class jHelper {
  public static jHelper jF() { return null; }
  public void M() {}
}

Kotlin

fun F() {
  val a = jHelper.jF()
  a.M()  //Упс!
}
NextGenenration ★★
()
Ответ на: комментарий от eao197

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

Достаточно взглянуть на длину hello world чтоб понять что более близкое знакомство не требуется.

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

Скажем так, был сильно удивлен сочетанию || и ->, поскольку раньше с таким не сталкивался.

Мир прекрасен и удивителен. Когда со следующим удивительным столкнётесь, не спешите паниковать.

Можете привести пример лямбды в Ruby без окружающих ее {} или do-end?

Разве я говорил что лямбды в них совпадают полностью?

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

Мой юный друг, не вы ли в разговоре про лямбды в Ruby давеча написали:

Для однострочных лямбд открывающие скобки ненужны.

Если это были вы, то не составит ли вам труда привести пример оной лямбды-однострочника в Ruby?

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

Если это были вы, то не составит ли вам труда привести пример оной лямбды-однострочника в Ruby?

Извинияюсь если не правильно поняли, но что в c# что в rust в однострочных лямбдах фигурные скобки не нужны.

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

Тут понимаешь с мат софтом боль и в C т.к большинство кода на фортране, а то что не на фортране — код прогнаны через f2c. Писать биндинги для раста нафиг надо. Проще прогнать через f2rs и тут боль с i32

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

Тем что в kotlin нужен лишний синтаксис для проверки на null, который порой не помогает если нужно. Это к тому что kotlin не идеал.

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

но что в c# что в rust в однострочных лямбдах фигурные скобки не нужны.

Сударь, я говорил о том, что не смотря на похожесть лямбд в Ruby и в Rust-е, лямбды в Ruby для меня удобнее тем, что там всегда есть отрывающая { или открывающий do. И тут вы такой про лямбды в C# и Rust. С хрена ли? Голову забыли включить или, по юности лет, развитие мозга еще не закончилось?

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

У математиков есть привычка создавать функции с именами типа i32?

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

Тем что в kotlin нужен лишний синтаксис для проверки на null, который порой не помогает если нужно

так в твоем примере нету никакого синтаксиса для проверки на null ;) а то что он автоматически такое сейчас не ловит - ну сорян, отпишы в багтреке

Это к тому что kotlin не идеал.

а что идеал? есть просто разные степени неидеальности

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

То есть твоя позиция такая: rust не удобен так как в однострочных лямбдах отсутствует открывающая и закрывающая скобки? И если б они были, то код внезапно стал понятнее?

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

так в твоем примере нету никакого синтаксиса для проверки на null ;)

Он будет в несколько других вопросах.

а то что он автоматически такое сейчас не ловит - ну сорян, отпишы в багтреке

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

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

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

Пойдите еще прикопайтесь к асинхронному коду на C++, ей богу.
Есть библиотеки для рантайма и зеленых потоков, есть даже экспериментальный GC, а есть tokio и futures, которые предоставляют асинхронные примитывы без многопоточного планировщика, и я использую второй вариант.

В чем ваша проблема?

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

Легкие потоки тащат с собой рантайм, тут же рантайма нет и потому и планировщик написан руками.

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

В чем ваша проблема?

Не моя, а твоя. Ты притащил пример кода, чтобы похвастаться, а хвастаться там нечем.

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

А чего ты в таком случае tokio и futures руками не написал? |

А че я свой язык и компилятор в нему в машинных кодах сам не написал?

Не моя, а твоя.

Нет, у меня нет проблем.

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

а во-вторых это всё равно через одно место.

Почему?

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

Которое я никому не навязываю.

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

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

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

Когда-то мейнстримом было пренебрежительно относиться к JavaScript. А уж прототипный ООП никак не назовёшь простым и легко осваиваемым. И? Это кого-то остановило?

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

Так что ты просто тролль, который хочет срач.

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

Вам нужна подсказка, как закрыть вкладку с обсуждением и не тратить время?

А так я здесь, в отличии от вас, не страдаю. Я жую попкорн и наблюдаю за вашим срачем. Изредка позволяя себе реплики из зала. :)

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

А так я здесь, в отличии от вас, не страдаю.

А я страдаю, по-вашему? ;)

Как я сказал в другой теме, мне не нравится то, что происходит в мире C++. Единственная видимая альтернатива — это Rust. Поэтому, чем раньше Rust захватит изрядный кусок рынка (не важно, от C++ или от каких-то других языков), тем лучше для меня. Но, судя по адекватности Rust-оманов, этого ждать придется еще долго.

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

Как я сказал в другой теме

Кажется в той теме я попкорн не ел.

Но, судя по адекватности Rust-оманов, этого ждать придется еще долго.

Простите, уточню. Вы говорите об адекватности местных или разработчиков? И если второе, вы жалуетесь на их неадекватность на ЛОРе? ;-)

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

а то что он автоматически такое сейчас не ловит - ну сорян, отпишы в багтреке

Так это сознательное решение было.

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

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

Пофиксил.

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

Что-то поменялось?

Да практически ничего. :) Стали писать на нём игори, серверную сторону сайтов, начали в него компилировать ну и в микроконтроллеры.

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

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

Местных

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

/me потянулся за следующим ведром попкорна

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

Да практически ничего. :)

Я про отношение.

начали в него компилировать

Это не от хорошей жизни делается.

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

/me потянулся за следующим ведром попкорна

Зато топики про Rust просто ракетой взлетают! :)))

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

Только такой вариант не будет работать.

<'a> - определение, &'a - использование

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

После апострофа что-то кроме лайфтайма может быть? Если нет то и так понятно что a - это lifetime.

Или наоборот, если объявляем что a - это лайфтайм, то зачем апостроф? Это как если бы в плюсах везде писали typename перед параметром шаблона.

Намного проще читается? Я сомневаюсь.

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

&a str longest<a>(&a str x , &a str y)  {

Без апострофов меньше шума.

typedef bool Fn() predicate;

bool stuff(predicate a_predicate)

Если писать справа, то шума больше - нужно двоеточие.

typedef Fn() bool  predicate;

stuff(predicate:  a_predicate) bool 
Leron ★★
()
Последнее исправление: Leron (всего исправлений: 1)
Ответ на: комментарий от Leron

Двоеточие позволяет чётко разделить имя переменной и её тип. Но это вкусовщина.

Ну и костыль, в виде сишного typedef, тут не нужен.

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

Ну и костыль, в виде сишного typedef, тут не нужен.

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

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

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

А можете пример найти?

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

А чем отличается двоеточие от ключевого слова as?

двоеточие - объявление типа; as - это приведение к типу

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

as используется для coersion. Двоеточие - тоже.

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

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

Так это rfc только. В языке этого ещё нет, как я понимаю.

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

если rfc начинается на 0000 значит у него нету официального номера, то есть его еще не приняли. И может никогда не примут.

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

Читая RFC надо помнить что:

- не все rfc приняты

- из них не все реализованы в компиляторе

- из тех что реализованы не все стабильны

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

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

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

Хотя местами, думаю, перегибы. Например, необходимость установки крейта rand для генератора случайных чисел. Это как же так возможно «ошибиться» в имплементации rand, чтоб бояться включать его в стандартную библиотеку?

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

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

Что в этом плохого, кроме того что «непривычно»?

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

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

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

Читаю вот книгу «The Rust Programming Language», 2nd ed. Дошел до главы 10, и пока как для человека с опытом с C++, Haskell и некоторым знанием Smalltalk, в Rust все выглядит логично, понятно и очень знакомо

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

с опытом с C++, Haskell

Rust как раз и пытается быть помесью C, C++, Haskell и OCaml.

Низкоуровневый, с функциональщиной и ML синтаксисом.

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

Что в этом плохого, кроме того что «непривычно»?

Очевидно: дополнительные телодвижения.

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

Lua появился раньше этого несчастья. Большинство известных игр класса ААА, такие как S.T.A.L.K.E.R. или ArmA(популярнейшая игра и моды к ней, вроде нашумившего DayZ ), не говоря про WoW, Payday 2, SimCity, Sims, Saints Row, Tom Clancy's H.A.W.X, Freelancer, Dark Souls, Dota 2, Mafia, Natural Selection 2(до сих пор в нее гамаю, и есть переполненные сервера) и еще сотню две культовых игр с миллионными аудиториями. А также в таких больших приложениях как OpenWrt, Wireshark, MySQL Workbench, VLC. Ваши любимые ion и awesome юзают его.

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

Lua уже использовался в первом CryEngine(аж 2003 год), когда про JS еще не слышали даже на веб платформе.

Посему пренебрежительное отношение к JavaScript не поменялось. и менятся не будет. Когда ты можешь за 5 минут тут же подключить сишные файлы и сразу начать скрипты писать, которые дергают функционал «сверху», а веберы в 2017 году только говорят про какие-то движки. НЕЧЕСЕ продвижение! Те кто писали сталкера, уже начали JIT прикручивать к Lua в далеком 2007, а эти только проснулись.

Когда я попадаю в среду веберов, у меня постоянное чувство дежавю и чувство «велосипедостроения». Все эти конференциии, все эти вопли, все эти статьи, все эти рекламы, весь этот хайп производить впечатение, что люди спали 50 лет развития компьютеров, а теперь для себя открывают быструю сортировку, а написать свой двигл с реферсным рендером - ЭТО НОВОЕ СЛОВО. А сишники в 90-ых только этим и занимались, что как бы свой дум или кваку на пентиумах запустить.

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

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

ерь для себя открывают быструю сортировку, а написать свой двигл с реферсным рендером - ЭТО НОВОЕ СЛОВО

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

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

Когда ты можешь за 5 минут тут же подключить сишные файлы и сразу начать скрипты писать, которые дергают функционал «сверху»

Это про luajit еще можно с натяжкой сказать. Для обычной lua, чтобы задействовать сишный код, сначала придется написать большую партянку на Си + Lua C API. И этот API, с его стеком, я бы не назвал верхом удобства

Однажды я писал такой биндинг для своей сишной либы (работа с девайсом через COM-порт). И биндинг получился такого же размера, что и либа

Что же до самой Lua.. На js (особенно на современном) писать в разы приятнее

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.