The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз языка программирования Rust 1.21"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз языка программирования Rust 1.21"  +/
Сообщение от opennews (??) on 14-Окт-17, 09:35 
Доступен (https://blog.rust-lang.org/2017/10/12/Rust-1.21.html) релиз языка программирования Rust 1.21 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.


По структуре язык  Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки  в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).


В подготовке нового выпуска приняли участие 135 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...):


-  Обеспечена (https://github.com/rust-lang/rust/pull/43838) возможность использования статичных ссылок (https://github.com/rust-lang/rfcs/blob/master/text/1414-rval...) для литералов (для размещения значений в статичной памяти (куче), вместо слотов стека):


    fn main() {
        let x: &'static u32 = &0;
    }


-  Перед блоком "‹...›" теперь допустимо указание опционального разделителя "::" в любом контексте:


    my_macro!(Vec‹i32›::new); // Нужно было писать раньше
    my_macro!(Vec::‹i32›::new); // Теперь можно указать и так


-  Библиотека jemalloc обновлена до версии 4.5.0;
-  Обеспечен (https://github.com/rust-lang/rust/pull/43506) запуск LLVM параллельно со стадией трансляции при компиляции с несколькими юнитами генератора кода ("-Ccodegen-units=N"). Изменение позволило снизить пиковые скачки в потреблении памяти в процессе сборки;
-  Стабилизированы API std::mem::discriminant (https://doc.rust-lang.org/std/mem/fn.discriminant.html),  needs_drop (https://github.com/rust-lang/rust/pull/44639) и итератор Iterator::for_each;

-  Расширена документация: На сайт doc.rust-lang.org добавлены руководства по rustdoc (https://doc.rust-lang.org/rustdoc) и std::os (https://github.com/rust-lang/rust/pull/43348). Документация по пакетному менеджеру перенесена в раздел doc.rust-lang.org/cargo (https://doc.rust-lang.org/cargo);
-  Добавлена возможность установки RLS (https://github.com/rust-lang-nursery/rls/) (Rust Language Server, серверный модуль для интегрированных сред разработки с поддержкой протокола LSP (https://www.opennet.dev/opennews/art.shtml?num=44682)) при помощи команды rustup ("rustup component add rls-preview");
-  В пакетном менеджере Cargo появилась возможность указания нескольких имён пакетов в команде "cargo install". В файл Cargo.toml добавлена секция "[patch]" (позиционируется как замена "[replace]") для переопределения определённых частей в графе зависимостей и обеспечена возможность использования масок в стиле gitignore в полях    include и exclude. Добавлена новая опция "--all-targets" для выбора сразу всех целевых платформ.

URL: https://blog.rust-lang.org/2017/10/12/Rust-1.21.html
Новость: http://www.opennet.dev/opennews/art.shtml?num=47385

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Релиз языка программирования Rust 1.21"  +27 +/
Сообщение от Аноним (??) on 14-Окт-17, 09:35 
> let x: &'static u32 = &0;

уродство

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Aleks Revo (ok) on 14-Окт-17, 10:59 
>> let x: &'static u32 = &0;
> уродство

Пони и единорогов в ASCII не завезли.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

61. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от omnomnom on 15-Окт-17, 09:51 
Из этого следует что язык нужно превратить в сомнительное подобие J?
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

30. "Релиз языка программирования Rust 1.21"  +7 +/
Сообщение от Аноним (??) on 14-Окт-17, 15:16 
автор новости пытался написать, что компилятор научился автоматически присваивать ссылкам на константы в выражениях вроде "let x = &0" время жизни "static"
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

47. "Релиз языка программирования Rust 1.21"  +3 +/
Сообщение от trdm (ok) on 14-Окт-17, 20:13 
> уродство

что только не сделают, что-бы с++ не учить..

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Аноним (??) on 14-Окт-17, 09:40 
Когда уже появится язык, позволяющий получить нужные программы в один клик?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от nc (ok) on 14-Окт-17, 10:15 
Когда появится Искусственный Интеллект, программы будут писаться в 0 кликов :)
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

11. "Релиз языка программирования Rust 1.21"  +20 +/
Сообщение от A.Stahl (ok) on 14-Окт-17, 10:24 
Сейчас набегут vim'еры и начнуть визжать что они уже пишут программы в 0 кликов.
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

25. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Аноним (??) on 14-Окт-17, 13:04 
Только в процессе много бибиканья происходит.
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

20. "Релиз языка программирования Rust 1.21"  –4 +/
Сообщение от kai3341 (ok) on 14-Окт-17, 11:24 
> Когда уже появится язык, позволяющий получить нужные программы в один клик?

Delphi

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

34. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Аномномномнимус on 14-Окт-17, 16:48 
лол какой жир
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

38. "Релиз языка программирования Rust 1.21"  +/
Сообщение от пох on 14-Окт-17, 18:46 
с ума сошел? Какой один клик, мне новую мышь в то время пришлось покупать.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

31. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Sw00p aka Jerom on 14-Окт-17, 16:36 
Зачем вам язык тогда? берите уже готовые нужные программы.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

49. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от trdm (ok) on 14-Окт-17, 20:15 
>  Когда уже появится язык, позволяющий получить нужные программы в один клик?

Давно уже есть. Это - чемодан баблаина.
Идешь и покупаешь нужные программы в один клик.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

74. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 15-Окт-17, 15:17 
> Когда уже появится язык, позволяющий получить нужные программы в один клик?

Возбми какой-нибудь scratch, чтоли.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Релиз языка программирования Rust 1.21"  +4 +/
Сообщение от Аноним (??) on 14-Окт-17, 10:06 
>let x: &'static u32 = &0;

Смесь Pascal, Perl, Java.

>my_macro!(Vec::‹i32›::new);

И эти люди рассказывают ужасы про Perl.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Релиз языка программирования Rust 1.21"  +8 +/
Сообщение от Дядя on 14-Окт-17, 11:33 
Так в Перле и нет никаких ужасов.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

35. "Релиз языка программирования Rust 1.21"  –5 +/
Сообщение от НяшМяш (ok) on 14-Окт-17, 17:26 
в Перле и так почти ничего нет
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

50. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Анонисмус on 14-Окт-17, 20:55 
Кроме своего Perl.
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

54. "Релиз языка программирования Rust 1.21"  –3 +/
Сообщение от Anonzzz on 14-Окт-17, 23:56 
Кроме собственного синтаксиса
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

7. "Релиз языка программирования Rust 1.21"  +2 +/
Сообщение от Аноним (??) on 14-Окт-17, 10:14 
> Перед блоком "‹...›" теперь допустимо указание опционального разделителя "::" в любом контексте

Нужно больше разделителей! Даёшь ":::", а лучше ":::::"!

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

9. "Релиз языка программирования Rust 1.21"  +/
Сообщение от A.Stahl (ok) on 14-Окт-17, 10:16 
И обязательные питоноотступы!
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

33. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аномномномнимус on 14-Окт-17, 16:47 
Любой приличный разраб должен ставить нормальные отступы, а вот эти портянки с винегретом в одну строку/колонку жуйте сами
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

36. "Релиз языка программирования Rust 1.21"  +4 +/
Сообщение от A.Stahl (ok) on 14-Окт-17, 18:22 
Вот именно. Нормальные. А не питоноотступы. И там где нужно. А не везде.
Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

56. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 15-Окт-17, 01:00 
> Даёшь ":::", а лучше ":::::"!

[:::::]

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

57. "Релиз языка программирования Rust 1.21"  +3 +/
Сообщение от Аноним (??) on 15-Окт-17, 01:01 
>> Даёшь ":::", а лучше ":::::"!
> [:::::]

:[|||||]:

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

68. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аноним (??) on 15-Окт-17, 13:26 
<======3
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

94. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аноним (??) on 16-Окт-17, 13:13 
8===э
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

10. "Релиз языка программирования Rust 1.21"  –5 +/
Сообщение от Аноним (??) on 14-Окт-17, 10:16 
>Rust напоминает C++

Больше C

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

12. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Аноним (??) on 14-Окт-17, 10:37 
>существенно отличается в некоторых деталях реализации синтаксиса и семантики

В худшую сторону ахах

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Релиз языка программирования Rust 1.21"  –4 +/
Сообщение от лютый жабист__ on 14-Окт-17, 10:40 
В этом крутом убийце всего и вся по-прежнему 5 типов строк или уже поболее сделали?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Релиз языка программирования Rust 1.21"  +/
Сообщение от red75prime on 14-Окт-17, 10:51 
Как было 2 так и осталось.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

28. "Релиз языка программирования Rust 1.21"  +/
Сообщение от red75prime on 14-Окт-17, 14:36 
Ну а то, что в каждой операционке есть ещё своё видение того как работать со строками - издержки реального мира.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

44. "Релиз языка программирования Rust 1.21"  +2 +/
Сообщение от KonstantinB (ok) on 14-Окт-17, 19:34 
Это вы щас Windows операционной системой назвали? :-)

Потому что в других ОС я проблем с такими элементарными вещами не припоминаю.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

62. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от лютый жабист__ on 15-Окт-17, 10:18 
Ну 5 способов конкатенации.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Aleks Revo (ok) on 14-Окт-17, 10:55 
Язык позволяет создавать новые типы, поэтому множество типов строк - открытое. Пользуйтесь. Или не пользуйтесь. :-)
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

32. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Sw00p aka Jerom on 14-Окт-17, 16:39 
> Язык позволяет создавать новые типы, поэтому множество типов строк - открытое. Пользуйтесь.
> Или не пользуйтесь. :-)

"много типов строк" - а как отличить одну строку от другой ?

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

48. "Релиз языка программирования Rust 1.21"  +3 +/
Сообщение от нонон on 14-Окт-17, 20:14 
По типу, очевидно
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

58. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Sw00p aka Jerom on 15-Окт-17, 05:09 
что есть тип?
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

73. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Ordu email(ok) on 15-Окт-17, 14:55 
Множество значений? В смысле теории множеств. Это не совсем так, применительно к программированию, в том смысле, что эта абстракция обладает определёнными недостатками в контексте программирования. Но можно попробовать в данном конкретном случае плясать от неё: может она поможет тебе объяснить, в чём собственно состоит твой вопрос. Я не понимаю, и судя по интенсивности и осмысленности диалога, другие тоже не понимают, что именно тебе интересно было бы узнать.
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

78. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 15-Окт-17, 17:04 
что есть тип? в ассемблере есть понятие типа?
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

79. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 15-Окт-17, 17:21 
> что есть тип? в ассемблере есть понятие типа?

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

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

То есть, если глянуть с той точки зрения, что любая команда принимающая какой-либо аргумент, ожидает в качестве аргумента не вообще всё что угодно, а нечто, удовлетворяющее вполне определённым правилам, то есть какое-то значение определённого типа. В том же at&t синтаксисе, допустим, такой типизации больше: если я пишу movq, значит ассемблер ожидает два аргумента -- 64-х битный источник, и 64-х битный приёмник. Или может быть источник может быть меньше?... Я не помню, с 64-х битной системой команд я знаком скорее понаслышке: понимать код понимаю, а написать не могу.

Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

80. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аноним84701 (ok) on 15-Окт-17, 17:22 
> что есть тип? в ассемблере есть понятие типа?

db dw dd dq
mul, imul, idiv, scasb,scasw, PCMPISTRI
Оно?


Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

83. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 15-Окт-17, 21:40 
ну и что значить db ? - Define constant byte(s) эт разве тип ?
Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

86. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 15-Окт-17, 22:43 
Да, это тип. Если русским языком пытаться обозначить этот тип, то выйдет что-то типа "байт в оперативке с конкретным адресом". Хотя, нет, вру. Не всегда с конкретным, это может использоваться и в объявлении структуры, и там уже конкретного адреса нет, только смещение относительно начала структуры.
Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

97. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 16-Окт-17, 15:54 
> что-то типа "байт в оперативке с конкретным адресом".

этот "байт в оперативке" и число и строковый символ и последовательность битов - где тут тип ?


Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

101. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 17-Окт-17, 16:44 
То есть, смущает то, что тип имеет несколько разных свойств? Или то, что наше интуитивное понимание того, как надо разбивать множество всех возможных значений на типы-подмножества?
Если первое, то C сохраняет все эти свойства байта, и ничего, он считается типизированным языком. Он разделяет знаковые/беззнаковые байты, считая их представителями разных типов, и абстрагируется от места хранения байта -- уже не идёт речи о том, лежит ли он в .data или на стеке или в регистре, все байты лежат в переменных, а какой тип памяти выступает бекендом к этой переменной уже проблемы компилятора -- но всё остальное остаётся так же как и в ассемблере.
Если же смущает второе, то вообще-то, если мы глянем, например, на ООП, мы увидим, что там неоднозначность проведения границ между типами, неоднозначность деления на типы постоянно используется, но с определёнными ограничениями правда, скажем может требоваться древовидное деление. Базовый тип наиболее общий, он содержит в себе множество значений объединяющий множества всех значений всех производных типов.
Если мы глянем в Common Lisp, мы увидим возможность объявить тип (or character integer), то есть заявить, что переменная может содержать либо символ, либо целое число. Или мы можем объявлять более дробные типы, вплоть до того, что можем указать предикат, для проверки принадлежности к типу, например, можно объявить множество простых чисел, и получать рантайм ошибки при попытке положить не простое число в переменную такого типа.
Границы типов -- это условность, которая определяется целями, ради которых эти типы придумали.
Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

103. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Sw00p aka Jerom on 17-Окт-17, 18:48 
>>То есть, смущает то, что тип имеет несколько разных свойств?

)) так у нас уже "тип" имеет свойство?

Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

104. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 17-Окт-17, 19:14 
>>>То есть, смущает то, что тип имеет несколько разных свойств?
> )) так у нас уже "тип" имеет свойство?

А почему нет? Мы объединяем элементы в множество по каким-то принципам, так? Все эти элементы имеют какие-то общие для них свойства. Я не вижу ничего странного в приписывании этих свойств элементов всему множеству -- с точки зрения теории множеств это может быть не хорошо, за строгостью речи надо следить и всегда различать множество и элемент множества, но с чисто практической точки зрения это удобно. Ну, или если ты не согласен с этими вольностями речи, я могу перефразировать своё предыдущее сообщение, с тем чтобы формулировки были бы достаточно строгими.

[add]
Хотя, бывают свойства и у множеств. Если взять множество целых чисел, то у него есть свойство замкнутости по сложению: сумма любых двух элементов этого множества будет элементом этого множества. Это не свойство какого-то элемента, это свойство именно множества. Впрочем, если мы говорим о том, что байт имеет восемь бит, но это всё же, скорее свойство байта, то есть элемента множества, а не свойство множества. Или может это всё глупая игра словами.

Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

105. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Sw00p aka Jerom on 18-Окт-17, 23:17 
коментарий без единого слова "тип" )) с выше описанным - соглашусь, есть понятие свойства (свойства как элементов, так и самих множеств), а давайте уйдём в начало, зачем нужен тип и для чего Рассел ввёл это понятие (якобы во избежания найденный им же парадоксов (антиномий) в теории множеств). Советую прочитать соответствующий трёхтомник Рассела.

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

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

106. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 19-Окт-17, 08:58 
> коментарий без единого слова "тип" ))

Ну это закономерный приём. Если оппонента смущает какое-то слово, надо пользоваться синонимами.

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

Почему лишь Рассела, а не сразу Декарта? Или даже лучше Сократа наверное почитать. Обязательно ведь взять какую-нибудь древность и читать её: чем раньше автор умер, тем больше он понимал в том, о чём писал, так ведь? И даже в том, о чём он не писал, он понимал лучше, надо только хорошенько поискать в его текстах, понимая его слова не прямо, а метафорически.

Кстати математики вполне себе одолели парадокс Рассела, зайдя к теории множеств несколько иначе. Там вся проблема была в неопределённом местоимении "все".

> пс: в программирование понятие "тип" сводится всего лишь к размеру занимаемой памяти.

Нет. Совершенно нет. Теория типов ушла очень далеко от идей Сократа. Не читай древних, читай современных авторов. Начни с википедии и двигайся дальше по ссылкам. Или возьми какой-нибудь язык отличный от ассемблера и посмотри там. Common Lisp, Haskell, rust или любой другой язык с продуманной типизацией. Не надо брать всякие там python, js и прочие. Научись писать программы на выбранном языке, а потом подумай каким целям служит понятие тип в этом языке. То есть, я на полном серьёзе тебе говорю, с самыми искренними интенциями: начни плясать от _цели_. Задайся вопросам: каким целям служит понятие типа в том или ином языке? Зачем программисты используют типы? Чего они достигают? Когда ты сформулируешь цели, подумай о том, как они достигаются. Когда ты это сделаешь, ты будешь смеяться над наивностью Рассела. Над Сократом, впрочем, посмеятся не удастся, потому что он говорил о типах в программировании совсем уж метафорически.

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

Даже с точки зрения размера это разные типы. Если мы сравним &str и String, то мы увидим, что &str -- это по сути указатель на кусок памяти плюс длина этого куска. То есть, грубо говоря, это 128 бит*. Если мы посмотрим на String, то это структура, которая содержит в себе указатель на кусок памяти (причём кусок памяти, который гарантированно находится в куче), затем 64 бита размера этого куска памяти, и ещё 64 бита в которых хранится длина строки. То есть даже с точки зрения размера -- это разные типы.

Но дело даже не в этом, дело в том, что код, который работает с String, не сможет работать с &str. Даже если как-то справиться с тем, что layout структур разный, то попытка перевыделить память под &str запросто может привести к попытке вызвать free на статической памяти, или на стеке, или на адресе, который указывает в середину блока, выделенного через malloc.

У &str и String есть различающиеся свойства -- &str занимает память, которую мы не можем освободить. Либо вообще не можем, либо в принципе можем, но &str не даёт нам достаточно информации о том, как это сделать. А если есть различающиеся свойства, то почему бы их не считать принадлежащими разным множествам/типам? И ведь это будет соответствовать тем целям, ради которых мы используем типы: это позволит компилятору проверять, что мы корректно работаем с данными, и не пытаемся вызывать free на куске памяти из стека.

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

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

107. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 19-Окт-17, 20:15 
>>Ну это закономерный приём.

ну я в принципе ждал ответа вроде этого: "тип" - это .....

Приведу выдержку из википедии (по вашему совету):

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

Теория типов — математически формализованная база для проектирования, анализа и изучения систем типов данных в теории языков программирования (раздел информатики). Многие программисты используют это понятие для обозначения любого аналитического труда, изучающего системы типов в языках программирования. В научных кругах под теорией типов чаще всего понимают более узкий раздел дискретной математики, в частности λ-исчисление с типами.

Современная теория типов была частично разработана в процессе разрешения парадокса Рассела и во многом базируется на работе Бертрана Рассела и Альфреда Уайтхеда «Principia mathematica»[1].
"""

Обратите внимание на второй абзац, "изучения систем <ЖИРНО>типов данных</ЖИРНО> в теории языков программирования", то есть значения элементов множеств, а сам тип есть некие допустимые рамки этих значений, и в информатике этими рамками служит размер хранимого значения, память ведь линейная, достаточно вспомнить, что представляет из себя всякие символьные, целочисленные, строковые "типы" в языке С, чем они отличаются эти по сущности последовательности байтов? - размером. Ассемблеру разве не всё равно, берёте вы значение для сложения из ячейки памяти для строки или для инта.

Продолжу цитатой из вики (по вашему совету):

""" Система типов
Система типов — совокупность правил в языках программирования, назначающих свойства, именуемые типами, различным конструкциям, составляющим программу — таким как переменные, выражения[en]*, функции или модули. Основная роль системы типов заключается в уменьшении числа багов в программах[1] посредством определения интерфейсов между различными частями программы и последующей проверки согласованности взаимодействия этих частей. Эта проверка может происходить статически (на стадии компиляции[en]) или динамически (во время выполнения[en]), а также быть комбинацией обоих видов.
"""

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

Ниже по тексту:

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

Вот и всё, когда дело доходит до исполнения, понятие "типа" данных ЯП исчезает, включается понятие "типа" как размера, ибо инструкция выполняющая допустим сложение двух флоатов требует соответствующего размера регистров, и отсюда вся хренотень с db dw dd dq - и собственно для каждого размера свои инструкции.

Далее по тексту:

"""
Изучением систем типов занимается теория типов, хотя на практике конкретная система типов языка программирования основывается на особенностях архитектуры компьютера, реализации компилятора и общем образе языка.
"""

В самой архитектуре нет того понятия "типа" которое придумали в ЯП, отсюда и появляются всякие рантайм проверки типов (RTTI) (в С конечно их нет, С++ есть но на примитивы).


Идём дальше

""" Типобезопасность
Робину Милнеру принадлежит выражение «Программы, прошедшие проверку типов, не могут „сбиться с пути истинного“»[10]. Иначе говоря, безопасная система типов предотвращает заведомо ошибочные операции, связанные с неверными типами. Например, выражение 3 / "Hello, World" очевидно является ошибочным, поскольку арифметика не определяет операцию деления числа на строку. Формально, безопасность означает гарантию того, что значение любого выражения, прошедшего проверку типов, и имеющего тип τ, является истинным элементом множества значений τ, то есть будет лежать в границах диапазона значений, допустимого статическим типом этого выражения.
"""

3 / "Hello, World" - как это выражение можно написать на ассемблере? (3 - 4 байта, "Hello, World" - 12 байтов (без терминирующего нуля допустим))


""" Каламбур_типизации
на досуг
"""

>>Задайся вопросам: каким целям служит понятие типа в том или ином языке?

зачем мне уходить в абстракцию идти вверх, если нужно идти вниз, ближе к архитектуре.
В самой архитектуре нет понятия "типа" как в ЯП, тока тип как размер данных который принимает та или иная инструкция. я же могу 4 байта инта сложить с четырмя байтами строки, так и строки то нет - она же тоже из нуля и единицы. Сложится ? - да сложится. Результат будет "верный" (подразумевается успешное исполнение инструкции) ? - да, но не ожидаемый как значение.


>>Зачем программисты используют типы? Чего они достигают?

Так лучше вообще без них, почему так высока популярность всяких динамически слабо типизируемых ЯП ? Что говорят "статисты"? их программы безопасней раз строго типизирован ЯП ? Типобезопасность - как критерий чего?


>>Даже с точки зрения размера это разные типы.

разные типы для кого? для человека может разные символьные и целочисленный, для компилятора С почти по барабану (или целое число в диапазоне 0-255, -127-+127), для архитектуре и подавно главное размер регистра.

>>То есть даже с точки зрения размера -- это разные типы.

я вот об этом же - кроме как "тип" как размер регистра(ячеек памяти) для архитектуры другого нет. Зачем всё усложнять? Я был бы рад если бы архитектура строго выделяла бы все описанные выше "типы", но она этого не делает, и нужность (необходимость) этих "типов" - увы не доказана даже в теории. Главный вопрос - зачем ввели эту теорию типов - остаётся открытым.



Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

110. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Ordu email(ok) on 20-Окт-17, 00:24 
Во. С этого надо было начать. Я с самого начала подозревал некорректное использование редукционизма, но никак не мог вас из этого вытянуть в явном виде. А спорить со своими спорными интерпретациями у меня нет никакого желания: есть немалый печальный опыт подобных споров, и сегодня я тщательно избегаю его повторения.

[disclaimer #1. Я накатал стену текста, за что простите, но у меня выдалось тут несколько свободных часов, и я решил предаться своей любимой графомании. За это я приношу извинения, но, написав, я подумал стоит ли постить, и решил, что я ведь никого не обязываю читать всё это. Я свой кайф от написания уже получил. А если вам не доставляет кайфа это читать, то мне, как заядлому графоману, это в общем-то уже и не очень важно. С другой стороны, может вы таки прочитаете, и это окажется полезным.]
[disclaimer #2. Стену я накатал, потом подумал, и решил дополнить неким пояснением, которое может быть будет полезным. Нам недоступна реальность для непосредственного восприятия. Из-за этого, в большинстве случаев мы можем безопасно считать, что никакой реальности нет, и всё что вокруг нас -- это выдумки, иллюзии. В некотором смысле так и есть: ведь если я вижу кружку с чаем, то реально это переживание кружки с чаем возникает потому, что моя психика построила образ кружки с чаем, то есть образ, "программный объект" соответствующий чему-то там в реальности. И я не знаю чему: в лучшем случае я могу описать те ощущения, которые кружка с чаем создаёт на сетчатке, но какова природа этой кружки я не знаю. Я не знаю как она выглядит. Вообще бессмысленно говорить как кружка чая выглядит в реальности, потому что реальный объект выглядеть как-то может исключительно в психике, но не в реальности. Поэтому, даже когда я там в контексте слов о теории категорий, говорю об объектах, то это не объекты реального мира. Их лучше представлять как некие программные объекты, которыми оперирует программа "психика" выполняемая на биологическом компьютере мозге.
Я решил написать об этом, потому что заметил некую предвзятость в отношении архитектуры процессора, то есть заметил идею о том, что архитектура процессора -- это некая догма, это реальность, а всё остальное -- это не реальность, но выдумки всякие. Архитектура процессора -- это такие же выдумки, как и всё остальное. Это тоже абстракции, которые созданы для того, чтобы проще было управлять схемами построенными на логических вентилях. Если условность этой абстракции непонятна, попробуйте спаять процессор на рассыпухе, или хотя бы выясните как это делается -- в интернете есть туева хуча информации, руководства, готовая схематика, даже промышленным образом собранные девайсы можно купить в виде плата полметра на полметра.]

Ваш тезис в том, что раз в системе команд процессора нет понятия тип, значит понятия тип нет вообще. Или может быть, что если мы не можем объяснить высокоуровневое понятие "тип" через логические вентили, на которых построен процессор, значит это бессмысленное понятие. (Ну, да, я очень вольно формулирую, и даже вероятно извращаю ваши слова, каюсь, но простите, сложно удержаться. Да и это не очень важно, я покажу это дальше.) Такого рода аргументы в общем случае строятся посредством редукционного перехода, то есть мы берём какой-то вопрос, какую-то проблему, которая сформулирована в рамках одной области знаний -- например программирования на высокоуровневых языках, -- а затем пытаемся переформулировать эту проблему в рамках более низкоуровневой области знаний, например, в системе команд процессора, или в логических вентилях или ещё в чём-то -- в принципе тут можно спускаться хоть до квантовой механики.

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

Я могу привести пример не из программирования, но очень занятный. Особенно с точки зрения тролля. Если вы поймёте, что я пытаюсь донести, и если вам удастся понять как думают хомячки и в чём их ошибка, то вы сможете до бесконечности вгонять их в когнитивный диссонанс, задавая "каверзные" вопросы. Тема: свобода воли. Общество давным давно ставит проблему свободы воли, задаваясь вопросом что это, и что с ней делать. Почему этот вопрос так волнует людей? Например, потому что наше понимание справедливости подразумевает, что если человек "по доброй воле" сделал гадость, то его надо наказать, а если он сделал это под давлением обстоятельств, если у него не было выбора, то у него есть оправдания, которые как минимум должны снижать размеры наказания. Если человек совершил хороший поступок, то тут то же самое: если он сделал это проявив свободу воли, то это котируется выше, чем если он сделал это случайно, или потому что у него не было выбора. Тут можно копать дальше, выясняя зачем обществу нужно именно такое понимание справедливости, как на всё это влияет свобода воли. Можно задаться целью проектирования идеального общества, а потом искать ответы на вопросы типа "как влияет на структуру общества то или иное понимание свободы воли обществом", или "если поведение X считается проявлением свободы воли, то как должна отличаться реакция общества на это поведение, по сравнению с ситуацией, когда поведение X не считается проявлением свободы воли". Можно придумать и другие задачи или вопросы связанные со свободой воли.

Так вот, очень часто люди начинают спор о существовании свободы воли с редукции в биологию, в физиологию, в химию, в квантовую механику или ещё куда-то. Причём те, кто хотят доказать, что свобода воли есть, любят редуцировать в квантовую механику, а потом рассуждать о том, что квантовая неопределённость и есть свобода воли. Но это серьёзная ошибка методологического уровня. В школе учат рассуждать на примере математики, в математике таких ошибок не существует, поэтому как правило люди даже не замечают ошибки в этих рассуждениях и могут спорить до скончания века. Ошибка в том, что как только мы заявили, что человек -- это сложная химическая реакция в кожаном мешке, так сразу мы "потеряли" свободу воли, потому что в химии нет никакой свободы воли по построению этой химии. Нет свободы воли -- нет проблемы свободы воли, так? "Если мы не видим суслика, значит его нет." Но те исходные социальные вопросы, с которых я начал, остались нерешёнными. То есть исходная проблема осталась проблемой. Умные люди пытались придумать какой-то фреймворк для решения этих проблем, в рамках создания этого фреймворка они запилили понятие свободы воли (впрочем "запилили" -- громко сказано, скорее они сделали кривую демо-версию). Им удалось решить какие-то вопросы и системно описать через это новое понятие какие-то социальные процессы и показать как их фреймворк предлагает решать те или иные социальные проблемы. Какие-то цели остались ещё недостигнутыми, поэтому эти умные люди продолжают дискутировать о том, как лучше пилить дальше понятие свободы воли. И тут приходит редукционист, говорит, что а) человек -- это химическая реакция в кожаном мешке, б) в химии нет никакой свободы воли, из (а) и (б) с очевидностью следует, что у человека нет никакой свободы воли. чтд, а вы все не умные люди, а только щёки с умным видом надуваете, а на самом деле идиоты. Тут умные люди делают facepalm.jpg и молча ретируются. (Вы не подумайте, я не причисляю себя к _этим_ умным людям, о чём свидетельствует хотя бы вот эта стена текста, которую я накатал, вместо ретирады.)

С программными типами то же самое. Если мы возьмём rust и зададимся вопросом зачем разработчики rust создавали ту систему типов, которая есть в rust'е, то мы увидим очевидный ответ: чтобы дать возможность программисту описать как можно больше ограничений на то, что можно делать с теми или иными кусками данных. Дать возможность программисту описать как можно больше правил работы с данными, правил которые затем компилятор сможет проверить. Идеальная система типов с их точки зрения -- эта такая система типов, которая позволяет создавать для любой программы такой набор типов, который будет позволять делать с данными только те вещи, которые осмысленны в рамках задач, решаемых программой. Вот они цели.

Теперь, если мы выполняем редукцию в низлежащую архитектуру процессора, в систему команд этого процессора, то мы начинаем мыслить о программе в иных абстракциях, на которые абстракции раста невозможно отобразить изоморфно. И поэтому многие утверждения о типах из rust'а после отображения на категории программирования в машинных командах, становятся бессмысленными, или двусмысленными/неоднозначными, или ещё каким-нибудь образом начинают вызывать сомнение в их истинности. Но -- вы знакомы с теорией категорий? -- тут надо помнить, что есть разница между утверждением и образом утверждения, полученным в результате применения к исходному утверждению некоего отображения (в нашем случае редукции). На эту разницу можно положить болт, если наше отображение изоморфно, то есть если одна категория (то есть множество объектов и множество всех связей между ними) отображаются взаимно-однозначно на другую категорию. (Множество матриц размера NxN изоморфно множеству однородных систем линейных уравнений с N переменными, поэтому я могу легко рассуждать о матрицах, и переносить выводы на ОСЛУ, и даже в речи взаимозаменяемо употреблять слова "ОСЛУ" и "матрица NxN" -- это не приводит к противоречиям, и даже математики-и-педанты-на-всю-голову снисходительно на это смотрят).
Но если отображение не изоморфно, и если несколько разных объектов (понятий, абстракций) rust'а отображаются в один объект в ассемблере, то тут заранее вообще ничего нельзя сказать о том, что случится с истинностью утверждений, после отображения. Ну, если у нас есть объекты x,y,z, есть утверждение p(x,y,z), и есть отображение f, то зная истинность p(x,y,z) мы ничего не можем сказать об истинности p(f(x),f(y),f(z)) в общем случае.

Я могу привести ещё один пример не из программирования. Пример, где редукция, как отображение между двумя способами представлять реальность, построена, работает и позволяет переносить проблемы из одного представления в другое. Термодинамика газов в том виде, в котором её рассказывали в школе. Там явно произносились слова "макропараметры", под которыми подразумевались такие вещи, как температура, давление и объём газа. Фишка в том, что газ состоит из молекул, и у молекул нет температуры и нет давления. У них есть объём, но он слабо связан с объёмом газа, по-крайней мере сумма объёмов молекул не сойдёт даже за оценочное значение объёма газа, там разница будет во много порядков. Это не вызывает когнитивного диссонанса? Как так: на микроуровне нет макропараметров, а на макроуровне они возникают? Если мы на макроуровне сформулируем какую-нибудь задачу, например, "как зависит давление от температуры?", а потом попробуем выполнить редукционный переход, то мы потеряем задачу. Физики и математики проделали кучу работы, и они построили математическую модель, позволяющую "редуцировать" давление и температуру до микропараметров, и пользуясь их формулами и определениями, мы в общем-то можем переформулировать задачу, заданную в терминах макропараметров, в термины микропараметров. Собственно законы термодинамики, устанавливающие связь между температурой давлением и объёмом, а так же накладывающие ограничения на динамику ещё одного макропараметра -- энтропию -- были доказаны именно через эту редукцию, хотя они и были исходно получены чисто эмпирически. Термодинамика мне нравится как пример тем, что здесь редукция макропараметров возможна, она реально построена и осмысленна.

> Обратите внимание на второй абзац, "изучения систем <ЖИРНО>типов данных</ЖИРНО> в теории
> языков программирования", то есть значения элементов множеств, а сам тип есть
> некие допустимые рамки этих значений, и в информатике этими рамками служит
> размер хранимого значения, ...

Возьмём те же строки. Допустим, что мне хочется в программе работать со строками в разных кодировках, поэтому я к каждой строке буду привязывать информацию о её кодировке. Инкапсулируем всё это как следует под API, и получим в результате, что две строки "привет мир" могут иметь один и тот же тип, и даже быть равными. Тут правильнее наверное употреблять слово "эквивалентными", хотя это зависит от контекста: иногда нам важно различать эквивалентность и равность, иногда нет. В том же lisp'е мы видим, несколько предикатов сравнения на равенство: eq который сравнивая два объекта проверяет два ли это объекта, или один и тот же, и equal, который сравнивая объекты сравнивает их на "равенство". eq на вышеприведённых строчках "привет мир" выдаст nil, т.е. false, потому что это два разных объекта, equal выдаст t, то есть true, потому что строчки состояет из одной и той же последовательности символов (не кодов символов, а именно символов). Но, обратите внимание, ни eq, ни equal даже не посмотрят на совпадение или несовпадение размеров. И мне как программисту пишущему прикладной код, совершенно не важно совпадают ли размеры или нет.

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

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

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

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

> """
> Если инструкции в теле функции написаны в предположении, что им на обработку
> должно быть передано целое значение, но вызывающий код передал число с
> плавающей точкой, то вызванная функция вычислит неверный результат.
> """
> Вот и всё, когда дело доходит до исполнения, понятие "типа" данных ЯП
> исчезает, включается понятие "типа" как размера, ибо инструкция выполняющая допустим сложение
> двух флоатов требует соответствующего размера регистров, и отсюда вся хренотень с
> db dw dd dq - и собственно для каждого размера свои
> инструкции.

Вы упускаете из виду один нюанс. Если мы говорим о том, что программа написана на высокоуровневом ЯП со строгой типизацией, то на этапе выполнения программы невозможна ситуация, когда в код, работающий с целочисленными значениями переданы флоаты. Это одна из ловушек редукционизма: очень легко потерять инварианты, которые выполняются на высоком уровне. То есть, сами инварианты никуда не деваются из программы, но мы, выполнив редукционный переход, перестаём их видеть. "Видишь суслика? Нет? А он есть."

> Далее по тексту:
> """
> Изучением систем типов занимается теория типов, хотя на практике конкретная система типов
> языка программирования основывается на особенностях архитектуры компьютера, реализации
> компилятора и общем образе языка.
> """
> 3 / "Hello, World" - как это выражение можно написать на ассемблере?
> (3 - 4 байта, "Hello, World" - 12 байтов (без терминирующего
> нуля допустим))

Это зависит от языка программирования. Если мы говорим о C, то тогда на ассемблере это будет выглядеть как строка "Hello, World" в секции .data, и деление 64-х битного значения 3 на адрес этой самой строки. По-крайней мере, компиляторы прошлого тысячелетия тщательно делали вид, что всё происходит именно так. Компиляторы нового тысячелетия могут выкинуть любой фортель в ответ на подобный код, ибо это UB.
Если же мы говорим о javascript, то... эмм... я плохо знаю javascript: он будет как-то приводить строку к целочисленному типу, и я не уверен, что он получит в данном случае. Можно проконсультироваться с документацией, там должно быть описано.

Строка 3/"Hello, World" не имеет какого-то своего собственного значения. Она может иметь значения в рамках той или иной грамматики, значение полностью определяется языком. Ваше представление о типах, как мне кажется, полностью определяется каким-то диалектом ассемблера. И при работе с тем диалектом оно абсолютно корректно. Но меня нисколько не удивит, если при переходе к другому диалекту ассемблера для того же процессора оно окажется некорректным. И уж совершенно нечему удивляться, если оно не будет работать в js.

>>>Зачем программисты используют типы? Чего они достигают?
> Так лучше вообще без них, почему так высока популярность всяких динамически слабо
> типизируемых ЯП ? Что говорят "статисты"? их программы безопасней раз строго
> типизирован ЯП ? Типобезопасность - как критерий чего?

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

Динамическая (но строгая) типизация, по сравнению со статической, допускает кучу багов в программе, но эти баги отчасти контролируемы, потому что эти баги будут приводить к рантайм ошибкам, которые детектируется системой типов, и затем обрабатываются. Даже если обработка сводится к тому, что программа "контролируемо" падает, это лучше, чем если она, перепутав float и int, продолжает работать как будто так и надо. В первом варианте поведения нет ничего хорошего, но второй позволяет не только DoS атаки, но ещё и произвольное выполнение кода. То есть, с этой точки зрения, динамическая типизация лучше, чем отсутствие типизации, но хуже чем статическая. Но у динамической типизации есть свои плюсы: она может сильно упрощать структуру программы. Например, если мне надо много типов строк, то мне не обязательно думать о том, следует ли все эти типы объединить в единую иерархию типов. Я просто использую много типов строк, ищу те ситуации где возникают рантайм ошибки, и в тех ситуациях делаю typecase (с смысле case по типу аргумента). Это может приводить к большим проблемам в будущем с поддержкой программы, это может приводить к тому, что в каких-то экзотических случаях программа будет падать с ошибкой, потому что в typecase не все возможные варианты перечислены, но зато если я не уделил внимания этапу проектирования программы, то я могу реализовать больше функциональности в программе, прежде чем я упрусь в невозможность продолжать писать код и в необходимость вернуться назад и начать проектировать программу с нуля, переписывать или рефакторить код. Такие фишки полезны, например, когда пишешь то, не знаю что. Когда важен не результат написания программы, а сам процесс её написания, который является исследовательским процессом, нацеленным на изучение предметной области.

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

Но, если я ещё могу худо-бедно согласиться с подходом C, который автоматом преобразует char к int, а double к float, то всякие глупости типа автоматические приведения строки к числу или числа к строке -- это вообще выходит за границы здравого смысла. Но, если пытаться найти объяснение отличное от глупости, то я бы предположил, что идея нестрогой типизации в языке нацелена на то, чтобы найти компромисс между отловом максимума ошибок и простотой написания кода/изучения языка. Понятно, что всё это происходит на фоне какого-то представления о том, какие именно задачи будут решаться на этом языке, какой код будет писаться. И как показывает практика, эти априорные представления очень часто оказываются ошибочными, поэтому компромисс совершенно не попадает в оптимум.

>>>Даже с точки зрения размера это разные типы.
> разные типы для кого? для человека может разные символьные и целочисленный, для
> компилятора С почти по барабану (или целое число в диапазоне 0-255,
> -127-+127), для архитектуре и подавно главное размер регистра.

Это сильно зависит от языка. А абстракции языка зависят от тех задач, и тех методов решения задач, на которые заточен язык. Язык C не различает символьный тип и int8_t, а в паскале -- это принципиально разные типы, и отображение между ними выполняется явным вызовом функций. Потому что Вирт посчитал, что негоже использовать арифметические функции для работы с символами. Что все применения арифметики к ASCII кодам должны быть инкапсулированы в хорошо оттестированной библиотеки, которая предоставляет программисту "safe API". И в этом ведь есть определённый смысл: это позволяет изменить внутреннюю кодировку строк, не запуская процесс аудита всего кода, чтобы убедиться, что вся работа с символами и строками осталась корректной после изменений представления строк.

>>>То есть даже с точки зрения размера -- это разные типы.
> я вот об этом же - кроме как "тип" как размер регистра(ячеек
> памяти) для архитектуры другого нет. Зачем всё усложнять?

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


> Я был бы
> рад если бы архитектура строго выделяла бы все описанные выше "типы",
> но она этого не делает, и нужность (необходимость) этих "типов" -
> увы не доказана даже в теории.

Ну, во-первых, это не совсем вопрос теории. Это во многом чисто практический вопрос, программисты создают инструменты, которые им удобны. Если мы посмотрим на теорию, то не найдём у неё никаких желаний, в теории нет таких понятий "нужно" или "хочется". Нужность чего-либо начинается с хотелок человека, и обосновывается ими же. И вот тут возникает "во-вторых": хотелки человека, как правило, не в том, что он хочет явно указывать где надо привести u8 к u64, хотелки человека заключаются в чём-то другом. И связь между хотелками человека и необходимостью вычистить язык от явных преобразований типов может устанавливаться, в частности, и формальными доказательствами. Местами это возможно, и местами это делается. Но чтобы найти такие теоретические доказательства, надо взять конкретную фишку языка, подумать о том зачем разработчик её привнёс в язык (не "зачем это надо мне", а именно "зачем это было надо разработчику языка" -- некоторые не умеют различать эти два вопроса, а зря), и вот потом, двигаясь от целей разработчика искать обоснования, и там иногда можно встретить и формальные доказательства.

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

> Главный вопрос - зачем ввели эту теорию типов - остаётся открытым.

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

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

111. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Ordu email(ok) on 20-Окт-17, 00:37 
Простите. nginx отвалился по таймауту пока постил, и я прежде чем подумать, зачем-то ещё раз отправил. Тупанул, каюсь.
Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

108. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 19-Окт-17, 20:25 
небольшое дополнение:

на той же "Машине Тьюринга" можно выполнить любой разрешимый алгоритм? там есть понятие "типа"?

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

87. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним84701 (ok) on 15-Окт-17, 23:49 
> ну и что значить db ? - Define constant byte(s) эт разве  тип ?

Обычно просто "define byte", хотя конечно сильно зависит от диалекта.
Чем не тип? Опять же, есть df (float), dt и т.д.
Кстати, из x86-экзотики еще вспоминаются комманды AAA AAD AAM (adjust ascii after add/div/mul).
www.club155.ru/x86cmd/AAD
> Описание:
> Команда AAD (ASCII Adjust AX Before Division) относится к группе команд двоично-десятичной [условно - можно самому забить опкод с нужным основанием, прим. номерного анонима] арифметики (Binary-Coded Decimal, BCD). Она используется для подготовки двух разрядов неупакованных BCD-цифр (наименее  
> значащая цифра в регистре AL, наиболее значащая цифра в регистре AH)

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

96. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Sw00p aka Jerom on 16-Окт-17, 15:48 
Чем не тип?

Ну где тут тип?

Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

14. "Релиз языка программирования Rust 1.21"  –3 +/
Сообщение от Аноним (??) on 14-Окт-17, 10:47 
На нем GUI можно или как у go - удел сетевых уно-файл&уно-сервис?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Aleks Revo (ok) on 14-Окт-17, 10:58 
> На нем GUI можно или как у go - удел сетевых уно-файл&уно-сервис?

https://crates.io/search?q=ui
https://crates.io/search?q=gui

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

19. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 14-Окт-17, 11:18 
А также:
https://godoc.org/?q=ui
https://godoc.org/?q=gui
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Lester on 14-Окт-17, 12:03 
> Перед блоком "‹...›" теперь допустимо указание опционального разделителя "::" в любом контексте
> my_macro!(Vec::‹i32›::new); // Теперь можно указать и так

Авторам не стоит на этом останавливаться. Нужно добавить еще опциональных разделителей, совершенству нет предела.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 14-Окт-17, 12:10 
С виду язык похож на пародию на C++. Если он станет популярен, в коде у программистов будет полная анархия.
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

40. "Релиз языка программирования Rust 1.21"  –3 +/
Сообщение от пох on 14-Окт-17, 18:55 
> С виду язык похож на пародию на C++

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

> Если он станет популярен,

уже стал.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

102. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от _ (??) on 17-Окт-17, 17:22 
>> Если он станет популярен,
>уже стал.

И что же значимое на нём написали? Не начали переписывать, а мля доделали? Ничего?

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

39. "Релиз языка программирования Rust 1.21"  +/
Сообщение от пох on 14-Окт-17, 18:51 
> Авторам не стоит на этом останавливаться. Нужно добавить еще опциональных разделителей,
> совершенству нет предела.

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

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

53. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 14-Окт-17, 23:54 
> Каждый раз, как я вижу в языке двоеточия

Прошло 5 часов, а список языков без двоеточий в вашем комментарии всё ещё пустой.

Хотя в чём-то я с вами согласен.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

69. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 15-Окт-17, 13:28 
Языка совсем без двоеточий не существует. Важна концентрация двоеточий на километр кода.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

92. "Релиз языка программирования Rust 1.21"  +/
Сообщение от leap42 (ok) on 16-Окт-17, 10:48 
> Языка совсем без двоеточий не существует

а как же petooh?

https://github.com/Ky6uk/PETOOH

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

24. "Релиз языка программирования Rust 1.21"  +12 +/
Сообщение от Аноним (??) on 14-Окт-17, 12:17 
Хоронили C++, порвали три альтернативы. ©
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Релиз языка программирования Rust 1.21"  +/
Сообщение от fidaj (ok) on 14-Окт-17, 13:45 
что-то онолитеки с опеннета невзлюбили ржавчину.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аноним (??) on 14-Окт-17, 14:38 
Потому что его адепты ведут себя как сектанты-неосиляторы.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

41. "Релиз языка программирования Rust 1.21"  +10 +/
Сообщение от Аноним (??) on 14-Окт-17, 19:11 
> Потому что его адепты ведут себя как сектанты-неосиляторы.

Пока что - ни одного адепта мы тут не видили, зато куча "несектантов" уже за 40 комментариев с подгораниями^W^W о (не)нужности  и (не)правильности накатали.


Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

70. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Аноним (??) on 15-Окт-17, 13:29 
Ничего необычного, на новости где ожидается повышенная концентрация сектантов ожидаемо набигают тролли.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

72. "Релиз языка программирования Rust 1.21"  +4 +/
Сообщение от Аноним (??) on 15-Окт-17, 13:51 
> Ничего необычного, на новости где ожидается повышенная концентрация сектантов ожидаемо
> набигают тролли.

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

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

81. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от freehck email(ok) on 15-Окт-17, 19:55 
> Да и троллей - раз-два и обчелся (прошу не путать тролля ... и обычного интернетного балабола)

"Только ситхи всё возводят в абсолют". На самом деле тролли по толщине все разные. Каждой аудитории -- своя толщина. :)

То, что набегают толпы толстячков, кое-что говорит об аудитории, как ни крути. ;)

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

43. "Релиз языка программирования Rust 1.21"  +2 +/
Сообщение от Борщдрайвен бигдата on 14-Окт-17, 19:32 
Потому что сами на нем не пишут и вряд ли будут писать.
У пользователей языка совершенно другие претензии, посерьезней и намного более конкретные.
А так занимать сторону побивателя камнями (либо чем-то другим, потеплее и помягче) всегда приятно. Чувство локтя и вот это всё.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

55. "Релиз языка программирования Rust 1.21"  +3 +/
Сообщение от Аноним (??) on 15-Окт-17, 00:05 
> У пользователей языка совершенно другие претензии, посерьезней и намного более конкретные.

Судя по списку изменений, претензии следующие:

1. Нельзя указывать опциональный разделитель :: перед блоком <>. А иногда хочется.
2. jemalloc уже две недели как вышел 4.5.0, а у вас ещё старьё.
3. Хватит каждый релиз менять Iterator::for_each несовместимым образом!
4. Хотим, чтобы в файле пакетного менеджера вместо [replace] использовалось название [patch]. Ну и поведение тоже поменяйте как-нибудь.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

27. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от fidaj (ok) on 14-Окт-17, 13:46 
>и предоставляет средства для достижения высокого параллелизма выполнения заданий

может кто знает, что-то подобное OpenACC в нем реализовано?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

37. "Релиз языка программирования Rust 1.21"  +/
Сообщение от scor (ok) on 14-Окт-17, 18:33 
Подскажите, плз, кто в теме. Там подобные штуки
```
trait T1 {
  const FS: usize;
  fn f1(&self) -> [u32; Self::FS];
}
```
уже можно делать или пока не запилили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Релиз языка программирования Rust 1.21"  –5 +/
Сообщение от Аноним (??) on 14-Окт-17, 19:32 
Странный язык какой-то. Хелловорлд весит аж 600 килобайт. На с++ у меня целый проект с гуем, с сетью, с 3д, с кучей огромых формул, порой не помещающихся на экран монитора, и скомпиленный файл занимает чуть менее 300 килобайт. А тут одна строка в консоли - 600 килобайт! Как так-то?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Sirob on 14-Окт-17, 20:00 
Я просто оставлю ссылку на эту замечательную статью здесь: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...

Автор понятно объясняет, почему бинарники, скомпилированные Rust, такие большие и показывает как уменьшить размер hello world с 600+ кб до 9.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

91. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Аноним (??) on 16-Окт-17, 10:35 
То есть эталонная реализация статически линкует аллокатор, и стандартную библиотеку? Какой же всё-таки руст "безопасный" язык!
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

46. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Конь on 14-Окт-17, 20:04 
Потому что по дефолту в бинарник суется std и jemalloc, которые можно откльчить, если очень хочется помериться пипи… бинарниками. И кстати, ты еще не учел, что в твой проект кроме этих 300 килобайт еще входит стандартная библиотека С++, проста она линкуется динамически
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

51. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от angra (ok) on 14-Окт-17, 22:03 
А теперь возьми свой замечательный бинарник с гуем, сетью, 3d и формулами и попробуй запустить на машине с той же ОС, но без libstdc++ и прочих либ. Почитай, что он напишет, потом посмотри на вывод ldd.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

52. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Вася1970 on 14-Окт-17, 22:52 
без операционки и с процессором другой архитектуры. нет - полумерам!
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

60. "Релиз языка программирования Rust 1.21"  +/
Сообщение от angra (ok) on 15-Окт-17, 06:48 
А что же ты сам полумерами ограничился? Если уж косишь под дурачка, то на полную катушку, предложи запустить вообще без компьютера.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

82. "Релиз языка программирования Rust 1.21"  +3 +/
Сообщение от freehck email(ok) on 15-Окт-17, 20:05 
> без операционки и с процессором другой архитектуры. нет - полумерам!

Тебе вообще-то мягко намекнули, что в растовом бинарнике куча всего библиотечного понапихано. А вообще, вопрос изначально был дурацкий. На него вечный ответ "запусти ldd и поймёшь, почему бинарь сишной программы весит меньше".

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

67. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от Аноним (??) on 15-Окт-17, 13:25 
Так и запишем, разделяемый рантайм ниасилили.
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

89. "Релиз языка программирования Rust 1.21"  +1 +/
Сообщение от Вареник on 16-Окт-17, 04:35 
У меня прошивка контроллера в 32кбайт флеша влазит.

Никаких shared lib, ядер и т.д.
Зато куча формул, сеть, протокол.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

59. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 15-Окт-17, 06:06 
Он даже уродливее C++
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

63. "Релиз языка программирования Rust 1.21"  +2 +/
Сообщение от gred (ok) on 15-Окт-17, 10:30 
> Он даже уродливее C++

Что поделаешь, любой язык расширяющий синтаксис Си будет смотреться уродцем, кроме самого Си.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

64. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Борщдрайвен бигдата on 15-Окт-17, 12:57 
> язык расширяющий синтаксис Си

Слишком толсто. Даже по меркам опеннета.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

90. "Релиз языка программирования Rust 1.21"  –2 +/
Сообщение от Аноним (??) on 16-Окт-17, 08:03 
C# вполне себе конфетка (по синтаксису), вот если бы он компилировался в нативный код
Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

93. "Релиз языка программирования Rust 1.21"  –3 +/
Сообщение от Аноним (??) on 16-Окт-17, 11:18 
К сожалению для Rust, теперь он стал ненужен, когда в C++17 сделали If and Switch statement with initializer (https://skebanga.github.io/if-with-initializer/) и Structured bindings (https://skebanga.github.io/structured-bindings/)


std::map<int, std::string> myMap;
....
if (auto[it, ok] = myMap.insert({ 2, "hello" }); ok)
{
  ....
}

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

95. "Релиз языка программирования Rust 1.21"  –1 +/
Сообщение от pripolz on 16-Окт-17, 14:13 
Кстати, гораздо лучше (и новее) Adobe Rust. Поддердивает kind-ы (вызовы типа kindof()) например. Ещё можно мержить переменные.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

100. "Релиз языка программирования Rust 1.21"  +/
Сообщение от Аноним (??) on 17-Окт-17, 06:55 
А корованы там можно?
Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру