Go 1.25

Скорее бы дженерики нормальные завезли

А они разве планируют это делать? И в чём проблема текущей реализации?

Мне сильно не хватает возможности объявлять их отдельно у struct-а и отдельно у «метода», чтобы можно было городить что-то вроде

type SomeStruct[A] struct {
}

func (a *SomeStruct[A]) doSomething[B]() B  {
...
}

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

Раз уж речь зашла про дженерики, отвечу на челлендж hateyoufeel из старого треда. Вот так будет написан аналогичный код.

Ещё есть такой пример, где меньше магии.

Коллекции в Го не реализуют никакие интерфейсы (и не должны), поэтому если мы хотим какой-то Iterable, то неизбежно нужны дополнительный стейт и обёртка. Я написал самую короткую просто для примера. Красивая обёртка в первом примере.

Компилятор не может сам вывести ограничение по HasNext/Next, но мы его можем явно указать.

Перегрузки операторов — non-goal языка, а поддержка + реализуется перечислением встроенных типов, которые можно складывать.

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

Fun fact: я до этого никогда не работал с дженериками в Го. Да и в других языках тоже.

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

Пример на С++ можно упростить. Не упускай что твой пример не умеет работать со всеми базовыми типами где есть +.

auto sum(const auto &seq) {
  decltype(seq[0] + seq[0]) result = 0;
  for (auto e : seq) result += e;
  return result;
}

В С++ шаблоны могут генерировать много кода, но это не значит что они всегда так будут делать. Программист может реализовать коллекции на базе void *, и обернуть их в типобезопасные шаблонные обертки, которые будут лишь вызывать методы, и служить средством для проверки типов.

Не упускай что твой пример не умеет работать со всеми базовыми типами где есть +.

Упрощение ради наглядности. Если бы в этом была необходимость, можно было бы вынести constraints.Integer | constraints.Float | constraints.Complex | ~byte | ~rune | ~string в отдельный символ constraints.Plus. Но поскольку на практике даже constraints.Integer (все int-ы + все uint-ы + uintptr) встречается редко, то он вынесен в экспериментальную библиотеку.

Лучше бы убрали дженерики. Был нормальный язык, а теперь стал плохой, испорченный. Повторяет судьбу Java.

Судя по всему уже никогда.

Страуструп об этом давно писал. Появляется новый простой язык, его фанаты говорят что вот, можно и без сложностей, а через N лет стандарт простого языка можно сравнивать с плюсовым. У некоторых языков судьба более печальна, когда их закапывают, как VB6.

Ещё не время бить тревогу. Дженерики хорошо вписываются в язык и не требует жертв. Уже было упомянуто отсутствие параметризации у методов. Множество других усложнений тоже было опущено.

Кому не нравится, могут ими не пользоваться)

Код на Go до сих пор ощущается примерно таким же, каким он был 10 лет назад. Тем временем, в C++ сложности добавляются непрерывным потоком. В С++11, спустя 25 лет, были добавлены атомики в без того перегруженную модель памяти. Всё-таки масштаб совершенно разный.

под впечателнием We Programmers (видимо стоит пролистать остальную чистату Мартина дяди Боба ибо оказалось для дебилов писать не эквивалентно дебилом быть)

ну вот «всё» упирается в «когда сворачивают(ся) подграфы» - на примере всяких суперкопиляций Турчина кака один из экстримов(тысячи их ) и полиморфизм первых машкодов (за отсутсвием индексных регистров - как формы отложенных вычислений) с одной из других

так и с генериками и прочими сутями «goto как что то плохое» - вот Муратори победитель Мартинов эпопеей Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025 очередное подтверждение что

индустрии проще интерпретировать чем «суперкомпилировать»

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

и да PL/I был такой жИ

maxcom, нет в планах убрать преобразование загружаемых png в jpg?

И .medium-image-container может max-height, хотя бы, до 50vh убавить?

Моё мнение - Го в принципе не нужна подобная хрень. Это всегда был язык, в котором бизнес-логика выполняется на 80% от доступной скорости, но при этом просто, надёжно и строго единственным способом. Зачем превращать его в очередной С++, когда оригинал жив и прекрасно себя чувствует? В этом просто смысла нет.

при этом авторы настолько отвыкли от 60ых(см Кнута где показана эквивалентность синтаксиса табличного obj.ofsetFildA и колоночного FildA[indexOfObj] - как «следствие» коммутативности умножения) и прикипели к 70ым

что кривой синтаксис хэшей(ака asoc-memory) в golang map - видно что не такое родное как посконное массив[индекс]

ваще имхо golang больше заточен под «АI» чем даже python - имеено в части однозначности и элементарности (атомарности и даже барионо-фермионности) это очевидно не Тьюринг/Пост но чисто С(цирка 1977) + csp

т.е golang это вариант llvm тока для людей

Вопрос спецам по сабжу: В нем появился какой нибудь GUI из коробки? Насколько я знаю у сабжа только статика, т.е. по идее имея какой то GUI легко выплюнуть прогу с GUI которая без проблем будет работать даже на windows …

(не могу вспомнить ни одной gui проги на сабже под linux)

Мне от дженериков не нужны ни хитрые границы типов, ни сохранение их в рантайме достаточна проверка принадлежности к конкретным типам при компиляци. Ну и generic methods, о котором я сказал вначале.

Фактически, они тоже были бы неполноценные, но и для меня они, прежде всего, альтернатива type switch в каких-то местах

вот Муратори победитель Мартинов эпопеей Casey Muratori – The Big OOPs: Anatomy of a Thirty-five-year Mistake – BSC 2025 очередное подтверждение что

Я что-то всё не могу осилить его выступление: я посмотрел 55 минут, но это всё можно свести к «Страуструп подложил нам всем дохлого страуса, потому что он не взял крайне полезную фичу „INSPECT“ из Simula и вместо это нам приходится использовать ужасные шаблоны» Ну и «А вот откуда готовилось нападениепришел пример наследования Shape->Circle, которым в меня тыкают в Twitter'е!». Я не уверен, что хочу тратить оставшееся время на это: ну то есть, да, занимательная цифровая археология, но он не показывает что не так с ООП (что заявлено в заголовке).

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

Язык стал соответствовать своему всратому логотипу. Молодцы, чётко следуют плану! (%

we programmers - это два мемуара - чисто история вт эт электромеханики и автобиография чела который асмил в индустрии в 1970 и со всеми остановками ...c/c++/жабие/астронафтика абстракцию / менежульё и проч соционикоко

по факту вычисления всё дешевле следовательно уже и дебилы на расхват

Ты хотя бы с Опеннета стянул новость, там подробнее написано.

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

Программист может реализовать коллекции на базе void *, и обернуть их в типобезопасные шаблонные обертки, которые будут лишь вызывать методы, и служить средством для проверки типов.

Почему это не может сделать компилятор?

Если тебе нужна Scala, ты знаешь где её взять.

Он не для GUI. Он для CLI (в меньшей степени) и веб-сервисов.

речь про goto considered harmful в части то требуются отдельные когнитивные затраты для умозрительного процессинга - по этому в целом оптимальней когда интрепретация отложена до самого последнего момента и поэтому вот мураторьевская esc проигрвывает «ooп» в части нехватки пехоты

и да «ооп» изначально для локализации всеведенья - закатывать в однопоток солнце в ручную и получаются «картинки как живые» с gui «псевдо 3d» 80x-начала90ых современный web тот ещё результат эволюции но при этом уж лучше был бы прямой скачёк от tui в mobile(c ойпадами и прочими тыкни и выбери) чем изуродованное ограничениями технического характера и припудренное маркетоидами gui периода <вся история винды от 1982(85!) и до где-то 2012 :) >

Ну я не знал что это такая принципиальная позиция.

лучше был бы прямой скачёк от tui в mobile(c ойпадами и прочими тыкни и выбери)

«Тыкни и выбери» страшно ограниченное же по сравнению с десктопом (и последнее не только история винды, это и маки, и IBM CUA, который на винду оказал огромное влияние…).

Представь, что тебе надо забить гвоздь. Ты взял в руки молоток, забил. Следом тебе надо вкрутить шуруп и ты такой: «А почему в молотке нет крепления для стержня отвертки?» - очевидный ответ - потому что это не отвёртка, это молоток.

Я видел какие-то GUI программы на Go. Но сейчас не могу найти их.

Недавно на Хабре было две интересные статьи, довольно высокого уровня. Одна про ошибку в WinAPI, одна про ошибку в стандартной библиотеке Go, проявляющейся на Windows в крайне редких ситуациях.

Я из интереса глянул авторов - они пилят какое-то GUI приложение под Windows.

Но это не единственный пример, видел и другие GUI на Go.

Но соглашусь, мне тоже кажется, что он не для этого.

По мне так довольно дырявая аналогия.

i mean:

есть кодовая\командная строка

есть текстовый файл который мультилайн который в vi/sam/vscode поле инпута при жилании

а вот «интуитивно понятный» gui это просто локально дешевле но с огромным «техническим долгом» у Крокфорда(json) есть 7-8 лекций прикольно названых что по сути (микро)(home и little office )персоналки(все начиная от ябла][ и до появление нормальных(c виду) (а нутри ад и из ajax) форм до середины нулевых ) - это по факту повтор всего что уже было устаканено на терминалах 3270? к середине 70ых на «больших"системах

gui ( и автор мыши и матери всех дем не виноват) ваще появилось из стремления „дорохо бохато“ ибо тот же rio(а по факту почти любая кроме состоявшейся оконая система) более логичный и более дорогой в освоении интерфейс

т.е. как обычно если кастомеры не грамотные то и интерфейс „интуитивно понятный“

Я видел программы с GUI на Си, СPP даже на Rust (про всякие GUI проги на python даже молчу.)

А вы в курсе что где в 2000 был проект php-GTK?

Чего уж там, на ЛОРе есть человек, который на PHP целое DE пишет, и ему глубоко пофиг, что другие думают о предназначенности этого языка для десктопа.

претензия к историческому gui

в усложнении автоматизации ибо происходит трансляция сущьностей в пиксели и без спецального api (оле и прочий вендор лок) интегрировать «интуитивно понятное» управление и получаем монстров RPA

т.е. тот же postscript как язык управления дисплеем более пригоден для интеграции приложения в «набор взаимодействующих компонент» чем читай состояние дисплея как набора битовых слоёв и откуривай семантику цветовых пятен «интуитивно понятных» кастомеру

речь и об expect как универсальном интергаторе tui

для gui нет нормального gui_expect ибо gui(в отличии от tui и web) пачкает картинками

Да я уже много лет наблюдаю ситутацию с сабжем и GUI и не очень понимаю в чем причина.

С другой стороны есть куча либ для TUI, практически в нативе но и на них тоже не особо наблюдаю прог … странно как то. Либо cli либо web.

пачкает картинками

А, «вы в этом смысле»? Типа GUI должен до самого последнего момента быть структурированным и только перед самым выводом на экран перегоняться в растр?

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

И многооконному десктопному «богатому» ГУИ тоже не противоречит, просто вся визуальная часть богатства должно быть по максимуму в одном месте. Wayland, кстати, в этом плане шаг назад по сравнению с X11.

Аналогия или нет, а ЯП - это инструмент и у него есть свои границы применимости, где он работает хорошо. Если начать эти границы как попало расширять и тянуть всякое, получится еще один PL/I, только и всего.

Наверное, тех, кто может и хочет, уже расхватали по другим языкам: традиционалисты пишут на с++ (а кто-то и на сишечке с vala), любители современности идут на Раст (правда, тоже не знаю, как там с GUI), у тех, кому надо попроще, есть Питон.

ООП с классами.

Вроде в сабже нет классов…

Я правда не очень сильно шарю, но насколько я знаю в С++ проблема с GTK так как он си и нужно юзать gtkmm. Но мне кажется как раз сишный GTK больше подходит к интерфейсному Go… а вообще х.з.

Ну я как минимум юзаю фрактал … https://gitlab.gnome.org/World/fractal

в С++ проблема с GTK так как он си и нужно юзать gtkmm

Не нужно, а можно. В плюсовой программе нет проблем вызывать сишные функции, gtkmm – всего лишь удобная необязательная обёртка, поскольку для большинства плюсовиков сишная имитация ООП с длинными именами функций и кучей параметров выглядит весьма неряшливо. Ну и для C++ вместо GTK можно использовать QtWidgets, чем я,например, и занимаюсь.

Ну и для C++ вместо GTK можно использовать QtWidgets

Это отдельная история, и да QT по сути ++, тут нет вопросов.

Вот мне бы хотелось чтобы спецы ткнули меня носом, как по мне ОО в Go точно такое же как ОО в GTK…

Go для гуёв не предназначен, но вот

https://github.com/go-graphics/go-gui-projects

Да я видел эту страницу, давно правда. Просто мне почему то не попадались проги с GUI и go.

Достаточно часто упоминают fyne

https://apps.fyne.io/all

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