штооооо?

switch true ... case option.is_some(val)

споры за раст тут оффтоп :)

мы ж про гошку

case option.some(val) -> case option.is_some(val)

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

даже проще можно

мы ж про гошку

интересный подход - напиши туды где принимают в роад на голосование

можно обойтись func enum(type int, body interface{}) -> Enum у Enum добавить два метода func type() -> int; func data() -> interface{}

можно обойтись func enum(type int, body interface{}) -> Enum у Enum добавить два метода func type() -> int; func data() -> interface{}

я вот честно говоря вообще не могу сообразить как ты пролему типов сумм собрался таким вот образом решать и чем это вообще лучше использования просто пустого интерфейса с тайпсвичами

я про матчинг же

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

я про матчинг же

кстати да в раст так)в го думаю проблемы на уровне низком)))

я про матчинг же

а это было бы ок

тайпсвитч работает со структурами?

а?!

а?!

присоединяюсь - какой такой типсватч?

@onokonem

я

я

https://t.me/gogolang/154809 help me

https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%82%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9_%D1%82%D0%B8%D0%BF_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

в хаскел, зачем в го?

в хаскел, зачем в го?

ага

enum, которого нам часто не хватает - тоже алгебраический тип

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

В ML они наверное ещё в 70-х появились. Из относительного мейнстрима они присутствуют в Swift. В котлин вот вроде тоже. Ну и Scala с Rust'ом, да. В C++ их велосипедят через чёрное темплейтное колдунство. В ООП языках их принято велосипедить через наследование. Но в ООП языках в принципе ничего хорошего нет. Применение у них крайне простое: выражать через типы то, для чего в языках без AlgDT применяются костыли по типу interface{} в го. Так с помощью того же обобщённого option в языках достигается null safety, а result является дефолтным способом возвращения ошибки не бросая исключение. Но вообще я говорю тут про тип сумму. Тип произведение и так в гошечке есть (хотя временами анонимных произведений ака кортежей не хватает).

enum, которого нам часто не хватает - тоже алгебраический тип

Да я копая легаси в 5.2 сильно почувствовал не\а себе это))

в хаскел, зачем в го?

да даже ради банального отказа от использования числовых констант в перечислениях их стоило завести

не уверен, что числовые константы тут помогут

да даже ради банального отказа от использования числовых констант в перечислениях их стоило завести

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

а можно - через интерфейс. и то, и то костыль, но интерфейс яснее

а можно - через интерфейс. и то, и то костыль, но интерфейс яснее

контракт - ко мне уже обращались)))как взять твое но с гарантией что будет работать через Н лет

я в смысле про подобные банальные штуки const ( UserStatusOk = 1, UserStatusPending = 2, UserStatusErr = 3, )

я в смысле про подобные банальные штуки const ( UserStatusOk = 1, UserStatusPending = 2, UserStatusErr = 3, )

вот iota же есть

вот iota же есть

угу. и когда пишешь на языках без неё - становится довольно грустно

я в смысле про подобные банальные штуки const ( UserStatusOk = 1, UserStatusPending = 2, UserStatusErr = 3, )

они обычно для другого

вот iota же есть

iota генерирует инты, а мне не инты нужны, а Ok, Pending и Err, при чём желательно, чтобы это был отдельный тип UserStatus.

iota генерирует инты, а мне не инты нужны, а Ok, Pending и Err, при чём желательно, чтобы это был отдельный тип UserStatus.

type BracketKind uint8 const ( Unknown BracketKind = iota Round Square Figure ) , не?

type BracketKind uint8 const ( Unknown BracketKind = iota Round Square Figure ) , не?

Обычно энумы из солидити так и расшифровываем

type BracketKind uint8 const ( Unknown BracketKind = iota Round Square Figure ) , не?

а так нельзя :) iota - только для не нетипизованных констант

type BracketKind uint8 const ( Unknown BracketKind = iota Round Square Figure ) , не?

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

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

как же нельзя? https://play.golang.org/p/XxFa5rXwoGC Или "нельзя" в смысле "приличные люди так не делают"?

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

я видел как люди используют его для констант, которые в БД хранятся

вот это точно ужас

> константы > в БД

потому что могут :D

Подскажите по поводу "как не надо делать" У меня есть несколько горутин которые читают из канала который я передаю им (канал0) и после обработки складывают данные в канал (канал1) который мы объявили как глобальную переменную пакета на старте программы я запускаю одну горрутину, которая ждет когда в канале1 наберется достаточно данных (счетчик) и записывает эти данные в базу это сильно костыльно, да?(

это нормально

фух

прям груз с плеч)

надо, правда, добавить сброс кеша по таймауту

есть такое

и там уже довольно нетривиально все становится сразу

тогда ок

Спасибо)

подскажите: читаю код реализации функций math и там все функции заданы двумя стркоами например : func Tan(x float64) float64 func tan(x float64) float64 { это как я понимаю чтобы компилятор сначала попытался использовать ассемблерную реализацию? или для чего?

а это где?

https://golang.org/src/math/tan.go?s=2594:2621#L72

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

но мне тут интереснее сама форма записи - сначала публичная запись но без тела а потом приватная но с телом

это разные функции, одна Tan, другая tan

Почему одна без тела?

там где-то рядом лежат еще платформенно-специфичные файлики, в которых определяется тело для Tan, и дефолтный вариант, в котором она просто зовет tan

Почему одна без тела?

https://stackoverflow.com/questions/14938960/what-does-a-function-without-body-mean\

Спасибо

Подскажите, как мжно создать юмьютабельный массив? и можно ли вообще

там где-то рядом лежат еще платформенно-специфичные файлики, в которых определяется тело для Tan, и дефолтный вариант, в котором она просто зовет tan

спасибо!

Подскажите по поводу "как не надо делать" У меня есть несколько горутин которые читают из канала который я передаю им (канал0) и после обработки складывают данные в канал (канал1) который мы объявили как глобальную переменную пакета на старте программы я запускаю одну горрутину, которая ждет когда в канале1 наберется достаточно данных (счетчик) и записывает эти данные в базу это сильно костыльно, да?(

Глобальная переменная это не хорошо. Сделай передачу этого канала явно вместе с каналом 0.

а как тогда во время инициализации программы быть с горутинами которые читают из этого канала и пишут в базу (они работают не в мейне, а в блоке инит, конфиги считывают и тп)? мне в 10-15 функций придется постоянно пробрасывать указатель на канал, я не считаю это какойто жуткой работой, но это сильно усложняет код, имхо

Даниэль сказал что это нормальная практика =|

на текущий день софт работает нормально, без утечек памяти (+- 1.5 месяца), решил просто подуточнить

до этого я считал это немного грязным решением

нормально имелось ввиду видимо много писателей - один читатель. А каналы в глоб. переменной и init, которая что-то там инициализирует - это пводод для рефакторинга. Вне main не должно быть ни каких изменяемых объектов, это аксиома

Глобальна переменная создаёт много проблем при тестировании, при попытках инициализации в другом месте.

Странная аксиома ?

Глобальна переменная создаёт много проблем при тестировании, при попытках инициализации в другом месте.

А если она нигде не иницилизуется?

Лучше иметь глобальную переменную и экономить время и на коде и на тестах!

не лучше. глоб. переменные - это зло в чистом виде

Кроме одного единственного места

почему у меня напрашивается сразу вопрос, а зачем придумали зло?(

типа нате переменную, но ее вообще нельзя использовать(

Лучше иметь глобальную переменную и экономить время и на коде и на тестах!

почему?

почему?

Время -- деньги, почему ж еще.

Время -- деньги, почему ж еще.

почему?

Почему что?

Почему что?

"Время -- деньги" связано с "Лучше иметь глобальную переменную"

"Время -- деньги" связано с "Лучше иметь глобальную переменную"

Там после слова "переменную" есть продолжение.

Там после слова "переменную" есть продолжение.

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

Зачем ее изменять?

почему у меня напрашивается сразу вопрос, а зачем придумали зло?(

Подменяемые базовые параметры, глобальные настройки типо time.Local, инициализация ошибок, генерация интстенса для статических методов.

Зачем ее изменять?

а зачем вы константу называете переменной?

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

IDE нажимаешь Find usages и все ?

IDE нажимаешь Find usages и все ?

гениально! зачем тогда нужно ООП?

В Go нет ООП

гениально! зачем тогда нужно ООП?

Не нужно

Если вы забыли ?

func BenchmarkStringPlus(b *testing.B) { var name string for i := 0; i < b.N; i++ { name += "value" } }

go 1.11 виснет напрочь )

не знаете почему?