http://shootout.alioth.debian.org/u64/compare.php?lang=go
Даже здесь большого отличия по быстродействию нет, хотя код на го там не особо-то оптимизировали.

Спасибо.

CL+LispWorks PE. /thread

LispWorks PE

Максимум проприетарности.

LispWorks PE

Нет, это совсем мне не надо.

по быстродействию нет

Я про память спрашивал. Впрочем в этих тестах с памятью у Go все вполне неплохо.

подойдет любой язык. не в языках счастье.

Ну и...

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

В общем общий совет - учить можешь что угодно, все равно реализовывать станешь на чем-нибудь более мейнстримном. Дело в том, что у каждого из перечисленных ЯП есть хорошо проработанные ниши, но никак не весь фронт «для любой задачи».

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

import Data.Conduit
import Data.Conduit.Binary
import Data.Conduit.TMChan
import qualified Data.ByteString.Char8 as S8
import Control.Concurrent
import Control.Concurrent.STM
import Control.Concurrent.STM.TMChan
import Control.Monad
import System.IO
import System.Process


import Debug.Trace

main = do
    -- create channel for tasks
    runnersChan <- newTMChanIO
    -- run 1 runner on 1 real proc
    n <- getNumCapabilities
    forM_ [0..n] $ \i ->
        forkOn i $ runner runnersChan
    sourceHandle stdin $$ sinkTMChan runnersChan
    where
        runner ch = do
            mt <- atomically $ readTMChan ch
            case mt of
                Just t ->  runCommand (S8.unpack t) >>= waitForProcess >> runner ch
                Nothing -> return ()

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

что за ЯП?

haskell в исполнении криворукого меня.

Спасибо.

Оно конечно просто на первый взгляд. Хорошо, книжку посоветует, думал брать эту - http://www.ozon.ru/context/detail/id/8696277/

Советую Real World Haskell и курс который Bryan у нас в Стэнфорде читал http://www.scs.stanford.edu/11au-cs240h/

Ну на самом деле все написано на официальном сайте: Microthreads, Channels, Scheduling. Для обработки большого числа задач как раз хорошо подходит.

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

RWH хорошо, курс предложенный выше тоже хорошо, но без только по слайдам грустно. Данная книга в общем-то тоже не плохая.

Но лучше держать что-нибудь под рукой, открытым канал #haskell, и иметь задачу.

P.S. на указанном тобой хосте и erlang должен вполне работать.

python

ну и это просто пока тут не навёрнуто MQ для адекватного добавления задач, логгирование задач, адекватная логика удаления задач, как выполняющихся, так и не добавленных, какая-то статистика и т.п. Так же является ли задача «внешней» или выпоняется в рамках языка, хотя в любом случае расширяется это достаточно просто.

понравился, или наоборот, если наоборот, то что не нравится.

Посмотри Scala. Компилируется в java bytecode и затем работает поверх Java Virtual Machine как обычный явовский код. Есть шикарные библиотеки актеров: стандартная и akka. Это если не хватит стандартных для самой явы средств по работе с параллельностью.

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

Минуc моего предложения в том, что придется освоить на английском книгу «Programming in Scala» 2-й редакции, а это 883 страницы. Тогда язык не будет казаться таким сложным.

В данный момент, хочется изучить что-то новое.

А... зачем? В смысле, если джаст-фор-фан, то учить надо то, что нравится (а то звучит типа - я хочу познакомиться с новой девушкой, подскажите с какой лучше знакомится, с блондинкой или с брюнеткой?;-))

С прагматической точки зрения, для повышения проф. уровня (скорости решения каких то своих задач, расширения спектра решаемых задач и т.д.) то к питону, который Вы уже знаете, неплохо бы подучить что нить шустрое (например C/С++) и отработать связывание с питоном. ИМНО это будет более эффективное вложение времени и сил, чем изучение Go;-)

Запилите уже сервис на ЛОРе, который бы выдавал ЯП учитывая потребности пользователя!

Кстати, актеры в Scala это аналог F#'повского Mailbox? А то никак не соберусь глянуть на них.

Отчасти. Но в akka по-моему можно написать распределенную систему на кластерах, когда сообщения гуляют между узлами. Во всяком случае мне так представляется, судя по паре слоганов, прочитанных про акку. Дальше не копал.

Запилите уже сервис на ЛОРе, который бы выдавал ЯП учитывая потребности пользователя!

А о чем тогда будут говорить благородные доны? Может еще сервис для лиспосрача завести?;-)

Все правильно написал. Лорчую, короче.

Ясно, спасибо, надо будет глянуть. Может чего стоящего нарою для себя.

Pascal/FreePascal же.

посмотри в сторону BrainFuck'а, это самый простой ЯП (всего 8 операторов).

Что ж все только попсенью интересуются-то, а? Кацкели, какамлы всякие.

ТС, смотри на Ada, Oberon, Modula-3.

а почему ещё никто TCL не предложил?

Да, через чур абстрактное.

Начни, пожалуй, с изучения русского языка.

Процессы в эрланге вовсе не для того нужны, о чем ты подумал. Никакого SMP там не надо, в типичном коде этих процессов могут быть тысячи (намного больше, чем ядер).

Ты бредишь. Весьма бредишь. И одного ядра хватает.

Ты неправильно понял. Тебя неграмотные дебилы обманули.

А заработать на Scala можно? Или лучше смотреть Clojure?

Думаю, что зарабатывают обычно не на языках. Вполне можно разработать на Scala программу или библиотеку, а затем заработать. Почему бы и нет?

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

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

Выбирать язык по тому, насколько ему «симпотизирует» (как ты изволил выразиться) ЛОР - плохая, дурацкая затея. Единственная причина популярности всей вышеописанной экзотики на ЛОРе - максимальная непохожесть на других и отстранённость от мейнстрима. Профессия программиста давно потеряла элитарный статус (пик которого пришёлся где-то на конец 90-ых), и многие не могут с этим смириться, посему подсознательно ищут механизмы компенсации. Как известно, если человеку нечем выделиться за счёт личных качеств, он пытается сделать это за счёт внешних атрибутов - автомобиля, айфона, или же вот языка программирования. ЛNСП, Хаскель и иже с ними безумно популярны на ЛОРе по этой и только по этой причине.

Ни один из упомянутых языков не удовлетворит твоим требованиям по быстродействию и аккуратному расходу памяти. (Одни из них чисто интерпретируемые и поэтому медленные, другие прожорливы до памяти, третьи тянут 60-мегабайтный компилятор в рантайм и так далее - не имеет смысла подробно останавливаться сейчас на этом.) Поэтому мой совет - прототипируй на чём угодно, хоть на том же Питоне или Scheme, убеждайся, что алгоритм рабочий, а потом переписывай на C/C++. Так поступает весь профессиональный мир. Если хочется поменьше низкоуровневой возни - очень рекомендую Vala: это такой C# с человеческим лицом, компилируемый в нативный код и имеющий «искаропки» все батарейки GLib.

Тебе надо забивать гвозди? Так бери обычный молоток и забивай. Тебе не помогут здесь сферические стеклянные наномолотки в вакууме. Лучше стальной болванки, насаженной на деревянную ручку, человечество в этом плане ещё ничего не придумало.

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

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

Предлагаю на этом все же остановиться и развить тему дальше.

Посмотри на Clojure, Scala, Erlang. Языки которые используются в продакшене. И довольно успешно. Если ты думаешь, что пределом мечтаний является C# or Java, то у меня плохие новости. Лучше успеть заскочить на этот поезд под названием distributed programming, пока он не ушел, а то потом будет мучительно больно его догонять при этом клепая унылые формочки на яве или шарпе.

Тебе надо забивать гвозди? Так бери обычный молоток и забивай.

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

Можешь посмотреть на Clojure:

http://www.flickr.com/photos/ghoseb/6404006213/

посмотри в сторону BrainFuck'а, это самый простой ЯП (всего 8 операторов).

Лямбда исчисление - переменные и две операции.

Их этого списка ничего, это языки для инопланетян(пожалуй кроме Go, там хоть синтаксис человечный), если есть задача, то нужно исходить из неё и подбирать инструмент под неё. В 99% случаев хватит «стандартных» языков, например Python, Ruby, C, C++. Из этих 99%, для реализации 50% задач новичка хватит наверно и bash-а. Не надо учить язык только потому что это «типа модно», толку с этого не будет.

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

Класс задач, для которых нужен параллелизм - очень узок и уныл. Большинство реальных задач совершенно последовательны.

А вот как раз унылые формочки требуют параллелизма. Интерфейс должен быть асинхронным, а за модальные диалоги надо убивать.

Их этого списка ничего, это языки для инопланетян

Говорят, программисты полезно расширить сознание.

Говно твоя лябмда. Достаточно S и K.

Достаточно S и K.

S, K и аппликация - тоже три.