ну, какбэ, заради апишки из 3-4 методов тащить за собой потроха фреймворка, из которых тебе не нужно 80%...

так себе удовольствие, имхо

Что содержит последнее число при панике? Адрес? main.main() /.../panic.go:12 +0x47

ну, какбэ, заради апишки из 3-4 методов тащить за собой потроха фреймворка, из которых тебе не нужно 80%...

Да ну какой-нить эхо весит мало, а работать удобнее

Да ну какой-нить эхо весит мало, а работать удобнее

ну ладно, насчёт "какого-нибудь эхо", пожалуй, соглашусь. Его юзать можно. Но он сам настаивает на том, что он микрофреймворк, и не тащит за собой свои логи, свой orm и т.д. и т.п. А вот тот же beego тащит, им увлекаться не стоит. При этом для неофита, вероятно, стоит сначала сделать руками ровно все то, что делает echo, чтобы иметь понимание того, что там происходит, а уже потом принимать решение о том, какие фреймворки в проект тащить.

но это имхо

просто когда про фреймворки спрашивают, обычно ищут "что-то вроде laravel или ror, только для Go". Вот те, которые себя позиционируют как "laravel на Go", имхо, тащить в проект из 3-4 методов в апи, не стоит

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

ну или начнешь костылями обмазываться

#зависимости #dig https://m.habr.com/company/funcorp/blog/372199/

#зависимости #dig https://m.habr.com/company/funcorp/blog/372199/

а что по бенчмаркам?

Гоферы, и все кому интересно, скоро, 2 июня в Харькове будет проходить Go митап Приходите, будем рады вас видеть ! ? событие на facebook : https://www.facebook.com/events/1809296232498435/ регистрация и билеты : https://app.softserveinc.com/apply/register/en/khgomeetup?utm_source=ID283_idr1192

#зависимости #dig https://m.habr.com/company/funcorp/blog/372199/

поясните коммент > Данный подход был бы прекрасен, если бы под капотом не использовалась рефлексия, чреватая паниками во время выполнения.

просто когда про фреймворки спрашивают, обычно ищут "что-то вроде laravel или ror, только для Go". Вот те, которые себя позиционируют как "laravel на Go", имхо, тащить в проект из 3-4 методов в апи, не стоит

мне вот интересно, а что конкретно такие люди ищут? какой конкретно функционал им нужен?

Как в main-е на самом верху отловить все паники всех горутин?

Никак?

и как быть? отлавливать в каждой по отдельности?

только в горутинах

и как быть? отлавливать в каждой по отдельности?

Конечно

И платить за все дефёры

Как в main-е на самом верху отловить все паники всех горутин?

зачем именно в main'е? можно же запустить главный процесс в отдельной функции

И платить за все дефёры

эхх. ну спсб за ликбез

на крайняк: func main () { func() (err error) { defer func() { if r := recover(); r != nil { fmt.Println("Recovered in f", r) } }() // Application code goes here }() }

но я бы перенёс запуск приложения в отдельную функцию в которой ловил бы и перезапускал если оно требуется

зачем именно в main'е? можно же запустить главный процесс в отдельной функции

И чо?

И чо?

и то!

и то!

И ничего это не даст, кроме того, что при os.Exit() вызовется дефёр

И ничего это не даст, кроме того, что при os.Exit() вызовется дефёр

ну вызовется, и что с того? он спокойно пройдёт recover

вопрос же в том как словить панику глобально

вопрос же в том как словить панику глобально

перенос стартовой точки в другую горутину в этом плане вообще ничего не даст

перенос стартовой точки в другую горутину в этом плане вообще ничего не даст

Спасибо, лень было писать это ещё раз

вот запускать ПРОЦЕСС из другого процесса и перехватывать его std out и парсить в нём панику - вот это сила!

aaa, пардон, я неправильно прочёл, my bad, имеется ввиду не из главной горутины а всех в принципе.. ну да, при запуске каждой - defer

Fork bomb for the win

вот запускать ПРОЦЕСС из другого процесса и перехватывать его std out и парсить в нём панику - вот это сила!

Хороший язык и обработка ошибок интересная

И ничего это не даст, кроме того, что при os.Exit() вызовется дефёр

https://golang.org/pkg/os/#Exit не будет там дефера

Хороший язык и обработка ошибок интересная

Ну так тут все серьезно, никаких игрушек

мне вот интересно, а что конкретно такие люди ищут? какой конкретно функционал им нужен?

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

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

да уж) такого в Go конечно пока ещё мало

да уж) такого в Go конечно пока ещё мало

ну, какбэ, не уверен, что оно тут нужно

ну, какбэ, не уверен, что оно тут нужно

it depends.. по сути мир переходит уже на API + WebApp, но люди из "PHP мира" всё пилят свои приложения в стиле server-side-rendered, вот им то как-раз такое и нужно

так-что да, сомневаюсь что оно прям нужно в Go

Иронично, что server-side-rendered в первом типе приложений все равно приходится прикручивать)

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

а полновесные MVC-фреймворки... ну, какбэ, и на go есть, только от них геморроя вполне можно получить

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

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

тем более, собери в кучу полсотни-сотню толковых гоферов с опытом, заплати им денег и попроси конкретно для тебя "полновесный MVC-фреймворк все-искаропки" запилить...

передерутся нафиг

если не на этапе "общей архитектуры", то уж при выборе логгера/orm'а - точно посрутся насмерть

потом будет война за шаблонизатор и роутер

потом будет война за шаблонизатор и роутер

Есть решение же: написать свое

в конечном итоге ты получишь за свои кровные (мы помним, ты им заплатил) штук 10 "полновесных фреймворков", пару "модульных систем" и с полсотни "решений на микросервисной архитектуре" - все это различной степени готовности и упоротости

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

Но если это full-featured, то там все свое обычно пишут, таки да.

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

собственно в части "собери в кучу полсотни-сотню толковых гоферов с опытом, заплати им денег и попроси конкретно для тебя "полновесный MVC-фреймворк все-искаропки" запилить..." ключевые понятия "в кучу" и "попроси их всех"

вот "full-featured" на го я уже видел, пока что не в восторге

Иронично, что server-side-rendered в первом типе приложений все равно приходится прикручивать)

первом типе?

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

первом типе?

Ну, для API + WebApp вам все равно нужен server-side-render как минимум для всяких скрапперов от поисковиков и читалок.

а го - он либо если хочется "попроще, но надежно, как трактор", либо если хочется "странного"

Ну, для API + WebApp вам все равно нужен server-side-render как минимум для всяких скрапперов от поисковиков и читалок.

современные WebApp это из-коробки умеют с помощью SSR, приложение просто хостится Node'ой и рендерится там. Есть чёткое разделение представления и данных

Зная, какие веселые люди пишут nodejs, я слабо верю, что оно так просто работает в духе "подключить одной строкой". Предполагаю, что там надо таки веселостей нахватать.

ERROR: S client not available

Зная, какие веселые люди пишут nodejs, я слабо верю, что оно так просто работает в духе "подключить одной строкой". Предполагаю, что там надо таки веселостей нахватать.

ну это вам конечно не сайт на PHP написать, но оно становится всё проще с эволюцией таких фреймов как Vue, React, Angular

уже даже фреймы чисто для SSR имеются такие как Nuxt.js на основе Vue.js

суть в том, что мир переходит на WebApp + API и Go из коробки отлично для API подходит и без всяких фреймов аля Laravel и всяких говно-CMS

зачастую просто берёшь шаблон приложения уже со всеми настройками и поверх него пишешь, ибо самостоятельно конфиги писать конечно полная жопа

Хороший язык и обработка ошибок интересная

ещё бы. другие на много хуже.

ещё бы. другие на много хуже.

Не, я думаю, что ты обманываешь меня.

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

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

Не, я думаю, что ты обманываешь меня.

а я вот думаю ты сам обманываешь себя

а я вот думаю ты сам обманываешь себя

Какое самомнение, лол

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

А зачем нужен фронтенд?

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

Уо-уо-уо пацанчик, ты дорогу то не попутал?

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

Штотынесёшь

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

Энтузиасты придумали программирование частично

Тот же Дейкстера

Штотынесёшь

обоснуй

А зачем нужен фронтенд?

для гешефта. но простофилям не нужен если ты об этом

для гешефта. но простофилям не нужен если ты об этом

Помоему ты знатный троль. Не кормите троля

Как жизнь мужики ?

Понял дядь.

Зажигалку ?

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

писать HTML сайты на DSL? ну-ну...

сейчас бы серьёзно воспринимать вбросы Filimonenkow'а

писать HTML сайты на DSL? ну-ну...

Ну как бы любой шаблонизатор, в то числе и в GO - это уже DSL. А вообще в том вбросе все достаточно уныло, особенно про здоровых людей и фронтенд.

Ну как бы любой шаблонизатор, в то числе и в GO - это уже DSL. А вообще в том вбросе все достаточно уныло, особенно про здоровых людей и фронтенд.

а что там про фронтэнд?)

а что там про фронтэнд?)

Сервер сайд фронтенд - это как "деревянное стекло"

Сервер сайд фронтенд - это как "деревянное стекло"

ну... я таки за web-apps нежели server-side frontends веб приложение более соответствует требованиям нынешнего времени

ну... я таки за web-apps нежели server-side frontends веб приложение более соответствует требованиям нынешнего времени

Я не про клиент-сервер, а про дебильность определения "сервер сайд фронтенд" фронтенд он либо фронтенд - либо нет. Где он реализован - не имеет отношения к тому как он реализован. Он ляпнул полнейший бред, вроде "Это не правильно, потому что все теплое, уже давно мягкое, а тут оно все еще квадратное"

Я не про клиент-сервер, а про дебильность определения "сервер сайд фронтенд" фронтенд он либо фронтенд - либо нет. Где он реализован - не имеет отношения к тому как он реализован. Он ляпнул полнейший бред, вроде "Это не правильно, потому что все теплое, уже давно мягкое, а тут оно все еще квадратное"

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