мы можем куда угодно стремиться

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

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

C++ перекомпиляция header'ов дорогая и отсутствие инкрементальной компиляции.. в Go с этим проблем гораздо меньше

generate + go практически всегда будет гораздо быстрее чем компиляция C++. Компиляторы C++ были основаны на дизайне, который учитывал ограничения железа 80-90 годов (в основном по памяти). А сейчас у нас памяти в ноуте как тогда в мега-дата-центре

или нет

надо мерить)

Здесь есть бекенд джава разработчики?

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

мне кажется, тебе пора в бан за оффтоп

Ахах

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

рано или поздно вы будете собирать проекты со скоростью С++, если даже в других языках и проектах с множеством кода, это рано или поздно становиться реальностью, проекты разрастаются. Кодо-генерация - это хорошо, когда сделано грамотно и применена "к месту". Ран-тайм "аннотации" - тоже хорошо и удобно, когда "к месту". Чтобы быстро собирать большие проекты, есть решения, в java - это билд кэши, успешно применяются в некоторых билд-тулзах (gradle). Без них - попа, скалисты "страдают", потому что там SBT тулза по умолчанию без них, а с ними сборка может "ускорятся" в 4-5 раз. Рано или поздно Go тожк к этому придет, когда код-база многократно вырастет.

рано или поздно вы будете собирать проекты со скоростью С++, если даже в других языках и проектах с множеством кода, это рано или поздно становиться реальностью, проекты разрастаются. Кодо-генерация - это хорошо, когда сделано грамотно и применена "к месту". Ран-тайм "аннотации" - тоже хорошо и удобно, когда "к месту". Чтобы быстро собирать большие проекты, есть решения, в java - это билд кэши, успешно применяются в некоторых билд-тулзах (gradle). Без них - попа, скалисты "страдают", потому что там SBT тулза по умолчанию без них, а с ними сборка может "ускорятся" в 4-5 раз. Рано или поздно Go тожк к этому придет, когда код-база многократно вырастет.

не будете. Не надо сравнивать компилятор Go и компилятор C++ Компиляторы C++ были основаны на дизайне, который учитывал ограничения железа 80-90 годов (в основном по памяти). А сейчас у нас памяти в ноуте как тогда в мега-дата-центре

?

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

рано или поздно вы будете собирать проекты со скоростью С++, если даже в других языках и проектах с множеством кода, это рано или поздно становиться реальностью, проекты разрастаются. Кодо-генерация - это хорошо, когда сделано грамотно и применена "к месту". Ран-тайм "аннотации" - тоже хорошо и удобно, когда "к месту". Чтобы быстро собирать большие проекты, есть решения, в java - это билд кэши, успешно применяются в некоторых билд-тулзах (gradle). Без них - попа, скалисты "страдают", потому что там SBT тулза по умолчанию без них, а с ними сборка может "ускорятся" в 4-5 раз. Рано или поздно Go тожк к этому придет, когда код-база многократно вырастет.

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

не будете. Не надо сравнивать компилятор Go и компилятор C++ Компиляторы C++ были основаны на дизайне, который учитывал ограничения железа 80-90 годов (в основном по памяти). А сейчас у нас памяти в ноуте как тогда в мега-дата-центре

Не согласен. Памяти тогда было - столько сколько было, оно соответствовало тем "маленьким" программам, которые были востребованы. Сейчас памяти больше, но стало использоваться "выведение типов" повсеместно в ЯП, контроль типов разными видами, контроль видимости и времени жизни. Не тешьте себя иллюзиями (как я думаю), что вот сейчас "много памяти", а это автоматически значит, что Go компилятор "построен по другим принципам" создания компиляторов. Эти принципы "принципиально не изменились" (имхо). И если сейчас кода относительно не много, то потом будет много и билд-тул, который будет собирать многомодульный проект из 10-ка частей - это станет реальностью, как у других ЯП.

Не согласен. Памяти тогда было - столько сколько было, оно соответствовало тем "маленьким" программам, которые были востребованы. Сейчас памяти больше, но стало использоваться "выведение типов" повсеместно в ЯП, контроль типов разными видами, контроль видимости и времени жизни. Не тешьте себя иллюзиями (как я думаю), что вот сейчас "много памяти", а это автоматически значит, что Go компилятор "построен по другим принципам" создания компиляторов. Эти принципы "принципиально не изменились" (имхо). И если сейчас кода относительно не много, то потом будет много и билд-тул, который будет собирать многомодульный проект из 10-ка частей - это станет реальностью, как у других ЯП.

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

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

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

Зачем мне его слушать? Для меня "легаси проект" в жизни, где порядка 30-40 модулей, каждый из которых по 2 или 3 "слоя" (веб/веб-сервисы, бизнес логика, БД компоненты) - это реалии жизни. Что Страусруп мне может рассказат про "хидеры"? Так вот в таком легаси-проекте - без многомодульного билд-тула "бедя", поэтому их и придумали. Прост в Го этого пока нет

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

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

можно учитывать не только ошибки, но и то хорошее, что уже есть. в других ЯП есть долгий путь, который они проходили ... например : сборка ручками, позже ANT, потом Maven, Gradle. Так что многомодульный билд-тул, который будет - генерить, копировать файлы обновляя ресурсы, компилить это все, собирать в более крупные модули (учитывая зависимости между модулями), деплоить на сервер, архивировать и т.д... - это реальность в других ЯП, просто "молодым и горячим" это не ведомо, до поры и времени.

можно учитывать не только ошибки, но и то хорошее, что уже есть. в других ЯП есть долгий путь, который они проходили ... например : сборка ручками, позже ANT, потом Maven, Gradle. Так что многомодульный билд-тул, который будет - генерить, копировать файлы обновляя ресурсы, компилить это все, собирать в более крупные модули (учитывая зависимости между модулями), деплоить на сервер, архивировать и т.д... - это реальность в других ЯП, просто "молодым и горячим" это не ведомо, до поры и времени.

не "можно" а "нужно" ?

не "можно" а "нужно" ?

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

в любом случае сравнивать C++ компиляторы с компилём Go - не лучшая идея. Они реализуют спецификации разных эпох, в Go вредный легаси не тянут как в плюсах в виде, например, header файлов, Go принципиально должен компилиться быстрее (зависит от уровня отладки)

проблема плюсов не в хедерах, а в темплейтах, и - в меньшей степени - в препроцессоре

а хедера на современном железе проблемы не представляют

так что дело не в легаси

проблема плюсов не в хедерах, а в темплейтах, и - в меньшей степени - в препроцессоре

я бы сказал "не только в header'ах"

в любом случае сравнивать C++ компиляторы с компилём Go - не лучшая идея. Они реализуют спецификации разных эпох, в Go вредный легаси не тянут как в плюсах в виде, например, header файлов, Go принципиально должен компилиться быстрее (зависит от уровня отладки)

А мы говорим про скорость и "сложность" сборки, которая не смотря "быстроту компилятора" будет "падать" со временем и с увеличение модульности. И говорить про нечто "волшебное" в компиляторе Го - это лукавство.

проблема плюсов не в хедерах, а в темплейтах, и - в меньшей степени - в препроцессоре

а что с темлейтами не так?

а хедера на современном железе проблемы не представляют

в C++ можно написать header-only библиотеку, которая будет компилировать, если я неошибаюсь, каждый раз, снова и снова (не уверен, умеют ли современные компили сиё дело кешировать) в Go это в принципе невозможно и ненужно

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

это микросервисы. не всегда годится

я вот тут телеграм десктоп собирал. больше часа повторная компиляция после правки одной строки

это модульность, годится всегда

я вот тут телеграм десктоп собирал. больше часа повторная компиляция после правки одной строки

с++

да.

а что с темлейтами не так?

они очень дорогие

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

» думаешь о небольших сервисах, то писать можно хоть на ...... Ибо сложность единицы небольшая, тестируешь ее снаружи..... Обратная сторона - увеличивается кол-во связей, а потом растет их "сложность и взаимодействие". Сам микросервис не работает "в безвоздушном пространстве", а взаимодейтсвует с остальными компонентами... и может даже "асинхронно". Чем больше связей, тем сложнее взаимодействие - тем больше гемороя. Так что "не стоит обольщаться"

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

» думаешь о небольших сервисах, то писать можно хоть на ...... Ибо сложность единицы небольшая, тестируешь ее снаружи..... Обратная сторона - увеличивается кол-во связей, а потом растет их "сложность и взаимодействие". Сам микросервис не работает "в безвоздушном пространстве", а взаимодейтсвует с остальными компонентами... и может даже "асинхронно". Чем больше связей, тем сложнее взаимодействие - тем больше гемороя. Так что "не стоит обольщаться"

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

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

Зря вы так думаете. :)

это была ирония

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

что вы называете барьерами, в которые программеры не умеют?

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

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

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

А так да, разделение труда админов и программистов размывается обратно. Надо уметь и код и эксплуатацию. Девопс же

И это хорошо. Не люблю слишком узкую специализацию. Отупляет

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

все ноют

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

докер для пидоров. только bare metal

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

Не обязательно API барьеры, у вас же может быт так, что "сохранение/удалени записи в/из базу" (одного микро-сервиса), вызывает автоматическую генерацию сообщения к другим "зависимым подсистемам" (мик-сер.), которые ловят его через "брокер-очередь" и обрабатывают своим образом, а может еще и порождают "свои команды/события". Тут барьеры API никак не помогут. А ведь такое работает.

Все равно накладные расходы будут

Зато может быть проще масштабировать

Как минимум разработку

А может и эксплуатацию

Пожскажите, пожалуйста, реализацию блокирующего Read() из сетевого соединения. Данные прилетают с разным интервалом времени и разного размера. Как этот паттерн лучше всего отработать?

Ыыыы офигенный ник и ава. За оффтоп ИЗВЕНИ

раньше хорошим тоном было написать приложение, так что бы модули между собой были слабо связанны идея ООП и все полетело в ООП, со страхом и ненавистью с сотней лишних наследований сейчас это перенесли на другой уровень, было бы желание, а где говнокодить пофиг. там где можно было сделать 4 микросервис и 2 не микро но сервиса, получается 3к микросервисов и как они связанны между собой, знает только все тот же индус, который и раньше из нирваны не выходил ну и да, точки отказа стали меняться

Пожскажите, пожалуйста, реализацию блокирующего Read() из сетевого соединения. Данные прилетают с разным интервалом времени и разного размера. Как этот паттерн лучше всего отработать?

а чем неблокирующий то неподходит?

cpu burn'ом

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

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

А в чате по джяве спросить не пробовали? xD

читая в infinite loop 0 байт из потока мы выжигаем проц, а хочется, чтобы чтение происходило по факту наличия данных в потоке

ERROR: S client not available

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

а вы делаете/используете что-то типа: - Saga pattern - Transaction log tailing ? просто интерес...

Пожскажите, пожалуйста, реализацию блокирующего Read() из сетевого соединения. Данные прилетают с разным интервалом времени и разного размера. Как этот паттерн лучше всего отработать?

а в go разве есть неблокирующий? есть блокирующий с таймаутом

а вы делаете/используете что-то типа: - Saga pattern - Transaction log tailing ? просто интерес...

хм... наверное не скажу сейчас сам. Там умный тимлид проектирует. Я пока только вникаю

Не обязательно API барьеры, у вас же может быт так, что "сохранение/удалени записи в/из базу" (одного микро-сервиса), вызывает автоматическую генерацию сообщения к другим "зависимым подсистемам" (мик-сер.), которые ловят его через "брокер-очередь" и обрабатывают своим образом, а может еще и порождают "свои команды/события". Тут барьеры API никак не помогут. А ведь такое работает.

это в пользу какого тезиса аргумент?

а в go разве есть неблокирующий? есть блокирующий с таймаутом

мм.. не так выразился, видимо. Блокирующий не всмысле неасинхронный, а всмысле ожидания появления данных в потоке, чтобы не выжигался проц вычитывая пустой буфер. Иными словами, чтобы горутина замирала на строчке msg := conn.BlockRead() если внутри потока ничего нет ( n_read == 0 )

а в go разве есть неблокирующий? есть блокирующий с таймаутом

ээээ. он же реализован через неблокирующие системные вызовы.

он реализован через event loop

что-то мне кажется вы не в ту степь уехали

мм.. не так выразился, видимо. Блокирующий не всмысле неасинхронный, а всмысле ожидания появления данных в потоке, чтобы не выжигался проц вычитывая пустой буфер. Иными словами, чтобы горутина замирала на строчке msg := conn.BlockRead() если внутри потока ничего нет ( n_read == 0 )

вы какую бизнес задачу решаете?

чтение эвентов из вебсокета

мм.. не так выразился, видимо. Блокирующий не всмысле неасинхронный, а всмысле ожидания появления данных в потоке, чтобы не выжигался проц вычитывая пустой буфер. Иными словами, чтобы горутина замирала на строчке msg := conn.BlockRead() если внутри потока ничего нет ( n_read == 0 )

так она замирает ровно на этом месте, пока хотя бы байт не появится

увы нет.

что - нет?

где у вас - нет?

увы нет.

а как узнать что там 0 байт, не попытавшись вычитать?

это в пользу какого тезиса аргумент?

Просто замечание, что не всегда микры и связи на апи делают.

чтение эвентов из вебсокета

у вас не хватает производительности? зачем полезли "вниз"

что - нет?

он не "замирает"

он читает 0 байт из потока и идет дальше

кто - он,

можно же было взять какой либо - https://github.com/gorilla/websocket и оки

можно же было взять какой либо - https://github.com/gorilla/websocket и оки

у него религиозный вопрос

можно же было взять какой либо - https://github.com/gorilla/websocket и оки

Спасибо Кэп ) Только оно не умеет из unix domain читать

коллега, не отвлекайтесь

кто - он,

Conn.Read(), конечно. Мы же о нем говорим

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

хм... наверное не скажу сейчас сам. Там умный тимлид проектирует. Я пока только вникаю

Значит скорее всего нет, не пользуетесь.

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

+ хотя может скорее "интерфейсы" нежели "барьеры"?

Conn.Read(), конечно. Мы же о нем говорим

а Conn - это какой conn?

а Conn - это какой conn?

net.Conn

вот этот? https://golang.org/pkg/net/#Conn

Спасибо Кэп ) Только оно не умеет из unix domain читать

чочочо? O_o Где вебсокет и где unix domain. Вы его (вебсокет) по назначению используется для общения браузер<>бек?