Lazin, пусть даже большинство библиотек в бусте направлены на расширение языка, 
там остаются библиотеки которые направлены на решение конкретных задач, например Asio и Spirit, 
и библиотеки которые направлены на оптимальное решение общих задач - скажем быстрый array вместо медленного вектора, прочие легковесные типы данных.

Аналог asio в OCaml/F# есть? Чтоб юзало порт завершения под виндой, kqueue под фряхой, и чтоб было удобно пользоваться?

К сожалению, то что OCaml не уступает по уровню С++ - жалкий пиар. Видел заметки в ЖЖ как писали интерпретатор для какой-то абстрактной машины. Вначале Ocaml заработает быстрее, потом С++ соптимизируют. Потом камль. Только камль после этого всего превращается в трудночитаемый язык.

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

там можно писать асинхронный код так, как будто он синхронный, благодаря такой фиче языка, как computation expressions

http://tomasp.net/articles/fsharp-webcast-async.aspx

Основной подвох в раскрутке языка.. C++ на руку в свое время сыграло его совместимость с С, после язык спас  boost, позволяя поднять его на приемлемый для того времени уровень, сейчас когда конкуренты окрепли (многие на плачевном опыте того С++), имхо нужно поторопится хотя бы с новым стандартом, чтоб поток "кочевников" с языка не стал  угрожающим Но к сожалению чтоб победить в сражении тех фич нового стандарта маловато, и только былой "авторитет" может удерживать язык на плаву :(. Tребуется нечто новое, выводящее язык на современный уровень, но пока о таком не слышно :(
вот пришлось закончить на грустной ноте ..

  Я имею ввиду в чем подвох OCaml. Какие его слабые стороны. Фичи как фичи это всегда успеется, но старый друг, лучше новых двух, хотя бы потому что знаешь откуда ждать засады  .

ну он конечно позаброшен малость, все из-за того, что его редко используют, но не думаю, что реализация хуже чем у delphi  
а с F# все как раз наоборот, все на очень хорошем уровне  

Lazin, ну тут уже кроссплатформенности шиш, кроме того функциональный. Скорее всего даже под CF2.0 не запуститься, а про использование старых наработок можно вообще забыть. Кросплатформенность в современной реалии это очень важно.
  Кстати вышла бета версия студии от ембаркадеро. Новая студия готовит Mac и Linux на нативном уровне. 

так это же хорошо
версия под Mono есть


ничего подобного, обычный .NET язык, можно делать все тоже самое, что можно делать на C# или Visual Basic  


поезд уже ушел  
а вообще, слабо верится, что оно у них нормально заработает на других платформах

  Обычный .NET язык и не работает под CF2.0. То что заточено под CF2.0 работает и на .NET . Обратное не верно. Например, Microsoft Robotics Studio заточен под CF2.0 и работает под .NET . Также как то что заточено под Mono будет работать и на .NET, но обратное опять же не верно.
  Получается F# с неуправляемым кодом сможет общаться только через COM. Работа с памятью напрямую не возможна. Придется выкручиваться. 
  Кстати для сравнения Delphi идет на встречу языку С. В нем ввели директиву PointerMath для удобства работы с низким уровнем. И довели до ума дженерики, сделали библиотеку Generics.Collections .NET совместимую. Так что двигаются в правильном направлении. Многое серьезно переработано. 

  Но опять же переносимость будет только при том, что программист ограничиться возможностями библиотеки VCL или будет использовать только платформонезависимые библиотеки, которых весьма не густо. Глядишь к 2012 доведут до ума. 

F# работает на CF2.0


из F# можно использовать P/Invoke, кстати, интересно, откуда такие выводы?  


поздно, засохнет и отвалится  

  Предположил. В любом случае ведь использование неуправляемого кода ограничено.

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

Добавлено через 2 минуты и 41 секунду
единственное, непонятное мне ограничение - отсутствие protected членов класса, причем, если класс пришел извне, то можно от него наследоваться и использовать его protected методы и свойства, но в F# нельзя создать класс с защищенными членами, только с закрытыми, либо открытыми, зачем так сделали - совсем не понятно...

Lazin, вот правильное применение OCaml.  

Ахтунг! Школьнег, фапающий на Це++, тебе на заметку:


  

kemiisto, как язык для обучения студентов, с этим я еще могу согласиться  

И на том спасибо.  Ты мне лучше вот что скажи. Для расширения кругозора мне лучше Haskell или OCaml копать?