Racket быстрее для многопоточной работы, чем Go

Так-то оно так, но в случае с Qt это как-то проще воспринимается: всё равно будут ломающие изменения, придётся править свой код.

Вот и в Haskell так живут. На самом деле, если это свой проект, то всё не так страшно, в каждом отдельном переходе переделывать очень мало надо. Проблема, если библиотеки, от которых твой проект зависит, вдруг вовремя не обновились.

Для целей оптимизации и так где возможно вычисления выносятся на этап компиляции и явные проверки типов выкидываются.

В динамическом языке это можно сделать в довольно узком спектре «внутренних вычислений».

А весь «API» со «стандартной библиотекой» не могут не ждать чего угодно на вход в рантайме…

Ну да ладно. Текущая ситуация понятна. Спасибо.

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

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

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

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

Хаскель по-своему тоже красив, но это как пролог нашего времени - изящно, но непонятно, насколько он практичен. Например, там очень нужно быть осторожным с утечками «пространства» (space leaks) из-за ленивости, а это совершенно неведомая зверушка для прочих языков. Как-то непрактично, не правда ли?)

А весь «API» со «стандартной библиотекой» не могут не ждать чего угодно на вход в рантайме…

Для простых случаев, где просто проверка, оптимизатор заменяет, например, car на unsafe-car, а + на fx+ или flonum+. Для сложных типа apply или map проверок в самих функциях всё равно в явном виде нет.

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

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

Zig смотрел?

Хаскель по-своему тоже красив, но это как пролог нашего времени - изящно, но непонятно, насколько он практичен. Например, там очень нужно быть осторожным с утечками «пространства» (space leaks) из-за ленивости, а это совершенно неведомая зверушка для прочих языков. Как-то непрактично, не правда ли?)

Если говорить о «практичности», то на первом месте будет стоять наличие готовых специалистов (и их цена). Тем не менее, на хаскеле что-то пишут и вакансии периодически проскакивают. Но это, конечно, совсем не мейнстрим.

Что касается «спейс ликов» - я не настоящий сварщик, но подозреваю, что должны быть инструменты упрощающие их поиск. С утечками памяти вон народ жить привык, так что будь хаскель мейнстримом, то и с этим привыкли бы жить.

Да, есть профилировщик

Неа, не смотрел. Я еще на tiobe ориентируюсь

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

Что касается «спейс ликов»

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

а это совершенно неведомая зверушка для прочих языков

Не совсем неведомая. В Си++ для борьбы с аналогичной проблемой придумали перемещающие конструкторы (move constructors).

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

Я представляю, что это. (:

Насчёт некритичности можно поспорить: мне попадались статьи, где автор описывал как с проблемой боролся и там совсем не «чуть больше» памяти расходовалось.

В Си++ для борьбы с аналогичной проблемой придумали перемещающие конструкторы (move constructors).

Не уверен, что это одинаковые проблемы. Во первых, в С++ copy elision было до перемещения. Во вторых, перемещение позволит сэкономить на одной лишней копии, у спейс ликов, насколько я понимаю, совсем другие масштабы.

Здравствуйте, мой перловый друг! Как ваши успехи?

Владимир

Вот c++ здесь совсем не причем - там перемещение для оптимизации. Иначе на фоне раста выглядело бы совсем несолидно, хотя перемещение в языках реализовано по-разному в деталях, но решает ту же задачу в целом.

Утечка пространства в хаскеле - это достаточно серьезная проблема. На нее напороться, как нефиг делать. А сожрать память может. Хуже того, даже если не всю память сожрет, то тут может ожидать другая засада. Раскрутка санка (thunk) до значения может произойти совсем не в том потоке, где программист ожидал, а это уже неприятно для многопоточки, из-за чего может просесть скорость. В общем, глядеть в оба глаза надо!

А программисты на других языках и знать не знают о таких сюрпризах хаскеля

Перемещение в расте и c++ очень полезно, помимо оптимизации, еще для создания замыканий, куда можно переместить объекты и функции

Например, так можно реализовать Cont

Во первых, в С++ copy elision было до перемещения.

Так и ликвидация утечек пространства тоже в компиляторе полуавтоматическая. sum [1..n] будет использовать константное пространство при оптимизации, начиная с -O1.

Во вторых, перемещение позволит сэкономить на одной лишней копии

По одной копии на каждой операции. Хотя согласен, именно памяти ест гораздо меньше.

Вот c++ здесь совсем не причем - там перемещение для оптимизации.

Так нетерпеливое вычисление тоже для оптимизации.

Раскрутка санка (thunk) до значения может произойти совсем не в том потоке, где программист ожидал

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

А программисты на других языках и знать не знают о таких сюрпризах хаскеля

Так сравнивать надо не с Си++, а с SQL и XSLT.

Например, так можно реализовать Cont

А пример есть, как это сделать?

Есть, но ссылки сюда кидать не буду. Могу лишь сказать, что идею может подать реализация комбинатора and_then для характеристки (trait) Future в расте. Они что-то много раз переделывали, пока шли к async, но сигнатура самого комбинатора - зацепка, по которой дальше довольно легко достраивается Cont для раста, а вот для c++ нужно еще почесать репу (для c++ получается с той же эффективностью, если хитро использовать шаблоны).

Только полноценного TCO не будет, но это не всегда нужно, потому что раскрутка стека может происходить из-за специфики прикладной области, где будет применяться Cont

Они что-то много раз переделывали, пока шли к async

Вообще эти async/await мне кажутся запасным дерьмецом часа икс. Если не получилось сделать или придумать что-то нормальное – то пихай в язык async/await (и всякие Futures) и делай вид, что так и было и всё хорошо.

Сжечь все ЯП где есть подобная биллиберда было бы куда правильней. Даже сишные pthreads не такие тупые как это.

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

Для сложных типа apply или map проверок в самих функциях всё равно в явном виде нет.

Как проверок не может быть, если «чезовские» apply или map «динамические» (бесконтрактные)? Схема делает «вывод типа» параметров функции по телу?

Да и зря ты так. Например, фьючи в скале достаточная хорошая штука, и ее часто и активно используют в проде - она проверена

Для map проверка будет при попытке взять первый элемент от всех аргументов кроме первого. А потом при вызове первого аргументов как функции с полученным списком параметров.

Также и при apply. Проверку будет делать не apply, а его первый аргумент. Если этот аргумент типизированный и выполняется внутри Typed Racket, то проверку делать не будет.

Схема делает «вывод типа» параметров функции по телу?

Нет. Делает проверку при вызове функции нижнего уровня. Или не делает, если окружение говорит, что функции можно заменить на unsafe и разрешена подстановка (inline) или вызывается тело типизированной функции.

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

Ну не легко. У меня есть опыт разработки на Go и на C++. C++ без своих костылей и аналогов STL будет жрать память и местами работать медленно. Да, можно поспорить насчет буста, но местами библиотеки реально чуть ли не на уровне питона работают. Нужна прям уже устоявшаяся кодовая база, чтобы проект легко масштабировался.

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

Это не так просто. Не те задачи. Проблемы с самой кодовой базой. Нужно синхронизировать гошный код и плюсовый. Я бы в первые лет 5-10 даже бы не трогал этот код. В го вполне можно предаллоцировать буферы, можно написать на голых сисколах код. В общем даже в самом го можно много всего наоптимизировать на начальных этапах.