The OpenNET Project / Index page

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

Mozilla разрабатывает новый язык программирования Rust

01.12.2010 13:03

Представители проекта Mozilla разрабатывают новый мультипарадигменный язык программирования Rust. Изначально, проект Rust был основан Грейдоном Хоаре (Graydon Hoare) в 2006 году, в 2009 году проектом заинтересовалась компания Mozilla Corporation и включилась в его разработку. Исходные тексты проекта распространяются в рамках лицензии BSD.

Список базовых возможностей:

  • Ориентация на безопасность:
    • Аккуратная работа с памятью - никаких нулевых и потерянных указателей. Автоматическое управление памятью;
    • Контроль изменчивости. Объекты неизменяемы (Immutable) по умолчанию;
    • Безопасность динамического выполнения: обработка сбоев, исключения, ведение лога, RAII / dtors;
    • Typestate: возможность определения сложных инвариантов, контролирующих структуры данных.
  • Ориентация на параллельность и эффективность кода:
    • Явный контроль памяти, контролирование схемы распределения памяти;
    • Крайне легкие задачи, формируемые в виде сопрограмм. Лёгкость в порождении тысяч и миллионов подпроцессов;
    • Итераторы стека (фактически лямбда-блоки без распределения кучи);
    • Статическая, нативная компиляция с созданием исполняемых файлов ELF, PE, Mach-o;
    • Прямой и простой интерфейс для кода на языке Си;
  • Ориентация на практическое применение:
    • Мультипарадигменный, исключительно функциональный, императивно-процедурный, объектно-ориентированный, поддерживающий параллельную actor-модель;
    • Функции первого класса с биндингами;
    • Нет номинальных типов или иерархии типов;
    • Мультиплатформенный, поддерживается Windows, Linux, MacOS X;
    • Хранение строк в UTF8, разнообразие низкоуровневых типов;
    • Работает с существующими нативными наборами инструментов: GDB, Valgrind, Shark и т.д.;
    • Практическая возможность нарушения правил: возможность игнорирования правил безопасности, если чётко указано, когда и как их нарушать.
Ответы разработчиков на вопросы "почему и зачем?" вкратце сводятся к следующему:
  • Существующие языки этого уровня абстракции и эффективности неудовлетворительны, в частности своим отношением к безопасности и плохой поддержкой параллелизма;
  • Целями проекта не являются: применение конкретных сверх-современных технологий; предпочтение выразительности, минимализму и элегантности перед другими целями; полный охват системного языка вплоть до степени "можно написать ядро"; охват полного набора возможностей C++ или любого другого языка - функциональность, охватывающая все наиболее употребительные возможности; 100%-ная статичность и безопасность; возможность работы на любой платформе.
  • Ни одна из частей ещё не готова к запуску в производство. На данный момент существует bootstrap-компилятор на Ocaml со множеством ошибок и отсутствующим функционалом; неполная, но рабочая версия runtime-библиотеки; некоторые тесты и документация; слабые зачатки стандартной библиотеки.
  • Участие компании Mozilla Corporation в проекте не предполагает внезапной переработки браузера, смысл её участия в экспериментировании и проверки некоторых возможностей. Каких-либо конкретных планов по реальному использованию на сегодня не существует, эти возможности будут зависеть от проявленного интереса сообщества.
  • Основная работа выполняется работниками Mozilla Corporation, основными правами владеет Mozilla Foundation, что не является необычным для разработки, спонсируемой крупными компаниями или организациями. Выбор Github, а не традиционных для Mozilla инструментов, таких, как Mercurial/Bugzilla/Tinderbox, продиктован особенностями самого Git, в частности быстрым прогрессом в развитии Git с того времени, как была выбрана Mercurial для основных нужд разработки в Mozilla, сниженные административные формальности для работы с кодом и т.п.


  1. Главная ссылка к новости (http://www.readwriteweb.com/ha...)
  2. Mozilla is Designing a New Programming Language Language Called Rust
  3. Project FAQ
Автор новости: JT
Тип: К сведению
Короткая ссылка: https://opennet.ru/28837-mozilla
Ключевые слова: mozilla, lang, Rust
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (103) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, emg81 (?), 14:28, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    объясните, пожалуйста, не-программисту, чем их существующие не устроили?
    я думал, что их уже столько, что всем для всего хватит.

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

    минусуйте, если хотите - свое мнение я высказал и не претендую на соответствие истине, это лишь моё мнение

     
     
  • 2.2, выше (?), 14:34, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    >объясните, пожалуйста, не-программисту, чем их существующие не устроили?

    Тем, что не устроили.
    Эволюция (не по Ламарку) расставит всё на свои места.

     
     
  • 3.5, Oles (?), 14:37, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Это при условии что программисты будут размножаться и умирать со скоростью бактерий.
    А без этого тысячи языков программирования без существенной разницы только будут мешать развитию.
     
     
  • 4.6, выше (?), 14:45, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Никто и не говорит, что процесс оптимальный.
    Оптимальных процессов развития пока не придумали, хотя за последних 100 лет есть некоторый прогресс, но человечество не очень рвётся его принять.
     
  • 4.30, DeadLoco (ok), 16:34, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +22 +/
    > Это при условии что программисты будут размножаться и умирать со скоростью бактерий.
    > А без этого тысячи языков программирования без существенной разницы только будут мешать
    > развитию.

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

    Это нормально, никому не мешают эти тысячи языков, у них своя собственная, очень нужная всем жизнь.

     
     
  • 5.36, Аноним (-), 16:49, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну это совсем дарвинизм.
    Вообще задача прогресса в такой среде, это выделять и подкармливать удачные комбинации, помогать им расти, создавать остальным лучшие условия.
    Без этого никакой С++ не вырастит, что уж говорить про Жабу.

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

    Хотя врядли конечно.

     
     
  • 6.40, DeadLoco (ok), 17:01, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да Ох, ошибаетесь Каждый вид сам должен пробиться и выжить в конкурентной бо... большой текст свёрнут, показать
     
     
  • 7.42, Oles (?), 17:07, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Каждый вид сам должен пробиться и выжить в конкурентной борьбе с другими видами в этой нише.

    как буд-то у вас есть пару сотен миллионов лет в запасе

     
     
  • 8.45, DeadLoco (ok), 17:19, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Разница в том, что мутабильность языковой среды в сотни раз превышает мутабильно... текст свёрнут, показать
     
  • 7.49, Аноним (-), 17:42, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ох, ошибаетесь...

    Ну, например интернет, которым вы сейчас пользуетесь, был подкормлен DARPА'ой.
    Железные дороги, медицина и космос - принципиально убыточные.
    Можете делать выводы.

     
  • 7.57, анонимм (?), 18:11, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи

    Да уж поменьше, чем в сипэпэ и похапэ

     
  • 7.68, Вася (??), 18:59, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Вспомните, сколько бабла было ухнуто в визуал-бейсик и делфи. И где теперь эти языки?

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


     
     
  • 8.95, anonymous vulgaris (?), 22:42, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А что много За Васик не скажу, но Дельфя у Борланда Кодгера всегда была на втор... большой текст свёрнут, показать
     
  • 8.104, Андрей (??), 21:11, 02/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Паскаль давно умер, кроме стран СНГ, где им ещё продолжают мучить подрастающее п... текст свёрнут, показать
     
  • 3.25, DeadLoco (ok), 16:27, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нажал плюс за понимание эволюционного характера технического прогресса.
     
  • 2.3, Devider (ok), 14:36, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Посмотрите статистику языков (ну например http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html). Языков 100500, а пишут все все равно на С\С++ и Java. Ну это очередной "еще один".
    >ни один существующий дистрибутив Linux меня не удовлетворил, и я решил сделать пятьсот первый

    ИМХО Вы ответили на свой вопрос. )

     
     
  • 3.11, Serega (??), 14:59, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    вы не учитываете что из академических языков фичи перекочёвывают в мейнстрим-языки. Сравните Java 1.4 и Java 7, C++98 и C++0x

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

    А про конкретно этот язык и его цели - ну что ж, плох тот солдат, который не мечтает стать генералом :)

     
  • 3.99, emg81 (?), 23:25, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    спасибо :)
     
  • 2.4, Аноним (-), 14:37, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >я думал, что их уже столько, что всем для всего хватит.

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

     
     
  • 3.14, Devider (ok), 15:10, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Идеала-то? Так его нигде нет.
     
  • 2.7, vle (ok), 14:47, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    http://en.wikipedia.org/wiki/Not_Invented_Here

    Что касается обозначенных целей и задач, то этот "новый" язык
    в чем-то похож на гугловский Go или, скажем, Erlang.
    Это если ставить легковесность потоков во главу угла.
    Все остальное -- просто пустой треп.
    Ничем не лучше, например, Lua, где все то же самое,
    и мультипарадигменность и сборщик мусора и легкая встраиваемость
    и интеграция с "С" и прочее и прочее.

     
     
  • 3.15, sk (??), 15:19, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    глупости. Где в Луа статическая типизация и контроль мутабельности? Луа с таблицами как основной структурой данных трагически мутабелен. Там есть корутины, которые позволяют писать в конкуррентной парадигме, но мультитредовость и луа плохо совместимые вещи, поэтому оно concurrent, но не parallel, если не считать разного рода самоделок поверх основной реализации.
     
     
  • 4.16, vle (ok), 15:38, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Где в Луа статическая типизация и контроль мутабельности?

    Если нужен чуть-более статически типизированный язык, можно взять Pike,
    тоже скриптовой.
    Если нужно аж чтоб совсем завернуться, можно взять SML или Caml.
    Если не выпендриваться, сойдут Java, Oberon-2 и многие многие тысячи других,
    вполне себе безопасных.

    Зачем нужен "контроль над мутабельностью" я пока себе слабо представляю.

    > Там есть корутины, которые позволяют
    > писать в конкуррентной парадигме, но мультитредовость и луа плохо совместимые вещи,
    > поэтому оно concurrent, но не parallel,

    Про Go и Erlang я уже сказал.

     
     
  • 5.23, sku (ok), 16:16, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >> Где в Луа статическая типизация и контроль мутабельности?
    > Если нужен чуть-более статически типизированный язык, можно взять Pike,
    > тоже скриптовой.

    тут дело в чём, этот раст не просто "статически типизированный" в смысле C, он умеет много хорошего и полезного, вроде disjoint union types и typestate, который, в частности, позволяет исключить класс ошибок обращения к неинициализированным данным или использования null pointers.
    > Если нужно аж чтоб совсем завернуться, можно взять SML или Caml.

    Rust позиционируется, как "язык для системного программирования" и ограничивает возможности системы типов исходя из соображений эффективности и багоустойчивости, идей, которые не проверены эдак тремя-четырьмя десятками лет, там нет. За вычетом этого Rust и ML немного похожи, что неудивительно, так как автор (Graydon Hoare) фанат Ocaml'я и компилятор Rust'a большей частью на окамле же и написан. Однако SML/Caml не подходят для той ниши системного программирования, в которую целится Rust. Не подходят, в частности, потому, что не поддерживают то самое RAII, не дают возможности подкрутить сборку мусора, не поддерживают прямых вызовов C. В этой нише сейчас только, фактически, намечаются три языка: C, Rust, BitC. Два последних ещё в колыбели. D для этой ниши великоват, он прямой последователь языка C++, не хочется даже думать об использовании D где-нибудь в embedded, месте где C благодаря простоте рантайма хорошо себя проявляет. Но C когда был сделан, пора бы уже как-то смениться поколениям.

    > Зачем нужен "контроль над мутабельностью" я пока себе слабо представляю.

    Формально иммутабельность дает коду свойство, называемое referential transparency: если просто, то функция, будучи вызванной с одним набором параметров, всегда возвратит один и тот же результат. Это очень упрощает рассуждения о корректности кода. В случае с наличием мутабельности дело усложняется, результаты зависят от _времени_: какое сообщение было получено объектом раньше, если мы говорим терминах message passing'a и тому подобное. Что в этом плохого: почти все баги, возникающие при concurrent программировании: злополучные races итп., растут из мутабельности и расшаривании мутабельного состояния.
    При отсутствии по умолчанию мутабельности концепция времени _неявно_ в код не затаскивается, надо явно указывать, что и где будет мутабельным. Это относительно новая для CS идея, которую стали принимать как имеющую практическое применение в конце 70-х, наверное, когда Стилом была доказана эффективность функциональных языков ("Debunking Myths" и другие Lambda Papers). Эта идея получила развитие в конце 80-х, когда Уодлером была придумана концепция монад как, в частности, и средство контроля над мутабельностью. Но монады штука слишком новая для системщиков, поэтому её появления в обозримом будущем в языках этой ниши не стоит ждать. Авторы Go ещё более осторожны и дальше результатов годов 60-х не идут, считая, что этого достаточно (Update: неверно, Hoare, CSP 1978). Кому-то и Си достаточно. Кому-то хочется средств исключения классов ошибок, предоставляемых статической типизацией.

    > Про Go и Erlang я уже сказал.

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

     
     
  • 6.33, VoDA (ok), 16:37, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Формально иммутабельность дает коду свойство, называемое referential transparency: если просто, то функция, будучи вызванной с одним набором параметров, всегда возвратит один и тот же результат.

    А как же быть с внешними вызовами? Вызов одной и той же функции с одним и тем же запросом к СУБД может вернуть разные результаты. То же самое с ФС и т.п.

     
     
  • 7.37, sku (ok), 16:52, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут контроль над мутабельностью и нужен, в хаскелле такие вещи оборачиваются в м... большой текст свёрнут, показать
     
     
  • 8.38, sku (ok), 16:54, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Mozilla разрабатывает новый язык программирования Rust... текст свёрнут, показать
     
  • 6.41, Tav (ok), 17:03, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Мутабельность, иммутабельность... По-русски это называется изменяемостью и неизменяемостью.
     
  • 6.53, vle (ok), 17:54, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Для типичных прикладных задач и большинства системных, за исключением разьве что... большой текст свёрнут, показать
     
     
  • 7.55, yk4ever (?), 18:02, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Для касается ембеда, то там тем более иимутабельность не нужна.
    > Лишние накладные расходы и абсолютно никаких выгод. См. бенчмарки ruby
    > против Lua/Go.

    По-вашему, Ruby тормозит из-за иммутабельности?

    Очень любопытно.

    Я вам поведаю неожиданное: в Ruby строки как раз мутабельные, а в Python нет. И при это Python как правило быстрее Ruby.

    А ещё можно сравнить на бенчмарках Perl (мутабельные строки) vs Haskell (иммутабельные). Угадайте, кто быстрее?

    Впрочем, если хотите быть дежурным чепухоносиком темы - нет препятствий патриотам :]

     
     
  • 8.59, vle (ok), 18:15, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет конечно Скорее всего там миллион причин И Питон и Руби -- тормозные, монст... текст свёрнут, показать
     
     
  • 9.61, yk4ever (?), 18:17, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И такая позиция бывает Но не совсем понятно тогда, зачем вы так смело рассуждае... текст свёрнут, показать
     
  • 7.58, sku (ok), 18:12, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Lua хороший выбор, стабильная реализация, хорошие библиотеки, сам он поднимается... большой текст свёрнут, показать
     
     
  • 8.63, vle (ok), 18:30, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да пусть ковыряются, кто ж против Только вот раскрутить новый ЯП примерно так ж... текст свёрнут, показать
     
     
  • 9.64, sku (ok), 18:40, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Idris это попытка 2010 г совместить зависимые типы и программирование системн... большой текст свёрнут, показать
     
  • 7.60, sku (ok), 18:16, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Для типичных прикладных задач и большинства системных, за исключением разьве что
    > сетевых приблуд, иммутабельность абсолютно не нужна.

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

     
  • 6.91, p (?), 21:26, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > языка: C, Rust, BitC. Два последних ещё в колыбели. D для

    Ada :p

     
     
  • 7.92, sku (ok), 22:14, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> языка: C, Rust, BitC. Два последних ещё в колыбели. D для
    > Ada :p

    Замечательная штука, спасибо.

     
  • 5.28, VoDA (ok), 16:30, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по всему Immutable объектов дает возможность функционального программирования. Или ФП возможен только при Immutable объектах.

    Дальше функциональное программирование теоретически легко параллелится. В отличии от С/С++/Java, где для распараллеливания нужно писать код руками (или пользоваться спец средствами типа JavaEE серверов, где обработка запросов идет параллельно, но сами запросы не параллелятся дальше).

     
     
  • 6.96, gegMOPO4 (ok), 22:43, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Судя по всему Immutable объектов дает возможность функционального программирования. Или
    > ФП возможен только при Immutable объектах.

    Помимо этого, для неизменяемых объектов вместо хитрого сборщика мусора с разрешением циклических ссылок можно применять просто подсчёт ссылок -- а значит время уничтожения детерминировано, отсюда возможность деструкторов и RAII. А важность последнего постепенно начали понимать и за пределами C++. И это радует.

     
  • 4.24, vle (ok), 16:17, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В конце концов, нужно различать собственно язык
    программирования и его реализацию. Если очень уж хочется
    добиться чего-то конкретно, берешь готовый ЯП с наработанными
    уже для него библиотеками и пишешь другую РЕАЛИЗАЦИЮ,
    как это делают любители CLisp, Scheme, CAML, SML и прочих
    "Паскалей" и "С".
    Языков, на уровне парадигм и спецификаций не противоречащих целям,
    практически любым, найти можно полно.
     
     
  • 5.32, sku (ok), 16:35, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В Scheme dynamic latent typing реализацией не исправишь Нужно делать другой язы... большой текст свёрнут, показать
     
     
  • 6.56, vle (ok), 18:11, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Дело не конкретно в схеме или паскале Дело в подходе Строить новый велосипед, ... большой текст свёрнут, показать
     
  • 3.103, botman (ok), 19:57, 02/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    http://en.literateprograms.org/Category:Environment:Portable

    Пока этот "язычёк" не появится на подобных вышеприведённому ресурсах - он будет бесполезным языком. Согласен, пока что у Lua и Erlang больше шансов быть хотя-бы академическим языком.

     
  • 2.8, Аноним (-), 14:52, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если придумывают новые, значит не все так как хотелось бы со старыми. Да и только наивный дурак будет утверждать, что человечество на пике своего развития в теории и практике программирования. Мы сейчас на уровне обезьянок в этой области, сделали пару шажков на пути до Луны.

    А насчет Rust'а, я предрекаю ему скорейшую смерть. Объяснять почему не буду, субъективное мнение, все равно в этой области никто ничего не понимает, объективным быть трудно.

     
  • 2.13, Ананим (?), 15:09, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Например:
    мне нравится rexx за его простоту и логичность - код тпа
    ...
    if then=if then say if/9+say*then
    ...
    внём выполнится как и задумано и не будет "выкрика" интерпритатора/компелятора о том что тут синтаксическая ошибка...
    Но мне не нравится то, что переменные могут называться только латинскими буквами, хочу переменную обзывать не "ochen_vajnayz_peremennaya", а просто "фигня_из_файла". Что мне делать? Можно написать разработчику, а можно взять исходники, подковырять их, дав возможность не только переменные кирилицей писать, но и операторы (if - ежеле, then - тады, say - изложи,...) и выкладываю, вдруг кому из староверов сгодиться...
    Вот так и создаётся куча языков/дистрибутивов/генно-модефицированых продуктов и т д...
     
  • 2.105, StrangeAttractor (ok), 04:15, 08/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > это выглядит как "ни один существующий дистрибутив Linux меня не удовлетворил, и я решил сделать пятьсот первый"

    И что в этом плохого? Imho вполне логично.

     

  • 1.9, V (??), 14:57, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    если он будет как XUL, то я против ))
     
  • 1.10, FractalizeR (ok), 14:57, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Язык неизменяем (Immutable) по умолчанию;

    Это как?

     
     
  • 2.17, Аноним (-), 15:47, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Все переменные по умолчанию константы.
     
     
  • 3.18, FractalizeR (ok), 15:49, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Все переменные по умолчанию константы.

    Гм. А это как? И зачем?

     
     
  • 4.31, Аноним (-), 16:34, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Учите Haskell :)
     

  • 1.12, Аноним (-), 15:08, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >Мультипарадигменный, исключительно функциональный, императивно-процедурный, объектно-ориентированный, поддерживающий параллельную actor-модель;

    "Я одену все лучшее сразу".

     
  • 1.19, Аноним (-), 15:52, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хранение строк в utf8...
     
  • 1.20, vle (ok), 15:52, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > UTF8 strings.

    Сколько же поколений будет наступать на одни и те же грабли :-/

     
     
  • 2.22, Crazy Alex (??), 16:10, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А чем UTF для строк не угодил, собственно? Максимум, что еще нужно - альтернативные строки, хранимые как массивы 32-битных символов со свободным преобрахзованием между этими двумя вариантами.
     
     
  • 3.27, vle (ok), 16:28, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А чем UTF для строк не угодил, собственно? Максимум, что еще нужно
    > - альтернативные строки, хранимые как массивы 32-битных символов со свободным
    > преобрахзованием между этими двумя вариантами.

    Тем, что в 21-м веке - это просто маразм. Для внутреннего представления
    строк лучше всегда использовать 32-битные символы,
    и забыть про все эти замшелости
    типа utf-8. "Свободное преобразование" в utf-8 и обратно IIRC сделано
    как раз в Pike. Удовольствия полные штаны.

     
     
  • 4.34, yk4ever (?), 16:37, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Дык UTF-32 ведь память будет жрать безбожно. Современные языки жонглируют в памяти кучей ASCII-идентификаторов, для них UTF-8 в самый раз. И вообще, строки в наши дни в основном обрабатывают поточно, равноширинность не критична.
     
     
  • 5.43, vle (ok), 17:12, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Дык UTF-32 ведь память будет жрать безбожно.

    Не будет. Это копейки.

    > Современные языки жонглируют в памяти
    > кучей ASCII-идентификаторов, для них UTF-8 в самый раз.

    Как работает сам интерпретатор/компилятор мне все равно, не об этом речь.

    > И вообще, строки
    > в наши дни в основном обрабатывают поточно,

    Ввод/вывод в кодировке, заданной локалью, например utf-8.
    Внутреннее представление -- всегда 32бита. Все очень просто.

    > равноширинность не критична.

    Критична. Например в регекспах и вообще практически
    любых операциях над строками.
    Верх маразма -- это хранить вместе со строкой еще и кодировку
    и перекодировать по мере требования. Чему людей только в школе учили?!

     
     
  • 6.44, yk4ever (?), 17:16, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Дык UTF-32 ведь память будет жрать безбожно.
    > Не будет. Это копейки.

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

    >> равноширинность не критична.
    > Критична. Например в регекспах и вообще практически
    > любых операциях над строками.

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

     
     
  • 7.47, vle (ok), 17:30, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> Дык UTF-32 ведь память будет жрать безбожно.
    >> Не будет. Это копейки.
    > Наивное предположение. Поковыряйте дампы памяти
    > современных программ, посмотрите из чего
    > они состоят.

    Я вас умоляю. "Дампы современных программ"...

    >>> равноширинность не критична.
    >> Критична. Например в регекспах и вообще практически
    >> любых операциях над строками.
    > Нет, неправда. Регэкспы - поточны, как и большинство операций над строками.

    Нет. Большинство алгоритмов над строками как раз не поточны
    и требуют быстрый random access.

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

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

     
     
  • 8.54, yk4ever (?), 17:55, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какие именно, м split - поточный contains - поточный replace - поточный рекэксп... текст свёрнут, показать
     
     
  • 9.65, vle (ok), 18:48, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет См contains То есть известные с 60-х алгоритмы Боера-Мура или Кнута-Мориса... текст свёрнут, показать
     
     
  • 10.67, sku (ok), 18:54, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тут такое дело, Substring search is just byte string search Properties 2... текст свёрнут, показать
     
     
  • 11.74, vle (ok), 19:18, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Принято Я и говорю, примерно так, если мне не изменяет память, и сделано в Pike... текст свёрнут, показать
     
     
  • 12.77, yk4ever (?), 19:28, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    И по этой в том числе Там же рефлексия есть Все имена объектов и методов плава... текст свёрнут, показать
     
     
  • 13.86, VoDA (ok), 20:23, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А как связана рефлексия и потребление памяти Или рефлексия и потребление CPU О... текст свёрнут, показать
     
     
  • 14.89, yk4ever (?), 21:17, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Напрямую Все данные для рефлексии обязаны валяться в куче рантайма Потому что ... текст свёрнут, показать
     
  • 12.94, gegMOPO4 (ok), 22:33, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Не подскажете ли размер символа в Жаве ... текст свёрнут, показать
     
     
  • 13.98, yk4ever (?), 22:57, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Увы, в данном случае товарищ прав Жабовский char - всегда ровно два байта Подд... текст свёрнут, показать
     
  • 10.70, yk4ever (?), 19:01, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Кнут-Моррис-Пратт и Бойер-Мур практически поточные Никто не мешает реализовыват... текст свёрнут, показать
     
  • 6.48, User294 (ok), 17:30, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Не будет. Это копейки.

    Ага. До тех пор пока не потребуется работать с большим количеством строк, например. А когда встанет вопрос - сожрать N памяти или 4N под одну и ту же операцию, станет совсем не прикольно. Никто не спорит что у UTF-8 есть свои дебилизмы как то отсутствие четкого понимания что N байтов - это гарантированно ровно M символов, что совсем не упрощает скажем взятие 125-й уникодной буквы из вон того массива. Но зато для английского текста он кушает в 4 раза меньше памяти, а для русского - в два. И конверсия на лету - будет проц грузить. И весь внешний мир и другие программы оперируют отнюдь не в 32-битном уникоде, так что конверсии обеспечены (или ваша сферическая программа работает в вакууме?). В общем напрашивается вывод что некоторым зажравшимся товарисчам уже некуда девать оперативку и вычислительную мощь проца. Ну вот вы такими программами и пользуйтесь, имхо.

     
     
  • 7.66, arturpub (ok), 18:51, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это во-первых, а во-вторых у них с UCS4 все вроде красиво, пока не...
    http://en.wikipedia.org/wiki/Unicode_equivalence

    Но ведь для них все это слишком сложно? ;)

     
     
  • 8.71, yk4ever (?), 19:03, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ещё про byte order забыли И про non-zero-byte-safe окружения ... текст свёрнут, показать
     
  • 6.50, sku (ok), 17:42, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В оправдание автору можно привести разве что распространенность UTF-8 сейчас  ( http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html ) и заботу о памяти. А так да, было бы удобней с UCS-4.
     
  • 4.35, VoDA (ok), 16:39, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Так внутреннее представление вообще никак не описано, описано представление для программиста и пользователя.

    И чем не угодил UTF-8 при работе с внешними системами, надписи на страничке сайта или GUI?

     
     
  • 5.46, vle (ok), 17:26, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Так внутреннее представление вообще никак не описано, описано
    > представление для программиста
    > и пользователя.

    У меня есть строка str размером в 1000000 символов на неизвестном мне языке.
    Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа.
    Есть возможность написать что-то вроде str[999000..999004] или
    substr(str, 999000, 5)? Насколько быстро выполнится эта операция?

    > И чем не угодил UTF-8 при работе с внешними системами, надписи на
    > страничке сайта или GUI?

    Для внешних систем будет то, что нужно внешним системам.
    Речь не об этом.

     
     
  • 6.51, User294 (ok), 17:47, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > substr(str, 999000, 5)? Насколько быстро выполнится эта операция?

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

    > Для внешних систем будет то, что нужно внешним системам.

    Ну да, конечно, если все заранее конвертить из utf-8 в 32-битный уникод.... проблема только в том что оно распухнет в разы (для инглиша - в 4 раза!), и кроме того, придется все данные конвертить. Так что если вам могут прислать из внешнего мира строку в N символов ее придется полностью пропарсить и сконвертить. Все N символов вообще. Что как-бы ничем принципиально не лучше substr там же, но еще и гарантированно происходит для вообще каждой строки из внешнего мира, независимо от того надо ли будет потом на ней делать substr или нет. А программы все-таки обыно не в вакууме работают, так что эта конверсия будет там и тут. Не боитесь что нужда ее делать поубивает все плюсы от возможности хапнуть N-ный символ просто и быстро?

    > Речь не об этом.

    Да никто и не спорит что utf-8 идеален. Он всего лишь компромисс. Достаточно разумный для того чтобы быть используемым в ряде ситуаций.

     
  • 6.52, yk4ever (?), 17:49, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа.

    Очень типовая задача. Большинство программ только этим и занимаются. "999000" - это вообще магическая константа

    > substr(str, 999000, 5)? Насколько быстро выполнится эта операция?

    За несколько миллисекунд на современном процессоре.

    Для одноразовой задачи - вполне достаточно.

     
     
  • 7.69, vle (ok), 19:00, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Мне нужно выделить подстроку длиной 5 символов, начиная с 999000-ого символа.
    > Очень типовая задача.

    Извлечение подстроки в строке -- типовая задача.

    > Большинство программ только этим и занимаются. "999000" - это
    > вообще магическая константа

    999000 -- это специально для тех,
    кто не знаком с элементарными основами типа O().

    >> substr(str, 999000, 5)? Насколько быстро выполнится эта операция?
    > За несколько миллисекунд на современном процессоре.

    Зачет!!! :-D
    У меня вопросов больше нет.

     
     
  • 8.73, yk4ever (?), 19:09, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, не типовая Это подзадача парсинга строки Если у вас для парсинга есть бол... текст свёрнут, показать
     
     
  • 9.79, vle (ok), 19:29, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    То есть уже на уровне языка программирования мне навязывают две лишние не нужные... текст свёрнут, показать
     
     
  • 10.80, yk4ever (?), 19:33, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, вы не поняли Это в примитивных языках вам навязана лишняя сущность смещен... текст свёрнут, показать
     
     
  • 11.82, vle (ok), 19:49, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Все я прекрасно понял Со строками Вы не работаете С ни... текст свёрнут, показать
     
     
  • 12.84, gegMOPO4 (ok), 19:58, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Какие ваши задачи ... текст свёрнут, показать
     
  • 12.87, yk4ever (?), 21:10, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Может скажете название компании и продукта Чтоб я ненароком не воспользовался ... текст свёрнут, показать
     
  • 6.76, gegMOPO4 (ok), 19:26, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С чего бы вам понадобилось выделить, начиная с 999000-ого символа? Откуда вы взяли это число? Нашли что-нибудь там? Тогда у вас есть смещение.
     
  • 6.101, VoDA (ok), 00:29, 02/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сколько вам приходилось делать подобного рода действия. И чтобы не над целой строкой, а только частью.

    У меня в практике или строка используется как есть ИЛИ парсится вся целиком и дальше разделяется на подстроки, преобразуется в числа и т.п.

    Потому и вызывает удивление.

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

    Потому вроде переопределение и интересно, но в java ее забанили. И вряд ли когда нибудь сделают.

     
  • 3.83, gegMOPO4 (ok), 19:56, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    vec[char] (char -- 32-битный). А для сложных программ, работающих с текстом, будет не только сам текст, но и деревья, аттрибуты...

     
  • 2.29, VoDA (ok), 16:33, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У вас представление строк для разработчика в чем то другом? Тогда постоянные грабли с многоязычностью... ну нах такой язык ;)

    PS внутреннее представление string может быть хоть во фракталах, если это не сильно затратно =)))

     
  • 2.75, gegMOPO4 (ok), 19:20, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они объясняют, почему так, и эти доводы разумны.

    1) Большинство внешних текстовых данных -- или UTF-8, или ASCII (подмножество UTF-8). Тратиться на перекодировку при вводе/выводе жалко.

    2) Большинство простых операций со строками (итерация, поиск символа или подстроки, разбивка, определение класса символа в ASCII) прекрасно работают с UTF-8, и даже проще и быстрее, чем с UTF-32 (достаточно таблицы 2^8 для классификации и преобразования регистра в ASCII).

    3) Большинство сложных операций со строками (сортировка, переносы, изменение регистра в странных алфавитах) всё равно требуют учёта национальной специфики (локали), это очень сложная и дорогая задача, накладные расходы на раскодирование UTF-8 на этом фоне мизерны. И в UTF-32 не будет проще, всё равно нужно учитывать комбинированные символы и т.п. Это если делать на совесть. Иначе см. п. 2.

    4) Если так уж нужно работать с UTF-32 -- пожалуйста, распакуйте в vec[char] (char 32-разрядный), потом запакуете. Накладные расходы те же, что и неявные при языковых строках в UTF-32, только вы их контролируете.

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

     
     
  • 3.85, vle (ok), 20:03, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Они объясняют, почему так, и эти доводы разумны.
    > 1) Большинство внешних текстовых данных -- или UTF-8, или ASCII (подмножество UTF-8).
    > Тратиться на перекодировку при вводе/выводе жалко.

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

    > 2) Большинство простых операций со строками
    > (итерация, поиск символа или подстроки, разбивка,
    > определение класса символа в ASCII) прекрасно работают с UTF-8, и даже
    > проще и быстрее, чем с UTF-32 (достаточно таблицы 2^8 для классификации
    > и преобразования регистра в ASCII).

    Точно так же, прекрасно все работает и для строк, представленных
    в виде wide символов. Не вижу никаких выгод.

    > 3) Большинство сложных операций со строками (сортировка, переносы, изменение регистра
    > в странных алфавитах) всё равно требуют учёта национальной специфики (локали), это
    > очень сложная и дорогая задача, накладные расходы на раскодирование UTF-8 на
    > этом фоне мизерны. И в UTF-32 не будет проще, всё равно
    > нужно учитывать комбинированные символы и т.п. Это если делать на совесть.
    > Иначе см. п. 2.

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

    > 4) Если так уж нужно работать с UTF-32 -- пожалуйста, распакуйте в
    > vec[char] (char 32-разрядный), потом запакуете. Накладные расходы те же, что и
    > неявные при языковых строках в UTF-32, только вы их контролируете.

    А заодно перепишите все уже имеющиеся системные и сторонние библиотеки.

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

    Накладных расходов на память нет. Это миф.
    Несоизмеримо больше занимает то, что никак не связано со строками.

     
     
  • 4.88, yk4ever (?), 21:14, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Например, при сопоставлении с теми же регекспами. Лишний расход на пустом месте.

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


    > Накладных расходов на память нет. Это миф.

    Да, да, и системная шина тоже миф. Всё уже прямо в регистрах процессора сразу сидит.

     
  • 4.93, gegMOPO4 (ok), 22:28, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Два раза На каждый обработанный байт При вводе и выводе И много раз, если нуж... большой текст свёрнут, показать
     
     
  • 5.100, vle (ok), 00:21, 02/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Однократный ввод и вывод -- абсолютная мелочь, на которую даже не стоит обращать... большой текст свёрнут, показать
     

  • 1.21, Anon (?), 15:57, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    еще одна поделка с кейвордами типа "fn", "let"...
    а потом они будут гудеть на каждом углу что оно лаконичнее чем C...
     
  • 1.26, Erley (ok), 16:27, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Недавно в мозиллу проинвестировал кто-то дофига денег, вот и не знают куда тратить...
     
     
  • 2.78, gegMOPO4 (ok), 19:28, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Недавно? В 2009-м году.
     
     
  • 3.90, Erley (ok), 21:19, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    я имел ввиду вот это:
    http://www.opennet.ru/opennews/art.shtml?num=28710
    т.е. они заработали 104 миллиона и вот сейчас не знают куда их девать :)
     
     
  • 4.97, gegMOPO4 (ok), 22:45, 01/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сомневаюсь, что на Rust пойдёт хотя бы 1% от этой суммы.
     

  • 1.81, gegMOPO4 (ok), 19:43, 01/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На первый взгляд язык кажется перегруженным фичами. Так и есть, авторы сами признают, что сейчас обеспокоены удалением и стабилизацией фич, а не добавлением новых. Но вроде бы какая-то система в этих фичах есть, и синтаксис отвращения не вызывает.

    Многие замечают сходство с Go. Оно не случайно, автор впечатлился более ранними языками Пайка. Но Rust появился на несколько лет раньше Go. Темпы развития, конечно, удручают, даже самокомпилятор пока не написан. Это скорее инкубатор для идей, чем реальный инструмент. Но может ещё при поддержке Мозиллы и раскрутят. Желаю удачи.

     
  • 1.102, Аноним (-), 11:35, 02/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем им http://cobra-language.com/ не подошел? Написали бы компилятор компилятор для реального железа и в бой!
     
  • 1.106, Аноним (-), 20:25, 06/07/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Язык программрования Rust с нуля [под Ubuntu x86]: http://www.drevlyanin.ru/post/7305354988/getting-started-with-rust-programmin
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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