А что Go сдох? Кто вместо него?

по сути, Go – это Limbo отвязанный от Dis

Как у тебя всё просто. Ты пойди отвяжи. Ты никогда не думал почему все язычки с генераторами, асинхронными функциями, зелёными тредами, акторами и т.п. поголовно на VM?

И почему же? Внезапно, потому что начиная с memory model если её делать правильно – уже не BCPL и Си получается, а нечто более типизированное.

тут вот недавно наткнулся на подборку про FGCS пятого поколения и его практический выхлоп: KL1, KLIC, PIMOS, Kappa-P, Quixote, MGTP и прочие.

и освежил в памяти подборку по транспьютерам.

так вот, Occam про CSP и libthread из Plan9 тоже про те же самые каналы.

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

2. вот интересно, если бы японцы взяли не пролог а, например, лисп и пытались кроме KCL/MKCL/ECL разивать. хотя можно было и LispKit LispKit-GNU_Pascal.tar.gz какой-нибудь древний взять и развивать или ещё какую реализацию SECD машины.

3. после рассказов про хайп и не взлетел и хвалебные речи в журналах что ещё ну вот-вот и тогда огого – полезно почитать на вебархиве отчёты например самих японцев от ICOT про FGCS и second-term project, там ещё 2-4 года оно продолжалось.

что же там всё-таки взлетело и в какой мере?

KL1 – DSL для представления знаний на базе пролога, KLIC – транслятор пролога в Си. первая версия (до second-term project) – на своей специфической архитектуре.

4. вообще любопытно сравнить например KLIC с mercury и прочим современным прологом, например, компилируемым в раст.

5. либо с прологом реализованным на лиспе. либо с лиспом, реализованным на прологе.

6. klic-3.003.tgz содержит ряд исходников 1991..1999 года. в newsletters есть отчёты про second-term project.

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

8. если сравнить с транспьютерами, то англичане продвинулись немного дальше. даже Atari Transputer Workstation, Atari TT030 и HeliOS какой-то сделали (который сейчас opensource).

9. в плане разработки языка для моделирования CSP и тулчейна на этом языке тоже дальше продвинулись: см. Ram’s_transputer_Home_Page/lanugages например.

10. логично было бы далее развивать FGCS на транспьютерах, например, конпелировать KLIC не в няшную сишечку а в Occam и/или, в гошечку.

11. впрочем, из Plan9 можно использовать libthreads который делает каналы Хоара на kencc, ?c/?l.

12. но дальше следы в новейшей истории про FGCS и транспьютеры уже теряются, хотя казалось бы….

13. Go/native go runtime, Limbo/Dis и libthread/Plan9 тут конечно же тоже не причём, просто к слову пришлось. а казалось бы…

Ты никогда не думал почему все язычки с генераторами, асинхронными функциями, зелёными тредами, акторами и т.п. поголовно на VM?

ну вот например в Unicon судя по книжке с примерами эта VM достаточно проста и прозрачна; притом можно дёргать функцией load сишные функции через dll-ки; притом можно Unicon -C отконпелировать в сишечку а не использовать байткод в интерпретаторе.

в Dis например тоже есть AOT интерпретатор.

VM – ну потому что наверное проще сделать сразу правильный корректный VM с правильными парадигмами и концепциями сразу в него заложенными (типа модульности, конкурентности, правильных ссылок а не указателей и т.п.) — чем лепить нагромождение костылей к компилируемому потомку BCPL.

концептуально правильней.

в BCPL (как и в каком-нибудь коболе) начиная с модели памяти, с типизации ссылок – получаем протечку абстракций.

попытки пофиксить могут привести в first class objects, first class environment или вообще упарываться по типизации высшего порядка в духе gradual typing и прочих GADT.

хотя например, 3-lisp github блог — был любопытен.

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

и конпелировать KLIC в него, а не в няшную сишечку.

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

vygr/ChrysaLisp в плане акторной модели тоже любопытен.

это – дальнейшее развитие Taos (TaoOS/Elate/AmigaDE) от того же разработчика.

профиль Chris Hinsley:

Inventor of the Taos OS. http://www.uruk.org/emu/Taos.html > https://en.wikipedia.org/wiki/Virtual_Processor <- links to scanned articles from Byte, PC-World…

тоже чтиво интересное, например, на OSnews про Elate/TaoOS/intent:

новое старое

старое лучше чем новое – там хоть картинки и код какой-никакой но есть.

например, вот ассемблер этого виртуального процессора: vp.jpg

сравни например, с $inferno/doc/dis.{ms,pdf} описанием Dis VM.

ИТОГО:

1. VM вовсе не обязательна — теоретически могли бы пойти по пути транспьютеров с Occam или компов пятого поколения с KLIC и прологом, транслируемым в сишку или Plan9/libthread транслирующим CSP Хоара в Cи библиотку с каналами.

2. VM может быть компактная регистровая – как в Dis VM / Limbo / Inferno, VP из Elate/intent/AmigaDE/TaoOS.

2.1. Ну или SSE подобная в духе LLVM или QBE. тоже регистровая VM с бесконечным количеством корректно типизированных регистров – в духе VP из Elate/intent/TaoOS.

2.2. Ну или берём простой компактный лисп в духе justin.lol sectorlisp либо first class object kernel/vau-expr/john.schutt либо 3-lisp либо вообще ribbit

2.3. и реализуем на нём ассемблер обычный, ну или необычный (конкуретный высокоуровневый, в духе VP/Taos/intent/Elate либо того же ChrysaLisp.

3. И далее раскручиваем эдакий акторный метапрог на самом себе, в духе FoNC/STEP на SmallTalk/OMeta/COLA=(Common Object/Actors Lamda Architecture)

В общем, думается что если бы взяли не пролог, а лисп – к практическим результатам в компьютерах пятого поколения бы пришли ещё раньше. Например, тот же ECL/MKCL/Kyoto Common Lisp бы раньше допилили.

Хотя в духе какой-то пролог ОС и так любопытно получилось.

Сейчас параллельный пролог с интеграцией в сишечку – это скорее всего, какой-нибудь mercury…

Интересная статья про уровни вежливости в языке (в том же номере Atari Magazines creative computing что и про FGCS) – что язык японский прагматически ориентирован, в отличие от….

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

… и что из-за непонимания контекста или омофонов можно очень эдак понять совершенно неправильно…

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

с этой точки зрения – выбор пролога (и например, KLIC и Kappa-P и Quixote и это всё) для воспроизведения нужного контекста всех этих отношений и уровней вежливости – вполне себе адекватное решение…

… со всех остальных практически значимых – лучше бы взяли

• например лисп а не пролог;

• схему или first-class objects в духе klisp kernel vau-exprs либо какой-то 3-lisp;

• ассемблер обычный на этой схеме в духе ikarus.intel-assembler.ss 1 2, 11-gholum.pdf или этого или charles-l/dirt/…/test.scm

• схему написанную на ассемблере в духе bones

либо

• схему с компактной VM в духе ribbit

схему написанную на ассемблере cкорее, схему конпелируемую в ассемблер (NASM), но могло бы быть и define-syntax DSL в духе ikarus

в общем, пойнт в том что отдельные элементы FGCS уже здесь – отдельные части готовы, хотя в целом конечно ещё «да, но пока нет».

либо сейчас со стороны про CSP и каналы Хоара проще рассуждать о граблях которые в 1980-1999 были не так видны.

ещё смущает например то, что даже тогда программистов на этом вот прологе было немного.

KLIC наверное был бы полезен, даже если сейчас есть более практичный mercury, транслируемый в сишку.

про остальной практический выхлоп FGCS вроде KBMS на прологе — далеко не так радужно, хотя например есть всякие attempto, opencyc, LogTalk, logicmoo и т.п. …

HeliOS какой-то сделали (который сейчас opensource).

пруфлинк: Helios-NG

K42 от бимеров тоже любопытен – там прагматично пытались из линукса какие-то совместимые ABI и API переиспользовать, хотя оно на С++ (и какие-то stubы для RPC в духе SculptOS/L4)

Вчера начал объяснять сыну, как понимать int main(), почувствовал себя дебилом

Вообще не пойму чего ты так расстроился с инт мейн. Функция, возвращаемый тип... Нормально там всё вроде объясняется. Проблема ж там не в инт мейн. Это ты просто уже на воду дуешь..

VM вовсе не обязательна — теоретически могли бы пойти по пути транспьютеров с Occam или компов пятого поколения с KLIC и прологом, транслируемым в сишку или Plan9/libthread транслирующим CSP Хоара в Cи библиотку с каналами.

Всегда когда читаю такие вещи, задумываюсь.

1) вы ссылаетесь на отчёты в рассылках, но в отчётах имеется тенденция приукрашивать достижения и преуменьшать проблемы, просто потому что это , ну вы понимаете, деньги. и если вы начнёте подробно описывать почему оно не взлетело у вас, то денег вам не дадут точно, лучше описать как через два года взлетит, аж не догонишь. Это я опускаю ту простую мысль, что свою работу ценишь и видишь преимущества, а недостатки искренне надеешься решить по ходу процесса (и по другому вряд ли бывает). Но не факт что недостаки по ходу этого самого процесса на самом деле решатся.

2) ваш пост не похож (пмсм) на результат глубоких изысканий, это похоже на обзор.. пока что индустрия остановилась на vm.

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

А так это всё болтология. Ну либо вы разгребаете авгиевы конюшни и поделились мыслями. Тогда конечно моё почтение и ждём прототипа (если вы вдруг собрались в эту сторону).

VM – ну потому что наверное проще сделать сразу правильный корректный VM с правильными парадигмами и концепциями сразу в него заложенными (типа модульности, конкурентности, правильных ссылок а не указателей и т.п.) — чем лепить нагромождение костылей к компилируемому потомку BCPL.

ЛОЛ, как ты ловко «невозможно обойтись без» заменил на «проще сделать». Я ж тебя спросил, попробуй не проще. Есть примеры?

Ты никогда не думал почему все язычки с генераторами, асинхронными функциями, зелёными тредами, акторами и т.п. поголовно на VM

pony например компилируется через LLVM. он что, тоже на VM?

пишут что нет:

Native Code

Pony is an ahead-of-time (AOT) compiled language. There is no interpreter nor virtual machine.

libthread из plan9 реализует каналы и точно обходится без VM.

есть примеры. но на VM проще.

например, можно сделать модульный лисп. например, взять какую-то схему вроде EuLisp, ISO ISLISP или пытаться модуляризовать SBCL в LLVM подобном SICL от Robert Strandh или как там его.

а можно взять например концептуальные

• kernel и vau-expressions от John Shutt и реализацию SINK или например klisp или ещё какую, тысячи_их или реализовать на ещё каком акторном языке, да хоть том же пони цирк с конями.

• 3-lisp например.

John Shutt cудя по диссеру решил концептуально сделать сразу правильные концепции, правильный VM.

ну примерно как Никлаус Вирт в проекте оберон решил взять модулу-2 и выкинуть unsafe в модуль SYSTEM и остальное сделать модульно концептуально, ООП на уровне модулей а не классов (акторно в Active Oberon).

а не взять какую-нибудь Аду и реализовать идеи на ней.

Кронос например реализовали на Модуле-2 хотя могли бы на Обероне (и Недоря в XDS и Excelsior OS примерно это и сделал).

а Кронос это не просто какой-то Lilit/Ceres, это позикс совместимая униксподобная ОС на модуле-2.

то есть, без VM при желании можно было бы и обойтись. но с ней концептуально проще реализовать сразу правильную memory model. пример то же Limbo и Dis (который если попытаться избавиться от VM примерно Go и его специфический рантайм и получится. там кстати Go развивается куда-то не туда – из него опять делают очередной С++ — добавляют шаблоны, дженерики и итераторы).

никогда такого не было – и вот опять. мало им что в аде из паскаля очередной С++ сделали, надо теперь и Limbo испортить.

LLVM – за «нативный код без VM» — кстати не считается или как?

а то разрыв шаблона у некоторых от очередной реализации Elate/intent/Taos/ChrysaLisp Virtual Processor:

• SSA представление

• высокоуровневый ассемблер

• Low-level VM есть, но она используется только во время компиляции.

в остальном скомпилированный любым LLVM подобным компилятором недоязычка код – это рантайм такого виртуального процессора, частично только времени компиляции, частично времени выполнения.

если мы берём например tinyGo конпелируемый через LLVM.

то получаем теоретически более компактный рантайм (практически, отдельно смотреть надо) и тулинг:

Возможность применения для Web и создания обособленных WebAssembly-приложений, используя интерфейс WASI (WebAssembly System Interface) для работы с файлами, сокетами и другими функциями, предоставляемыми операционной системой

В отличие от находящегося в заброшенном виде похожего компилятора emgo в Tinygo сохранена оригинальная модель управления памятью Go с использованием сборщика мусора и вместо компиляции в представление на языке Си задействован LLVM для генерации эффективного машинного кода.

да, вот если там сборщик мусора есть – то VM есть или нет?

и где там отстреливаемый gc как например в Nim и возможность как-то подсократить рантайм меньше мегабайта (например, пишут что):

Поддержка наиболее распространённых моделей плат микроконтроллеров.

вы серьёзно? ad hoc интерфейсы влезут в рантайм меньше мегабайта, например, десяток килобайт?

или это уже не совсем Go получится – а какой-то очередной DMDv1/Phobos rt/Amber rt/… и прочий зоопарк пока DMDv2 Phobos не стандартизировали?

гы… в мигалке светодиодами хелловордной на страничке https://tinygo.org/ они почему используют Arduino UNO а не чего-нить попроще?

вот если эту мигалку хелловордную на ad hoc интерфейсах переписать

– взлетит или не взлетит? шмогла или не шмогла?

или тупо рантайм во Flash не поместится? :)))

примеры под ардуйню не показательные какие-то, очередной safeC из Dlang делают – только теперь на новомодном Go.

где горутины и каналы? где ad hoc интерфейсы – я вас спрашиваю?

я уж молчу об очередном Go++ с темплейтами и итераторами во все поля.

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

во сколько Мб рантайма это всё обойдётся?

хотя компиляция в WASM и сервер приложений на Go непосредственно на железке – это прикольно.

я такую штуку на Lua видел, mako/barracuda и прочее.

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

ох, это прекрасное: «да, но пока нет!»

языковые фичи lang-support и непроходящие тесты стандартных пакетов стд. библиотеки stdlib

слишком много не реализовано – чтобы этот недоязычёк можно было всё ещё назвать Go.

хотя тут надо отдельно смотреть про gc, рантайм, почему какой-то тест не проходит и пакет не работает.

например, в важных опциях important-options есть --gc=none (хотел поржать с –gc=realtime как в Nim – а жаль, нет такой опции).

а в неважных (не новомодных, по видимому): misc-options

ключик -size надо смотреть.

вот какую угодно ересь придумают – лишь бы обыкновенный map файл не смотреть.

кстати, а что это за нанотехнологии ?

кто-нибудь пробывал?

лавсан, ау. пробовал эту ересь? что именно там не работает? :))

вот кстати да, сыну наверно проще объяснять будет крошечный недоgo с мигалкой светодиодом ардуиновой.

– «вот это, сынок, системное программирование. с рантаймом в полтора мегабайта».

– «а теперь мы со всей этой фигней попытаемся взлететь. о! слышышь, жужжит. это полрантайма и стандартная библиотека отвалилась. продолжаем полёт плавно-плавно в режиме планирования.»

– «а таперича, сынку, подключись через JTAG отладчиком. и объясни, почему эта новомодная фигня НЕ РАБОТАЕТ».

Вчера начал объяснять сыну, как понимать int main(), почувствовал себя дебилом.

Мои соболезнования. Объясняю школьникам плюсы, чувствую себя прекрасно.

SFINAE уже объяснил и «unspecified behaviour» (политкорректное Undefined Behavior)?

и чем модули от неймспейсов отличаются?

Какая разница какой язык здесь будет? Кто надо примет кого надо, с условием выучить нужный язык😀️

Потом год на планерке будет - "ну вы же понимаете, молодые специалисты.. не освоились.. а вы что предлагаете вместо их критики?…"🤢️

Поэтому язык выбирать наверное нужно «не для здесь». Может там получше

SFINAE

Не нужно школьнику.

UB

В чем проблема?

модули

Вообще не нужно.

я тут придумал наглядное объяснение. правда, понять могут не только лишь все. мало кто захочет это делать.

в духе «о формализации неформализуемых понятий» Н.Непейводы про Н.В. Белякина:

(эпиграф)

Современная наука пронизана, говоря образами даосской философии – мужской силой ян. Она стремится к порядку, рациональности, определённости, формализации и навязывает это своё стремление обществу.

Но как известно, когда ян достигает расцвета, появляется инь – женское начало, соответствующее неупорядоченности, иррациональности, неформализуемости.

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

вот есть языки с сильным мужским «ян» и The Right Thing – например, Ada. там пытались избавиться от всяческого UB потому что проектировали инженеры.

а есть языки вроде Cи и BCPL, которые проектировали рукожопы по приципу «чем хуже, тем лучше» – с массой всяческого UB прямо в стандарте, далеко не отходя от порога.

порядок пытаются построить из хаоса. и это только начало – мы ещё даже не начинали про кластер метапарадигм С++ и его нагромождение костылей.

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

<…>

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

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

Более того, такую особенность человека нельзя высокомерно игнорировать как недоразвитость. Только принимая в расчет якобы ошибочное понимание человеком, можно дать понятие ошибки в языке программирования. Критерии ошибки в математической формализации достаточно ясны: либо прямое противоречие, либо расхождение с истинностью в стандартной модели.

Критерии ошибки в программе тоже просты: в лучшем случае выдает не то, что надо, а в типичном — просто «виснет». А вот в описании алгоритмических языков очень трудно сделать такую ошибку, которая привела бы к невычислимости некоторых конструкций. Поэтому, как ни парадоксально, есть понятие ошибки в программе, но до сих пор в информатике практически нет понятия ошибки в том, на чем базируются программы: в определении алгоритмических языков.

вот UB которое Is not an error – что это такое и зачем?

Увэсь свит з намы, тарас! Разом до пэрэмогы!

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

Те же модели позволяют прояснить и феномен, открытый современной психологией: волнообразное формирование понятий у детей. Ребенок, вроде бы овладевший, скажем, понятием объема,

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

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

Постулаты неформализуемости

tl;dr: школота, запомните все – UB это плохо. если не хотите закапываться в дебри "кластера метападагим"

Я эту простыню читать буду только за деньги, сорян.

ну если так много «не нужно <…ибо ниасилел…>» – то ты объясняешь не целый С++ – а какое-то ограниченное его подмножество – которое всё тужится, да так и не может вылезти никак. не выходит каменный цветок.

школьнику конечно без С++ никуда.

ибо ниасилел

Никто не осилил плюсы. Дед Страуструп вряд ли помнит и в полной мере понимает все, что внесли в язык за последние 10 лет. Плюсы это помойка, но это безальтернативная помойка.

ты объясняешь не целый С++ – а какое-то ограниченное его подмножество

Именно это я и делаю. Есть программа, которую надо вычитать детям. Хотелки шизика с лора, который лезет в дебри языка «просто потому что», никому не интересны.

школьнику конечно без С++ никуда.

Скоро только уроки православия и нвп останутся, не бзди.

Скоро только уроки православия и нвп останутся, не бзди. аминь