Расскажи мне за это )

блин как сделать для 2 типов общую ф-ию

Сделать интерфейс Collection

ну извращение компилировать то что не предназначалось для этого

Продакшн нормально так что ага

Интелл сделало логику проца на питоне и написало свой компилятор взяв за основу пайпай и ситон

ну до таких подробностей я не спускался но все же go низкоуровневый ведь?

type MyInterface interface { me() *[]MyStructure }

Да, только для метод можно использовать как Marshall метод

И опять уперся что ругается тк разное кол-во элементов

Ты просто не вкурил суть интерфейсов Щас доберусь до ноутбука и покажу

На С можно делать низкоуровневое. Ну - пытаться. В го нет адресной арифметики, поэтому на нем пытаться бесполезно

И опять уперся что ругается тк разное кол-во элементов

На С можно делать низкоуровневое. Ну - пытаться. В го нет адресной арифметики, поэтому на нем пытаться бесполезно

Лет 5 назад мое изучение питона как раз закончилось на выборе какую же версию на тот момент изучать :D

Тут два варинта: - либо, как выше указал @elemc, можно заменить оба этих типа одним в виде слайса структур - либо подумать, какое свойство у твоих структур общее и выделить его в интерфейс. Например, в вашем случае нужно получать дамп каждой коллекции. Тогда сделаем интерфейс Collection с методом DumpCollection(io.Writer) error и реализуем его для каждого вашего типа https://play.golang.org/p/HNQeaVEsK8

А как сделать чтобы получить снова этот же тип массив?

Если я так делаю, это очень плохо? // HatersDevelop project main.go package main import ( "fmt" ) func main() { var x, y int fmt.Println("X NOW:", x, " Y NOW:", y) go split(100, &x, &y) fmt.Println("X NOW:", x, " Y NOW:", y) } func split(sum int, x, y *int) { *x = (sum / 50) *y = ((*x * 3) / 2) }

Если я так делаю, это очень плохо? // HatersDevelop project main.go package main import ( "fmt" ) func main() { var x, y int fmt.Println("X NOW:", x, " Y NOW:", y) go split(100, &x, &y) fmt.Println("X NOW:", x, " Y NOW:", y) } func split(sum int, x, y *int) { *x = (sum / 50) *y = ((*x * 3) / 2) }

у тебя последний println не ждет завершения горутины

Очень плохо - это делить на ноль 😄

Нет там на 0 деления 😆

Значит не "очень плохо" ))

То есть в принципе такой подход допускается? И это не очень плохо, а просто плохо )

Новая идея для линтера - оценка по шкале, насколько плох код. 😄 Раз компилится и работает, значит допускается (компилятором 😄).

А если он компилится, работает, но результат не вервый на выходе? 😆

Собственно это и есть программирование в филосовском смысле 😂

Если я так делаю, это очень плохо? // HatersDevelop project main.go package main import ( "fmt" ) func main() { var x, y int fmt.Println("X NOW:", x, " Y NOW:", y) go split(100, &x, &y) fmt.Println("X NOW:", x, " Y NOW:", y) } func split(sum int, x, y *int) { *x = (sum / 50) *y = ((*x * 3) / 2) }

Плохо! Два потока будут использовать общую память. Каналы же есть.

Ну и пускай используют, это как пример только

Тогда не понятно про что вообще был вопрос...

go run -race

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

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

Тоже плохо. Ты можешь их потерять

Хорошо а если слайс забивать по ссылке сразу в 2-х горутинах, при этом не важно в каком порядке будут данные поступать, как насчет этого?

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

Глупый вопрос, но почему?

Слайс это всего лишь указатель на память. append в некоторых случаях может выделять новый блок памяти. в одном потоке ты добавил данные, а второй поток выделил новую память и тоже добавил данные. потом они по очереди обнови информацию в слайсе, произойдёт в момент slice := append() как раз когда надо обновить твою переменную, и получится, что слайс будет указывать на другой участок памяти, где данных от первого потока нет