ну я просто не придумал куда впихнуть

если делать на уровне пакета- будет полотно

если делать на уровне пакета- будет полотно

(насрать)

потом забываешь поправить полотно когда в хедлеры что-то добавил

начинается жесть

да и main хотелось бы в три строчки уместить

@onokonem https://github.com/romshark/Go-2-Proposal---Immutability#3-immutability-by-default-go--2x как-то так

ноу, сенкью, серьезно, нет, не надо так

ноу, сенкью, серьезно, нет, не надо так

1. либо постоянно писать много const 2. либо постоянно писать мало mut 3. либо постоянно писать много много копирования и for циклов 4. либо постоянно резаться об острое лезвие pointer aliasing'а выбирайте сами, я выберу 1 в случае Go 1, в Go 2 я выберу 2

какая же это обратная совместимость то? весь код полетит в ад, и дальше осталось только дойти до copy on write, чтобы вообще никто уже ничего не понял

какая же это обратная совместимость то? весь код полетит в ад, и дальше осталось только дойти до copy on write, чтобы вообще никто уже ничего не понял

с const обратная совместимость гарантирована, он может быть добавлен в Go 1.x без последствий с mut - нет, это возможно только с кардинально новым подходом в теоретическом Go 2.x

я мельком видел вашу войну за иммутабельность, даже теоретически понимаю, где это поможет (допустим передача аргументов в интерфейс отправляет их на хип, тк кто знает, то там в интерфейсе будет, с конст станет лучше), но by default == плохая идея

я мельком видел вашу войну за иммутабельность, даже теоретически понимаю, где это поможет (допустим передача аргументов в интерфейс отправляет их на хип, тк кто знает, то там в интерфейсе будет, с конст станет лучше), но by default == плохая идея

https://github.com/romshark/Go-2-Proposal---Immutability#311-safety-by-default Immutability stands for compile-time safety, which would then be default behavior. The developer will have to explicitly annotate mutable types using the mut modifier preventing types from accidentally being declared mutable by forgetting to prepend the const qualifier.

1. либо постоянно писать много const 2. либо постоянно писать мало mut 3. либо постоянно писать много много копирования и for циклов 4. либо постоянно резаться об острое лезвие pointer aliasing'а выбирайте сами, я выберу 1 в случае Go 1, в Go 2 я выберу 2

@di3young ??

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

откуда вы проблемы такие находите в нежирных сервисах?

юниттестирование иммутабельность

вот в 10-летнем монолите выстрелить себе в ногу да (:

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

зачем писать постоянно const?

когда его 5 поколейний говноедов колхохозят

прям OTRS вспомнился

юниттестирование иммутабельность

не смогу точно процитировать, но в данном интервью Rob Pike упомянул: https://youtu.be/BBbv1ej0fFo что он ужаснулся когда понял что большинство unit test'ов в динамических языках писали из-за отсутствие строгой типизации.

юниттестирование иммутабельность

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

откуда вы проблемы такие находите в нежирных сервисах?

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

ну я вообще за неслишком жирные сервисы, которые тестить снаружи

зачем писать постоянно const?

тогда пишите копирующий код

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

тогда пишите копирующий код

что копирующий?

ну я вообще за неслишком жирные сервисы, которые тестить снаружи

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

тогда пишите копирующий код

я тут видел либу, где мне кусок памяти из shared memory из функции возвращали, и норм :) на доверии

ну я вообще за неслишком жирные сервисы, которые тестить снаружи

ну не используйте тогда иммутабельность))) кто вам мешает?)))

я тут видел либу, где мне кусок памяти из shared memory из функции возвращали, и норм :) на доверии

молодцы, всё на доверии строите! вам в таком случае лучше в мир JS, там типизация тоже по доверию ?

ну не используйте тогда иммутабельность))) кто вам мешает?)))

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

это только я, вроде

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

если вы не поняли зачем это нужно - это не значит что оно не нужно всем)))

это только я, вроде

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

@onokonem меня сейчас больше интересует как будет действовать иммутабельность на каналы

@onokonem меня сейчас больше интересует как будет действовать иммутабельность на каналы

Нельзя закрыть канал?

Нельзя закрыть канал?

ну т.е. const chan можно только читать?

ну т.е. const chan можно только читать?

Или в него писать

ни посылать в него ни закрывать его нельзя?

Как вариант

@onokonem меня сейчас больше интересует как будет действовать иммутабельность на каналы

я бы хотел спросить - нахера нам иммутабельные каналы?

что делать с ними?

Иммутабельность головного мозга

Запретить закрытие из функции, куда такой канал был передан

ch := library.GetChan() // const chan int ch <- 10 // Compile-time error val := <- ch // reading is fine

ch := library.GetChan() // const chan int ch <- 10 // Compile-time error val := <- ch // reading is fine

это зачем может быть нужно?

это зачем может быть нужно?

ну если мы канал из сторонней библиотеки получаем, она же заинтересована чтоб ты в этот канал не писал предсказуемости ради

Запретить закрытие из функции, куда такой канал был передан

это какой-то странный кейс.

ну если мы канал из сторонней библиотеки получаем, она же заинтересована чтоб ты в этот канал не писал предсказуемости ради

а чо с ним делал?

это какой-то странный кейс.

А в другом раскладе смысла не вижу

а чо с ним делал?

только читал

ну так верни канал только для чтения

ну так верни канал только для чтения

ну а как ты предотвратишь чтоб в него писали?

OMG

пусть лучше компилятор это запрещает

стрелочкой

коллега, есть RO каналы, и компилятор запрещает в них писать

коллега, есть RO каналы, и компилятор запрещает в них писать

поясни плиз

https://gobyexample.com/channel-directions

https://gobyexample.com/channel-directions

да, вот этого я до сих пор не знал

спасибо

век живи, как говорится

в таком случае... хмм, да, видимо каналы в этом не нуждаются

поясни плиз

https://play.golang.org/p/fme3YsxbbJa

ERROR: S client not available

правда, илья быстрее успел

https://play.golang.org/p/fme3YsxbbJa

?? не знал, спасибо

https://play.golang.org/p/fme3YsxbbJa

корректнее тогда уж так https://play.golang.org/p/71kXOCdon4p

короче я понял const chan относится к категории immutable reference type. Это не означает что в канал нельзя писать или его нельзя закрывать, это означает что сам reference на канал нельзя мутировать, т.е. это равносильно const * T const chan const Object иммутабельный канал на иммутабельный объект же просто вернёт иммутабельный объект при чтении из канала и не позволить изменить сам reference на этот канал

всё в принципе складывается в согласованную целостную картинку https://github.com/romshark/Go-2-Proposal---Immutability/issues/11

Скоро такое и до го докатится, Создатель языка программирования Python Гвидо ван Россум объявил о том, что из языка уберут служебные слова master («хозяин») и slave («раб») по соображениям политкорректности.

Ээээ. 10 лет пишу на Питоне и не слышал про кейворд мастер

Ээээ. 10 лет пишу на Питоне и не слышал про кейворд мастер

Каменты в исходниках пайтона писали слэйвы

А в го что менять-то?

Скоро такое и до го докатится, Создатель языка программирования Python Гвидо ван Россум объявил о том, что из языка уберут служебные слова master («хозяин») и slave («раб») по соображениям политкорректности.

Не он такое сказал)

А в го что менять-то?

Рутину переименовать в хобби

Да и не так сказано было

Скоро такое и до го докатится, Создатель языка программирования Python Гвидо ван Россум объявил о том, что из языка уберут служебные слова master («хозяин») и slave («раб») по соображениям политкорректности.

а из tkinter'а тоже?

Испорченный телефон каиф

а репликация теперь у них менеджер/уборщик вместо master/slave?

Здравствуйте. Кто то наблюдал снижение скорости вызова функции time.Now() в версии go 1.11? после обновления Go с версии 1.10 до версии 1.11 проект стал кушать процессора в 2 раза больше По pprof на 2 месте по потреблению процессора - time.Now

Здравствуйте. Кто то наблюдал снижение скорости вызова функции time.Now() в версии go 1.11? после обновления Go с версии 1.10 до версии 1.11 проект стал кушать процессора в 2 раза больше По pprof на 2 месте по потреблению процессора - time.Now

Больше выделения памяти или каких операций?

памяти потребляется так же

операций то же

откатился до 1.9.7 потребление проца упало в 2 раза

На что стало времени больше тратиться? Что делает time.now долго?

а репликация теперь у них менеджер/уборщик вместо master/slave?

celebrity/follower

celebrity/follower

Да-да-да

просто получение текущего времени, вот код: time.Now().AddDate(2, 0, 0)

просто получение текущего времени, вот код: time.Now().AddDate(2, 0, 0)

Pprof же умеет дальше по стеку строить граф что происходит? Не сравнивали 2 графа?

еще не сравнивал

еще не сравнивал

Интересный момент. Напишите если выясните. Критичный вопрос.

по стеку идет так: runtime timerproc 1.36s (2.09%) -> time sendTime 0.21s (0.32%) -> time Now 0.15s (0.23%) -> time now 11.96s of 12.18s (18.39%)

вообще первый раз вижу что бы time Now потреблял столько процессорного времени

по стеку идет так: runtime timerproc 1.36s (2.09%) -> time sendTime 0.21s (0.32%) -> time Now 0.15s (0.23%) -> time now 11.96s of 12.18s (18.39%)

а на других системах (OSях) проверяли?

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

да и сравнение будет не честным