Как там этот rust поживает?

immutable разве не нужно собирать?

Нужно, конечно.

как это связано со сборщиком мусора.

Они там сами еще толком не определились, что и как у них будет со сборкой мусора: http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-th...

Так вроде же есть std::comm и std::pipe? Или ты про что-то другое?

А вот без std::, как реализовать очередь средствами языка вручную? Очередь по своей природе очень даже mutable, и все readers/writers хотят знать о ней и обращаться к ней наперегонки.

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

А вот без std::, как реализовать очередь средствами языка вручную?

На unsafe, как ARC; или на отдельной задаче.

У го с этим всё хорошо. Разве что стоит вопрос с версиями сторонних пакетов: https://docs.google.com/document/d/1_IJTRD6dDQvyCfyim4KJexq8ZrKUPvUd3GMSA8cw8A4

Темплейты - это же макросы, не?

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

что за задачка?

Моя любимая. Где-то тут я её недавно уже писал, потерялась.

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

Требования: 1) первая функция ничего не знает о второй (считаем, что она будет в какой-нибудь библиотеке); 2) если мы ошибёмся и сгенерируем во второй функции последовательности разной длины, программа не скомпилируется.

Тест именно на полиморфизм, ибо, кроме как закодировать длину последовательности в её типе, никаких других вариантов не видно. А так как длина последовательности заранее неизвестна, то и количество (моно-)типов, которые по ходу выполнения возникнут, тоже неизвестна.

Если в языке есть нормальные дженерики, задачка решается на раз. И тут не особенно даже нужен хаскель, например, C# справляется на раз. ОКамл, кстати, справляется, но с гребенями.

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

Для метапрограммирования наверняка тоже что-то есть (вон Miguel напирает на шаблоны).

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

Тест именно на полиморфизм, ибо, кроме как закодировать длину последовательности в её типе, никаких других вариантов не видно. А так как длина последовательности заранее неизвестна, то и количество (моно-)типов, которые по ходу выполнения возникнут, тоже неизвестна.

А если у нас язык с зависимыми типами?

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

Ну и наф^Wзачем тут полиморфизм? Список, рекурсивная ф-ия с аккумулятором и все дела, не?

Эм... где тут две последовательности? Ты вообще в курсе, что такое «скалярное произведение»?

Признаю, я в условия не вчитался.

как на счёт такого?

-module(mul).
-export([m/2, g/1]).

g(N) ->
  g(N, []).

g(0, L) ->
  L;

g(N, L) ->
  g(N-1, L ++ [random:uniform(10)]).

m(L1, L2) ->
  m(L1, L2, []).

m([], [], L) ->
  lists:foldl(fun(E, A) -> E + A end, 0, L);

m([H1|T1], [H2|T2], A) ->
  m(T1, T2, A ++ [H1*H2]).

8> mul:m(mul:g(10), mul:g(10)).
337

Если бы ты вчитался в условия, то обнаружил бы там «должно фейлить на этапе компиляции». Вряд ли ты сумеешь изобразить такое на Erlang.

Да. Всё ухожу.

Ну, собственно, тебе уже ответили.

А если у нас язык с зависимыми типами?

Ну или так, да. Согласен.