|
Top-level
 @drq Во-первых, мы не цапались. Во-вторых, мы говорим про engine, которой придется иметь дело со многими соединениями одновременно, поэтому как раз уместно выбирать из эрланга и го. Но в го нет нормальной многозадачности, и поэтому весь процес разработки на го упрется в войну с ситуациями «добавил 100500-ю подписку и все поломалось». Тут до бенчмарков именно производительности может вообще не дойти. А когда дойдет — окажется, что го и не быстрее на таких задачах. I’ve been there. 6 comments
@drq привет, попробуйте 100К горутин на распберри, потом поговорим снова. Там шедулер приколочен сбоку к изначально спроектированной кооперативной многозадачности. Вытесняющая работает только на стенде с сотней-тысячей горутин максимум, потом начинаются нежданчики.  @mudasobwa поинт понятный. Только из условий задачи я предположил, что 100K и не должно быть. Сколько подключений будет обсуживать такой инстанс? Как раз сотни максимум. А в этой ситуации гошечка всё равно будет жрать меньше памяти и проца. @SignPainter да пофиг сто раз на память и проц в этой задаче, Nerves https://nerves-project.org/ в холодильниках и чайниках работает без сучка и задоринки. А вот обслуживать каждое подключение синхронно — это очевидный архитектурный проёб. По-хорошему, придется на каждое подлючение держать пул воркеров для обслуживания «связей». Сиречь, O(N²), пардон. @mudasobwa да ну как это пофиг? :) @SignPainter 60 лет назад Кнут закрыл этот вопрос, казалось бы. Мне все равно, расходуется 0.1%, или целых 0.5% ресурсов. Так-то, чистый си будет еще эффективнее. Хаскель тоже. Тащить туда электрон — это лишнее, но говорить о преимуществах го перед nerves в данном контексте — смешно. |
Gregory's Server
@mudasobwa здрасьте. А как же goroutines?
@SignPainter