спасибо!

Прирост по сравнению с чем? Ну это же получается типичная модель системы массового обслуживания. Из очереди берется горутина и отправляется в свободную машину выполняться

По сравнению с обычными файберами, распределёнными по ядрам. Но на реальной задаче, а не на числодробилке.

В D "глобальные" переменные все thread-local, если корутина в другом потоке окажется, потеряет эти данные. А переносить их вместе с ней - слишком много мороки...

Но если умный диспетчер распределения между машинами возможен, то возможен такой же диспетчер, учитывающий перемещения TLS

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

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

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

Для ядра и его кэша нет разницы между TLS данными и прочими, например, кучей, насколько я понимаю.

Кстати, почему-то ПХП-шники очень Go любят я хз

Не правда, не все :)

Ievgenii ну может не все, но корреляция весьма высокая

Возможно

По-моему объяснение весьма простое - параллельная отложенная обработка задач это то с чем сталкивается любое веб-приложение при росте, пхп справляется с этим так себе, вот и ищут альтернативу с низким порогом входа

А мне го даже напоминает чем-то php времен версии 4.x

Имхо вообще никаких сходств

Там тоже не было никаких наворотов и убогая ООП модель :)

Все что хочешь писать - пиши ручками снова и снова. Язык маленький, учится легко.

Еще, кроме всего прочего, у меня есть предложение по перечеслениям, тем что enum. Но там очень много писать, и поэтому я скорее всего не напишу...

Тут такое дело, когда я что-нибудь придумываю, сразу же записываю, чтобы потом, когда будет время, можно было вспомнить и дальше развить мысль... Но про перечесления я записал только их ограничения, а то как хотел их расширить не записал. И немогу вспомнить... Вот все что есть https://pastebin.com/XP4PS5gi Видно что они хотели сделать перечесления, но так и не сделали, и кажется не очень торопятся. Ошибки в компиляторе тоже видно...

По-моему объяснение весьма простое - параллельная отложенная обработка задач это то с чем сталкивается любое веб-приложение при росте, пхп справляется с этим так себе, вот и ищут альтернативу с низким порогом входа

Чего? Рабит ставишь и пишешь небольшой демон или по крону каждую минуту проверяешь очередь (но это так себе решение)

Ну так да, пишется демон на go )

На пыхе тоже его легко писать)

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

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

Ну, я пых никогда не видал, но знаю что гдето-тма есть JIT на LLVM.

Не, там это пока только в планах

Было время, википедия "писала", мол прими участие в тестировании этого JIT, кажется это было давно.

видимо речь о HHVM шла

Нет, именно JIT на LLVM.

Да есть там вроде какие-то early реализации от Стогова, но это все глубоко в core team делается и не очень публично. Может к версии 8.0 или 9.0 и выкатят

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

В подавляющем большинстве случаев этого достаточно

Фейсбук что-то не сильно тупит, нет?

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

Конечно, есть места, где производительность нужна ну край как, но это не везде

А там где хайлоад и отложенные задачи - там сразу и go в преимуществе перед php

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

Да, но при этом даже не понимают, что это такое...

А там где хайлоад и отложенные задачи - там сразу и go в преимуществе перед php

Возможно, но скорость разработки и штат пхп-шников найти и быстрее и лешевле

Да и заменить кадры проще

Да тут кидали уже статью про то что "вы не google", она дельная. Ну что поделать в мире IT есть куча мифов и всяких местечковых верований, такова жизнь.

А там где хайлоад и отложенные задачи - там сразу и go в преимуществе перед php

Лично мы все это решаем на пыхе

И производительность нас устраивает

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

А найти +/- толкового пыховца и проще и дешевле. Не просто, а проще...

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

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

Я все время))))

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

Что-то проще решать на одном языке, что-то на другом.

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

Я вот все не найду время как следует засесть за Ди

Хотя очень хочу

Фейсбук что-то не сильно тупит, нет?

Так у фб не похапе давно. Сперва HHVM был, потом Hack...

И оно медленнее чем 7й пых

Э вы не путайте, я более чем уверен что хайлоад демоны у них на C++ написаны

Кстати, у меня ФБ дико всегда тупит с чего его не открывай. Понятно дело что там JS тормозит, но в целом он работает ужасно

Э вы не путайте, я более чем уверен что хайлоад демоны у них на C++ написаны

Я не о демонах

Ну мы же как раз о демонах говорим

Да, С++ там тоже хватает. Но большая часть их двухгиговой кодобазы - бывший РНР, теперь Hack. В любом случае скорость фб мало что говорит про РНР

Тогда актуальней рассматривать badoo - там все канонично :)

бэкенд разный на пхп, критичные скоростные сервисы на си и на go

так это ж, по поводу фэйсбука: http://forum.dlang.org/post/l37h5s$2gd8$1@digitalmars.com

Слишком расплывчато

Ну это 2013 год и вроде уже Александреску оттуда уволился.

Так что используют ли они сейчас - непонятно.

последний пост год назад: Spoke quite recently to a chap still there and he said yes, they are.

видимо, где-то что-то используют)

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

вот это фактически и имеется ввиду, думаю

ERROR: S client not available

а чего в линуксе гошного есть?)

ээээ мммм докер?

Нуили так: сейчас ничего нет, но через год понапишут

докер, все продукты от hashicorp, prometheus. Это сходу.

ну даже не знаю, восемь лет единственная система дома — кубунту, ниразу с го не сталкивался)

и, подозреваю, не скоро столкнусь)

Может и да, его основная ниша это серверные микросервисы

Но гуглом то ты пользуешься? Как минимум )

Пытаюсь собрать пример на vibe.d. Линкер сыплет:

Linking... /usr/bin/ld: cannot find -levent /usr/bin/ld: cannot find -levent_pthreads collect2: error: ld returned 1 exit status

Он свой libevent не может найти или какой-то другой?

На винде собирается нормально.

Весь лог: (dmd-2.074.1)user@twilight:~/imghosting/imghosting# dub build --build=release WARNING: A deprecated branch based version specification is used for the dependency libevent. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Selected package libevent 2.0.2+2.0.16 does not match the dependency specification ~master in package imagehosting. Need to "dub upgrade"? Performing "release" build using dmd for x86. vibe-d:utils 0.7.31: target for configuration "library" is up to date. vibe-d:data 0.7.31: target for configuration "library" is up to date. vibe-d:core 0.7.31: target for configuration "libevent" is up to date. diet-ng 1.2.1: target for configuration "library" is up to date. vibe-d:http 0.7.31: target for configuration "library" is up to date. vibe-d:diet 0.7.31: target for configuration "library" is up to date. vibe-d:mail 0.7.31: target for configuration "library" is up to date. vibe-d:mongodb 0.7.31: target for configuration "library" is up to date. vibe-d:redis 0.7.31: target for configuration "library" is up to date. vibe-d:web 0.7.31: target for configuration "library" is up to date. vibe-d 0.7.31: target for configuration "libevent" is up to date. imagehosting ~master: building configuration "application"... ../../.dub/packages/vibe-d-0.7.31/vibe-d/source/vibe/http/server.d(286,33): Deprecation: alias diet.traits.FilterCallback is deprecated - Use SafeFilterCallback instead. Compiling Diet HTML template login.dt... Compiling Diet HTML template upload_form.dt... Compiling Diet HTML template gallery.dt... Linking... /usr/bin/ld: cannot find -levent /usr/bin/ld: cannot find -levent_pthreads collect2: error: ld returned 1 exit status Error: linker exited with status 1 dmd failed with exit code 1.

А, вкурил.

Накатил libevent

=)

Ага, именно. Но ты спрашивай если что.

При всем моем уважении к vibe.d, он хреново сделан. Течёт он знатно...

Нунинаю, у меня один сервис на нем месяцами без перезагрузки живет и меньше 40 МБ занимает.

2D box blur без циклов :)

При всем моем уважении к vibe.d, он хреново сделан. Течёт он знатно...

есть hunt и cgi_d

У тебя нет на него нагрузки

Дай на него ab -n 1000000 -c 1000 -t

И посмотри на память

Можешь даже повторить потом

Ещё вырастет

есть hunt и cgi_d

Да, но времени нет :(

http://www.opennet.ru/opennews/art.shtml?num=46739

Там какое-то коммит какой-то огромный на это был. Вроде бы даже сотни тысяч строк

Слили ветку в один коммит, небось