Состоялся (http://blog.rust-lang.org/2016/01/21/Rust-1.6.html) релиз языка программирования Rust 1.6 (http://www.rust-lang.org), развиваемого проектом Mozilla, обеспечивающего автоматическое управление памятью и предоставляющего средства для высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (https://www.opennet.me/opennews/art.shtml?num=36576), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model).
Новый выпуск примечателен переводом libcore в разряд стабильных. Стандартная библиотека функций Rust базируется на базовой библиотеке libcore, которая не зависит от платформ и самодостаточна. Поверх libcore построена расширенная библиотека libstd, через которую доступны функции работы с памятью, вводом/выводом и многопоточностью. В обособленном виде libcore может применяться в низкоуровневых компонентах операционных систем и во встраиваемых платформах. Стабилизация данной библиотеки позволяет низкоуровневые приложения, используя стабильный Rust. Кроме libcore в разряд стабильных также переведено около 30 расширенных библиотечных функций и методов libstd, таких как функции семейства drain() для работы с коллекциями, From для преобразования типов и Vec::extend_from_slice().Язык Rust развивается проектом Mozilla и сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий. При этом Rust обходится без использования сборщика мусора или runtime, что делает возможным создания на Rust библиотек, которые могут выступать в роли прозрачной замены библиотекам для языка Си. Для распространения библиотек на языке Rust, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек введён в строй репозиторий crates.io (https://crates.io/).
По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование и модель акторов, а также обобщённое программирование и метапрограммирование, в статических и динамических стилях.
URL: http://blog.rust-lang.org/2016/01/21/Rust-1.6.html
Новость: http://www.opennet.me/opennews/art.shtml?num=43716
Мозилла в последнее время выкидывает все что не ФФ и не приносит бабло. Кода мозилла от него откажется?
Дык в будущем этот их ФФ и будет на расте
Возможно будет. Разработчики уже не говорят о ближайшей замене gecko на servo, речь идет о возможном постепенном внедрении частей на rust в gecko. А это, ИМХО, говорит о том, что они хотят зацепиться, чтоб их не забыли и не похоронили, если они не смогут в ближайшее время создать конкурентный аналог. Ну и кроме того, это говорит о том, что они явно недооценили сложность и объем задачи.
Вряд ли, учитывая то, что сейчас делают мозилловцы, они проведут статистическое исследование, узнают что на фаерфоксе сидит только треть пользователей браузеров и решат прекратить его пилить вообще, выпустят FireChromium.
Если не будет развивать его Mozilla, будут развивать его другие:
В Dropbox пишут новые сервисы на rust, будет кому поддерживать.
Создадут какую-нибудь Nonprofit Organization курирующую разработку, и существующую через взносы, и будут обеспечитвать ЗП разрабочикам языка.
Некрасивый он и плохо читаемый. Наверно на него пересядут Си-шники.
Жрущим кактус не привыкать?
Для сишника там слишком много условностей и заморочек.
Когда же наконец запилят один самый мощный язык программирования в котором будет один синтаксис? Сейчас не очень удобно запоминать C++, C#, Python, Ruby, Rust, Go, Swift, Java :'(
Swift чем не подходит?
Нельзя делать сайты и клепать программы под Windows and Android или можно?
Сайтики уже можно. Windows and Android скоро будет, в баг треке уже баг есть ждите.
Пиши на Лиспе, в нем один синтаксис.
Точнее, в нём вообще толком синтаксиса нет. Тем и плох.
Тем и хорош.
Односторонние медали встречаются нечасто.
Ну да. Но лисп для мейнстрима банально неудобен. Впрочем, как любое универсальное решение.
И каждый из прочитавших этот комментарий под словом "мейнстрим" понял что-то свое.
Характеристика мейнстрима только одна - его МНОГО. И это заведомо исключает любой язык, для которого нет орды готовых специалистов и готовых частных решений. Я даже поверю, что на лиспе можно что-то быстро разработать - но на мейнстримных языках, скорее всего, это вообще не придётся разрабатывать - всё давно готово и есть те, кто умеет с этим работать - и в количествах.
Ну а теперь задумайся, откуда появляются "орды готовых специалистов и готовых частных решений". Даю две подсказки
1. Их не боженька создает.
2. js, java, C++, C#, PHP, Python, Perl во времена мейнстримности FORTRAN просто не существовали.
Это как раз легко объяснить:1) на языке простое делается просто, а дальше - как повезёт. Это то, что произошло с со всеми скриптовыми из перечисленных. А дальше - снежным комом и в конкуренции с похжими языками - есть разработчики - значит, на языке пишут - и так далее, пока его не заменит что-то похожее, но более подходящее, как произошло с уходом массы с перла в пхп.
2) есть ниша, на которой приходится писать, и там есть много денег. Это произошло с C#, когда VS переганала на него всех в принудительном порядке.
3) Есть ниша, и в какой-то момент для неё есть только один подходящий язык. Так произошло с плюсами, когда понадобилось писать сложный софт, и это же произошло, когда появилась джава и J2EE как полная среда для энтерпрайза.
Лисп, при всём уважении, ни в одну из этих категорий не попадает - на нём не просто делать простые вещи, в него принудительно никто не загоняет и в силу своей универсальности он не имеет специфической ниши, в которой у чего-то специализированного не было бы преимущества.
А этого МНОГО - его одним куском много, или оно из множества небольших и разных мейнстримов состоит?
А в каждом из этих небольших и разных мейнстримов - наблюдается ли внутренняя однородность?
За цифирками - к TIOBE или на сайты вакансий, но как бы очевидно, что сейчас всё, кроме совсем специфических областей перекрыто менее чем десятком языков, и лиспа там нигде и близко нет в макроскопических количествах.Я вообще не понимаю, с чем тут спорить. Лиспу почти семьдесят лет, к анстоящему моменту никакого распространения он не получил. По-моему, этим его характеристика как практически применимого языка полностью исчерпывается. Академические плюсы и эстетика - вопрос другой, но к практическим результатам они отношения не имеют. по этому поводу могу ещё отказ от MIT 6.001 припомнить.
Зато на нём можно легко и непринуждённо быстренько зафигачить себе DSL специально под нужную тебе задачу с нужным тебе синтаксисом. :)
Можно. Но этот DSL будет весьма слабо читаем.А вот на любом современном интерпретируемом языке это, скорее всего, будет проще, быстрее и результат будет куда удобнее в использовании. А если взять специализированный язык, которых сейчас хватает для любой области и на любой вкус - результат будет ещё лучше.
> Можно. Но этот DSL будет весьма слабо читаем.Это уже зависит от Вас, и только от Вас.
> А вот на любом современном интерпретируемом языке это, скорее всего, будет проще,
> быстрее и результат будет куда удобнее в использовании.Нет. Просто нет. Без лисповых макросов *проще* и *быстрее* это точно не будет.
Вот давеча понадобился DSL для одной программки на Ocaml, так оказалось проще встроить в него R5RS, чем писать на синтаксический анализатор на нём самом. Но Ocaml, конечно, не "современный интерпретируемый". Однако как написать такое на Perl, Ruby или Lua я даже не представляю.
> А если взять специализированный язык, которых сейчас хватает для любой области и на любой
> вкус - результат будет ещё лучше.Ну во-первых их вечно НЕ хватает. Во-вторых, как они по-вашему появляются-то?
А сопровождать этот код потом будет полтора магиканца на пенсии? Где-то мы про такое недавно читали =)
FORTRAN учите, будете вообще неувольяемым =)
А дайте задачу - уверен, что найдётся пяток готовых решений для чего-то мейнстримного и по столько же модулей на питоне/перле, которые можно по-быстрому прикрутить.Как появляются - не важно (хотя большинство распространённого написано отнюдь не на лиспе). Важно то, что для абсолютного большинства задач они уже есть, причём в них уже собраны основные грабли и есть союзники в борьбе с оставшимися.
Ну вот есть разница между 80-ми, когда связность была плохой, набор готовых решений - сравнительно малым, сложность задач - терпимой, а набранный индустрией опыт - не таким уж большим, и нынешним временем, когда всё это увеличилось многократно.
Ну не пишет себе сейчас нормальный человек набор контейнеров, виджетов и алгоритмов. Сейчас есть прямой смысл конентрирооваться на одной задаче, а всё остальное брать готовым, и быстро оценить то, что тебе интернетом принесло - гораздо более ценный навык, чем что-то на порядок проще написать самому вне какой-то узкой области. Потому что в первом случае есть шанс хоть что-то за свою жизнь успеть.
Ровно так же, как веке в 17-м можно было заниматься физикой в одиночку и получать хорошие результаты в нескольких областях - а сейчас одиночка не может добиться вообще ничего, и единственный осмысленный вариант - узкая специализация и максимальное использование результатов коллег со всего мира.
Вот вы сами построили strawmanа, и сами его успешно забороли с усердием, достойным лучшего применения.
Почему вы считаете что на Лиспе нормальный человек продолжает писать набор контейнеров, виджетов и сортировку списка - но непонятно зачем на таком предположении останавливаться и не пойти до конца - почему бы тогда не предположить что он еще и Лисп-машину самостоятельно перед этим себе делает из FPGA, а потом компилятор Лиспа для нее?
Есть quicklisp, есть еще много чего. С основными мейнстримовыми библиотеками бегло можно ознакомиться в http://eudoxia.me/article/common-lisp-sotu-2015/
А уж насчет узкой специализации физиков - расскажите об этом автору статьи "Графен" в Британике, порадуйте человека.
Потому что мне тут в сотый раз начали рассказывать о том, как лисп хорош для быстрого создания DSL.Мой тезис - быстро создавать DSL практически никогда не нужно. Если есть хоть малейшая возможность - нужно брать готовые языки, дополнять библиотеками (лучше тоже готовыми, возможно - доработанными). Если не выходит - стараться брать готовые DSL, если надо - опять-таки, подключаясь к разработке/доработке существующих. Уникальных задач очень мало, уникальных областей деятельности - и того меньше. Нечего придумывать велосипеды.
Кстати, хоть сколько-нибудь сложный DSL продумывается много дольше, чем релализуется - на чём угодно.
И что не так с Кацнельсоном? Занимался ферромагнетиками, потом спрыгнул на графен, с которым и возится. Неплохое подтверждение как раз.
> Потому что мне тут в сотый раз начали рассказывать о том, как лисп хорош для быстрого создания DSL.Ну что ж, я могу Вам только посочувствовать, что Вам 100 раз объясняют столь простую истину, а Вы никак не можете её понять. :)
Ну ладно. Так значит, Ваш тезис -- "лисп не хорош для быстрого создания DSL"?
> Мой тезис - быстро создавать DSL практически никогда не нужно.
Ах, теперь вот как? Так Вы собираетесь доказывать, что лисп не хорош для быстрого создания DSL через доказательство того, что DSL и не нужно создавать быстро. Неплохое начало, коллега. :)
> Если есть
> хоть малейшая возможность - нужно брать готовые языки, дополнять библиотеками (лучше
> тоже готовыми, возможно - доработанными). Если не выходит - стараться брать
> готовые DSL, если надо - опять-таки, подключаясь к разработке/доработке существующих.Ну, быть может, хоть я и расставил бы приоритеты несколько иначе, всё это вполне возможно. Но тем не менее никаким образом не обосновывает тезис, что быстро разрабатывать DSL не нужно.
> Уникальных задач очень мало, уникальных областей деятельности - и того меньше.
> Нечего придумывать велосипеды.Ооо, уникальных задач -- пруд пруди. До сих пор нет нормальной программы для преподавания детям геометрии. До сих пор я не встретил хорошей программы для визуализации зависимостей между пакетами. И это только навскидку. Можете поспорить. Я с удовольствием "перениму" опыт.
> Кстати, хоть сколько-нибудь сложный DSL продумывается много дольше, чем релализуется -
> на чём угодно.Не всегда технология развивается после теоретического обоснования. Часто (я бы сказал, в 90% случаев) бывает так, что архитектор видит, какой программа должна быть, и начинает её проектирование одновременно с разработкой ряда компонент. А в процессе разработки и всплывают подводные камни, которые не были ранее замечены. И тогда вносятся исправления в архитектуру. Порой весьма существенные, вплоть до принятия решения о полном переписывании программ. Об этом писали ещё Брукс и Реймонд, а уж им-то я думаю, Вы верите побольше моего. Если хотите, могу привести конкретные ссылки, мне не составит труда.
PS: я всё-таки хочу добавить к словам rob pike, что если в Вашем сообщении 99 верных утверждений, то это не делает верным и сотое тоже.
> Ах, теперь вот как? Так Вы собираетесь доказывать, что лисп не хорош
> для быстрого создания DSL через доказательство того, что DSL и не
> нужно создавать быстро. Неплохое начало, коллега. :)Вообще-то такого не прочёл -- скорее "неважно, потому что не требовалось/требуется".
> Ооо, уникальных задач -- пруд пруди. До сих пор нет нормальной программы
> для преподавания детям геометрии. До сих пор я не встретил хорошей
> программы для визуализации зависимостей между пакетами. И это только навскидку.Кстати, найдёте/сделаете -- подёргайте, заранее благодарю.
По части геометрии сразу вспомнил http://www.pacifict.com/Story/ и http://archives.seul.org/schoolforge/discuss/
По части зависимостей -- Вы ведь явно не про apt-cache dotty и дальше фильтрАми, так понимаю?
>А если взять специализированный язык, которых сейчас хватает для любой области и на любой вкус - результат будет ещё лучше.Ну тЭорЭтически - вот их то лишперы и делают :)
Это Вы про JavaScript, Python и PHP чтоли? Более мусорных языков я в жизни не видел (bash не в счёт).
Из этих - питон как DSL выглядит очень чистенько - определешь нужную библиотеку - и всё. Lua для того же часто используют.
... и всё. Только, #%$^, синтаксис, тебе этого должно хватить.
Да тебе нужен 1С! Там всё понятно.
МНЕ НУЖЕН УНИВЕРСАЛЬНЫЙ ЯЗЫК, а не 1C
это была ирония же
PL/1
> PL/1Ха! Надо же чего вспомнили! :)
Мамина сиська, это универсальный язык для вас?
Brainfuck же!
Когда-то давно на роль такого языка претендовал C++. Всего каких-то 17 лет назад можно было выучить только его, и получить возможность писать код под любое железо того времени и под любую задачу.
А потом предметная область начала фрагментироваться, причём скорость фрагментирования всё возрастает. Кажется, в мире IT пресловутая сингулярность наступит с года на год, потому как уже сейчас языки, фреймворки и парадигмы плодятся с такой чудовищной скоростью, что даже если начинать учить их сразу после выхода, к моменту изучения они как раз успевают устареть.
Всё идёт к подходу "один проект - один язык", когда количество действующих языков сравняется с числом крупных проектов. И знания, полученные в одном проекте, для любого другого будут полностью бесполезными, т.к. станет практически невозможно найти два проекта, написанных на одном языке.
Это всё hype, его можно спокойно игнорировать, базовые знания по computer science уже годов с 70ых как не устаревают.
> Это всё hype, его можно спокойно игнорировать, базовые знания по computer science
> уже годов с 70ых как не устаревают.Ога, небазовые вперемешку с не-знаниями переполняют аналы.
Начните с бенчмаркинга на Haswell классических структур данных и алгоритмов.
> Начните с бенчмаркинга на Haswell классических структур данных и алгоритмов.А что там?
Ну, например, можно обнаружить как хитрые списки, над которыми бились лучшие умы в computer science 1970-х, со своими O(1), сливают тупейшим массивам с их позорными O(N) на примерно всех разумных N.
Кнутов с Седжвиками и Корменами формально и не упрекнешь, они скажут что ничего конкретного про сами эти О и не обещали, и вообще это такие математические абстракции, к реальной жизни никак не относящиеся, а что все понаделали себе в головах интуциций про эти O - так это к понаделавшим. Тем не менее, контринтуитивным в реальной жизни для подавляющего большинства овладевших "принципами computer science из 1970-х" оно остается.
А реально влияющие (побольше чем N) вещи типа branch prediction, reference locality, cache awareness в computer science 1970-х описаны, как бы это помягче выразиться, не очень (хотя у IBM был работающий в IBM360 out-of-order еще до 1970-х).
А детальнее где глянуть? Что-то на практике я об такое не бился, ни на C, ни на плюсах. ни на перле, ни на джаваскрипте. Хотя оптимизировать всякое приходилось.
А начните вот с Мейерса http://www.aristeia.com/TalkNotes/ACCU2011_CPUCaches.pdf
Хотя там фактически только про кэш и оно уже довольно старое по нынешним временам, но в любом случае стереотипы периодически пересматривать - занятие полезное. Например, стереотипы про важность выравнивания данных после Haswell можно считать устаревшими, он достаточно умный чтоб в большинстве случаев сделать все правильно самостоятельно. Или вот CLHash ускорился почти в два раза на Skylake по сравнению с Haswell, а остальные хэши - не очень.
> Ну, например, можно обнаружить как хитрые списки, над которыми бились лучшие умы
> в computer science 1970-х, со своими O(1), сливают тупейшим массивам с
> их позорными O(N) на примерно всех разумных N.О как, не слышал.
да-да, особенно представления о многопоточных программах.
> Всего каких-то 17 лет назад можно было выучить только его, и получить возможность писать код под любое железо того времени и под любую задачу.Сильно подозреваю, что 17 лет назад или ваши задачи были несколько специфичными или же это вообще рассуждения с высоты удобного дивана ) ), типа "главное – возможность! А результат ... ну подумаешь, придется переписать кусок на Си ..."
Насчёт c++ exceptions - он, как обычно, ничего не уточнил, так что не понять, насколько он прав.Уж не знаю, что у него за требования к языку для писания ядра, но вот насчёт "hide things like memory allocations behind your back" - он либо гонит, либо имеет в виду что-то большее, чем аллоцирование в куче.
А вот за "object-oriented code in c without c++ crap" я очень хочу кого-то убить. Эта хрень адски плохо отлаживаается и ещё хуже модифицируется, так как единственный способ сделать ООП на сях (я имею в виду - как положено, с наследованием и полиморфизмом) - куча макросов, от которой тошнит, и не меньшая куча опасных преобразований типов.
Если бы Линус делал "как положено", у нас бы сейчас вместо ядра были EJB с RMI-IIOP и феминистками.
Так что спасибо ему огромное за то что он руководствуется здравым смыслом и плевать хотел на весь тот crap, который "положен",
> и под любую задачуЧё-то не помню я тогда нашествия плюсатых cgi-шек (спрашивали ведь и "за сайты")...
mod_perl вовремя появился. Сишные модули к апачу писали иногда, если надо было совсем быстро. Но редко, перл не сильно уступал в работе со строками, а ничего другого в вебе было не надо практически никогда.Хотя базовое утверждение автора, конечно, полная чушь. 17 лет назад на одних FoxPro, Clarion, Paradox и Clipper было понаписано больше кода чем на Си и С++, с большим отрывом.
Давно запилили
https://ru.m.wikipedia.org/wiki/ДРАКОН
Согласно тому что они обещают нет сборщика мусора и нет ручного освобождения памяти. Я правильно понял?
Тогда может ли раст решить задачу и как:
Есть несколько массивов. В начале каждый из них имеет равный размер и содержит указатель(? или как там его называть) на объект. Потом некоторые элементы удаляются. Таким образом на некоторые объекты не остаётся ссылок ни в одном массиве и их надо удалить. Тут если не сборщик мусора, то перед удалением каждого объекта надо просматривать остальные массивы и проверять содержится ли в них указатель и если не содержится то удалять объект. Это единственный вариант который сразу приходит в голову. Но он крайне не эффективен при больших размерах массива и большом количестве массивов.
Первый курс?
Чего первый курс? Вот почему когда задаёшь вопрос, то ответить не могут, упрекнуть в некомпетентности могут, минусовать могут?
Что ты там написал в первом сообщении вообще не понятно. В основной массе языков без GC используется подсчет ссылок, получаешь ссылку инкрементишь счетчик, как только выходишь из области видимости (scope) происходит декримент счетчика и если он 0 то объект удаляется. Как это работает когда ссылка должна быть передана за scope я не знаю, это все можно нагуглить словами rust memory model scope escape analysis.
У счетчиков есть проблема с циклическими ссылками, когда есть два, три или более объектов ссылающихся друг на друга (A->B->C->A), ничего не знаю про руст, но недавно прочел про swift, в нем можно декларировать слабые ссылки, кейворды я тебе накидал, гугли тему.
Как раз сборщик мусора решает эту задачу почти как вы описали, т.е. неэффективно. А без сборщика это решается элементарными счетчиками
Есть умный указатель. У него есть указатель и счётчик. Как только мы делаем a = b количество ссылок на a уменьшается, на b растёт. Как только количество ссылок станет равно 0 вызывается деструктор для объекта на который указывает указатель. По сути это и есть сборщик мусора. Который за одно и является счётчиком встречаемости объекта.
> По сути это и есть сборщикЕсли бы это был сборщик мусора... подсчет ссылок использовался для управления памятью в больших приложениях с незапамятных времен. Просто когда у тебя один объект используется в трех разных местах, то без подсчета тяжело понять когда этот объект можно удалять. Но есть там проблемы с циклическими ссылками как я описал выше.
У GC проблема с вынужденными stop-the-world паузами потому никакого real-time на java не пишут и расход памяти. Зато jre решена проблема с фрагментацией памяти и создание нового объекта обходится вроде бы дешевле, за счет того, что памяти у системы ненужно запрашивать, т.к. CG уже запросил с запасом. Хотя и для "С" это не проблема, можно использовать для менеджмента памяти костыли от апача с бассейном и ведрами :)
А как, кстати, производится управление счётчиком "умного указателя" при многопоточной работе? Лочится на время присваивания?
У меня нет достаточной компетенции для ответа на вопрос, я джава кодер, максимум доводилось заниматься портированием сишных приложений на джаву.
> Таким образом на некоторые объекты не остаётся ссылок ни
> в одном массиве и их надо удалить.И в чем, интересно, здесь будет профит от ручного освобождения памяти?
А так:
https://doc.rust-lang.org/stable/nomicon/destructors.html
https://doc.rust-lang.org/std/rc/
Массивы(есть еще tuple и vec) в rust иммутабельны. Так что такая "задача" там просто не возникнет. Также там есть несколько разных типов указателей, есть понятия ownership и lifetime, так что методы работы с ними весьма отличаются от привычных по С.
в описанной ситуации rust позволит использовать только указатели с подсчетом ссылок (Rc или Arc). Попытка изменить объект при наличии указателей других типов приведет к ошибке компиляции
>Rust библиотек, которые могут выступать в роли
>прозрачной замены библиотекам для языка Си.ну, вот и хорошо. перепишите Линукс (ядро) уже на нём.
Тут правда не линукс:
https://github.com/thepowersgang/rust-barebones-kernel
https://github.com/redox-os/redox
Рекомендую прочитать статью сотрудника Microsoft который вместе с Anders Hejlsberg работал над TypeScript:http://www.jonathanturner.org/2016/01/rust-and-blub-paradox....
Особо интересно узнать мнение бывалых C++ ков.
+1 Отличная статья. Вопрос можно обобщить s/мнение бывалых C++ ков/мнение бывалых Blub программеров/g :)