Alexandr
мне просто интересно, это как то реализуемо или только специализированные хранилища юзать
Vasily
/dev/shm
но вы скорее всего 10 раз выстрелите себе в голову
лучше редис
Vasily
или любые другие решения
Alexandr
понял, спасибо
3030
кому-нибудь удалось подружить gogland и дебаг внутри докер контейнера?
Anton
Плюсую, кстати
Alexander
Привет)
Alexander
ты на go пересел ?
Alexander
тут все пересели на go )
Alexander
я смотрю заразное поветрие
Alexander
а основной язык не джава случаем ?
Alexander
# что ли ?
Anton
Там тоже был, но ещё злее
dev_sheep
Пхп?
dev_sheep
😱
Anonymous
Из моего любимого Python?
Alexander
го, кстати, огонь для пет-проектов. если основное занятие кровавый тырпырпрайз. я пробовал на питоне - но как-то не то
Anton
Похапэ и питоша, да
Anonymous
Питоша не злой, питоша хороший
Alexander
неудобный он, если привык к статической типизации.
dev_sheep
Но пехепе
Alexander
просто российский рынок насыщен спросом на php
Maxim
што
Alexander
поэтому на нем и пишут многие
invariance
давайте не будем устраивать срач про пхп в чате про голанг
Alexander
оО чем питон ? если только в написании кода
Alexander
я бы сказал что у го все шансы подвинуть джаву и шарпы в тырпрайзе, если бы был такой же набор библиотек на все случаи жизни, заточенных под бизнес.
Ruslans
он простой и лаконичный
ну для этого нужно пепы прочитать, код нормальных людей посмотреть, это уже сложно юным опенсорсерам
invariance
сейчас бы называть компилируемый строготипизируемый язык медленным в отношении интерпретируемого с динамотипизацией...
Anonymous
⏺ Vаdim
он простой и лаконичный
+++++. Хороший скриптовый язык с С подобным синтаксисом. За php в посл время авктивно взялись. Стал строже. Быстрее. По тестам php 7ка стала уделывать некоторые тесты на питоне. Мне го конечно нравится больше. Но пых хороший тож
invariance
Alexander
я джавист, есичо
Fedor
да ну. хайп есть, люди есть. преимущества есть. я не говорю заменить. подвинуь
слишком сложно писать и маленький функционал
Fedor
го мне очень напоминает C, на нем писать что-то масштабное и расширяемое слишком геморно
Oleg
invariance
Roman
John
го мне очень напоминает C, на нем писать что-то масштабное и расширяемое слишком геморно
Ну для монолитов он явно не предназначен
Fedor
но вот в бизнесе как-то не очень его используют
Anton
го мне очень напоминает C, на нем писать что-то масштабное и расширяемое слишком геморно
Так гошечка же не про масштабность, тут как раз надо всё максимально атомарно делать
invariance
ну так и на C ядро linux написано и продолжает писаться
что в принципе означает, что тут как всегда работает правило на вкус и цвет языка нет
Alexander
пока не будет аналогов bpm движков, фрейворков типа apache camel/spring integration и прочего, на го писать бизнес-приложения не будут. всякие микросервисы - да. но не тырпрайз приложения
invariance
пока не будет аналогов bpm движков, фрейворков типа apache camel/spring integration и прочего, на го писать бизнес-приложения не будут. всякие микросервисы - да. но не тырпрайз приложения
Энтерпрайз так то на микросервисной архитектуре можно строить.
Fedor
го хорошо для микросервисов, у него отличный инструментарий для параллельного программирования, но целиковое приложение на нем городить слишком дорого
Fedor
время программиста сейчас сильно дороже времени машины
invariance
Fedor
я вот Го взял в дополнение к ruby, как раз узкие места в параллельные микросервисы выносить
Alexander
spring - я вообще ни видел ни разу смысла использовать таких монстров
invariance
С чего вообще тут взялось мнение, что монолитные приложухе это какой то общепринятый стандарт?
invariance
для энтерпрайза в т.ч.
Fedor
при чем тут монолит?
Alexander
Энтерпрайз так то на микросервисной архитектуре можно строить.
можно. но все равно должен быть флоу, который эти самые микросервисы дергает. ты этот флоу или сам кодишь. или рисуеешь в красивом bpmn-моделерре. и твой красивый и понятный сценарий потом исполняется в bpm-движке.
invariance
В энтерпрайзе микросервисных архитектур больше, чем монолитных, ежели что
John
С чего вообще тут взялось мнение, что монолитные приложухе это какой то общепринятый стандарт?
Я бы сказал это скорее привычка
invariance
(ладно, сервис ориентированных, так и быть)
Fedor
я про удобство разработки и простоту написания когда
Fedor
а монолит - не монолит - не важно
Anton
время программиста сейчас сильно дороже времени машины
В этом и вся суть. Монолиты очень дорого поддерживать, а микросервисы относительно легко. И го, как бы там не было, позволяет писать код, который можно и через год понять (В этом лично для меня его главный плюс)
Anton
Как показывает опыт - самая затратная часть проекта это поддержка и развитие, а не написание первой версии
Fedor
вот тут не соглашусь, монолит легко поднять и запустить, если он написан грамотно, а десяток микросервисов поднять и заставить общаться между собой на новой железке гораздо сложнее
invariance
> Монолиты очень дорого поддерживать, а микросервисы относительно легко.
В реальности все наоборот)
Alexander
spring - я вообще ни видел ни разу смысла использовать таких монстров
один раз попались умники для того что бы реализовать мини сервис с несколькими входными точками (3 вызова всего) вхреначили в проект jBoss - а проект был под систему пропусков, тупо считать ID карты и найти в базе
Fedor
тут даже докер не всегда спасает, разве что все версии всего зафризить, что бы чего-нибудь не дай бог не обновилось
invariance
Микросервисную архитектуру намного, намного сложнее поддерживать.
Alexander
spring - я вообще ни видел ни разу смысла использовать таких монстров
значит задач не было. нам под какие-то задачи spring batch офигенно зашел
invariance
но легко масштабировать, это факт