Опубликован почти окончательный драфт генериков в Go

Компилятор Go в каждый ваш бинарь пихает закладки. Да, продолжайте жрать говно от гугла.

Выкатывай пруфы, разоблачитель.

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

Бачок смывной проверил у себя в квартире? Ты знал что там закладки?

Переносимо, напиши отдельный код для каждой платформы.

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

Тебе же в принципе. Ты сам занял эту тупую позицию. Получи.

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

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

Люди повышают продуктивность труда, желательно с минимальными потерями в качестве.

Хахаха. Для т.н. «повышения продуктивности труда» предлагается потратить 10 лет на изучение языка, чтобы начать писать на нём более-менее профессионально, т.е. «с минимальными потерями в качестве». No, thanks.

предлагается потратить 10 лет на изучение языка

Это все из эпохи С++, сейчас таким никто не занимается. И даже С++ врядли. 10 лет учить язык программирования - это какая-то дикость. Computer Science в целом - да, а закорючки писать, это надо быть феноменально тупым чтобы долбить синтаксис и обзор стандартной библиотеки 10 лет

Зачем писать многократно отдельный код для каждой платформы, если можно писать однократно переносимый код на C?

Зачем многократно упражняться с вызовом free, если можно этого не делать и все еще жить шикарной квартире или доме? Не мыслишь широко.

Речь о неких свойствах C++, которые делают возможным написание софта, который невозможно написать на чистом C.

Не релевантно, даже не пытаюсь вступать в дискуссию, правда это или нет. В любом случае вставляешь что надо на С куда угодно, хоть в Python

Ты можешь полноценную статью накатать или хотя бы первую часть из серии статей?

Блог же не проблема завести.

Предложение довольно глупое

Равно как и предложение писать на Си, мучаясь со строками и простыми структурами данных, занимаясь копипастой или говном на void*, руками занимаясь удалением памяти(даже без RAII) и т.д. и т.п.

Равно как и предложение писать на Си, мучаясь со строками и простыми структурами данных, занимаясь копипастой или говном на void*, руками занимаясь удалением памяти(даже без RAII) и т.д. и т.п.

Ты что - это же ИЛИТНО :)

Блог же не проблема завести.

Достаточно проблемно. Нужно и завести и написать. И если завести ещё можно, если прям вообще забить на всё, что написать сложно.

Написать нормальный текст, который бы в полной мере объяснял суть идеи/проблемы - долго. Очень долго. А долго нету.

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

Я не хочу начинать с каких-то обрывков фраз - не хочу разочаровывать пацанов. Контент должен быть на уровне.

Пока Вы готовитесь, пацаны уже проведут 100500 конференций, поучая других пацанов.

Они уже 100500 провели и от одной очередной ничего не изменится. К тому же, ты хочешь что-бы контент был очередной 100501 ненужной конференцией, которая ни на что не влияет?

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

Может стоит повременить с лором тогда?

Что такое генерик в Go?

На хабре называют «дженериками». Я считаю, это неправильно, ведь уже есть заимствованное слово «генерализация» с похожей этимологией: https://dic.academic.ru/dic.nsf/dic_new_philosophy/311/ГЕНЕРАЛИЗАЦИЯ

А так же база для системы типов.

В нору такую мышь.

В нору такую мышь.

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

Скорее бы вы уже свои «откровения» начали писать.
Не тратьте время попусту на форум.

Владимир

Не тратьте время попусту на форум.

Я не трачу время на форуме. Я пишу тогда, когда я ничего другого адекватного делать не могу.

Может стоит повременить с лором тогда?

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

Ваши суждения зачастую очень емки и требуют обстоятельного объяснения.
Ну вот смотрите.
Предположим высказал суждения: - вэб плох; - работа с метаданными в C++ - а-ля PHP; - ...

и при этом не обстоятельно не объяснил почему считаю так, то что о них можно сказать?
Верны они или нет это другой вопрос, но обрывки фраз без попыток обоснования их смотрятся «не очень».
У вас именно так зачастую построен диалог.
Какая из него и кому польза?

PS: Не проблема «сненерировать» тонны «правильных» суждений.

Владимир

и при этом не обстоятельно не объяснил почему считаю так, то что о них можно сказать?

Я обосновываю всё достаточно, не менее чем мои оппоненты, если я с кем-то спорю.

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

Допустим, я говорю про С++. Мои тезисы вполне обоснованы и очевидны для всех, кто понимает то, о чём я говорю. Но проблема в том, что люди не видят в примерах то, что вижу я - они попросту их не понимают.

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

И её никак не решить. Т.е. что-бы её решить - я должен пацанов научить понимать С++, если кто-то из них не понимает. Но это так же сложная задача, ведь я должен ещё и объяснить почему С++ нужно понимать. А для того что-бы объяснить - его нужно понимать. Это замкнутый круг.

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

У вас именно так зачастую построен диалог.

Понимаешь, я могу тебя послать за примерами и ты не вернёшься.

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

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

Вообщем, правила я тебе сообщил. Если не следовать этим правилам - оппонент/скептик может всегда требовать обоснований бесконечно.

Продуктивность разработки на C++. (комментарий)

Понимаешь, я могу тебя послать за примерами и ты не вернёшься.

В этом и проблема ваших диалогов.
У вас одностороннее движение - «всех посылаете».

Владимир

кто-нибудь пишет на go в emacs?

Мало кто из гоферов, все подсели на GoLand.

подскажите, как там включить подсветку типов (напр. var s string)

Попробовал у себя: M-x go-mode

Подсветка есть.

Дорогие коллеги программисты, программистки и программята. Относительно generics. Если завезут - будем пользоватся генериками. Если не завезут - go generate. generics, как из названия понятно, генерит код на этапе компиляции. В C++ для этого есть целый язык поверх языка. В других есть что-то попроще. В C генерят макросами и разными утилитами. Результат один: перед компиляцией нагенерить кода, а во время компиляции проверить типы.

Если Вам не нравится Go - не советую на нем писать. Мысль проста: свои личные проекты Вы вправе делать на чем угодно даже на ассемблере (Colibri OS). А если хотите кушать - вакансии есть практически под любой язык - выбирай какой нравится и пили.

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

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

Я пользуюсь. Но у меня все достаточно просто: go-mode, gocode, gofmt на сохранение.

Ожидал, что он сейчас про Prolog начнёт рассказывать. А он какого-то д€рьма навернул про инлайн кода.

Предлагает ли Go какое-либо решение этой проблеме? На темплейтах такое пишется абсолютно банально.

zip :: [a] -> [b] -> [(a, b)] 
zip3 :: [a] -> [b] -> [c] -> [(a, b, c)] 
zip4 :: [a] -> [b] -> [c] -> [d] -> [(a, b, c, d)] 
zip5 :: [a] -> [b] -> [c] -> [d] -> [e] -> [(a, b, c, d, e)] 
zip6 :: [a] -> [b] -> [c] -> [d] -> [e] -> [f] -> [(a, b, c, d, e, f)] 
zip7 :: [a] -> [b] -> [c] -> [d] -> [e] -> [f] -> [g] -> [(a, b, c, d, e, f, g)] 

Дерьмо. Пойду напьюсь. Я им в твитор писал, что родовые типы не нужны, но они там видать говна поели.

Я им в твитор писал

kostyarin_ ★ (03.08.19 11:28:21) очень жирно

Оправдываешь комментарий.

Неужели го таки превращается из домашней поделки левой пятки пайка в сравнительно полноценный язык? Сначала модули нормальные сделали вместо помойки в ~/go (одного рабочего пространства хватит всем, ага), теперь генерики/шаблоны…

полноценный

Неполноценный. В полноценном языке работал бы полноценный ffi с сишкой, в идеале в обе стороны, были бы нормальные шаблоны/генерики, а не те, что сочетают типобезопасность Си и скорость Smalltalk.

zip :: [a] -> [b] -> [(a, b)]

Начать с того, что в Go отсутствуют туплы. Вместо них придётся создавать структуры и сливать слайсы в слайс структур. И для поддержки разных сочетаний типов в текущем состоянии нужно будет пользоваться кодогенерацией, например этой библиотекой: https://github.com/cheekybits/genny

полноценный ffi с сишкой

Он не очень нужен в Go. Много низкоуровневых задач решаются непосредственно в Go. Производительность и компактность бинарного кода со временем улучшится до сравнимой с C (скорее всего, применением специального компилятора вроде tinygo), что сделает язык C окончательно неактуальным.

Что же тогда, с точки зрения языка, возвращает такая функция?

func Sqrt(f float64) (float64, error) {

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

Template Haskell превозмог ту проблему, на крестах она решится быстро и красиво с помощью parameter packs. Стоило тогда вообще тащить собственно шаблоны, встраивать что-то в компилятор, если собственно обобщенное программирование все равно остается на плечах внешних кодогенераторов? Почему не хватило жабовских генериков, м?

много низкоуровневых задач

При чем тут низкоуровневость? Дело в эффективном использовании существующего кода. Нанимать команду дрессированных мартышек для переписывания с сишки на го дело все же неблагодарное.

Вы зачем Царя слили, засранцы?

Все просто — синдром вахтера в деле.

что сделает язык C окончательно неактуальным.

Сколько уже было таких «убийц C», где же мы их всех хоронить-то будем.

Вы зачем Царя слили, засранцы?

Царя в другой теме уже удаленной какой-то штангист закопал.

Что же тогда, с точки зрения языка, возвращает такая функция?

Список значений. Это не равно туплу, т.к. присвоить результат функции можно только разрозненным переменным. Фича эта (список значений) на самом деле чрезвычайно важна в Go для достижения элегантности обработки ошибок. Функция должна возвращать результат (а не передавать через указатель одному из параметров), и при этом должна возвращать состояние ошибки (значение типа error по соглашению всегда последнее в списке).

Почему не хватило жабовских генериков

User-defined генерики не планировались с самого начала, т.к. они противоречат религии простоты, которую проповедует Go. Надо отметить, что встроенные типы вроде array, slice, map и channel — обобщённые, т.е. значительная доля применений генериков покрыта.

гетерогенный список значений не кортеж

Выглядит логично, ничего не скажешь. Возвращаясь к тому примеру с zip, ведь ничто бы не мешало возвращать структуру. Вот совсем ничто. А чтобы не писать бойлерплейт лишний раз, встроить анонимную декомпозируемую на свои поля структуру в язык, обозвав туплом. Казалось бы, что проще. Более того, я готов поспорить, что под капотом оно именно так и работает, и то, о чем ты сейчас говоришь, есть искусственные ограничения.

элегантности обработки значений

a, err := foo()
if err == nil {
    b, err := bar(a)
    if err == nil {
        ...
    }
}

Элегантность/10, скручиваем стек руками. Для чего изобретали исключения – непонятно. Что еще более важно, необходимость проверки err на nil ненамного выше, чем необходимость проверки errno в Сишке. Ее почти нет. Кстати, Раст, также отказавшийся от исключений, предлагает map, and_then и прочие функциональные прелести, сильно снижая длину необходимого кода и убирая бойлерплейт. При этом еще и принуждает проверять на ошибки, либо явно отказываться от проверки. И если где-то что-то ломается, можно просто grep unwrap, с большой вероятностью найдя источник ошибки.

встроенные типы […] – обобщённые

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

Ну и наконец про tinygo, ни о каких мк и низкоуровневых системах не может идти и речи, если у пользователя нет внятного контроля даже над аллокацией памяти. Раст и плюсы предлагают большое количество статически аллоцируемых контейнеров, гарантированно не трогающих кучу. Может ли пользователь в Go аллоцировать map с статической вместимостью на стеке? Насколько я знаю – нет.

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

для достижения элегантности обработки ошибок

Ааааааааа!

Покажи растишную, аналогичную этой:

a, err := foo()
if err == nil {
    b, err := bar(a)
    if err == nil {
        ...
    }
}

Для чего изобретали исключения – непонятно

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

В Go, кстати, есть механизм исключений и их ловли (panic/recover), но применяется он не везде, а только где нельзя обойтись без.

неплохо, а если ошибки требуют обработки/логирования?

Прямо на месте? Тогда: https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with-result.html

Проблема с Go вовсе не в том, что он примитивнее аналогов. Проблема в нежелании адептов Go признать это

Какая-то надуманная проблема. Мы же не в академическом или артистическом мире, где непременно требуется какое-то внешнее признание и одобрение. Программирование — мир практиков. Если конкретный язык практичнее для конкретной задачи, то неважно, как его оценивают другие — простой, примитивный или ещё какой.

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

Откуда эта чушь пошла?

Java, C#, Python, Scala, Kotlin и т.д. и т.п.

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