Язык программирования будущего

Если в ынтерпрайзе, то какой-нибудь ущербный с кучей батареек.

C, C++ так и останутся, скорее всего. Go - провальный.

Если их не реализовали, по крайней мере сразу, значит не очень хотели.

Go creators просто не нашли способ реализации generics, который бы их удовлетворял (см. faq). А так дженерики в Go были бы полезной фичей, т.к. interface{} требует явного приведения типа. Радует, что generics на текущий момент — все таки «open issue».

А как же объявление переменных через := (в компилируемых языках я такого особо не видел)?

Haskell с его type inference оставляет Go далеко позади. И «CSP-style concurrency» в нем есть. Но у него и гораздо выше порог вхождения.

Код на го в целом выглядит чище и компактнее аналогичного на C.

Да. А про С++ лучше и не вспоминать.

А вообще прогони свою программу на Go через strace и посмотри на вызовы, уверен, что тот же message proccessing сделан через фьютексы в определенных случаях.

И что с того? Это деталь, скрытая реализацией. Дело в том, что в C тебе придется вручную долбиться с «мьютексами-фьютексами», в то время как то в Go нужно всего лишь написать «go fun(channel)»

О, у илитки бугурт.

это когда макакам давали решать на основе их интеллектуального уровня что лучше, а что хуже?

С тех пор как появилось ремесло, наверное.

И это хреново

Что в этом хренового? У таких языков, как С, довольно узкая ниша. Прикладную фигню на С писать незачем.

тем круче должны быть cpu, хранилища данных и тп.

Будто это что-то плохое.

На сегодняшний день уже через СЕТЬ прокачиваются огромные объемы не нужной инфы

И снова на сцене аналитики, лучше всех знающие что нужно, а что нет.

Конкурренси - это многопоточность? Типа встроенные мьютексы, фьютексы, так?

Не знаю как сделано в Go, но в Haskell и Erlang просто реализованы свои планировщики процессов и свои менеджеры сообщений, то есть прямо в user-space внутри VM, так что они к ядерным и glibc-шным тредам и примитивам синхронизации имеют малое отношение, что-то, конечно, используется, например, делается несколько тредов ОС по ядру на каждое и прибиваются к ним по affinity, при этом лёгких процессов в самой VM может быть далеко не несколько (а несколько сотен тысяч), а использование местных форков и сообщений вовсе не означает выполнение каких-либо системных или библиотечных вызовов вообще. То есть, тут VM это такая недоОС. Есть даже проект по портированию GHC в XEN. Ещё был LightHouse - когда его делали использовали обычный планировщик GHC в качестве планировщика процессов, его же менеджер памяти, дописывались в основном драйвера.

Если так, то явно вызовы идут с glibc, так?

Это можно проверить - собрать что-нибудь с помощью go и посмотреть в strace/ltrace соответствующие вызовы на предмет пропорциональности использованию оператора go и каналов.

Плюсы навсегда.

Давайте повангуем. Имеется в виду не какой-то сферический язык в вакууме, а уже существующий. Какой язык вытеснит в производстве (или хотя бы встанет в один ряд с) C++, C#, Java?

Жабаскрипт, век воли не видать :D

выстрелил? ты имеешь в виду, «не захватил с собой толпы хомяков»? А оно надо вообще?

что там на перфокартах было?..

LightSwitch.

О, у илитки бугурт.

чини парсер, пролетарий

что там на перфокартах было?..

дырочки, циферки и срезанный уголок (ключ)

Java, Python имхо.

pyskel

rust. Как go, но с generics всё в порядке.

rust. Как go, но с generics всё в порядке.

токмо оно ещё в стадии глубокой... ...разработки

D

Какой язык вытеснит в производстве (или хотя бы встанет в один ряд с) C++, C#, Java

python. Уже вытесняет.

Да ну нафиг!

а использование местных форков и сообщений вовсе не означает выполнение каких-либо системных или библиотечных вызовов вообще

This is impossible. По простой причине - синхронизация данных. Сколько способов расшарить данные вы знаете? Shm, TCP/IP (+ unix domains), heap, [Posix|Zero|etc] MQ. Везде нужно добавлять локи, там где нет блокировок означает, что используются одноядерные решения (лекговесные потоки, коросы, fibers), которые просто делаю jmp и засчет этого достигается бешенная скорость, а также возможность создавать сотни тысяч подобных «потоков». А чтобы связать две разные по пиду нити (созданные через clone), в каждой из которой используются доступ к одной и той же памяти нужна блокировка. И неважно, что внутри каждой нити еще понасоздавали тысячи коросов. Коросы из-за блокировок между процессами/полноценными потоками потеряют все свои фичи, т.к. им придется ждать когда родители синхронизируют свои данные. Итого, вся поточность сделанная в юзерспейсе имеет свои ограничения в зависимости от реализации. И вот мы и пришли к futex'ам.

Реализации потоков в хаскеле и эрланге сильно различаются. В ерланге это полноценные процессы (рулятся через erts), в то время как в хаскелле это максимум десяток потоков прибитых к номеру ядра/процессора. И синхронизация данных у них происходит по-разному.

А если нет изменяемых данных принадлежащих нескольким потокам, а всё общение происходит через каналы?

И что каналы? Каналы синхронны. Один процесс ждет данных из другого процесса и никакой мультипоточности нет. Ну конечно можно в получить данные прибить канал, сделать дело, но в чем тогда разница от просто двух разных процессов связанных через tcp + сериализация ? :)

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

В ерланге это полноценные процессы

Что сие означает?

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

Что сие означает?

Ну сколько процессов эрланг запускает для достижения мультипоточности? Один + потоки через clone? Или несколько разных процессов, которые можно по одиночке прибить через kill ? Или и то и другое вместе?

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

Да и спит, пока сосед не скажет продолжить работу. И чем это лучше futex ?

Нет не спит.

Можно просто собрать rust и удостовериться, что он может задействовать несколько ядер в одном процессе.

Вобщем, каналы, судя по опыту в перле, это клево, когда их используется два. Как только их три и более получается спаггети-код, который сложно дебажить. Так что особых плюсов от сего этого я не вижу. Для ряда задач это удобно. Если в го все скрыто внутри go func() то это клево, но не означает, что из-за этого надо бросать си/си++/хаскель/лисп и т.п, так как есть задачи где этот функционал даже излишен, ИМХО. И вопрос встает ребром, если в си/си++ я могу делать логику так как я хочу, используя futex или set/getcontext, дает ли го мне такие же возможности или заставляет использовать свою парадигму каналов?

Процесс — насколько я помню, один на каждую ноду. Потоков — несколько. В каждом из них — до фига собственных зелёных потоков (которые в терминах эрланга называются «процессы»).

Хаскель делает то же самое.

И вот мы и пришли к futex'ам.

Я не вижу использования mutex / futex у GHC когда он работает в однопоточном режиме, все forkи, расшаренные синхронизируемые MVar / TVar, каналы STM - всё работает исключительно средствами рантайма. В многопоточном режиме (-threaded) - да, используются вовсю (но pthread_creat делает только при старте или по просьбе (forkOS)), но если посмотреть в исходники rts, то они там используются больше самим рантаймом для своих (а не языковых) структур данных - например, есть schedule-р содержащий список текущих task-ов которые могут работать на разных capabilities, все функции которые хотят что-то в нём поменять должны, очевидно, делать блокировки (у шедулера есть свой мютекс).

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

ХЗ про Перл, но в Си «спагеттистоcть» кода не от числа каналов зависит.

конечно можно в получить данные прибить канал, сделать дело

Прибивать канал не обязательно.

в чем тогда разница от просто двух разных процессов связанных через tcp + сериализация ? :)

А в чем разница программы на Си и ассемблере?

но если посмотреть в исходники rts, то они там используются больше самим рантаймом для своих (а не языковых) структур данных

https://github.com/ghc/ghc/blob/master/rts/STM.h <- комментарий в самом начале, про то что происходит с синхронизацией мутабельных языковых данных общих для разных тредов.

Лисп на какой-нибудь промежуточной VM.

C# + JavaScript

Собственно это я и хотел узнать. Все реализации, в том числе и в го, даже со своим CSP по сути используют то, что можно делать и сейчас средствами glibc на си++. Можно заюзать хаскель, эрланг, которые будут делать все точно также технически, просто вид кода будет другим. Иными словами го всего лишь еще один фломастер.

А в чем разница программы на Си и ассемблере?

А включить голову слабо? Какие масштабы дает го с со своим CSP ? Один комп. Сколько дает tcp ? Правильно, хоть весь интернет с 4 млр. компов и устройств. Иногда такой критерий важен. При этом для го надо писать гибридные код, который будет понимать как сокеты, так и крутиться внутри себя через csp, в то время как если писать однопоточные приложения код пишется единый без излишеств. Эрланг за счет этого и взлетел. Поточность была включена намного позже, если что.

А в чем разница программы на Си и ассемблере?

А включить голову слабо?

Включи уже, пора.

Какие масштабы дает го с со своим CSP ? Один комп. Сколько дает tcp ? Правильно, хоть весь интернет с 4 млр. компов и устройств. Иногда такой критерий важен.

Иногда, но не в этом случае. Напоминаю твою фразу:

gh0stwizard> конечно можно в получить данные прибить канал, сделать дело, но в чем тогда разница от просто двух разных процессов связанных через tcp + сериализация ? :)

Так вот, разница между использованием CSP и использованием _для этой же цели_ TCP - как разница между программой на Си и на ассемблере.

Эрланг за счет этого и взлетел.

Причем тут Эрланг вообще? Но раз уж ты его упомянул: Эрланг - тормоз^WVM-based язык, сделанный специально для распределенных задач, а Go - native-compiled язык, сделанный для написания параллельных серверных приложений.

Clojure?

HTML

Предвидел подобный комментарий, когда писал пост, но нет, я имел в виду не Clojure. В хорошем смысле. Про Clojure я просто ничего не знаю, поэтому поругать не могу. А вот годных реализаций Scheme и CL на jvm или дотнете маловато.

Хех :) Надеюсь что успею до полёта в армию поковырять кложуру. Скалу развивают на jvm и на дотнете, надеюсь увидеть на дотнете и кложуру, но что то чувствую что врядли. Кложура всё таки гуглоподелка, и врядли гоголевцы захотят затачивать своё детище под платформу конкурирующей фирмы.

Язык будущего тот, на котором программируют студенты и школьники.

Это паскаль и его производные. :-)

Но мне кажется, будущее, скорее всего, - за деревянными счетами.

Но мне кажется, будущее, скорее всего, - за деревянными счетами.

Это потому, что ты жопоголик // К.О.

будущее - за деревянными счетами.

Вот всё таки не зря говорят что в ходе эволюции мозг человека уже давно начал стремительно уменьшаться в размере.