значит задач не было. нам под какие-то задачи spring batch офигенно зашел

это все от лени

есть аналог на go ? apache camel ? есть что-то похожее ? jboss drools ? bpmn ?

а зачем в go аналоги всяких мультитулов ?

инструмент надо выбирать под задачу

именно. поэтому го пока не для энтерпрайза.

точнее не замена той же джаве

именно. поэтому го пока не для энтерпрайза.

))

С каких пор энтерпрайз вообще подразумевается в контексте одного языка какого то

в 2017 году

вы че, люди)

дело не в языке. дело в экосистеме

Именно

и вы продолжаете говорить, что го не для энтерпрайза, а вот джава другое дело

хотя их можно юзать в одной экосистеме и жить счастливо

дело не в языке. дело в экосистеме

я ж говорю это все от лени

и еще кучу инструментов и языков

у го маленькая ниша в традиционном тырпрайзе

у го маленькая ниша в традиционном тырпрайзе

Растет семимильными шагами относительно других

но шансы вклинится есть

так я и начал блин с того, что у го хорошие шансы вклиниться

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

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

вдруг прокатит

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

легкие микросервисы просто белиссимо

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

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

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

Йеп, вот что-то вроде такого

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

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

У меня так на прошлой работе монолит на рельсе с необходимыми сервисами сжирал под 10Г памяти. Я тогда просто поковырялся в конфигах elasticsearch и редиса, и мне вполне стало хватать 4Г на домашнем ноутбуке )

все зло от сервисов на яве ))))

Само собой, что при масштабировании тут возникает целая куча проблем: с дискавери, хелф чеками каждого сервиса и вот этим всем, но до этого момента всё прекрасно для развития и поддержки проектика :)

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

если все крутиться в докере, то относительно просто

У меня так на прошлой работе монолит на рельсе с необходимыми сервисами сжирал под 10Г памяти. Я тогда просто поковырялся в конфигах elasticsearch и редиса, и мне вполне стало хватать 4Г на домашнем ноутбуке )

elasticsearch - эластик сам по себе жрет много очень, только ему наверно и нужно около 4 Гб

а если ограничивать ресурсы на JVM то тупить начинает

в место эластика начал вот это использовать - https://github.com/blevesearch/bleve

elasticsearch - эластик сам по себе жрет много очень, только ему наверно и нужно около 4 Гб

он по умолчанию под себя резервирует 2Г, и потом еще отжирает по необходимости. Причем необходимость странная, я ограничил в 512 и не заметил разницы, то ли в swap все выкидывать начал, а в dev окружении нагрузка не такая, что бы в диск упираться, то ли ему реально столько памяти не надо, просто жадничает

ну если еще sphinx n-граммы допилят то можно на него смело пересаживаться

И все-таки где можно почитать best practice для go?

https://golang.org/doc/effective_go.html

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

вот что в effective_go, что в статьях из интернетов, для обработки ошибко создают структуру из строк, и метод, который для этой структуры возвращает общую строку с ошибкой

в туре же просят сделать type ErrNegativeSqrt float64, и написать для него метод такой, что: ErrNegativeSqrt(-2).Error() будет возвращать строку с ошибкой

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

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

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

func Error() string - требование интерфейса error

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

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

это понятно, вопрос почему они предлагают тип ошибки делать float64

https://go-tour-ru-ru.appspot.com/methods/20

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

Нет Функция, которая возвращает ошибку, должна заворачивать в этот тип отрицательные числа Сам метод никакой проверки делать не должен

он лишь выводит в текст отрицательное число

Может я и правда не так условие понимаю, но объявив для него метод func (e ErrNegativeSqrt) Error() string такой, что ErrNegativeSqrt(-2).Error() возвращает "cannot Sqrt negative number: -2"

как я понял, они хотят что бы этот метод возвращал текст ошибки, только если передано отрицательное число

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

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

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

https://play.golang.org/p/lBVhyT3zoQ

ну я по сути так и сделал

как я понял, они хотят что бы этот метод возвращал текст ошибки, только если передано отрицательное число

нетр, читай условие

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

это понятно, вопрос почему они предлагают тип ошибки делать float64

Ошибка должна хранить в себе информацию В данном случае она хранит в себе невалидный параметр функции

ок, тоесть проверки внутри они от меня и не ждут

хорошо, спасибо

это было бы бессмысленно

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

ок, тоесть проверки внутри они от меня и не ждут

https://play.golang.org/p/vumbvrxSCx

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

они просят проверку внутри Sqrt, а не внутри Error

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

а как жить, когда нужно шарить модельки данных между сервисами?

иии?

а как жить, когда нужно шарить модельки данных между сервисами?

завести еще один сервис, ессно

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

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

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

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

😂

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

да, god object, конечно.

получилось у меня заставить работать goland+docker+debug, но вот только как-то частично. Где-то брейкпоинты срабатывают, где-то нет. Не срабатывают когда в самом goland'е брейкопоинт с крестиком стоит: http://prntscr.com/heot3h В соседнем файле, крестика нет и бп работает: http://prntscr.com/heotfz

а как жить, когда нужно шарить модельки данных между сервисами?

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

Вечер добрый. Скажите, у кого-нибудь работает go get git.apache.org/thrift.git/lib/go/thrift? У меня бесконечно висит, видимо их git висит :( пробовал так же зеркало go get -u github.com/apache/thrift/tree/master/lib/go/thrift, но там странное: package github.com/apache/thrift/tree/master/lib/go/thrift: cannot find package "github.com/apache/thrift/tree/master/lib/go/thrift" in any of: /usr/local/Cellar/go/1.7.5/libexec/src/github.com/apache/thrift/tree/master/lib/go/thrift (from $GOROOT) $HOME/go/src/github.com/apache/thrift/tree/master/lib/go/thrift (from $GOPATH) И я как-то теряюсь что делать дальше.

go get -u github.com/apache/thrift

а, не , там всё равно подпапка

go get git.apache.org/thrift.git/lib/go/thrift/...