Не шутите так

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

Ну так для этого есть Rust. А Go вроде как другой язык. Или я что-то путаю?

Rust — совсем о другом, это язык с совсем другой областью применения.

Писать код который использует компайл-тайм рефлексию и параметрический полиморфизм вместо, прости Господи, рантайм рефлексии.

А чем Rust не подходит под это описание?

А чем Rust не подходит под это описание?

В Rust нет GC, это создаёт некие сложности при написании кода.

Rust — совсем о другом, это язык с совсем другой областью применения.

Rust это прямой соперник C++ Увы Gо никакой язык не заменит

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

В Rust нет GC, это создаёт некие сложности при написании кода.

Какие же сложности?

Какие же сложности?

Ну напишите какой нибудь циклический граф на расте, поймёте что за сложности.

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

Надо конкретную задачу решить "суперкостыльно" и генериками и посмотреть, что лучше читается. Только задача нужна практическая, а не "напишите генерик с параметром-типом"

Надо конкретную задачу решить "суперкостыльно" и генериками и посмотреть, что лучше читается. Только задача нужна практическая, а не "напишите генерик с параметром-типом"

> практическая То есть не библиотечный код, да?

Боюсь авторы языка не осилят. Параметрический полиморфизм — не та фича, которую можно нахрапом взять.

Не все за 1 день делается. Если реально хочется помочь, то нужно подготовить толковое предложение, иначе это все просто "вот там, за бугром хорошо, а тут ужасно и бла бла бла"

> практическая То есть не библиотечный код, да?

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

Не все за 1 день делается. Если реально хочется помочь, то нужно подготовить толковое предложение, иначе это все просто "вот там, за бугром хорошо, а тут ужасно и бла бла бла"

> хочется помочь Ну нет, этим людям помогать мне не хочется.

Надо конкретную задачу решить "суперкостыльно" и генериками и посмотреть, что лучше читается. Только задача нужна практическая, а не "напишите генерик с параметром-типом"

Ну среднестатистическому гоферу конечно будет нечитаемо и непонятно. Также как всяким джавистам непонятен и нечитаем вывод типов.

Ну среднестатистическому гоферу конечно будет нечитаемо и непонятно. Также как всяким джавистам непонятен и нечитаем вывод типов.

Что за "среднестатистический гофер"? Дискриминация какая-то.

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

Практическая задача - мономорфизация и статическая диспетчеризация ради повышения производительности за бесплатно вместо использования интерфейсов.

О_о

Практическая задача - мономорфизация и статическая диспетчеризация ради повышения производительности за бесплатно вместо использования интерфейсов.

то есть то же "напишите генерик", только сложными словами.

Что за "среднестатистический гофер"? Дискриминация какая-то.

Ну я ещё и по джавистам прошёлся

глупый вопрос var a int go func() { for range time.Tick(time.Millisecond) { a++ } }() go func() { fmt.Println(a) time.Sleep(time.Second) }() это ж будет неопределённое поведение и data race?

Ну я ещё и по джавистам прошёлся

Ещё можно по C++никам пройтись, те тоже по большей части предпочитают пребывать в своем манямирке и не вылазить наружу.

глупый вопрос var a int go func() { for range time.Tick(time.Millisecond) { a++ } }() go func() { fmt.Println(a) time.Sleep(time.Second) }() это ж будет неопределённое поведение и data race?

Будет

глупый вопрос var a int go func() { for range time.Tick(time.Millisecond) { a++ } }() go func() { fmt.Println(a) time.Sleep(time.Second) }() это ж будет неопределённое поведение и data race?

да, это data race. Есть пакет sync, если нужно обращаться к одной переменной из одновременно работающих горутин

да, это data race. Есть пакет sync, если нужно обращаться к одной переменной из одновременно работающих горутин

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

Сам принцип правильный, но работает он не обязательно везде

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

Либо один писатель, либо много читателей

Есть базы данных с принципом один писатель - много читателей, там этот принцип работает прекрасно

Есть базы данных с принципом один писатель - много читателей, там этот принцип работает прекрасно

это точно. sqlite например

Есть базы данных с принципом один писатель - много читателей, там этот принцип работает прекрасно

Ну там наверняка есть какие-то имплисит локи.

Либо транзакции.

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

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

байт не до конца запишет??

Ну напишите какой нибудь циклический граф на расте, поймёте что за сложности.

Это не ответ. Какие именно сложности? Компилятор вас ругается за плохие привычки?

int бывает больше байта

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

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

Это не ответ. Какие именно сложности? Компилятор вас ругается за плохие привычки?

Компилятор и Rc не умеют в циклические структуры данных.

я и для интов юзаю atomic от греха по дальше

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

я и для интов юзаю atomic от греха по дальше

Лол, до чего го людей доводит.

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

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

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

в го лучше всегда использовать мютекс?

вы тут переизобретаете RWLock что ли? (котоpый RwMutex в го)

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

Это если записи нет вообще и только чтение идёт.

в го лучше всегда использовать мютекс?

если переменная используется из разных одновременно работающих горутин и не константа, то mutex было бы неплохо. Чтоб при случайном забывании, что в переменную нельзя писать, ничего плохого не случилось

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

Да и на запись не нужны

Да и на запись не нужны

лок-фри?

лок-фри?

++

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

В данном случае вполне безопасный код, так как будет выполняться атомарная процессорная операция. Если хочется уверенности, то тогда атомик использовать. Для более сложных данных уже мютексы.

лок фри это какое-то слишком сильное колдунство

лок фри это какое-то слишком сильное колдунство

Для гоферов так точно. Ведь если дженериков нет, то им STM и твари для каждого типа придется самому имплементить.

В данном случае вполне безопасный код, так как будет выполняться атомарная процессорная операция. Если хочется уверенности, то тогда атомик использовать. Для более сложных данных уже мютексы.

а точно перезапись инта атомарная оперция? атомик-функции для интов же не просто так придумали

наверно в одноядерных системах на int не нужен мютекс.

а точно перезапись инта атомарная оперция? атомик-функции для интов же не просто так придумали

Ну процессор ее, насколько в курсе, атомарно выполняет. Кстати, сами атомик укладываются в несколько ассемблерных инструкций (там мютексы не задействуются).

наверно в одноядерных системах на int не нужен мютекс.

в одноядерных системах и Go не нужен

Ну процессор ее, насколько в курсе, атомарно выполняет. Кстати, сами атомик укладываются в несколько ассемблерных инструкций (там мютексы не задействуются).

Какой процессор?

Единственное, может это не для всех видов процессоров выполнимо.

Ну процессор ее, насколько в курсе, атомарно выполняет. Кстати, сами атомик укладываются в несколько ассемблерных инструкций (там мютексы не задействуются).

Любой инкремент, или инкремент регистра?

то есть мы пришли к выводу, что атомик или более сложный мютекс нужен всегда на чтения (даже для int-а) ?

Тот же инкремент int64 на 32х разрядном атомарно не выполнить.

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

Просто инкремент значения - это чтение из памяти в регистр, инкремент регистра, запись обратно в память. В x86/x64 это одна комманда вида inc [eax], но насколько атомарно выполняет её сам процессор - это большой вопрос. Плюс ещё как кеши между ядрами синхронизируются.

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

то есть мы пришли к выводу, что атомик или более сложный мютекс нужен всегда на чтения (даже для int-а) ?

Для int желателен. Чтобы на каком-нибудь процессоре конфуза не вышло.

Так что можно сказать, что для всего обязательно, чтобы где-нибудь конфуза не вышло.

то есть мы пришли к выводу, что атомик или более сложный мютекс нужен всегда на чтения (даже для int-а) ?

На любую общую между потоками мутабельную память.

Просто инкремент значения - это чтение из памяти в регистр, инкремент регистра, запись обратно в память. В x86/x64 это одна комманда вида inc [eax], но насколько атомарно выполняет её сам процессор - это большой вопрос. Плюс ещё как кеши между ядрами синхронизируются.

А с чего ты взял, что он в регистре всегда?

Просто инкремент значения - это чтение из памяти в регистр, инкремент регистра, запись обратно в память. В x86/x64 это одна комманда вида inc [eax], но насколько атомарно выполняет её сам процессор - это большой вопрос. Плюс ещё как кеши между ядрами синхронизируются.

И да, это 100% атомарно

И да, это 100% атомарно

Откуда такие сведения?

А с чего ты взял, что он в регистре всегда?

Ну я сомневаюсь, что процессор прямо в памяти будет делать инкремент.

Откуда такие сведения?

Архитектура x86

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

Архитектура x86

Да неужели?

Ну я сомневаюсь, что процессор прямо в памяти будет делать инкремент.

Тебе компилятор не даёт гарантий, где будет размещена переменная, в регистрах или оперативке

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

Тебе компилятор не даёт гарантий, где будет размещена переменная, в регистрах или оперативке

Причём тут компилятор, если мы про процессор вообще говорим?

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

*всегда не одно и тоже

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

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

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

А она разве гарантирует атомарность таких операций?

А она разве гарантирует атомарность таких операций?

Inc да

Inc да

какой inc?

Инкремент

Инкремент

инкремент чего?

вот inc eax скорее всего атомарный

а другая команда inc [eax] уже может быть как-то не очень атомарной

Ты тролль чтоль?

нет. я серьёзно спрашиваю

Ты не можешь обну ассемблерную команду нептомарно выполнить

это разные команды

Никак

Я понимаю, что разные

Ты не можешь обну ассемблерную команду нептомарно выполнить

А вот это очень сильное утверждение

Можно ещё вспомнить, что существуют ещё архитектуры кроме древнего x86

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