Да, сделать на коленке, допилить проброс исключений, форкнуть кокаиновый фреймворк и сделать так чтобы он со всем этим работал. Очень тривиальная задача.
Имхо такая обработка ошибок как там неудобна и лучше бы они сделали исключения, в этом соглашусь. Я вообще не думаю что Go какой-то очень крутой язык, по моему достаточно средний даже. Совсем простые вещи там пишутся легко, но если требуется что-то более сложное, то языка на это явно не хватает. Для наших задач Go хорош и мы его любим за это, простые вещи можно разрабатывать и тестировать быстро.
Думаю Google сыграл большую роль в популяризации языка, без него ему было бы намного хуже.
Мое личное мнение, что json в коммуникациях machine-to-machine с фиксированным протоколом это вообще вещь достаточно вредная. Если данные действительно динамические и посылается совсем что угодно, то json — хорошее решение. Но там где протокол постоянен лучше использовать нечто вроде protobuf. Json, msgpack это некая структура данных где они могут быть а могут и не быть и это нужно постоянно проверять, в то время как в protobuf и подобных это реализовано на уровне протокола и его пользователь уже имеет некоторые гарантии того, что данные представляют из себя то что он ожидает.
Go же в тех случаях где с json приходится работать на уровне протокола старается хоть как то жестко связать его в структуру, что по моему хорошо. Кроме того никто не запрещает работать в Go с json также как в javascript или python, можно также не анмаршалить его в структуру, а просто обращаться по какому-то пути к элементам json.
В фреймворке Go Кокаина не все идеально сейчас, мы планировали серьезный рефакторинг в ближайшее время. Он работает хорошо и надежно, но код и интерфейсы стоило бы причесать, плюс добавить тестов. Но посмотреть, конечно, можно :) github.com/cocaine/cocaine-framework-go
Javascript с v8 работает быстро, но как то не прижился именно у нас. Меня когда я еще делал скрипты для веб страниц сильно смущало обилие коллбэков. Насколько я знаю в ноде уже есть генераторы или нечто подобное чтобы писать аля синхронно, но как то не довелось все это попробовать.
Ну и да динамическая типизация для подобного проекта думаю будет не нужна, придется писать больше тестов.
Этот метод внутри себя обращается к сервису Кокаина через go-framework. А обращения к нему как раз реализованы через channels. То есть управление останавливается там, где оно доходит до чтение из канала фреймворка и, как только он записывает туда ответ, исполнение продолжается.
Вообще именно в нашем отделе java традиционно не использовали и этот вопрос как-то особенно не рассматривался. :)
Java действительно кажется не медленнее чем Go по тестам и по моим собственным воспоминаниям о работе с ней, имеет обширную стандартную библиотеку и много сторонних либ. Из недостатков по сравнению с Go можно отметить отсутствие lightweight threads из коробки и очень большой memory footprint одного запущенного инстанса, что для облачного приложения может быть критично. Еще один правда незначительный недостаток, то что нужно тащить за собой java runtime, на выходе у Go же получается статически слинкованный бинарник зависящий только от libc.
Думаю Google сыграл большую роль в популяризации языка, без него ему было бы намного хуже.
Go же в тех случаях где с json приходится работать на уровне протокола старается хоть как то жестко связать его в структуру, что по моему хорошо. Кроме того никто не запрещает работать в Go с json также как в javascript или python, можно также не анмаршалить его в структуру, а просто обращаться по какому-то пути к элементам json.
Ну и да динамическая типизация для подобного проекта думаю будет не нужна, придется писать больше тестов.
Java действительно кажется не медленнее чем Go по тестам и по моим собственным воспоминаниям о работе с ней, имеет обширную стандартную библиотеку и много сторонних либ. Из недостатков по сравнению с Go можно отметить отсутствие lightweight threads из коробки и очень большой memory footprint одного запущенного инстанса, что для облачного приложения может быть критично. Еще один правда незначительный недостаток, то что нужно тащить за собой java runtime, на выходе у Go же получается статически слинкованный бинарник зависящий только от libc.