современный нам интеренет был создан на php, а не на node. это важно понимать

¯\_(ツ)_/¯ ну потому что пхп подходит для уж очень узкого спектра задач ? в отличии от го и той же ноды ? и то что он неплохо подойдет для написания форума, не значит что его надо учить и использовать вместо той же ноды ?

Форум наследие фидо, там не требуется сверхмощностей. Че там учить, тоже не понятно.

в случае с форумом сначала встанет вопрос А зачем писать своё? и дальше от этого прыгать

в случае с форумом сначала встанет вопрос А зачем писать своё? и дальше от этого прыгать

Ну как бы да, но я так понял задротство ради задротства

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

@onokonem А можно подробное, что бы вы использовали для написания этого классического форума? Пусть это будет PostgreSQL, три таблицы: пользователи, посты и комменты. Из дополнительных требований: - должны писаться логи в файлы, т.е. если какая-то была ошибка, она должна быть записана в файл - должна сессия пользователя сохраняться при перезапуске приложения. Например я у себя в ноде для этого использую редис, а что использовали бы вы? - после перезапуска браузера пользователь должен остаться залогиненым, т.е. храним что-то в куке Использовали ли вы что-то кроме стандартной библиотеки?

тут только драйвера для БД сторонние

Форум наследие фидо, там не требуется сверхмощностей. Че там учить, тоже не понятно.

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

¯\_(ツ)_/¯ ну потому что пхп подходит для уж очень узкого спектра задач ? в отличии от го и той же ноды ? и то что он неплохо подойдет для написания форума, не значит что его надо учить и использовать вместо той же ноды ?

пхп подходит как раз для большого спектра задач.

пхп подходит как раз для большого спектра задач.

Да ну. Для чего, кроме веба?

@onokonem А можно подробное, что бы вы использовали для написания этого классического форума? Пусть это будет PostgreSQL, три таблицы: пользователи, посты и комменты. Из дополнительных требований: - должны писаться логи в файлы, т.е. если какая-то была ошибка, она должна быть записана в файл - должна сессия пользователя сохраняться при перезапуске приложения. Например я у себя в ноде для этого использую редис, а что использовали бы вы? - после перезапуска браузера пользователь должен остаться залогиненым, т.е. храним что-то в куке Использовали ли вы что-то кроме стандартной библиотеки?

А можно я? Echo + plain JS, без фреймворков. Ну если только CSS-фреймворк какой-нибудь. По архитектуре - фронт и бэк разделять, на JS запилить простенькую логику рендеринга форума и нужных сущностей, бэк - это просто REST с авторизацией по токену, который или в куках, или в localStorage.

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

Я такой форум знаю только один, Московской бирже принадлежит :>

Да, именно. У меня просто задачи это примерно как примитивный форум + еще куча разных демонов, которые общаются с другими микросервисами. Как раз я подозреваю, что Го реально хорош для того, чтобы общаться с микросервисами. Это моя боль в Node.js, я никак не могу найти вариант общения микросервисов, который мне понравился бы. И вот в Го у меня надежда на gRPC, что он хорош. И вот я начал для теста писать эту классическую админку для операторов, и понял что что-то не понимаю я радости Го :) А иметь в арсенале много языков я не любитель, так как когда в наличии только один язык, то код пишется практически мышечной памяться. А переключаться между контекстами разных языков это убивает такое автоматическое написание.

не надо server-side рендеринг HTMLа только пилить, с этим точно будет боль)

@onokonem А можно подробное, что бы вы использовали для написания этого классического форума? Пусть это будет PostgreSQL, три таблицы: пользователи, посты и комменты. Из дополнительных требований: - должны писаться логи в файлы, т.е. если какая-то была ошибка, она должна быть записана в файл - должна сессия пользователя сохраняться при перезапуске приложения. Например я у себя в ноде для этого использую редис, а что использовали бы вы? - после перезапуска браузера пользователь должен остаться залогиненым, т.е. храним что-то в куке Использовали ли вы что-то кроме стандартной библиотеки?

логи - structlog постгрес - reform или/и squirrel сессия - в JWT, защищена криптографически, в куке. для jwt есть либы, но мы когда-то написали свою, поэтому не посоветую.

Да ну. Для чего, кроме веба?

Ну форум - это веб. Или нет?

Ну форум - это веб. Или нет?

Я не спорю, широкий круг задач - это веб?

Я не спорю, широкий круг задач - это веб?

Веб бывает разный. Ну онлайн-ОС я, конечно, не представляю на PHP, но платежные шлюзы, шеллы и парсеры - почему бы и нет?)

Да, именно. У меня просто задачи это примерно как примитивный форум + еще куча разных демонов, которые общаются с другими микросервисами. Как раз я подозреваю, что Го реально хорош для того, чтобы общаться с микросервисами. Это моя боль в Node.js, я никак не могу найти вариант общения микросервисов, который мне понравился бы. И вот в Го у меня надежда на gRPC, что он хорош. И вот я начал для теста писать эту классическую админку для операторов, и понял что что-то не понимаю я радости Го :) А иметь в арсенале много языков я не любитель, так как когда в наличии только один язык, то код пишется практически мышечной памяться. А переключаться между контекстами разных языков это убивает такое автоматическое написание.

а в ноде что мешает grpc заюзать, лол?

@onokonem Спасибо! По поводу PostgreSQL вопрос. Как я понял, вы привели пример ОRМ, или я ошибаюсь? У меня просто неприязнь еще с Java / Hibernate от ORM. Вначале с ними все замечательно, а когда проект сложный, то понимаешь, что через год больше времени тратишь на борьбу ОРМ при решении нестандартных задач, чем на бизнес логику. Поэтому я уже очень давно работаю с MongoDB, так как никакие там ORM не нужны, и при смене языка, мои знания не теряются. Как я понял, в го еще нет нормального официального драйвера для монги. Это у меня вторая попытка на Го начать писать. Года два назад как раз мне что-то очень не понравилось в том неофициальном драйвере монги, и я на Го забил. И вот вопрос такой: а возможно ли писать сложные приложения с PostgreSQL с базовыми драйверами, ну или легковесными хелперами обвязками над ними? Т.е. чтобы никакой черной магии ORM типа Hibernate не было.

https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/

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

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

@onokonem Спасибо! По поводу PostgreSQL вопрос. Как я понял, вы привели пример ОRМ, или я ошибаюсь? У меня просто неприязнь еще с Java / Hibernate от ORM. Вначале с ними все замечательно, а когда проект сложный, то понимаешь, что через год больше времени тратишь на борьбу ОРМ при решении нестандартных задач, чем на бизнес логику. Поэтому я уже очень давно работаю с MongoDB, так как никакие там ORM не нужны, и при смене языка, мои знания не теряются. Как я понял, в го еще нет нормального официального драйвера для монги. Это у меня вторая попытка на Го начать писать. Года два назад как раз мне что-то очень не понравилось в том неофициальном драйвере монги, и я на Го забил. И вот вопрос такой: а возможно ли писать сложные приложения с PostgreSQL с базовыми драйверами, ну или легковесными хелперами обвязками над ними? Т.е. чтобы никакой черной магии ORM типа Hibernate не было.

Сейчас работаю с монгой на го. Не можете подсказать какие проблемы у драйвера ?

Ну это было года два назад. Я уже точно не помню, но было что-то типа такого, но могу и наврать. У меня был батч инсерт, на много документов. И оказалось, что драйвер имел какие-то лимиты. Типа не мог он больше 10К за раз документов заинсертить, но с цифрами могу врать. И мне нужно было самому делать воркараунд этой проблемы, разбивать мои списки на пачки. Естественно в JS и Java такой проблемы не было, они сами автоматом работали как надо.

@onokonem Спасибо! По поводу PostgreSQL вопрос. Как я понял, вы привели пример ОRМ, или я ошибаюсь? У меня просто неприязнь еще с Java / Hibernate от ORM. Вначале с ними все замечательно, а когда проект сложный, то понимаешь, что через год больше времени тратишь на борьбу ОРМ при решении нестандартных задач, чем на бизнес логику. Поэтому я уже очень давно работаю с MongoDB, так как никакие там ORM не нужны, и при смене языка, мои знания не теряются. Как я понял, в го еще нет нормального официального драйвера для монги. Это у меня вторая попытка на Го начать писать. Года два назад как раз мне что-то очень не понравилось в том неофициальном драйвере монги, и я на Го забил. И вот вопрос такой: а возможно ли писать сложные приложения с PostgreSQL с базовыми драйверами, ну или легковесными хелперами обвязками над ними? Т.е. чтобы никакой черной магии ORM типа Hibernate не было.

jmoiron/sqlx посмотри, понравится точно)

Prevet

Ну это было года два назад. Я уже точно не помню, но было что-то типа такого, но могу и наврать. У меня был батч инсерт, на много документов. И оказалось, что драйвер имел какие-то лимиты. Типа не мог он больше 10К за раз документов заинсертить, но с цифрами могу врать. И мне нужно было самому делать воркараунд этой проблемы, разбивать мои списки на пачки. Естественно в JS и Java такой проблемы не было, они сами автоматом работали как надо.

Просто работал в компании рекламной и там пользуются монгой для миллионов записей и вроде таких проблем не было .__.

так там батчем

Так и там не по одному. массивы данных слишком большие чтобы выдавать их по одному

кто их знает

похоже вот на это https://github.com/go-mgo/mgo/issues/288

судя по всему стало получше

Доброй ночи, чат. Вопрос касается Го немного косвенно, но за помощь и идеи буду благодарен. Задача стоит такая: нужно написать утилиту создания отчетов, которая бы заполняла шаблоны LibreOffice (выбран чтобы не технические люди могли редактировать шаблоны) данными, получаемыми из постгреса и генерировала файл. Графический интерфейс либры использовать нельзя. Вопросы по этой куче добра: 1) Если бы перед вами стояла такая задача, что бы вы использовали как генератор шаблонов вместо либры (требование - простота интерфейса, чтобы создателю шаблонов не пришлось писать разметку) 2) Если использовать либру, какие возможные пути заполнения файла-шаблона? Пока рассматривал макросы (пока не увидел способа запустить без ГУИ), разархивирование файла-шаблона и изменение xml напрямую (негибкий подход) и использование АПИ либры через Го-обертки (еще не читал доки АПИ, если есть кто-то с опытом - буду рад совету)

судя по всему стало получше

Так это заброшенный драйвер. Сейчас развивается комьюнити

https://github.com/globalsign/mgo

Даже в самой репе той на нее ссылка есть

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

А. Окей хорошо :)

@onokonem Спасибо! По поводу PostgreSQL вопрос. Как я понял, вы привели пример ОRМ, или я ошибаюсь? У меня просто неприязнь еще с Java / Hibernate от ORM. Вначале с ними все замечательно, а когда проект сложный, то понимаешь, что через год больше времени тратишь на борьбу ОРМ при решении нестандартных задач, чем на бизнес логику. Поэтому я уже очень давно работаю с MongoDB, так как никакие там ORM не нужны, и при смене языка, мои знания не теряются. Как я понял, в го еще нет нормального официального драйвера для монги. Это у меня вторая попытка на Го начать писать. Года два назад как раз мне что-то очень не понравилось в том неофициальном драйвере монги, и я на Го забил. И вот вопрос такой: а возможно ли писать сложные приложения с PostgreSQL с базовыми драйверами, ну или легковесными хелперами обвязками над ними? Т.е. чтобы никакой черной магии ORM типа Hibernate не было.

squirrel не ORM, а генератор запросов. две вещи я из него использую: 1. генератор IN clause по набору параметров неизвестного заранее количества 2. возможность генерить запросы и для постгреса, и для мускула. формат плейсхоллдера разный же про монгу не скажу ничего - я ей не пользуюсь написать сложное на чистом постгресе не сложнее, чем в любом другом языке. но придется или руками, или кодогенератором лепить список параметров для чтения из ответа в переменные.

Спасибо! Попробую на вашем стеке сделать этот тестовый веб форум.

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

Очередной ответ в стиле "вы просто все тупенькие". :) Мол, всё круто, именовать в одно слово или сокращение можно что угодно. Вот только на практике, проекты (особенно большие) как раз забивают на рекомендации и делают названия в том же snake_case, потому что некоторые вещи ну просто _неадекватно_ называть сокращенно или в одно слово. И, самое главное, для чего сокращать там, где это сказывается на читабельности? Чтобы быть не как все? Сэкономить несколько символов при печати? Слишком сложно читать? Чтобы было по-гошному минималистичное и "крутое" имя? То, что одно слово или аббревиатура/сокращение - далеко не всегда лучший вариант, по-моему, очевидно хотя бы по опыту других языков.

БТВ, в docker вынуждены писать местами два полных слова слитно, в нижнем регистре. То же самое в kubernetes. В influxdb забивают и разрезают слова подчеркиванием, чтобы совсем уж дико не смотрелось, в итоге там есть пакеты в snake_case, да (все тупенькие, видимо). За примерами далеко ходить вообще не нужно.

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

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

Вот скажите, docker, kubernetes, influx - тупые бездельники?

Почему они не могут уложиться в name convention?

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

Name convention тогда плохой? :)

Инфлюкс плохой пример, они говнари ещё те

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

Очередной ответ в стиле "вы просто все тупенькие". :) Мол, всё круто, именовать в одно слово или сокращение можно что угодно. Вот только на практике, проекты (особенно большие) как раз забивают на рекомендации и делают названия в том же snake_case, потому что некоторые вещи ну просто _неадекватно_ называть сокращенно или в одно слово. И, самое главное, для чего сокращать там, где это сказывается на читабельности? Чтобы быть не как все? Сэкономить несколько символов при печати? Слишком сложно читать? Чтобы было по-гошному минималистичное и "крутое" имя? То, что одно слово или аббревиатура/сокращение - далеко не всегда лучший вариант, по-моему, очевидно хотя бы по опыту других языков.

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

Это вполне соотносится с рекомендациями

как бы ты что не назвал, всегда есть минимум 5% недовольных (а среди программистов 95%), поэтому, забей

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

ты наверное можешь спросить Пайка, может он даже ответит

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

https://github.com/google/gvisor/tree/master/pkg/atomicbitops https://github.com/kubernetes/kubernetes/tree/master/pkg/securitycontext

https://github.com/docker/docker-ce/tree/master/components/engine/restartmanager

не во флуд ли? это все сторонние проекты, а в самом го как с этим?

О, тёзка @altai256

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

эти все вопросы это не строгие правила, а рекомендации. такие же, как например - покрытие 100% кода тестами хорошо, остальное говнокод. реальных проектов со 100% покрытием практически нет, однако нельзя сказать "мы стремимся к 90%, больше ненужно". или например я считаю любую функцию длиннее 10 строк говнокодом, но это не означает что я буду сидеть и распиливать каждую 11строчную, однако буду держать в голове, что если у меня есть функция в 20 - надо бы зарефакторить, оставить тудушку хотя бы.

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

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

ERROR: S client not available

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

42

Вечный вопрос о именовании переменных в программировании

Это не сильно важно. Важно чтобы оно было читаемо. Ну назови ParamID или как-то так. чтобы было понятно происхождение

и все

ясно, я думал может есть какая-то рекомендация на такой кейс. спасибо.

Ну следуй общему гайдлайну форматирования го и именования. Почитай в блоге го. В остальном просто делай явно но не сильно длинно и все будет хорошо

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

rawId, dirtyId

rawId, dirtyId

аналогично

Это не сильно важно. Важно чтобы оно было читаемо. Ну назови ParamID или как-то так. чтобы было понятно происхождение

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

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

вы такой капризный, надоело читать — не читайте.

чат про go, обсуждают naming conventions в go, т.ч. все по теме.

это не очень гошный нейминг конвеншн, а вообще общепрограммистский

про такое обычно пишут во всяких хороших общепрограммистских книгах ?

И пишут там «следует называть переменные хорошо»

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

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

ребятки, а как вы именуете переменные, которые нужно конвертнуть в другой тип? Допустим, мне приходит в URL запросе ID - это строка. А мне нужно число. Я делаю переменную idStr, и потом уже из неё получаю число, которое назову id.

не вижу проблемы. Главное потом понять что там.

@onokonem А можно подробное, что бы вы использовали для написания этого классического форума? Пусть это будет PostgreSQL, три таблицы: пользователи, посты и комменты. Из дополнительных требований: - должны писаться логи в файлы, т.е. если какая-то была ошибка, она должна быть записана в файл - должна сессия пользователя сохраняться при перезапуске приложения. Например я у себя в ноде для этого использую редис, а что использовали бы вы? - после перезапуска браузера пользователь должен остаться залогиненым, т.е. храним что-то в куке Использовали ли вы что-то кроме стандартной библиотеки?

Ну iris (щитай замена экспресса). Сессии в redis. Если сессий много (сотни тысяч, миллионы) - то JWT Генерировать шаблоны любым шаблонизиатором (но я бы сделал go+react - можно стильно быстро молодёжно, быстрый форум наше всё). Стандартная библиотека - не решение всех проблем. Если она существует - не означает, что запрещается использовать чтото ещё. Алсо, начинать архитектуру надо не постов и комментов, а с ACL и уведомлений, это самая нагрузосоздающая часть - глядишь, и база поменялась, и от постгре отошли. Следующий момент - спамеры. Если думаете, что от спамеров можно отмахнуться, то нет, проект может умереть. Вот пример форума на Go - https://github.com/kjk/fofou - автор сдался перед спамерами. Вот пример второго форума: https://github.com/go-tango/wego НИчем подход от ноды не отличается ни-чем. К ноде гораздо ближе чем к PHP.

И очень важный момент - на go можно писать форум, но сложно движок форума

скажите пока-пока плагинам, как в phpbb, wordpress и так далее - go это компилятор

.so есть, но для линукса

Идеально - познать счастье в связке REST+React

и REST делать на swagger

ну почему, а сделать модуль как микросервис? геморнее в подключении но сама функциональность плагинов остаётся?

только оно ни хера не rest будет

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

rest - это утопия

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

rest - это утопия

rest - это для crud

если у нас не crud - у нас не будет rest, а будет rpc