Доступен (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.me/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.me/opennews/art.shtml?num=47385
> let x: &'static u32 = &0;уродство
>> let x: &'static u32 = &0;
> уродствоПони и единорогов в ASCII не завезли.
Из этого следует что язык нужно превратить в сомнительное подобие J?
автор новости пытался написать, что компилятор научился автоматически присваивать ссылкам на константы в выражениях вроде "let x = &0" время жизни "static"
> уродствочто только не сделают, что-бы с++ не учить..
Когда уже появится язык, позволяющий получить нужные программы в один клик?
Когда появится Искусственный Интеллект, программы будут писаться в 0 кликов :)
Сейчас набегут vim'еры и начнуть визжать что они уже пишут программы в 0 кликов.
Только в процессе много бибиканья происходит.
> Когда уже появится язык, позволяющий получить нужные программы в один клик?Delphi
лол какой жир
с ума сошел? Какой один клик, мне новую мышь в то время пришлось покупать.
Зачем вам язык тогда? берите уже готовые нужные программы.
> Когда уже появится язык, позволяющий получить нужные программы в один клик?Давно уже есть. Это - чемодан баблаина.
Идешь и покупаешь нужные программы в один клик.
> Когда уже появится язык, позволяющий получить нужные программы в один клик?Возбми какой-нибудь scratch, чтоли.
>let x: &'static u32 = &0;Смесь Pascal, Perl, Java.
>my_macro!(Vec::‹i32›::new);
И эти люди рассказывают ужасы про Perl.
Так в Перле и нет никаких ужасов.
в Перле и так почти ничего нет
Кроме своего Perl.
Кроме собственного синтаксиса
> Перед блоком "‹...›" теперь допустимо указание опционального разделителя "::" в любом контекстеНужно больше разделителей! Даёшь ":::", а лучше ":::::"!
И обязательные питоноотступы!
Любой приличный разраб должен ставить нормальные отступы, а вот эти портянки с винегретом в одну строку/колонку жуйте сами
Вот именно. Нормальные. А не питоноотступы. И там где нужно. А не везде.
> Даёшь ":::", а лучше ":::::"![:::::]
>> Даёшь ":::", а лучше ":::::"!
> [:::::]:[|||||]:
<======3
8===э
>Rust напоминает C++Больше C
>существенно отличается в некоторых деталях реализации синтаксиса и семантикиВ худшую сторону ахах
В этом крутом убийце всего и вся по-прежнему 5 типов строк или уже поболее сделали?
Как было 2 так и осталось.
Ну а то, что в каждой операционке есть ещё своё видение того как работать со строками - издержки реального мира.
Это вы щас Windows операционной системой назвали? :-)Потому что в других ОС я проблем с такими элементарными вещами не припоминаю.
Ну 5 способов конкатенации.
Язык позволяет создавать новые типы, поэтому множество типов строк - открытое. Пользуйтесь. Или не пользуйтесь. :-)
> Язык позволяет создавать новые типы, поэтому множество типов строк - открытое. Пользуйтесь.
> Или не пользуйтесь. :-)"много типов строк" - а как отличить одну строку от другой ?
По типу, очевидно
что есть тип?
Множество значений? В смысле теории множеств. Это не совсем так, применительно к программированию, в том смысле, что эта абстракция обладает определёнными недостатками в контексте программирования. Но можно попробовать в данном конкретном случае плясать от неё: может она поможет тебе объяснить, в чём собственно состоит твой вопрос. Я не понимаю, и судя по интенсивности и осмысленности диалога, другие тоже не понимают, что именно тебе интересно было бы узнать.
что есть тип? в ассемблере есть понятие типа?
> что есть тип? в ассемблере есть понятие типа?Смотря как, мы определяем понятие "тип". Выбор того, как определять понятие, определяется целями, для которых нам нужно это определение. Не зная целей, я не могу выбрать определение; не зная определения, я не могу ответить на вопрос.
Но, думаю, что всё же в ассемблере типы есть, причём даже в любом ассемблере. Например, в дурацком intel'овском синтаксисе постоянно приходится выполнять явные приведения типов при доступе к памяти по адресу. Писать всякие там dword ptr, и прочие. Значения бывают разных размеров, и на это приходится оглядыватся, потому что не все операции автоматически расширяют или сужают эти размеры. Иногда можно взять и загрузить байт в 64-х битный регистр -- недостающие биты будут забиты нулями, иногда это не работает, и требуется использование специальной инструкции.
То есть, если глянуть с той точки зрения, что любая команда принимающая какой-либо аргумент, ожидает в качестве аргумента не вообще всё что угодно, а нечто, удовлетворяющее вполне определённым правилам, то есть какое-то значение определённого типа. В том же at&t синтаксисе, допустим, такой типизации больше: если я пишу movq, значит ассемблер ожидает два аргумента -- 64-х битный источник, и 64-х битный приёмник. Или может быть источник может быть меньше?... Я не помню, с 64-х битной системой команд я знаком скорее понаслышке: понимать код понимаю, а написать не могу.
> что есть тип? в ассемблере есть понятие типа?db dw dd dq
mul, imul, idiv, scasb,scasw, PCMPISTRI
Оно?
ну и что значить db ? - Define constant byte(s) эт разве тип ?
Да, это тип. Если русским языком пытаться обозначить этот тип, то выйдет что-то типа "байт в оперативке с конкретным адресом". Хотя, нет, вру. Не всегда с конкретным, это может использоваться и в объявлении структуры, и там уже конкретного адреса нет, только смещение относительно начала структуры.
> что-то типа "байт в оперативке с конкретным адресом".этот "байт в оперативке" и число и строковый символ и последовательность битов - где тут тип ?
То есть, смущает то, что тип имеет несколько разных свойств? Или то, что наше интуитивное понимание того, как надо разбивать множество всех возможных значений на типы-подмножества?
Если первое, то C сохраняет все эти свойства байта, и ничего, он считается типизированным языком. Он разделяет знаковые/беззнаковые байты, считая их представителями разных типов, и абстрагируется от места хранения байта -- уже не идёт речи о том, лежит ли он в .data или на стеке или в регистре, все байты лежат в переменных, а какой тип памяти выступает бекендом к этой переменной уже проблемы компилятора -- но всё остальное остаётся так же как и в ассемблере.
Если же смущает второе, то вообще-то, если мы глянем, например, на ООП, мы увидим, что там неоднозначность проведения границ между типами, неоднозначность деления на типы постоянно используется, но с определёнными ограничениями правда, скажем может требоваться древовидное деление. Базовый тип наиболее общий, он содержит в себе множество значений объединяющий множества всех значений всех производных типов.
Если мы глянем в Common Lisp, мы увидим возможность объявить тип (or character integer), то есть заявить, что переменная может содержать либо символ, либо целое число. Или мы можем объявлять более дробные типы, вплоть до того, что можем указать предикат, для проверки принадлежности к типу, например, можно объявить множество простых чисел, и получать рантайм ошибки при попытке положить не простое число в переменную такого типа.
Границы типов -- это условность, которая определяется целями, ради которых эти типы придумали.
>>То есть, смущает то, что тип имеет несколько разных свойств?)) так у нас уже "тип" имеет свойство?
>>>То есть, смущает то, что тип имеет несколько разных свойств?
> )) так у нас уже "тип" имеет свойство?А почему нет? Мы объединяем элементы в множество по каким-то принципам, так? Все эти элементы имеют какие-то общие для них свойства. Я не вижу ничего странного в приписывании этих свойств элементов всему множеству -- с точки зрения теории множеств это может быть не хорошо, за строгостью речи надо следить и всегда различать множество и элемент множества, но с чисто практической точки зрения это удобно. Ну, или если ты не согласен с этими вольностями речи, я могу перефразировать своё предыдущее сообщение, с тем чтобы формулировки были бы достаточно строгими.
[add]
Хотя, бывают свойства и у множеств. Если взять множество целых чисел, то у него есть свойство замкнутости по сложению: сумма любых двух элементов этого множества будет элементом этого множества. Это не свойство какого-то элемента, это свойство именно множества. Впрочем, если мы говорим о том, что байт имеет восемь бит, но это всё же, скорее свойство байта, то есть элемента множества, а не свойство множества. Или может это всё глупая игра словами.
коментарий без единого слова "тип" )) с выше описанным - соглашусь, есть понятие свойства (свойства как элементов, так и самих множеств), а давайте уйдём в начало, зачем нужен тип и для чего Рассел ввёл это понятие (якобы во избежания найденный им же парадоксов (антиномий) в теории множеств). Советую прочитать соответствующий трёхтомник Рассела.пс: в программирование понятие "тип" сводится всего лишь к размеру занимаемой памяти. И говоря о разном типе строк я считаю - не правильным, так как эти якобы разные типы строк в памяти могут занимать один и тот же размер, и иметь одинаковые значения как минимум всё из нулей и единиц.
> коментарий без единого слова "тип" ))Ну это закономерный приём. Если оппонента смущает какое-то слово, надо пользоваться синонимами.
> с выше описанным - соглашусь, есть
> понятие свойства (свойства как элементов, так и самих множеств), а давайте
> уйдём в начало, зачем нужен тип и для чего Рассел ввёл
> это понятие (якобы во избежания найденный им же парадоксов (антиномий) в
> теории множеств). Советую прочитать соответствующий трёхтомник Рассела.Почему лишь Рассела, а не сразу Декарта? Или даже лучше Сократа наверное почитать. Обязательно ведь взять какую-нибудь древность и читать её: чем раньше автор умер, тем больше он понимал в том, о чём писал, так ведь? И даже в том, о чём он не писал, он понимал лучше, надо только хорошенько поискать в его текстах, понимая его слова не прямо, а метафорически.
Кстати математики вполне себе одолели парадокс Рассела, зайдя к теории множеств несколько иначе. Там вся проблема была в неопределённом местоимении "все".
> пс: в программирование понятие "тип" сводится всего лишь к размеру занимаемой памяти.
Нет. Совершенно нет. Теория типов ушла очень далеко от идей Сократа. Не читай древних, читай современных авторов. Начни с википедии и двигайся дальше по ссылкам. Или возьми какой-нибудь язык отличный от ассемблера и посмотри там. 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, и сейчас просто гадаю о том, как оно может быть.
>>Ну это закономерный приём.ну я в принципе ждал ответа вроде этого: "тип" - это .....
Приведу выдержку из википедии (по вашему совету):
""" Теория типов
В математике, логике и компьютерных науках теорией типов считается какая-либо формальная система, являющаяся альтернативой наивной теории множеств, сопровождаемая классификацией элементов такой системы с помощью типов, образующих некоторую иерархию. Также под теорией типов понимают изучение подобных формализмов.Теория типов — математически формализованная база для проектирования, анализа и изучения систем типов данных в теории языков программирования (раздел информатики). Многие программисты используют это понятие для обозначения любого аналитического труда, изучающего системы типов в языках программирования. В научных кругах под теорией типов чаще всего понимают более узкий раздел дискретной математики, в частности λ-исчисление с типами.
Современная теория типов была частично разработана в процессе разрешения парадокса Рассела и во многом базируется на работе Бертрана Рассела и Альфреда Уайтхеда «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), для архитектуре и подавно главное размер регистра.
>>То есть даже с точки зрения размера -- это разные типы.
я вот об этом же - кроме как "тип" как размер регистра(ячеек памяти) для архитектуры другого нет. Зачем всё усложнять? Я был бы рад если бы архитектура строго выделяла бы все описанные выше "типы", но она этого не делает, и нужность (необходимость) этих "типов" - увы не доказана даже в теории. Главный вопрос - зачем ввели эту теорию типов - остаётся открытым.
Во. С этого надо было начать. Я с самого начала подозревал некорректное использование редукционизма, но никак не мог вас из этого вытянуть в явном виде. А спорить со своими спорными интерпретациями у меня нет никакого желания: есть немалый печальный опыт подобных споров, и сегодня я тщательно избегаю его повторения.[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, хотелки человека заключаются в чём-то другом. И связь между хотелками человека и необходимостью вычистить язык от явных преобразований типов может устанавливаться, в частности, и формальными доказательствами. Местами это возможно, и местами это делается. Но чтобы найти такие теоретические доказательства, надо взять конкретную фишку языка, подумать о том зачем разработчик её привнёс в язык (не "зачем это надо мне", а именно "зачем это было надо разработчику языка" -- некоторые не умеют различать эти два вопроса, а зря), и вот потом, двигаясь от целей разработчика искать обоснования, и там иногда можно встретить и формальные доказательства.
ЯП -- это инструмент. Такой же как и лопата. Если нам придёт в голову построить теорию лопаты, то мы будем двигаться от тех целей, для которых лопата предназначена. Вряд ли мы будем исследовать, какие свойства лопаты помогают или мешают использовать её для выкручивания винтов с крестовым шлицом из механизма наручных часов. ЯП -- это инструмент, в отношении которого есть какие-то ожидания о том, для каких задач он подходит, а для каких нет. И двигаясь от этих ожиданий можно обосновать те или иные решения принятые разработчиками ЯП. Или обратно: разглядывая решения, принятые разработчиками, можно предположить их ожидания и цели.
> Главный вопрос - зачем ввели эту теорию типов - остаётся открытым.
Я ни на что не претендую, но надеюсь, что здесь мне удалось накидать достаточное количество ниточек, за которые можно потянуть, и в конечном итоге распутать клубок этого открытого вопроса. Я надеюсь, что мне удалось донести мысль о том, что если смотреть на высокоуровневый ЯП с точки зрения ассемблера и любые утверждения об этом языке переводить в термины ассемблера, то можно быть практически уверенным в том, что этот высокоуровный ЯП и все утверждения о нём станут бессмысленными, глупыми и вообще нехорошими. И что такой результат -- это не потому, что утверждения действительно такие, и не потому, что все разработчики высокоуровневых языков идиоты (а среди них есть очень даже умные люди, с огромным опытом программирования), а следствие того, что мы при редукции теряем смысл утверждений, а потом воюем с соломенным чучелом. Ну и блистательно побеждаем.
Простите. nginx отвалился по таймауту пока постил, и я прежде чем подумать, зачем-то ещё раз отправил. Тупанул, каюсь.
небольшое дополнение:на той же "Машине Тьюринга" можно выполнить любой разрешимый алгоритм? там есть понятие "типа"?
> ну и что значить 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)
Чем не тип?Ну где тут тип?
На нем GUI можно или как у go - удел сетевых уно-файл&уно-сервис?
> На нем GUI можно или как у go - удел сетевых уно-файл&уно-сервис?https://crates.io/search?q=ui
https://crates.io/search?q=gui
А также:
https://godoc.org/?q=ui
https://godoc.org/?q=gui
> Перед блоком "‹...›" теперь допустимо указание опционального разделителя "::" в любом контексте
> my_macro!(Vec::‹i32›::new); // Теперь можно указать и такАвторам не стоит на этом останавливаться. Нужно добавить еще опциональных разделителей, совершенству нет предела.
С виду язык похож на пародию на C++. Если он станет популярен, в коде у программистов будет полная анархия.
> С виду язык похож на пародию на C++что тебя удивляет, если его написали программисты на c++, решившие что сейчас они покажут миру, как правильно придумывать языки?
> Если он станет популярен,
уже стал.
>> Если он станет популярен,
>уже стал.И что же значимое на нём написали? Не начали переписывать, а мля доделали? Ничего?
> Авторам не стоит на этом останавливаться. Нужно добавить еще опциональных разделителей,
> совершенству нет предела.главное, сохранить концепцию - все они должны набираться с зажатым shift, в крайнем случае - требовать обязательного чередования shift-и не-shift символов, ни в коем случае не разделяясь пробелами.
Каждый раз, как я вижу в языке двоеточия и тому подобный жыр в синтаксисе - я точно знаю, что его изобрел неумелец слепого набора.
> Каждый раз, как я вижу в языке двоеточияПрошло 5 часов, а список языков без двоеточий в вашем комментарии всё ещё пустой.
Хотя в чём-то я с вами согласен.
Языка совсем без двоеточий не существует. Важна концентрация двоеточий на километр кода.
> Языка совсем без двоеточий не существуета как же petooh?
Хоронили C++, порвали три альтернативы. ©
что-то онолитеки с опеннета невзлюбили ржавчину.
Потому что его адепты ведут себя как сектанты-неосиляторы.
> Потому что его адепты ведут себя как сектанты-неосиляторы.Пока что - ни одного адепта мы тут не видили, зато куча "несектантов" уже за 40 комментариев с подгораниями^W^W о (не)нужности и (не)правильности накатали.
Ничего необычного, на новости где ожидается повышенная концентрация сектантов ожидаемо набигают тролли.
> Ничего необычного, на новости где ожидается повышенная концентрация сектантов ожидаемо
> набигают тролли.Только сектантов все еще не видать.
Да и троллей - раз-два и обчелся (прошу не путать тролля, отлично или хотя бы неплохо знающего матчасть и оперирующего недомолвками, смещенными акцентами и прочими фокусами с фактами - и обычного интернетного балабола, газифицирующего лужи в промышленных масштабах и искренне считающего себя Искуссным Троллем).
> Да и троллей - раз-два и обчелся (прошу не путать тролля ... и обычного интернетного балабола)"Только ситхи всё возводят в абсолют". На самом деле тролли по толщине все разные. Каждой аудитории -- своя толщина. :)
То, что набегают толпы толстячков, кое-что говорит об аудитории, как ни крути. ;)
Потому что сами на нем не пишут и вряд ли будут писать.
У пользователей языка совершенно другие претензии, посерьезней и намного более конкретные.
А так занимать сторону побивателя камнями (либо чем-то другим, потеплее и помягче) всегда приятно. Чувство локтя и вот это всё.
> У пользователей языка совершенно другие претензии, посерьезней и намного более конкретные.Судя по списку изменений, претензии следующие:
1. Нельзя указывать опциональный разделитель :: перед блоком <>. А иногда хочется.
2. jemalloc уже две недели как вышел 4.5.0, а у вас ещё старьё.
3. Хватит каждый релиз менять Iterator::for_each несовместимым образом!
4. Хотим, чтобы в файле пакетного менеджера вместо [replace] использовалось название [patch]. Ну и поведение тоже поменяйте как-нибудь.
>и предоставляет средства для достижения высокого параллелизма выполнения заданийможет кто знает, что-то подобное OpenACC в нем реализовано?
Подскажите, плз, кто в теме. Там подобные штуки
```
trait T1 {
const FS: usize;
fn f1(&self) -> [u32; Self::FS];
}
```
уже можно делать или пока не запилили?
Странный язык какой-то. Хелловорлд весит аж 600 килобайт. На с++ у меня целый проект с гуем, с сетью, с 3д, с кучей огромых формул, порой не помещающихся на экран монитора, и скомпиленный файл занимает чуть менее 300 килобайт. А тут одна строка в консоли - 600 килобайт! Как так-то?
Я просто оставлю ссылку на эту замечательную статью здесь: https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab...Автор понятно объясняет, почему бинарники, скомпилированные Rust, такие большие и показывает как уменьшить размер hello world с 600+ кб до 9.
То есть эталонная реализация статически линкует аллокатор, и стандартную библиотеку? Какой же всё-таки руст "безопасный" язык!
Потому что по дефолту в бинарник суется std и jemalloc, которые можно откльчить, если очень хочется помериться пипи… бинарниками. И кстати, ты еще не учел, что в твой проект кроме этих 300 килобайт еще входит стандартная библиотека С++, проста она линкуется динамически
А теперь возьми свой замечательный бинарник с гуем, сетью, 3d и формулами и попробуй запустить на машине с той же ОС, но без libstdc++ и прочих либ. Почитай, что он напишет, потом посмотри на вывод ldd.
без операционки и с процессором другой архитектуры. нет - полумерам!
А что же ты сам полумерами ограничился? Если уж косишь под дурачка, то на полную катушку, предложи запустить вообще без компьютера.
> без операционки и с процессором другой архитектуры. нет - полумерам!Тебе вообще-то мягко намекнули, что в растовом бинарнике куча всего библиотечного понапихано. А вообще, вопрос изначально был дурацкий. На него вечный ответ "запусти ldd и поймёшь, почему бинарь сишной программы весит меньше".
Так и запишем, разделяемый рантайм ниасилили.
У меня прошивка контроллера в 32кбайт флеша влазит.Никаких shared lib, ядер и т.д.
Зато куча формул, сеть, протокол.
Он даже уродливее C++
> Он даже уродливее C++Что поделаешь, любой язык расширяющий синтаксис Си будет смотреться уродцем, кроме самого Си.
> язык расширяющий синтаксис СиСлишком толсто. Даже по меркам опеннета.
C# вполне себе конфетка (по синтаксису), вот если бы он компилировался в нативный код
К сожалению для 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)
{
....
}
Кстати, гораздо лучше (и новее) Adobe Rust. Поддердивает kind-ы (вызовы типа kindof()) например. Ещё можно мержить переменные.
А корованы там можно?