OberonCore

Go позиционируется как системный язык -- то есть как замена Сям. Однако пока реализация не ахти -- по тестам на том же shootout в несколько раз медленнее, чем Си:
http://shootout.alioth.debian.org/u64/b ... =gpp&box=1

Если речь опять о мелкогранулярной оптимизации кодогенератора - то как раз для заявленной ниши (системное и серверное ПО) она совершенно некритична.

Собственно, не совсем понятно (мягко говоря), как из заявленного "позиционирования" следует необходимость создавать "ухудшенную версию Оберона" (если я правильно понял коллег)

Илья, не совсем Вас понял: разве наличие или отсутствие оптимизации (хоть мелко-, хоть крупногранулярной) влияет как-то на синтаксис

Я отвечал Geniepro на его указание на проигрыш на тестах Сям.

Да никак не вытекает...
Просто сделали язык так, как им хочется (привычно). Необходимость заимствованного из Оберонов они сами прочуяли (ещё в Limbo-Inferno), а о необходимости недозаимтствованного не догадываются опять же в силу отсутствия своего опыта (ну вот как сишнику понять с ходу, нахрена нужны EXTENSIBLE RECORD.. и т.п.).

Ну хорошо, вот ещё один, уже серверный, микробенчмарк:
http://timyang.net/programming/c-erlang ... rformance/
и опять можно увидеть, что Go уступает сям, яве, эрлангу (хотя эрланг на одном ядре в целом уступает всем)...

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

Ну, проницательность и компетентность имеет у каждого свои границы.
(яркий пример - ФП. Не работая на ФЯ, трудно представить себе, как именно они поведут себя на серьёзных задачах, и какие их средства где и как "сыграют").

Чтобы понимать, как использовать обероновские средства, надо работать на Обероне. Иначе до конца многое неясно. Особенно если учесть, что некоторые возможности этого маленького языка внезапно открываются лет через 5 работы на нём

Воистину, так!

Это применимо к любому языку (в т.ч. и программирования)

Ну, если язык не представляет собой ничего особенного, а просто "ещё один в струе", то открывать в нём обычно нечего.

Не... Я и так вижу...
А вот чтобы понять, как использовать средства ББ - тут действительно поработать надо...

Всё таки, Go может быть и часть "струи", но неплохо "профильтрован"

Нет, к Go как раз моя фраза не относилась. Go - любопытен
И ожидаем. После Plan-9 и Inferno.
Скрещивая сформировавшиеся на них взгляды авторов с ориентацией на задачи, которые продиктованы новой конторой.

"Любопытен" - это слова...
А пальцем показать, нельзя

Необязательно именно так: "это вот точно лучше". Можно и: " вот это МОЖЕТ оказаться лучше"

Хорошо, мне, например, любопытны slices. Потому что сам вводил в Обероне библиотечно похожие понятия, и на них строил некоторые вещи.

И размер множества, ограниченный 32 элементами, да?

Да. На практике этого в большинстве случаев хватает. Если нет - делают массив, список или (что угодно еще) OF SET - под задачу.

Ещё в Турбо Паскале было 256 элементов в множестве. Ещё бы лучше - безразмерно. Реализовать поддержку в компиляторе не так уж трудно. Гораздо важнее - чтобы программист не нагружался лишними проблемами, не относящимися к задаче (массивы множеств, ишь ты!).