не верю. их тупо больше...

Ну давайте тогда все unsafe операции запретим, чтобы чудаки себе и другим в ноги не стреляли

а я бы и запретил, будь моя воля

а ну понятно

а я бы и запретил, будь моя воля

И сломал бы мне тонну проектов

ну - бодливой корове бог рог не дает

методы унести в третий пакет

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

ещё тьюринг полноту надо запретить, чтобы бесконечные циклы никто создать не смог

Ваще круто было бы 👍

Ну давайте тогда все unsafe операции запретим, чтобы чудаки себе и другим в ноги не стреляли

С ума сошел?

С ума сошел?

нет, просто довёл идею до абсурда

Вот чего стоит сделать с unsafe - это сделать блоки кода

И ещё очень хочется свои коллекции вместо стандартных

а зачем?

мне вот не хочется :)

И ещё очень хочется свои коллекции вместо стандартных

если в 2.0 угодить всем любителям странного, эдак можно и руст переплюнуть

методы унести в третий пакет

Это ничем не помогает, только теперь в цепочке импортов появляется 3 пакет, получается что два других ипортят его, а он импортит оба... а при разносе на 4 пакета я получил крговую зависимость...

Это ничем не помогает, только теперь в цепочке импортов появляется 3 пакет, получается что два других ипортят его, а он импортит оба... а при разносе на 4 пакета я получил крговую зависимость...

А в GO нет чего-то похожего на плюсовую #pragma once ?

коллега

что вам не помогает

А в GO нет чего-то похожего на плюсовую #pragma once ?

Передавай в туда in/out каналы и пуляйся данными

да причем тут каналы

человек схему типов сдизайнить не може без циклических зависимостей

а вы ему каналы

что вам не помогает

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

Или Вы предлогами вынести вызываемый метод в другой пакет?...

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

надо сесть и начертить в голове/в пейнте/на бумажке схему желаемой работы с учетом невозможности цикличных импортов )

я поначалу тоже о подобное спотыкался

надо сесть и начертить в голове/в пейнте/на бумажке схему желаемой работы с учетом невозможности цикличных импортов )

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

а чем каналы плохо? :)

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

нет

раздели логику и данные

если в 2.0 угодить всем любителям странного, эдак можно и руст переплюнуть

А что странного?

ну, примитивный пример из головы: - есть пакет DB, оперирующий общением с БД. Конект, дисконект, ещё что-то - есть пакет с бизнес-логикой - есть данные, которые должны быть доступны обоим пакетам (сами данные, их структуры): модели/описания таблиц собственно, выносишь модели в отдельный пакет - и импортишь его куда угодно. Главное, чтобы в нём не было _вообще_ ничего лишнего: это тупо структуры, которые ничего не знают ни про БД, ни про логику

у тебя, например (ну пальцем в небо, не зная твоей начинки) - сделать отдельные структуры "UserMessage", "UserResponse", которые пулять по каналам в ядро и обратно

А что странного?

на сколько я понимаю, стандартные контейнеры устраивают всех кроме вас и может быть ещё пары тройки людей

у тебя, например (ну пальцем в небо, не зная твоей начинки) - сделать отдельные структуры "UserMessage", "UserResponse", которые пулять по каналам в ядро и обратно

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

эм... а что именно непонятно?)

создаёшь 2 канала (ин, аут) или один (ин/аут) ; из "общателя" передаёшь в ядро, или наоборот, или в оба при инициализации дальше обоими пакетами слушаешь эти каналы, при поступлении данных - что-то с ними делаешь

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

Тот же самый брокер, только вместо редиса с sub/pub у тебя просто ин/аут канал

создаёшь 2 канала (ин, аут) или один (ин/аут) ; из "общателя" передаёшь в ядро, или наоборот, или в оба при инициализации дальше обоими пакетами слушаешь эти каналы, при поступлении данных - что-то с ними делаешь

Солидарен

Щас попробую осознать... Что-то пробивается в голову :)

Да, в парадигму вьезжать надо

А потом всякие там блокировки.... Особенно если куча каналов создается и убивается динамически

Тяжко питонисту go дается....

Тяжко питонисту go дается....

И тут солидарен.

Ничего, привыкнешь очень быстро

Тяжко питонисту go дается....

Самое сложное, это переключиться с асинхронной модели мвшления

Прочёл generics draft overview. Не очень понятен радостный ажиотаж ФП-боев. Судя по тексту там больше вопросов чем ответов, совершенно не понятно появятся ли дженерики в Го-2, а если появятся, то в каком виде. Контракты в том виде, как он их описал, было бы круто конечно, но маловероятно что они будут (а без них я так понял дженерикам не бывать). Не понятно например как определить эквивалетность контрактов и как их наследовать.

Тут есть кто говорил что джинерики не нужны?

Что вы будете говорить после того как их введут?

Что, коллеги, благодарю!! Пошел осознавать :) всем доброй ночи!

Прочёл generics draft overview. Не очень понятен радостный ажиотаж ФП-боев. Судя по тексту там больше вопросов чем ответов, совершенно не понятно появятся ли дженерики в Го-2, а если появятся, то в каком виде. Контракты в том виде, как он их описал, было бы круто конечно, но маловероятно что они будут (а без них я так понял дженерикам не бывать). Не понятно например как определить эквивалетность контрактов и как их наследовать.

Самый годный фидбэк про джененрики в Го, что я видал - Maxwell Corbin https://github.com/golang/go/wiki/Go2GenericsFeedback. Чувак предлагает ввести в гошечку first class packages как в ocaml. Вот это тема!

Что вы будете говорить после того как их введут?

смотря кому и куда их введут. но я за 5 лет программирования на go не столкнулся с задачей, где были бы уместны генерики

Самый годный фидбэк про джененрики в Го, что я видал - Maxwell Corbin https://github.com/golang/go/wiki/Go2GenericsFeedback. Чувак предлагает ввести в гошечку first class packages как в ocaml. Вот это тема!

Package level generics avoids the most abusive problems of meta-programming while retaining the bulk of its usefulness.

смотря кому и куда их введут. но я за 5 лет программирования на go не столкнулся с задачей, где были бы уместны генерики

ни кто не столкнулся

не

вот @pragus говорит, что они ему были бы полезны - и я ему верю

просто он ленится объяснить, в чем :)

смотря кому и куда их введут. но я за 5 лет программирования на go не столкнулся с задачей, где были бы уместны генерики

То есть вы не измените мнение?

вот @pragus говорит, что они ему были бы полезны - и я ему верю

сдаётся мне там какая-то экзотика. @twentydraft тоже вот говорит что нужны, стращая нас некими графами, но код показать тоже стесняется, что характерно

какое именно мнение я не изменю? повторяю по буквам: за 5 лет программирования на go не столкнулся с задачей, где были бы уместны генерики

так видно?

вы столкнулись, коллега?

опишите, пожалуйста, свою задачу

мне больше кажется, что они хотят изобрести неудобную версию interface{} 🙂

мне больше кажется, что они хотят изобрести неудобную версию interface{} 🙂

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

лучше бы сделали более удобным (и менее затратным) получение типа данных из интерфейса (типа чтобы я мог сделать что-то вроде `if i.Type != int { return }`). А, погодите, они же это и хотят ввести в виде type section 😄 кошмарЪ

Привет, есть что-нибудь на го, что умеет создавать онлайн график? В gui

Привет, есть что-нибудь на го, что умеет создавать онлайн график? В gui

github.com/wcharczuk/go-chart - огонь либа

лучше бы сделали более удобным (и менее затратным) получение типа данных из интерфейса (типа чтобы я мог сделать что-то вроде `if i.Type != int { return }`). А, погодите, они же это и хотят ввести в виде type section 😄 кошмарЪ

и проверкуи типов уедут в рантайм

нет уж, не надо

@onokonem как вам вот это \\ list package list[T] type T interface{} type List struct { Val T Next *List } // main package main import ( il "list"[int] sl "list"[string] ) var iList = il.List{3} var sList = sl.List{"hello"} имхо - и рыбку съесть и овцы целы

этого недостатточно, к сожалению

на сколько я понимаю, стандартные контейнеры устраивают всех кроме вас и может быть ещё пары тройки людей

Окей, вот хочу я map с сохранением порядка, например

этого недостатточно, к сожалению

конечно. но идея то годная

Окей, вот хочу я map с сохранением порядка, например

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

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

опишите, пожалуйста, свою задачу

Извините, на Го не пишу. Просто интересовался. :) Удачи вам.

Извините, на Го не пишу. Просто интересовался. :) Удачи вам.

да при чем тут go