то есть вот такой код не упростить? https://play.golang.org/p/bJGngfy8Lw (у нас имеется именно массив ссылок, надо значения из него передать в set)

для начала, вот этот код делает ровным счетом это же: https://play.golang.org/p/ZMpOJp5jM7

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

для начала, вот этот код делает ровным счетом это же: https://play.golang.org/p/ZMpOJp5jM7

о, спасибо ) что то я совсем не подумал, в set я принимаю именно значения, не указатели, просто в одном месте массив указателей попался, поэтому логика отдельная

точнее даже не я принимаю, там фактически функция из стороннего модуля

в set ты принимаешь указатели, потому что ты так написал

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

вот в обратную сторону уже не оптимизируется так просто похоже case *int: { if res, ok := val.(int); ok { *f = res } }

и так для каждого типа

что-то ты непойми что написал

сейчас подробнее напишу

я о коде

вот что то типа такого https://play.golang.org/p/q_ZN9-uI7F

вот что то типа такого https://play.golang.org/p/q_ZN9-uI7F

угу https://play.golang.org/p/HGGZktn7mA

для начала, вот этот код делает ровным счетом это же: https://play.golang.org/p/ZMpOJp5jM7

кстати нет, ты заменил set(*f) на set(f), а если там писать set(*f) то вылезет тот самый invalid indirect of f (type interface {})

то есть вот так оно не будет работать https://play.golang.org/p/ngU4W9fpK2

А кто знает может где-то есть либа на golang для api менеджера Signal.

?

Очень надо, а у них только Java либа

*месенджера

https://whispersystems.org

Народ

При попытке сделать sudo go ошибка появляется

что нет такой команды

с обычным go все пашет

как быть?

почитать про PATH

дак все норм прописано

export PATH=$PATH:/usr/local/go/bin export GOPATH=$HOME/golang

это для твоего пользователя, а sudo его меняет же

понял, спасибо

Кто на ВК хакатон едет?)

куда-куда ты нас послал?

Полагаю что речь о https://vk.com/vkhackathon

а что там делать гоферам?

В прошлом году было весело. Вспомнил университетские годы :D В этом году поучаствовал бы тоже, но узнал слижком поздно

приложения такие на пхп надо писать )

Ну это дело вкуса))

да как бы

там все смотреть будут на идею и реализацию, а именно — картинку и фронтенд) а на голанге ты дольше будешь валидаторы запросов подключать, проще взять пхп фреймворк

приложения такие на пхп надо писать )

ну хрен знает

Смотря какую цель перед собой ставить :) Если "выиграть", то нужно что-то хорошо выглядящее(не обязательно рабочее даже, лол). А если just for fun то почему бы не написать на любимом языке

расшарил на GO на 80ый порт приложуху, и пилишь)

ну мы покрайне мере, в стеке GO + Redis + SphinxSearch выбрали )

Смотря какую цель перед собой ставить :) Если "выиграть", то нужно что-то хорошо выглядящее(не обязательно рабочее даже, лол). А если just for fun то почему бы не написать на любимом языке

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

мб похапэ будет, если идея / время не оправдает себя

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

Смотря что требуется. Если нужна скорость, то вариант на php/ruby ты будешь основное время разгонять

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

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

Смотря что требуется. Если нужна скорость, то вариант на php/ruby ты будешь основное время разгонять

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

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

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

у меня знакомые чуваки ходят на людум хакатонить. в итоге игры делают на флеше )

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

Ну это уже личное, у каждого своё. Кто-то вообще один ходит на такие мероприятия

я собирался туда, пока чуваки не зарелизили Заявки :D

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

до ума = сделать кучу работы по фронтенду и доделать бекенд

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

Ну, на бэке всё логично )

а на фронте - какой-то ценный пушной зверек...

вы просто сношаете его в противоестественные щели

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

методологий*

очепятался

*в любой непонятной стируации обвиняй браузеростроителей*

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

смотря какой стек

*в любой непонятной стируации обвиняй браузеростроителей*

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

ERROR: S client not available

смотря какой стек

ну тут да. Моя фраза по поводу "противоестественных" технологий относилась к вебне.

ну тут да. Моя фраза по поводу "противоестественных" технологий относилась к вебне.

я имею ввиду, какой у тебя фронтовый стек

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

фронт в браузере - зло. Но зло неизбежное.

есть на фронте довольно логичный стек с которым проблем столько нет

но он полностью исключает MV*

есть на фронте довольно логичный стек с которым проблем столько нет

например?

react+redux

ну, т.е., по-прежнему, вебня?

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

Забавно, но мне не кажется оптимальным подходом реализовывать низкоуровневые библиотеки для построения интерфейсов под каждый язык и платформу. Зачем, если можно просто взять браузер. Фреймворков в мире фронта сейчас много и некоторые из них просто великолепны(react)

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

redux конечно буэ.. адхок реализация elm на js )

flux не нужен. redux.

redux конечно буэ.. адхок реализация elm на js )

elm-то тут опять при чем?

да то что содрано оттуда

а так конечно не при чем )

будто бы CQRS никогда до elm не было

а где на фронте это было?

да что угодно, реализующее CQRS на js.

Забавно, но мне не кажется оптимальным подходом реализовывать низкоуровневые библиотеки для построения интерфейсов под каждый язык и платформу. Зачем, если можно просто взять браузер. Фреймворков в мире фронта сейчас много и некоторые из них просто великолепны(react)

Т.е. ты предлагаешь отказаться от низкоуровневых библиотек для построения интерфейсов? И на чем мы будем строить интерфейсы браузеров? И все десктопные приложения, требующие периодически предсказуемого времени отклика и "отзывчивости" тоже все в браузер запихаем? И интерфейсы DE тоже все в браузер?

ну как бы “что угодно”, но по факту до redux как-то нихера и не было в мире js

всякие mobx уже потом пришли

Т.е. ты предлагаешь отказаться от низкоуровневых библиотек для построения интерфейсов? И на чем мы будем строить интерфейсы браузеров? И все десктопные приложения, требующие периодически предсказуемого времени отклика и "отзывчивости" тоже все в браузер запихаем? И интерфейсы DE тоже все в браузер?

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

Т.е. ты предлагаешь отказаться от низкоуровневых библиотек для построения интерфейсов? И на чем мы будем строить интерфейсы браузеров? И все десктопные приложения, требующие периодически предсказуемого времени отклика и "отзывчивости" тоже все в браузер запихаем? И интерфейсы DE тоже все в браузер?

Не предлагаю, но предполагаю что эти библиотеки отойдут на задний план и будут более низкоуровневыми, со временем. Потому что нет смысла вкладывать годы в их разработку, если всё можно гораздо быстрее и проще сделать в браузере(с не слижком большими потерями производительности, которыми можно пренебречь в угоду скорости разработки). Кстати, DE, строящие интерфейсы "в браузере" уже есть, тотже gnome. Там конечно не совсем браузер в привычном понимании этого слова, но нечто похожее

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

а кто говорит о велосипедах? И, в случае разработки под браузер, вы не берете на себя ответственность за разработчиков браузеров и веб-стандартов?

а кто говорит о велосипедах? И, в случае разработки под браузер, вы не берете на себя ответственность за разработчиков браузеров и веб-стандартов?

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

а кто говорит о велосипедах? И, в случае разработки под браузер, вы не берете на себя ответственность за разработчиков браузеров и веб-стандартов?

Стандарты есть везде. И если говорить про вэб то я уж лучше буду использовать его, потому что он популярнее, что говорит о том что обратная совместимость там будет поддерживаться достаточное время(пример - переход на es6)

Блин, люди, если мне нужна простая гуйня к чату - не вижу ничего зазорного упаковать веб-страницу, а если нужно что-то серьезное - тут уже стоит думать, исходя из задач. Короче - что использовать нужно решать исходя из требований и задач, не новость. Можно и gnome\kde в браузер загнать, но зачем? Так же можно и github в натив написать, но опять таки нахрен?

Не предлагаю, но предполагаю что эти библиотеки отойдут на задний план и будут более низкоуровневыми, со временем. Потому что нет смысла вкладывать годы в их разработку, если всё можно гораздо быстрее и проще сделать в браузере(с не слижком большими потерями производительности, которыми можно пренебречь в угоду скорости разработки). Кстати, DE, строящие интерфейсы "в браузере" уже есть, тотже gnome. Там конечно не совсем браузер в привычном понимании этого слова, но нечто похожее

Поверь, не все можно сделать в браузере. Про "не слишком большие потери производительности" - забавно, улыбнуло. Про скорость разработки - еще веселее. Вы реально верите, что написать гуй для простенькой софтинки на Qt/QML или GTK - это дольше, чем сваять браузерную весию? Секрет популярности вообще не в скорости разработки. Секрет исключительно в стоимости (веб-дизайнер относительно недорог. Плюсом - единожды написанный сайт всегда можно упаковать в пакет и выдать это за десктопное приложение).

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

Ага, платформа-то одна... Только вот есть IE, Chrome, Opera, Firefox и прочие... Все с "местечковыми причудами"

Ага, платформа-то одна... Только вот есть IE, Chrome, Opera, Firefox и прочие... Все с "местечковыми причудами"

IE deprecated и почти всем заказчикам нахрен не нужен, а остальные прекрасно работают и так.