Спасибо всем за ссылки и мнения. Будем курить полученную инфу. На данный момент все, что накурилось - взять 2-3 микросервиса из нашего «зверинца» (а у нас их немало) и каждому члену команды попробовать реализовать и на Go и на С++. А там уже подводить сравнительные итоги.

Много денег у компании?

Ну попробуйте тогда на хорошем REST фреймверке vibe.d http://vibed.org

Там биндинги к си и си++ драйверам бд легко пишутся, при нужде.

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

Если есть возможность использовать хотя бы C++11, то рабочий и производительный код получается быстро. А конкурентность реализуется сторонними библиотеками.

PS: сколько лет ты собираешься потратить на ловлю buffer overflows и thread deadlocks в C++ коде?

buffer overflows в большей мере присущи plain old C, а не C++.

При использовании более высокоуровневых инструментов, чем std::thread, со thread deadlocks в C++ придется сталкиваться не чаще, чем в Go с его гороутинами и каналами. Таковых инструментов для C++ не так уж и мало (достаточно вспомнить TBB, HPX, Just::Thread Pro, CAF, SObjectizer, Boost.Fiber, да и хотя бы POCO).

Так что, если сравнивать Go с plain old C, то да, тут все однозначно. Если же Go с С++11/14, то не так просто.

можешь сам посмотерть

http://sourceforge.net/p/card-raytracer-bench/code/HEAD/tree/trunk/ лол нода рвет всё, что не компилицо и не намного тормознее гоу...

sourceforge.net

Откажусь, пожалуй.

да, лучшее место, там еще и svn

я помогу тебе:

drsm@s400:~/work/card-raytracer-bench-code/trunk$ time go run go/card-raytracer.go > /dev/null

real    0m51.592s
user    0m51.698s
sys     0m0.198s
drsm@s400:~/work/card-raytracer-bench-code/trunk$ time node js/card-raytracer.js > /dev/null

real    1m47.684s
user    1m47.294s
sys     0m0.260s
drsm@s400:~/work/card-raytracer-bench-code/trunk$ head -n 5 /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz
drsm@s400:~/work/card-raytracer-bench-code/trunk$

версии не указаны

окружение не указано

какая-то невнятная синтетическая параша

Ок.

Много денег у компании?

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

И что-то получается, что Go имеет абсолютно те же минусы что и C++, в принципе как и любой другой компилируемый язык. Фичи Go (channels и goroutine) можно и в Cpp состряпать если нужно. Ну а если коснуться кол-ва библиотек и средств разработки - получается для микросервисной архитектуры С++ заруливает Go в несколько оборотов.

Какой то bullshit bingo, но если вы пришли к таким выводам, то берите кресты и радуйтесь (ахах).

похоже у ТС с напарником оооочень много свободного времени, раз на крестах рест ваять собираются ))))).

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

Если задача, как ты говоришь, состоит в перекладывании говна из базочки в JSON-чик, то я бы взял жабку, в ней в современном JAX-RS или Spring-е любой REST запиливается декларативно и не включая моска вообще. Современные серваки под нее почти поголовно асинхронные, читай на epoll-ах, под онтопиком, так что почему бы и нет. Хочется хардкора и адовой произодительности - есть netty. Вместо жабки я бы смотрел только в сторону плюсов.

Веб на современных крестах вполне человечен.

http://obsuditor.ru/chat

Это запилено на моей самодельной крестовой либе.

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

В Go тебя тоже никто не страхует от разыменования нулевого указателя и от порчи контейнеров из разных потоков. Дейстивтельно, goroutine и channels можно налабать на C++, но никто не принесёт в Go всей плюсовой мощи. Ну и Go конечно спасает от лажаний с манипуяциями с адресами памяти, но в плюсах тебя никто не держит от того, чтобы писать не видя никаких адресов вообще. Большие проекты на Go - это боль в сравнении с плюсами: часто хочется написать шаблонный алгоритм, а приходится плодить сущности. Может я просто плохо знаю Go-интерфейсы... Но современные кресты лаконичны и просты, но надо больше мозга. А сколько у вас мозга вам никто не скажет, кроме вас.

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

Давать разным людям писать на Go и C++ и сравнивать итоги — эксперимент странный: каждый чел склонен обрастать предпочтениями, мозг у всех думает разными способами: одна и та же сущность/идиома разным кажется говном/рулезом.

Ещё есть REST, который я не пробовал, но говорят что это «правильные плюсы». Не пробовал, не знаю.

Но я бы на месте автора всё равно на Go попробовал бы наваять, это полезный опыт и сервис он сделает - может и плюсов не захочется, кто знает автора.

«разгребать потуги отлить в граните» — на похапэ можно так отлить, что никто не разгребёт. Снимает фотограф!

«Работает - не трогай» — не путь настоящего учёного. А кто против науки, тот становится мракобесом и деградирует.

Люди вроде тебя, не знакомые с Си++, с места в карьер начнут путать buffer overflow с выходом за границы массива

Писал на плюсах лет десять, и тут, почувствовав себя говном, полез гуглить:

In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory locations.

И чем оно отличается от выхода за границы массива (какого массива)?

заниматься вашим обучением мне лень

Ну позязя!

Ещё есть REST, который я не пробовал, но говорят что это «правильные плюсы».

А по-русски это как будет?

Писал на плюсах лет десять

Аналогичная фигня. Потом сделал перерыв на 15 лет, возвращаюсь... а плюсы-то уже не те!!1

Ну позязя!

Нед.

А по-русски это как будет?

Скорее всего, https://casablanca.codeplex.com/

Имелся ввиду RUST.

Видимо, речь о языке Rust, тогда все становится на свои места.

А вот по поводу:

Это запилено на моей самодельной крестовой либе.

Эту свою любу вы запилили с какой целью? Просто proof-of-concept или для чего-то другого?

открыл исходники, увидел

bool json::details::g_keep_json_object_unsorted = false;
void json::keep_object_element_order(bool keep_order)
{
    json::details::g_keep_json_object_unsorted = keep_order;
}

закрыл исходники

Писал на плюсах лет десять

Аналогичная фигня. Потом сделал перерыв на 15 лет, возвращаюсь... а плюсы-то уже не те!!1

Выход (а точнее зарождение) крестов в 83-85м. В 90х выходит первый типа стандарт. Но ты уже преступил к плотной работе с крестами. В 90х. В совке. Думаю ты имеешь хорошие корни в каком-то универе, который смог тебе подогнать и доки и ЭВМ и задачи под это всё. Тебе лет 30-35, не меньше. Пишешь до нулевых. Бросил, наверно, потому что не понравились ++98, да и кризис среднего возраста, 40-45. 15ть лет скитаний. Вот тебе 60, и ты понял что время вернуться к крестам. А кресты уже не те.

И это всё, если учитывать что вернулся ты в прошлом году.

Тёплая жизненная история.

Теперь юзни фишку библии, типа я хоть и говорил прямо, но это всё фигурально. Да и вообще ты кто такой? Ну или типа круто промолчать, или придумать невразумительную крутость. Порадуй, пожалуйста :)

Вот тебе 60, и ты понял что время вернуться к крестам.

Феерично. Просто феерично.

Цели не было, так сложилось... Я делал плюсовый http://fintank.ru/ (там R-tree дерево хранит много кубиков и ищет столкновения) и мне не понравилась какая-то падающая в кору сишная websocket-либа, с которой я тогда работал, решил покурить https://tools.ietf.org/html/rfc6455 и запилить свою вебсокет-либу. От этой либы отросла небольшая реализация HTTP-протокола. Потом стало интересно запилить свой минимальный HTTP с минимумом копирований памяти (как в nginx), с пулом ресурсов и без зависимости от любых boost-ов. Получилась лично мне удобный сервер, куда в шаблон передаётся тип, умеющий следить за дескрипторами (на epoll например) и больше зависимостей от платформы нет. Для FreeBSD достаточно подменить epoll-класс на kqueue-класс в шаблоне.

Выход (а точнее зарождение) крестов в 83-85м. В 90х выходит первый типа стандарт.

Zortech C++ - 1988, Turbo C++ - 1990, оба для попсового DOS.

Тёплая жизненная история.

За исключением того, что с годами ты напутал (с причинами бросания - тоже).

Да и вообще ты кто такой?

Вот.

Будь конструктивным.

Ок, если брать статический массив, там будет выход за границы памяти массива или даже стека. Выход за границы любого динамического массива – тот же buffer overflow. Учитывая, что статическими массивами пользуются довольно редко, не вижу причины как-то особенно выеживаться по поводу различия index out of range и buffer overflow.

Да и вообще ты кто такой?

Вот.

Та не. Это ты у меня должен был спросить :)

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

Большая часть buffer overflow в Си - это результат операций со строками. В Си++ они делаются через класс string и гораздо более безопасны.

не вижу причины как-то особенно выеживаться по поводу различия index out of range и buffer overflow

И не выеживайся - оставь это троллям. Будь конструктивным!

Да и вообще ты кто такой?

Вот.

Та не. Это ты у меня должен был спросить :)

Зачем? Со временем будет видно, кто ты и что ты.

Пишу на сях. Проблем нет. А этот высер гугола лучше не трогай даже палкой.