а можно подробнее? вот например ситуация: есть сервер А, он «мастер», допустим, его сторадж успевает k транзакций на запись в минуту. далее мы добавляем в кластер сервер Б, он тоже «мастер», сторадж у него аналогичный, и нагрузку мы на него даём аналогичную. далее мы наблюдаем падение производительности локальных транзакций на сервере А до ~k/2 (производительность осталась прежней, просто добавилась нагрузка с реплики). это уже масштабирование или нет? я понимаю как master-master помогал в старых версиях mysql (там всё в процессор упиралось), но postgres уже 10 лет назад точно масштабировался на любое количество ядер CPU, так что к нему это не относится.
это почему вдруг? в момент перехода с него на нативный компилер была сильная регрессия по производительности, другой вопрос что проблем с ним много (так говорят, сам не пробовал), да и переносимость сильно страдает
Автор — молодец, нашёл ошибку там, где другие и не заметили. Даже и с учётом того, что Rust — всё ещё язык экзотический и хорошо разбирались в нём из 45 тыс. просмотревших 45 в лучшем случае. И тем не менее сенсации не получилось:
Голый net/http не используется в highload проектах на golang
Этот тезис я писать не буду, а то ребята из Mail.ru обидятся :-D
Включал эту штуку на Intel HSW — работало великолепно, butter-smooth, как охарактеризовал phoronix. В amdgpu, к сожалению, поддержки не завезли, и в этом году скорее всего уже не будет.
Да, они на Go, да «проекты большие», но если вы таки посмотрите на исходный код, то увидите, что 2 из 3 ваших примеров состоят из 10(!)+ небольших сервисов и клиентов к ним, хотя можно было обойтись и 2-мя. Concource — да, состоит из «всего» 4-х кусков, но это никак не опровергает мой тезис «Go хорош для небольших демонов».
Да к примеру простое суммирование превращается в ад. Аж 40 строк. Нафига спрашивается?
автор того сниппета с сайта dlang очевидно болен, не думаю, что здесь есть что обсуждать
Сейчас время BigData и очень часто на сервере нужно что-то посчитать и обработать прежде чем отдать
вот в этом гошечке просто нет равных ибо идеоматичный код:
1. автоматически масштабируется на любое количество доступных ядер (будь их хоть 2, хоть 64)
2. практически не блокируется
3. в принципе быстро работает: даже при одном потоке Go, в среднем, быстрее Java и NodeJS (популярный нынче выбор для бэкендов) и во много раз (до 10) быстрее Python3.
4. имеет небольшое и прогнозируемое потребление памяти
моё мнение такое: Go — язык нишевой, он хорош для создания небольших сервисов (демонов), ориентированных на работу с сетью (в. т.ч. и веб-приложений) и консольных клиентов к ним (или просто утилит). и в этой нише он «лучший» (да, я гофер, да я уже пробовал php, python, ruby и даже perl). в «треугольнике винда-линукс-андроид» лучше D (если вы уверены, что D — некстген C++, я, например, не уверен, и брал бы плюсы, при всех их минусах)
а можно поподробнее почитать про алгоритм? хочу, например, стать рекомендуемым для некоторых вакансий
это почему вдруг? в момент перехода с него на нативный компилер была сильная регрессия по производительности, другой вопрос что проблем с ним много (так говорят, сам не пробовал), да и переносимость сильно страдает
после висяка есть что-то подозрительное?
и подчеркнул то, в чём Go, на мой взгляд, хорош
недавно здесь на Хабре была статья про веб-приложение, кажется, на asm, но «можно» != «хорош в чём-то»
автор того сниппета с сайта dlang очевидно болен, не думаю, что здесь есть что обсуждать
вот в этом гошечке просто нет равных ибо идеоматичный код:
1. автоматически масштабируется на любое количество доступных ядер (будь их хоть 2, хоть 64)
2. практически не блокируется
3. в принципе быстро работает: даже при одном потоке Go, в среднем, быстрее Java и NodeJS (популярный нынче выбор для бэкендов) и во много раз (до 10) быстрее Python3.
4. имеет небольшое и прогнозируемое потребление памяти
а можно примеры, пожалуйста, не могу представить такие данные, что не обработать в Go
так сейчас время такое и большинство бизнес-процессов вокруг этого построено, разве нет?