Язык, удовлетворяющий этим критериям?

Да, OCaml подходит для параллельного программирования. В нем есть модуль Thread, который позволяет вам программировать сетевые приложения так, как если бы вы это делали на Java.

Обратите внимание, что в настоящее время он не поддерживает настоящий параллелизм (у вас не будет двух потоков, запускающих код OCaml параллельно), но это не имеет значения, поскольку OCaml намного быстрее, чем многие другие языки (например, на QuadCore Language Shootout показывает, что OCaml превосходит даже Haskell с многоядерными возможностями).

OCaml подходит для параллельного программирования. Стандартная библиотека поддерживает две модели параллелизма: потоки с общей памятью (с mutexes и условные переменные для синхронизации) и событий на основе Concurrent ML Джона Реппи.

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

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

В зависимости от того, что вы имеете в виду под подходящим для параллельного программирования, я бы порекомендовал OCaml или SML (Standard ML):

1. Несколько потоков для того, чтобы не ждать ввода-вывода (сеть / файловая система / ..); возьмите OCaml - его компилятор генерирует очень быстрый код и имеет множество отличных библиотек
2. Если под параллелизмом подразумеваются собственные потоки, которые позволяют использовать несколько ядер на одной машине в одном и том же сегменте разделяемой памяти; возьмите SML (polyml) - он имеет приличный компилятор и поддерживает нативные потоки

Помните, что с любым из этих решений вы начнете использовать вывод типов! Когда вы к этому привыкнете, программирование на любом языке заставит вас плакать! ;)

Python удовлетворяет большинство ваших потребностей, кроме статической типизации, однако из-за своей конструкции он имеет так называемую GIL или Global Interpreter Lock. Это означает, что потоки Python не выполняются отдельно. Это может объяснить критику, о которой вы говорили в отношении Python и параллельного программирования. Однако в python есть модуль multiprocessing, который предоставляет API для использования таких процессов, как потоки. Также реализации python, которые работают под разными виртуальными машинами, не имеют GIL, если вы уже знакомы с Java, возможно, вам следует изучить Jython, который является реализацией python, работающей на JVM.

Также не очевидно, но стоит отметить, что Python компилируется в байтовый код. Он делает это при первом импорте любого скрипта, а это означает, что если исходный файл python редактируется и импортируется, он компилируется один раз, все дальнейшие попытки импорта того же модуля используют версию с байтовым соответствием и не повторяют скрипт. Это поведение больше похоже на java, чем на PHP, который буквально повторно интерпретирует исходный код при каждом запуске.

Я хотел бы представить три языка, которые могут в значительной степени удовлетворить все функции, которые вы ищете.

1. Haskell

   • Has an interpreter (for faster development): Ghci and the Hugs interpreter
   • Имеет компилятор (потому что скомпилированный код будет работать быстрее): компилятор Glasgow Haskel.
   • Имеет возможности объектно-ориентированного программирования: в некоторой степени, прочтите статью Haskell vs OOP
   • Статически типизированный: да, без объявления типа
   • Подходит для параллельного программирования: Да, конечно

2. Erlang

   • Has an interpreter (for faster development): Well the way Erlang works, you may not have an REPL, but then not always interpreter can help for faster development. But to some extent you can use erl for the purpose.
   • Имеет компилятор (потому что скомпилированный код будет работать быстрее): Да
   • Имеет возможности объектно-ориентированного программирования: Нет, но есть экспериментальные расширения. Но если вы разрабатываете на Erlang, вам лучше придерживаться функционального программирования.
   • Статически типизированный: Нет
   • Подходит для параллельного программирования: да, этим и известен Erlang.

3. Groovy

   • Has an interpreter (for faster development) : Yes
   • Имеет компилятор (потому что скомпилированный код будет работать быстрее): Да
   • Имеет возможности объектно-ориентированного программирования: да, в конце концов, он основан на Java
   • Статически типизированный: Нет
   • Подходит для параллельного программирования: да, наследуется от Java.

Ну наконец то

• В Java есть что-то под названием BeanShell, которое может работать как интерпретатор Java, если именно это мешает вам использовать Java.

• Вы скрутили Python, чтобы добавить в язык параллелизм.

Если вы хотите продолжить исследование, используйте следующие вики-ссылки

• Система типов
• Языки параллельного программирования
• Сравнение языков программирования
• REPL

Прежде всего, важнее подумать о других ресурсах.

1) Имеет интерпретатор (для более быстрой разработки) - imo un true

2) Есть ли компилятор (потому что скомпилированный код работал бы быстрее) - правда? как насчет разных арок на машинах разработчика и сервера и развертывании?

3) Имеет возможности объектно-ориентированного программирования - почему? функциональные языки лучше подходят для параллельного программирования

4) Статически типизированный - почему? если он имеет значение "null" в системе типов, тогда нет никакой разницы между этим и не статически типизированным imo.

Лучшие критерии

1. Сколько существует качественных библиотек и фреймворков, которые вы можете использовать.
2. Как вы будете развертывать это решение
3. Насколько легко привлечь новых разработчиков к вашему проекту

4. Какое качество комьюнити :)

   • Ocaml - отличный язык, и с библиотекой Lwt вы можете выполнять асинхронный код, даже имея 1 простой процесс. Окамл тоже молниеносно! Это кажется хорошим решением, но у вас не так много готовых фреймворков.

   • У Erlang есть библиотеки, это круто, быстро и кажется лучшим решением для ваших нужд.

   • Ruby и Ruby On Rails не позволят вам легко писать параллельный код, но вы сможете быстро построить решение и начать зарабатывать на нем деньги :) Я имею в виду, что примерно в 10 раз быстрее, чем на других языках, потому что у вас есть готовые блоки. Кроме того, в этом случае развертывание является самым простым.

   • Node.js отличная скорость, легко подбирать языки (javascript), но на ранней стадии разработки, поэтому не так много готовых вещей.

Вот как я подхожу к решениям:

С точки зрения производительности вы торгуете

1. Крышка памяти

2. Крышка процессора

   • Memory cap ( ram ) means that solution written in this language will consume more and more ram and in the end you will have to buy new boxes fast and boxes to scale will have to be "fat":)
   • Ограничение ЦП означает, что решение имеет действительно агрессивный сборщик мусора и выделяет много мелких объектов, которые часто очищаются.

Node.js и Rails в этом контексте ограничены памятью, Rails будет потреблять в среднем ~ 250 МБ оперативной памяти на одного рабочего в производственной среде. Ocaml / Oscigen, Erlang / Webmachine ограничены процессором, большинство функциональных языков пойдут по этому пути.

Я провел небольшой тест для веб-машины на моем MacBook Pro с процессором i5 https://gist.github.com/1996858 Этот ресурс обслуживал простой json, каждый раз извлекаемый из Redis без кеширования.

1 миллион запросов Всего: соединений 1000 запросов 1000000 ответов 1000000 длительность теста 463,413 с

Connection rate: 2.2 conn/s (463.4 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 390.6 avg 463.4 max 3245.7 median 453.5 stddev 101.6
Connection time [ms]: connect 0.1
Connection length [replies/conn]: 1000.000

Request rate: 2157.9 req/s (0.5 ms/req)

Теперь самое лучшее, что я наблюдал за использованием памяти. это было около 19,3 мб барана.

Если вы спросите меня, я бы построил прототип приложения в Rails, затем извлек бы json api и построил их в Erlang с помощью webmachine. Или просто создайте приложение на Erlang с помощью веб-машины и просто используйте некоторые приятные функции некоторых рубиновых библиотек, таких как capistrano, для развертывания :)

1. Изучите Scala.
2. Если вас не устраивает и вы готовы работать с MS Visual Studio, изучите F #.
3. Если вас не устраивает и вы можете пересмотреть свою точку зрения (3), изучите Haskell.
4. Если вас не устраивает и вы можете пересмотреть свою точку зрения (5), изучите OCaml.

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